Kubernatesデプロイでハマった！
Kubernates(k8s)に入門してみようということで、Oracle Cloud上のAlwaysFreeリソースにある監視基盤をk8sの上に載せようと思い立ち、今ある監視基盤を破壊し、VMを分けてkubeadmで順調にインストールして1,2日で復旧できるだろ…と思っていた時期が私にもありました。
日本語の公式ドキュメントは見ない
kubernatesの公式ドキュメントには様々な言語の種類があるようですが、少なくとも日本語のドキュメントは英語版最新バージョンに沿った翻訳はされておらず、ところどころ古い内容があるので、基本的に英語版を参照するようにしたほうがいいかと思います
デプロイ時に参照するドキュメント
ここでのデプロイとは、Ubuntu22.04上でのkubeadmを用いた典型的なk8sクラスターのデプロイです
- kubeadmやその他ツールのインストール : Installing kubeadm
- containerdのインストール時のレポジトリ情報(Dockerのレポジトリを入れるのでDockerのサイトです) : Install Docker Engine on Ubuntu
- 諸々のホストOSの設定(地味に重要。必ずすべて読む) : Container Runtimes
- クラスタの作成 : Creating a cluster with kubeadm
(もう少し一つにまとめてくれないかな〜)
なぜかデプロイできなかった
kube-apiserverポッドが何故か再起動しまくり(CrashLoopBackoff状態)、その他podもCrashLoopBackoff状態になりました
kube-apiserverがないともちろんクラスター間などもできないのでエラー出まくりでkubectl等の各ツールもConnection refusedで使えない状態になってしまうといった状況でした
結果としてこれの原因はContainerdの設定ミス(設定無しで行けると思っていた)でした。上記にもあるContainer Runtimesに書いてあるCgroup driversの設定を関係ないものだと思い、していませんでした
どうやら/etc/containerd/config.tomlを色々いじる必要があるそうです。aptでcontainerd.ioを取得すると、初期コンフィグは色々省略されているみたいなので下記コマンドでcontainerdのデフォルトコンフィグに書き換えます
containerd config default | sudo tee /etc/containerd/config.toml
その後に、再度コンフィグを開いて SystemdCgroup = Falseと書いてある所をTrueに置き換え、containerdデーモンを再起動します
これで自分は解決しました(ドキュメントに書いてあることです…自分はRadditのスレッドでここをいじらないといけないことを知りました)
kube-apiserverが使えないときのデバッグ
kube-apiserverがCrashBackLoopoff状態に陥っているときは、kubectlなんてもちろん使えません。なのでpodのログを見ることすら困難に陥ります
その状態の場合はコンテナ内のログを収集することで最低限何もログが取得できないということを回避できます
Containerdの場合は以下のコマンドでコンテナのリストが取得できますので、あとはDockerコマンドと同じ要領でcrictl logs ${CONTAINER_ID}を実行することでコンテナ内で発生したログをkube-apiserverなしで取得できます
sudo crictl --runtime-endpoint unix:///var/run/containerd/containerd.sock ps -a
