橋本修太です。

例によって例のごとく、よくわからないけど動かなくなって、よくわからないままに手探りで解決したので、覚書を残させて頂きます。

現象

kubectlでdeploymentのyamlをapplyしても、DESIREDからCURRENTに移行しなくなった

要するに、新しいpod（Dockerで言うところのコンテナ）が動かなくなった、という事です。

原因

不明

直前に、nginx-ingress入れたりしていたんですけど、それでしょうか・・・・

解決方法

crictlで、Exitedなkube-controller-manager-****を削除したら、動き出しました。

手順

現象発生時、何かを調べたとは思うのですが、忘れてしまいました・・・とりあえずKubernetesを再起動させました。

NODEの削除（masterでの作業）

$ kubectl drain <node name> –delete-local-data –force –ignore-daemonsets
$ kubectl delete node <node name>

NODEの再起動（master含む各NODEでの作業）

$ kubeadm reset

$ reboot

いつもこの方法なんですけど、これでいいんでしょうか？

そして、いつもどおり起動していきます。

master起動

kubeadm init –cri-socket=/var/run/crio/crio.sock –pod-network-cidr=10.244.0.0/16

cp -i /etc/kubernetes/admin.conf ~/.kube/config

kubectl apply -f ./kube-flannel.yml

最後の、flannelのymlは、githubから落としてきたものです。詳細はGeeko Magazineをご覧ください。ただ、README.mdに書いてある、以下のコマンドでも正しく動きそうですね。flannelかな？と思って、こちらで試してみたのですが、動作は同じようでした。masterなので、いつどういう動作をするかは、保証されないのでしょうが・・・

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

そして、同じ現象に出くわします。nodeの状態を以下のコマンドで確認するのですが、

kubectl get nodes

ずっと、STATUSはNotReadyのまま。

kube-system（というnamespaceで配置される、システム系のpod）を確認します。

kubectl get pods –all-namespace

すると、kube-controller-manager-****（****は、マスターのマシン名）のSTATUSが、CreateContainerErrorとなったまま。

ふーむ・・・ここでグーグル先生に泣き付く事小一時間。こんな感じで辿りました。

ログ確認

journalctl

Kubicは、Kubernetes関係のログはほぼここに入っています。いるはずです。いると思っています。

すると、こんな感じのログが立て続けに出力されていました。

pod_workers.go:190] Error syncing pod
****************** (“kube-controller-manager-linux-riis_kube-system(*********************)”), skipping: failed to “StartContainer” for “kube-controller-manager” with CreateContainerError: “the
container name \”k8s_kube-controller-manager_kube-controller-manager-linux-riis_kube-system_********************_**\” is already in use by \”************************************
\”. You have to remove that container to be able to reuse that name.: that name is already in use”

******はマスクです。ランダム英数字が入っています。また、linux-riisが、masterのマシン名です。

podのログも確認してみましたが、同じようなログが出力されていました。（はずです・・・もしかしたら、コンテナを生成できなかった、程度だったかもしれません・・・）

kubectl logs pods/kube-controller-manager-****（マシン名） -n kube-system

-nオプションで、namespaceを指定しないと、見つからないと言われるので注意です。

ふむふむ、どうも、IDだかがかぶってしまって、新しいkube-controller-managerを起動できないようです。

ここでイメージとコンテナの確認です。Kubicはcri-oを使っているため、コンテナ関連のコマンドはcrictl、サービスはcrioになります。crictlのホームページはこちら。Dockerと似たような感じで使えるのではないでしょうか。ちなみに、このコマンドが入っているパッケージはcri-toolsです。

サービスステータスをチェックします。

systemctl status crio

CNIのデフォルトネットワークが見つからないよ、というエラーが見えますが、flannelを適応すれば直るでしょう・・・直ると信じたいです。（事実、直りました。）

では、コンテナの確認です。

crictl ps -a

すると、Runningとなっているものと、Exitedとなっているもの、２つのkube-controller-manager-****が。その他にも、kube-apiserver-****や、kube-scheduler-****も同じように、二種類。

Exitedとなっているものは不要なので（不要で終了したのでExitedなはずなので）、削除しましょう。

crictl rm ****（コンテナIDです。先のcrictl ps時に表示されます。）

そして、システム系のpodを確認。

kubectl get pods –all-namespaces

すると、なんと、kube-controller-manager-****が、Runningに変わっているではありませんか！

ただ、ちょっと待ってkubectl get nodesしても、NotReadyだったので、同じくExitedだった、kube-apiserver-****と、kube-scheduler-*****のコンテナも、削除しました。

そして待っていると・・・・無事、masterがReadyになりました。

後は、ワーカーNodeのkubeadm joinもすんなり動き、正常稼働に戻りました。

課題＆感想

• 情報収集の方法をもっと知りたい
• crictl知ったのは良かった
• Kubicの再インストールを考えたけど、粘ってみてよかった。（いつもこうとは限らない）
• 正常時のログとかを認識していないと、異常時にあたりを付けにくい
• ingressは、Kubic用があるっぽい
• 今見てみたら、kube-schedulerとか、Exitedなのがあった・・・

openSUSE Advent Calendar ももう17日目ですね

今日はこの blog が動いている geeko.jp のサーバーのメンテナンスの話です。このサーバーは ConoHa で動いており、13.1, 42.3 とアップデートをしてきました。今回は42.3 から 15.0 にアップデートしました。

アップデート方法

いつもオンラインでアップデートしています。クラウドの場合、ディスクイメージをダウンロードして、ConoHa にアップロードし、インストーラを起動してアップデートはちょっと大変です。オンラインアップデートであればリポジトリの URL を書き換えて zypper dup するだけなので簡単です。

リポジトリのURLを書き換える方法はいくつかありますが、YaST のリポジトリ設定からバージョンの部分を書き換えるのがオススメです。

zypper dup --download-only
zypper dup

ディスク容量には余裕があるので、一度ダウンロードが完了するのを待ってから、アップデートを適用しました。

MySQL から MariaDB へ

15.0 には、これまで提供されてきた mysql-community-server のパッケージがなく、完全に Maria DB に置き換えられています。やったことは以下の3つです。

1. mariadb のパッケージをインストールする
2. 設定ファイルを更新する
3. systemctl で mariadb を自動起動するようにする

設定ファイルは、新しい設定ファイルをそのまま使いました。一応、これまでのファイルと新しい設定ファイル /etc/my.conf.rpmnew を比較したところ、内容はかなり増えていますが、コメントアウトされた部分以外はほとんど同じでした。

+bind-address = 127.0.0.1
+log-error = /var/log/mysql/mysqld.log
+secure_file_priv = /var/lib/mysql-files
-sql_mode=''
+sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

SuSE Firewall2 から Firewalld へ

Leap 15.0からCentOSなどでお馴染みの firewalld が使えるようになりました。これまでのSuSE Firewall2 も引き続き使うことができます。移行する場合は手動で SuSEfirewall2 パッケージを削除して、firewalld をインストールする必要があります。

Firewalld では次のように使用したいサービスのポートを開けられます。

firewall-cmd --permanent --add-service https
firewall-cmd --reload

Let’s Encrypt で TLS に対応

アップデートしたついでに、Webサーバーを TLS に対応させました。証明書は無償の Let’s Encrypt で取得しました。

Let’s Encrypt の certbot コマンドを使えば、証明書の取得から Apache の設定まで1コマンドです。このあたりの細かい話は Geeko Magazine SP 2018冬号に書いていますので、ぜひ読んでみて下さい。

変わらなかったもの: PHP とPerlアプリケーション

geeko.jp で動いていた WordPress や Vanilla Forum、Pukiwiki はそのまま動きました。このあたりは 13.1 からのアップデートと比べると、とても楽でした。

おわりに

ということで、大したことではありませんが、geeko.jp のサーバーをアップデートしたときの話を書いてみました。42.3のサポート期間はあと半年くらいですので、これから 15.0 にアップデートする方は参考にしてみて下さい。

明日は鹿さんが USB オーディオの話の続きを書いてくれるそうです。

 

 

 

この記事は、「openSUSE AdventCalendar 2018」16日目の記事です。

皆さんおはようございます。橋本修太です。

さて、先日jaのMLにこんな投稿がありました。

【意訳】

openSUSE(Kubic)でCloud Foundry動かしたことある人います？

Kubicのキーワードが目に止まり、はて、Cloud Foundryとは？と思った私は、調査してみました。

本記事は情報収集のみとなります。「やってみた」は次の機会になりますこと、ご了承ください。

Cloud Foundryとは

ホームページはこちら。概要を纏めてくださっているページが幾つか有りますので、それらを見ていきますと、どうやら、webアプリケーションのソースコードをpushするだけで、ビルド・デプロイを自動で行ってくれる、オープンソースのソリューションの模様（商用版もあり）。イメージとしてはherokuに近いですね（こんな記事もありました）。

「アメリカのFortune 500企業のうち約半数が導入済み」といった謳い文句も見られますね。

インストール方法

いくつかあるようです。Cloud Foundry自体、複数のコンポーネントで構成されるソリューションなので、手順があったり、インストールを支援してくれるソリューションがあったりします。

また、Pivotal、SUSEなどがチューニングしたソリューションもあって、それぞれ強みがあるようです。

ちなみに、Cloud Foundryとやりとりを行うコマンドラインツール群、cf-cliは、openSUSEにパッケージがありました。（動くかな？）

A. PCF-DEVをインストール

PCFとは、Pivotal Cloud Foundryの略です。Pivotalはクラウドで有名な会社のようです。

ここが展開している、ローカル開発用のCloud Foundry、PCF-DEVが、インストールしてみるには丁度良いよ、という投稿もstack overflowで見たりしました。

構成としては、Linux（私の場合openSUSE）の上に、VirtualBoxを動かし、その中でPCFを動かすようです。

インストール方法はこちら。

B. BOSHでインストール

BOSHは、Cloud Foundryの導入・運用を制御するソリューションのようです。

単一マシンに展開したり、クラスタ構成に展開したりもできるようです。

通常、Cloud Foundryをインストールと言えば、この方法が正攻法？なのかもしれません。

C. SUSE Cloud Foundryをインストール（on Vagrant）

SUSEも、Cloud Foundryには力を入れていて、チューニングしたソリューションを持っていました。

githubはこちら。

主なチューニング点として、以下が挙げられていました。

• Kubernetes（Docker）の上で動くように、Cloud Foundryのコンポーネントのコンテナライズにfissileを使っている
• Cloud FoundryのコンポーネントはopenSUSE Steamcellで動く
• オプションとして、Cloud FoundryのAppをopenSUSE stackのpreviewで動かす事が出来る

Steamcellだの、stackだの、previewだの、ちょっとピントこない単語が沢山・・・これらはおいおい調べていく事にしまして、1番目に付いて、もともとCloud FoundryはKubernetesの上で動くようには作られていなかったのですが、そこをSUSE等が開発したとの事です。

件のgithubには、on Kubernetesで動かす方法も記載されているのですが、ここではPCF-DEVと同じように、VMの上で動かす方法を。

Disclaimerに、「openSUSE 42.xは、libvirtでテストしてますよ」とあります。ここが42.xになっているのが、ちょっと気になるところですが・・・（あと、SUSEのgithubなのに、openSUSEがOpenSUSEになっている所とか）

あとは、Deploying SCF on Vagrantのセクション通りにやっていけばよさそうです。

ただ、要件にいきなり「メモリは16G以上は用意してね」とあって、私のデスクトップはもう無理状態です。

D. SUSE Cloud Foundryをインストール（on Kubernetes）

C.で触れましたが、Kubernetesの上にインストールできるのが、SCFの強みとの事。Helmでインストールするようですね。インストールページには要件等書いてありますので、適応させて行けば動くでしょうか？

ちなみに、環境チェック用スクリプトがあるのですが、Kubic上で走らせた所、半分ぐらいerrorとなってしまいました。

課題＆感想

• やってみる！
• もう少し、正確かつ精密な情報を収集し、記事にする

駆け足で情報収集だけしたのですが、結構複雑な構成をしていて、ちゃんと理解しようとするとそれなりのボリュームになりそうです。使う側は、ソースコードをcf pushすれば、デプロイまで完了、とやりやすい事この上無いですね。

では、16Gメモリを積んでいるノートPCがあるので、近いうちにやってみたをやってみたいと思います。

明日は @ftake さんの、geeko.jpをメンテナンスした話ですね。塩漬けに近かったサイトですので、色々と面白い話題が出てきそうです。こうご期待。

 

 

 

 

2017-10-21の、openSUSE.Asia Sumut 2017 で、「Zeroconf as simple name resolution for LAN」というタイトルで15分の発表を行いました。英語での発表ではなく、日本語での発表でしたけれど。
最初に日本語の資料を作っておいて、そこから英語に翻訳していったのですが、英語に自信が無いので、英語での発表を何回もしている人に添削をお願いしました。原形をとどめないくらいあちこち直されました。やはり、中学英語レベルで英語プレゼン資料を作るのは難があったみたいです…..
ともあれ、171021-en-opensuse-ribbon に発表資料を置きましたので、ご興味がある方はご覧ください。

2017-08-13 の IRC定例で話題になった Proxmox-VE について、簡単にメモしておきます。

Proxmox-VE の一次情報は、 https://pve.proxmox.com/wiki/Main_Page  です。

Proxmox-VE はVMware ESXiに似た、仮想化アプライアンスで、Webベースで仮想マシンの制御や、LXCベースのコンテナの制御を行えます。オープンソース版と商用版がありますが、kernelがエンタープライズ版か否かくらいの違いしかありません。
ベースは、Debianで、その上にPerlで書かれたVM管理用ツールがインストールされています。ISOイメージからインストールすると、ターンキー仮想ホストとして、ディスクの初期化からパーティションの作成まで一気にやってしまいます。

LVMベースのディスク管理を使用しています。各仮想マシンはLVMのシンプロビジョニングか、通常のファイルで保持されます。スナップショットを使ったバックアップ機能もあります。

openSUSEの検証などにはよく使っています。ほぼすべてメッセージが日本語化されていますので、わかりやすいと思います。ESXiと違ってDebian 9 が動くマシンであればそのまま使えます。お手軽な仮想環境制御ツールをお探しの方は、一度試してみてはいかがでしょうか。

 

2017年1月15日の記事で、firstboot的な機能をautoyastに埋め込む例を紹介しました。しかし、当該記事では、うまくいかない場合があることが分かりました。記事中では

<scripts>
<post-scripts config:type=”list”>
<script>

と言う記載がありましたが、ここが問題でした。

実は、autoyastで、設定後、各種スクリプトを動かすための設定方法は
マニュアルにきちんと書いてあります。<scripts>の次のタグの記述で、どのタイミングでスクリプトを動かすかを決められるのです。そして、<post-scripts>の場合には、再起動後YaSTが各種設定をしている中でスクリプトを動かします。これがどういう問題を引き起こすかというと、スクリプトの中にzypperコマンドでリポジトリを設定しようとするときに、ファイル競合を起こして設定が出来ないという問題が発生してしまうのです。

そこで、<init-scripts>に切り換えて、各種daemon等が起動したあとに、スクリプトを実行するようにします。そうすることで、zypper コマンドが正しく動くようになりました。

google での検索では、当該マニュアルまでうまくたどり着けなかったのですが、/usr/share/doc/packages/autoyast2/ 配下にマニュアルがあり、そこを参照することで原因と対策が分かりました。やはり、マニュアルは読むものですね。

 

下記の記事に対する更新情報があります。こちらを参照してください。

firstboot 機能はautoyastにも組み込めます。しかし、firstbootの解説の所にはあっさりとしか書いてないので、いろいろやってみましたがうまくいきませんでした。しかし、autoyastの設定の中から代替の方法を見つけました。
以下のようにautoinnst.xml に記述を追加すると、再起動後の初期設定中にスクリプトを動かす事が出来ます。

  <scripts>
<post-scripts config:type=”list”>
<script>
<debug config:type=”boolean”>true</debug>
<feedback config:type=”boolean”>false</feedback>
<feedback_type/>
<filename>demo.sh</filename>
<interpreter>shell</interpreter>
<location><![CDATA[]]></location>
<network_needed config:type=”boolean”>false</network_needed>
<notification>demo</notification>
<param-list config:type=”list”/>
<source><![CDATA[#! /bin/sh
touch /root/testend
sleep 50

]]></source>
</script>
</post-scripts>
</scripts>

この設定は autoinst機能を追加したYaSTでも設定出来ます。やってみましょう。

まずYaSTを起動し、「その他」→「独自のスクリプト」を選択し、編集画面に移ります。

新規作成を選び、スクリプト名(ファイル名)を入力し、スクリプトの実体を、「スクリプトソース」に記入します。これで、autoyastが生成するautoinstファイルにスクリプトが組み込まれます。

さらに、生成されたautoinstスクリプトを適宜編集し、自動実行を行わせるサーバに組み込みます。その後、ネットワーク越しに自動インストールが行われ、再起動後に、先ほど設定したスクリプトが動作します。「demo」というタイトルが表示されています。

実行後、ログインしてみると、ちゃんとファイルが出来ています。