はじめに
デプロイは、いつも計画どおりに進むとは限りません。問題が発生したときは、再現性のあるトラブルシューティング手順が必要です。
この実験では、「見つからないイメージ事件」を解決します。
Kubernetes のトラブルシューティングは、多くの場合、オブジェクトのステータス確認から始まり、次にイベントを確認し、さらに詳しく調査します。この実験では、証拠に基づいて問題を切り分けるワークフローに取り組みます。
この実験では、次の操作を行います。
- 現場を作る：意図的に壊れた Pod をデプロイします。
- 調査する：「双眼鏡」に相当する
getを使って、問題があることを確認します。 - 証拠を集める：「虫眼鏡」に相当する
describeを使って、根本原因を特定します。 - 事件を解決する：設定を修正し、アプリケーションが復旧する様子を確認します。
壊れた Pod を作成する
まず、意図的なタイプミスを含む Pod をデプロイします。これは、存在しないイメージを指定するという、よくあるエラーを再現したものです。
この操作は、問題が後になって初めて発見されるマニフェストを Kubernetes が数多く受け付けることを理解するのにも役立ちます。YAML ファイルは構文的に正しくても、実際の動作としては誤っている場合があります。そのため、トラブルシューティングでは「オブジェクトが受け付けられたか」と「ワークロードが正しく起動したか」を分けて確認する必要があります。
broken-pod.yaml という名前のファイルを作成します。
nano broken-pod.yaml
次の内容を貼り付けます。wrongtag123 という不審なイメージタグに注目してください。
apiVersion: v1
kind: Pod
metadata:
name: broken-pod
spec:
containers:
- name: nginx
image: nginx:wrongtag123
Ctrl+X、Y、Enter の順に押して保存して終了します。
Pod をデプロイします。
kubectl apply -f broken-pod.yaml
YAML の形式が正しいため、Kubernetes はこのファイルを受け付けます。この時点では、まだ「事件」は検出されていません。
失敗を確認する
次に、デプロイした Pod のステータスを確認します。現場を双眼鏡で見渡すような操作です。
ErrImagePull や ImagePullBackOff などのステータスは、最終的な説明ではなく症状です。次にどこを調査すべきかを示しています。適切なトラブルシューティングでは、ステータス出力を診断の手がかりとして使い、ステータスだけで原因を断定しません。
default namespace にある Pod を確認します。
kubectl get pods
最初は ContainerCreating と表示されることがあります。しかし数秒後には、通常 ImagePullBackOff または ErrImagePull に変わります。
ImagePullBackOff とは、Kubernetes の表現で「このイメージを取得しようとしたが失敗した。しばらく待ってから、もう一度試す」という意味です。
これで、被害者である Pod が正常な状態ではないことを確認できます。
イベントを調査する
失敗したことは分かりましたが、原因はまだ分かりません。原因を特定するには、さらに詳しく調査する必要があります。
kubectl describe コマンドは虫眼鏡のような役割を果たします。指定したリソースの内部イベントやログを表示できます。
特に重要なのが Events セクションです。このセクションには、scheduler や kubelet などの Kubernetes コンポーネントが残した短い経緯が記録されています。初心者がイベントを読まずに思いつきで修正すると、間違った問題を解決しようとして時間を無駄にしがちです。
壊れた Pod を調査します。
kubectl describe pod broken-pod
このコマンドは大量の情報を出力します。画面の一番下までスクロールして、Events セクションを探してください。
次のような内容が表示されます。
Type Reason Message
---- ------ -------
Normal Pulling Pulling image "nginx:wrongtag123"
Warning Failed Failed to pull image "nginx:wrongtag123": manifest unknown
Warning Failed Error: ErrImagePull
manifest unknown というメッセージが決定的な手がかりです。イメージが保存されている Docker registry に、nginx:wrongtag123 の記録がないことを意味します。
事件は解決しました。原因は、無効なイメージタグです。
Pod を修正する
根本原因が分かったので、問題を修正します。
この最後のステップでは、より一般的なトラブルシューティングのパターンも確認します。まず状況を観察し、証拠から仮説を立て、対象を絞った変更を 1 つ行い、その後に復旧を確認します。この手順を守るほうが、複数の変更を一度に推測で加えるよりも信頼性が高くなります。
broken-pod.yaml ファイルをもう一度開きます。
nano broken-pod.yaml
「タイプミス」を修正します。nginx:wrongtag123 を nginx に変更してください。nginx はデフォルトで nginx:latest として扱われるため、有効なイメージです。
apiVersion: v1
kind: Pod
metadata:
name: broken-pod
spec:
containers:
- name: nginx
image: nginx
保存して終了します。
修正を適用します。Kubernetes は、新しい情報を使って既存の Pod を更新できます。
kubectl apply -f broken-pod.yaml
次に、復旧の様子を監視します。
kubectl get pods -w
ステータスが ImagePullBackOff から Running に変わることを確認してください。
監視を停止するには、Ctrl+C を押します。
よくできました、探偵さん！エラーを特定し、サービスを正常に復旧できました。
まとめ
この実験では、Kubernetes のトラブルシューティングにおける基本的なワークフローを学びました。
- 観察：
kubectl get podsを実行して、失敗しているワークロードを特定します。 - 調査：
kubectl describe podを使って Event ログを確認し、エラーメッセージを探します。 - 修正：YAML マニフェストを更新し、修正内容を適用します。
この「Get、Describe、Fix」という手順によって、Kubernetes の運用で遭遇するデプロイの問題の 90% に対処できます。
