calico-kube-contorollersが0/1 Runningで止まる

スポンサーリンク

はじめに

AWS上に作ったkubernetes環境ですが、いつもはEC2インスタンスを止めて余計な料金が発生しないようにしてました。使いたいときだけEC2起動させればkubernetesが使える環境にしていたのです。

ただいつの頃からかEC2インスタンスを起動しても↓のようになってしまいkubernetesの環境が復旧しませんでしたorz

そもそもkubernetesをhardwayで作らない限り遭遇しない事象だとは思いますが一応の原因と事象の解消が出来たので書き残しておきます。

知識ないのにhardwayなんかに手を出すからこうなるorz

ちなみにkubernetesのversionは1.15.1で確認してます。

事象発生時のlog

事象発生時に取得したものです↓

corednsのCompletedはcalico-kube-contorollersのReadiness Probeが失敗しているのが原因だと思ったので一旦保留。

kubectl logs -n kube-system calico-kube-controllers-5fb6b5764b-smxcbの抜粋

dial tcp 10.32.0.1:443: i/o timeoutってkube-apiserverと通信できていない?

kubectl get events --sort-by=.metadata.creationTimestamp --all-namespaces | grep calico-kube-controllersの抜粋

Readiness probe failed: Error reaching apiserver: taking a long time to check apiserverってことはapiserverとの通信に時間が掛かりすぎててReadiness probeが失敗しているらしい。ぐぬぬ。

どうもkube-proxyが怪しい

色々手探りで調べてみるとkube-proxyをDaemonSetにした辺りから挙動がおかしくなっているようでした。実際kube-proxyをDaemonSetからsystemdに戻すと事象が解決します。

これやってからダメになったのかorz

そこでkube-proxyがDaemonSetなときとsystemdでの違いを探してみました。

色々調べて引っかかったのはnetstat -anpでの接続情報。成功時と失敗時でそれぞれ取得してみました。

kube-proxyがsystemdの場合(成功)

※見やすいようにタグだけ追加

10.63.0.11:6443でESTABLISHEDしてるのがわかります。

kube-proxyがdaemonsetの場合(失敗)

※見やすいようにタグだけ追加

Foreign Addressが10.32.0.1:443になっていてSYN_SENTの状態。

Foreign Addressが違う・・・

おそらくcalico-kube-controllersからmasterにいるkube-apiserverへの通信がうまくいっていない。原因はkube-proxyだろうと思う。

kube-proxyのmanifestを修正する

色々ググった結果、KUBERNETES_SERVICE_HOSTとKUBERNETES_SERVICE_PORTを設定することで対処できるんじゃないかと祈りながら設定。

古いの消してからこれをkubectl apply -f すると

Foreign Addressが10.63.0.11:6443でESTABLISHEDになってます。

calico-kube-controllersのpodを確認すると

ということで各nodeを再起動してもkubernetesは復旧するようになりました。

原因がわからない

kube-proxyがsystemdのとき、envにKUBERNETES_SERVICE_HOSTもKUBERNETES_SERVICE_PORTも設定してないんですよね・・・。setにもない。

ちなみにkube-proxyに先ほどのenv設定あるなしは当然差分が出てくれる。

・manifestにenv設定なし

・manifestにenv設定あり

参考サイト

KUBERNETES_SERVICE_HOSTの存在を知ったサイト

KUBERNETES_SERVICE_HOSTだけでは動かずKUBERNETES_SERVICE_PORTの存在を知ったサイト

最後に

色々試して解決!!(謎は残ったけどorz)

ちなみにcalico-kube-controllersをmaster1のnodeに作成されるようにしてもダメでした。master1にあるcalico-kube-controllersからならmaster1にあるkube-apiserverに通信できるかなーと思ったけどkube-proxyがダメだと無理なんですね。kube-proxyの大切さを痛感しました。iptables全然わからないのがつらい。

関連コンテンツ



シェアする

  • このエントリーをはてなブックマークに追加

フォローする