橋本修太です。

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

現象

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なのがあった・・・