「SEROKU フリーランス(以下、SEROKU)」の中の人をやっている kouki です。
Rancher 2.0 にアップデートしてから最近は社内 k8s 環境も安定して動作しています。(たまに開発が活発になって過負荷が発生したりしていますが)
今回は前回の社内Kubernetesトラブルシュート-前編と比べるとシンプルなトラブルだったため、あまり記事としてのボリュームはありません。
発生したトラブル
Rancher 2.0 を使ってクラスタを構築する際に Node を誤って設定してしまい、一度クラスタから外して、再度クラスタに追加するという作業を行いました。
その際に、 etcd による設定の同期が走りますが、この時に「request cluster ID mismatch」といったログが延々と出力され、 Node がクラスタに追加されない、という事象が発生しました。
トラブルシューティング
「request cluster ID mismatch」という文字列と、 Node を再追加したときの挙動から原因追及のヒントにし、「これは一度追加した Node に何かしらの情報がストア(or キャッシュ)されているままで、最新の状態に更新されていないのではないか？」というところから当たりをつけました。
また、昨今の OSS の慣習から「/var/lib/ や /opt/、 /etc/ ディレクトリなどに独自の設定ファイルなどを格納する慣習にしているだろう」ということもヒントに含めました。
RancherOS が動作しているサーバに SSH ログインし、上記のディレクトリを探っていくと、様々なディレクトリに「それっぽい」情報が格納されていることが分かりました
/opt/rke の tree 一覧
/opt/rke$ tree
.
|-- etc
| |-- ceph
| `-- kubernetes
| |-- cloud-config
| `-- ssl
| |-- certs
| | `-- serverca
| |-- kube-ca.pem
| |-- kube-node-key.pem
| |-- kube-node.pem
| |-- kube-proxy-key.pem
| |-- kube-proxy.pem
| |-- kubecfg-kube-node.yaml
| `-- kubecfg-kube-proxy.yaml
`-- var
|-- lib
| |-- cni
| | `-- networks
| | `-- k8s-pod-network
| | `-- last_reserved_ip.0
| |-- etcd
| | `-- member
| |-- kubelet
| | |-- cpu_manager_state
| | |-- plugin-containers
| | |-- plugins
| | `-- pods
| `-- rancher
| `-- rke
| `-- log
.../var/lib/rancher の tree 一覧
/var/lib/rancher$ tree
.
|-- cache
|-- conf
|-- engine
| |-- docker
| |-- docker-containerd
| |-- docker-containerd-ctr
| |-- docker-containerd-shim
| |-- docker-init
| |-- docker-proxy
| |-- docker-runc
| `-- dockerd
|-- etc
|-- preload
| |-- docker
| `-- system-docker
|-- state
| `-- cni
`-- volumes/etc/kubernetes の tree 一覧
/etc/kubernetes$ tree
.
|-- cloud-config
`-- ssl
|-- certs
| `-- serverca
|-- kube-ca.pem
|-- kube-node-key.pem
|-- kube-node.pem
|-- kube-proxy-key.pem
|-- kube-proxy.pem
|-- kubecfg-kube-node.yaml
`-- kubecfg-kube-proxy.yaml「/opt/rke/var/lib/etcd/member というディレクトリが恐らく過去に追加された情報を持っているだろう」と予測を立て、このディレクトリを削除して再度 Node の追加を行ったところ、正常に Node が動作するようになりました。
予想通り etcd の過去の情報がストアされていることが原因でした。
また、 /opt/rke/etc/kubernetes や /etc/kubernetes ディレクトリ以下には証明書関係が書き込まれているため、こちらも念のためクリアはしておいた方がよかったかもしれません。
まとめ
昨今ではいわゆる「デファクトスタンダート」なディレクトリ構成を取る OSS が増え始めていて、トラブルシューティングをする際にもディレクトリを探し回るということが無くなってきました。
そのため、今回のような単純なトラブルの場合には即座に対応することができました。
調査した時期は Rancher 2.0 がリリースされて間もなく、ドキュメントが公開されていなかったため、本記事のような場当たり的な対応が必要でした。
2018/09/10 現在では Rancher 2.0 のドキュメントも整備され始め、「Cleaning cluster nodes | Rancher Labs」という便利なドキュメントが公開されています。
公式からこういった情報の提供を待つことも手段の一つですが、OSS への貢献を積極的に行うには先述したような泥臭い対応をしながら協力して問題を報告していく姿勢が大切だと思います。
今後もエッジの効いた技術を採用しつつ、安定運用を目指していけたら、と心がけていきたいところです。
関連記事
KubernetesをRancher 1.6から2.0 へアップデートした話
DockerfileとKubernetesHelmChartを入れる
