障害調査の仕方
Kubernetes、あるいはコンテナを利用してサービスを本番運用している時と物理／仮想マシンで運用している時では障害調査方法がかなり違ってきます。
ここでは障害調査の導入として、kubectlを使った調査方法を簡単に説明していきます。
Podが起動していない！ まずは何をすれば良い？
kubectl get podでPodのステータスを確認すると、Runningになっていない。こんなときどうするのか、いくつか方法を紹介します。
Podの詳細を見る
kubectl describe pod
まずはPodの詳細をみてみましょう。出力結果の下部にある「Events」に動作していない理由が書かれていることがあります。コンテナイメージのタグを間違えた、のようなケースでは「指定されたイメージが無い」のように書かれていることがあります。
ログを参照する
kubectl logs
前節のログで説明した通り、Kubernetes標準のログ収集機能を利用してログを参照することができます。kubectl logsを利用することでPodのログを参照することができます。Deploymentなどを利用して複数Podを起動した場合、kubectl logs -l name=myLabelのように、ラベルで複数のPodを指定した方が便利なこともあるでしょう。
コンテナ内でshellを実行する
kubectl exec-c -- /bin/sh
コンテナ内に入って調査したい、そんなときに使えるコマンドです。コンテナにログインしてshellを起動するため、そもそもコンテナにshellが入っていない場合は利用できません。そのような環境で調査するためには、次の説明に進んでください。
コンテナにログインしてもデバッグ用ツールが何も入っていない！
コンテナは起動を早く、そして脆弱性を減らすために、余計なものを入れない方が良いとされています。その結果、いざ障害発生時にコンテナにログインして調査しよう！ と思っても、これまで障害調査時に利用しているあらゆるコマンドが入っていない、というケースが多く出てくることでしょう。
そんなときには以下の方法を試してみてください。
デバッグ用コンテナを起動する
Kubernetes v1.23からbetaになった機能です。
kubectl debug -it--image=busybox --target=
デバッグしたいPod名とコンテナ名を指定し、デバッグ用コンテナを立ち上げます。ここではBusyBoxコンテナイメージを指定していますが、他のコンテナイメージを指定することも可能です。
詳しくは公式ドキュメントを参照してください。
デバッグ用Podを立ち上げる
kubectl debugを利用できないバージョンのKubernetesを利用しているような環境ではデバッグ用のPodを立ち上げる方法があります。
以下のコマンドを利用すると、デバッグ用のPodを立ち上げることができます。
kubectl run busybox –image=busybox:1.28 –rm -it –restart=Never /bin/sh
ただしこの方法ではあくまで別Podを利用するため、直接デバッグしたいPodのファイルを参照するなどといった操作はできません。エンドポイントをcurlで叩いてみたり、pingコマンドで疎通を確認したりといった用途に有用です。
ここまで簡単ではありますが、障害調査の仕方を紹介しました。kubectlにはここで紹介しきれないほどの有用なオプションがあるため、kubectl Cheat Sheetを参考にどのようなオプションがあるかみてみることをお勧めします。
また、公式のドキュメントにPod以外のデバッグTipsが載っています。こちらも適宜参照すると良いでしょう。
