Kubernetes（K8s）の基本操作・kubectlコマンド｜Pod・ログ・障害調査
Kubernetesのクラスタを管理するときに、対象クラスター・Namespaceを確認し、安全にPodの状況を調べるためのkubectl実務ガイド。Docker単体と異なる仕組みと変更操作の影響も整理します。
この記事の目的
Pod・Deployment・Serviceの関係、kubectlの基本的な読み取り操作、トラブル時の確認先。
最初にやること
kubectl config current-contextとkubectl get pods -n appで接続先・Namespace・Podを特定します。
kubectl delete・apply・rollout restartは状態変更です。原因調査の初手で実行しないでください。app・APP・POD_NAME・CONTAINER_NAMEは例です。context・namespace・権限を実環境で確認してください。Kubernetesの運用・トラブルシューティング全6記事
kubectlの基本操作を入口に、作業ガイド3件・障害対処3件に分けています。
運用系・個別テーマ
Deployment更新・切り戻し
変更・ロールアウト履歴・undoを確認
記事を読む →運用・個別テーマConfigMap・Secretの確認と安全な更新
設定を保持するオブジェクトの確認と、反映方式によるPod再起動の要否・セキュリティ上の注意を整理します。
確認する →運用・個別テーマService・EndpointSliceの接続確認
Serviceが正しいPodを選択できているか、転送先ポートとReady条件が一致しているかを確認します。
確認する →トラブルシューティング
CrashLoopBackOff
直前の終了ログ・再起動・probeの調査
記事を読む →障害対応ImagePullBackOff
イメージ取得・認証・タグ・通信の調査
記事を読む →障害対応Kubernetes PodがPendingのまま
PodのConditionsとEventsから、リソース・Node制約・ストレージ・イメージ取得のどれが原因か絞ります。
確認する →Docker基本操作との違いはこちら。コンテナランタイムとKubernetes APIの管理対象を混同しないでください。
1. Kubernetesで扱う基本のオブジェクト
| 対象 | 役割 |
|---|---|
| Pod | 1つ以上のコンテナを含む実行単位 |
| Deployment | レプリカ数・更新を管理するコントローラー |
| Service | Podへの安定した到達先 |
| Namespace | 名前・権限・対象範囲の分割 |
| Node | Podを実行する計算ノード |
Docker単体の操作とは異なり、kubectlはAPIサーバーを経由してKubernetesのオブジェクトを調べます。コンテナランタイムにDocker Engineが使われているとは限りません。
2. context・Namespaceの確認
contextとNamespaceは誤操作を避ける基本です。kubeconfigやconfig viewの出力には接続情報・認証情報が含まれる可能性があるため、共有前に確認します。
kubectlのclientとAPIサーバーは原則としてマイナーバージョン±1以内での利用がサポートされます。kubectl versionで接続先のバージョンを確認し、クラウド提供KubernetesやOpenShift等のサポート要件も併せて確認してください。Kubernetes公式のバージョンスキューポリシー。3. PodとDeployment・Serviceの参照
get podsに表示されるSTATUS列はPod phaseそのものではなく、コンテナ待機理由などの要約表示を含む場合があります。ConditionsとEventsで詳細を確認します。
4. 現在ログ・直前ログを確認
--previousは直前のコンテナログがある場合に取得できます。execはコンテナ内部で新規プロセスを実行するので、read-onlyの確認コマンドでも権限と負荷に注意します。
5. 目的・状態から専門記事へ
| 目的・状態 | 確認先 |
|---|---|
| Deploymentの更新・切り戻し | rolloutの操作と安全な更新 |
| ConfigMap・Secretの更新 | 設定値の反映方法と秘密情報の確認 |
| Serviceの接続確認 | selector・EndpointSlice・portの確認 |
| CrashLoopBackOff | 直前ログ・終了理由・probeの切り分け |
| ImagePullBackOff / ErrImagePull | イメージ・認証・通信の切り分け |
| Pod Pending | FailedScheduling・Node・PVCを切り分ける |
6. 本番操作における区分
| 区分 | 例 | 注意 |
|---|---|---|
| 参照 | get・describe・logs | RBACと機密情報を確認 |
| プロセス実行 | exec | コンテナ内にプロセスが起動する |
| 状態変更 | apply・scale・rollout restart | 実サービスへ影響 |
| 削除 | delete | オブジェクト・Pod・永続データの影響確認 |
7. 障害時に記録する内容
クラスター、Namespace、対象オブジェクト、時刻、直近の変更、Events、コンテナログ、RBAC権限を同じ作業記録にまとめます。
Deploymentの設定変更が必要なら更新・切り戻しの個別ガイドで影響評価から進めます。
8. 調査結果から次の行動を決める
以下は想定例であり、実機で取得した結果ではありません。kubectl get podsのSTATUS表示だけで原因を決めず、describeのEvents・Conditionsと組み合わせて判断します。
| 見えた状態（想定例） | 次の安全な行動 |
|---|---|
CrashLoopBackOff | 対象コンテナを指定してlogs --previous、終了理由、probeと直前の変更を調べ、再起動原因の調査へ進む |
ImagePullBackOff | Eventsの認証・タグ・名前解決のエラーを読み、イメージ取得の調査へ進む |
Pending / FailedScheduling | PodScheduled、Node制約、requests、PVCを順に確認し、スケジューリング調査へ進む |
PodはRunningでもService通信が失敗 | Ready・EndpointSlice・selector・targetPortを調べ、Service疎通の調査へ進む |
| 変更後のDeploymentが完了しない | ロールアウトの進捗と履歴を収集し、安全な更新・切り戻し判断へ進む。最初からundoやPod削除を実行しない |
完了判定：対象context・Namespaceが正しく、問題に対応した根拠が揃い、修正後のReady・ログ・業務通信を確認できた場合にのみ完了とします。判断材料が不足する場合はEvents・変更履歴・担当者の管理情報を追加取得します。