kubectl の日常操作は、「接続先を確かめる」「状態を見る」「マニフェストを適用する」「ログとシェルで中を見る」「ロールアウトを管理する」の5つに分けて覚えると、迷わずに使えるようになります。この記事では、それぞれの場面でよく使うコマンドを、なぜそのコマンドを使うのか、どこでつまずきやすいかと合わせて整理します。本番クラスタを誤って操作しないための習慣も扱います。
コマンドは、Kubernetes の現行のサポート対象の版で共通して使えるものに絞っています（2026年10月現在）。kubectl はクラスタのコントロールプレーンとの版の差が1マイナーバージョン以内であることがサポートの条件なので、kubectl version でクライアントとサーバーの版を先に確認してください。
接続先と名前空間を確かめる
kubectl の事故で多いのは、ステージングのつもりで本番クラスタを操作してしまうことです。操作の前に、今どのクラスタを向いているかを確かめる習慣をつけます。
kubectl config get-contexts # 登録されているコンテキストの一覧（* が現在）
kubectl config current-context # 現在のコンテキスト名
kubectl config use-context staging # コンテキストを切り替える
kubectl config set-context --current --namespace=my-app # 既定の名前空間を変える既定の名前空間を設定しておくと、毎回 -n my-app を付けずに済みます。ただし、名前空間を変えたことを忘れて別の場所を操作することもあるため、削除や変更のコマンドでは -n を明示するほうが安全です。シェルのプロンプトに現在のコンテキストを表示するツールを入れておくのも有効です。
状態を見る（get / describe）
kubectl get pods # Pod の一覧
kubectl get pods -o wide # ノード名や IP も表示
kubectl get deploy,svc,ingress # 複数の種類をまとめて
kubectl get pods -A # すべての名前空間
kubectl get pods -l app=wordpress # ラベルで絞り込む
kubectl get pod <Pod名> -o yaml # 実際の定義をYAMLで
kubectl describe pod <Pod名> # 詳細と Eventsget は一覧、describe は1つのリソースの詳細です。describe の末尾にある Events には、スケジュールできない理由、イメージの取得失敗、プローブの失敗などが記録されるため、問題を調べるときはまずここを見ます。
-o yaml で表示される内容には、自分が書いていない項目（既定値や status）も含まれます。マニフェストと見比べるときは、spec の部分に注目してください。特定の値だけ取り出したいときは -o jsonpath が使えます。
kubectl get pod <Pod名> -o jsonpath='{.status.podIP}'リソースの種類名や項目の意味が分からないときは、kubectl api-resources で種類の一覧（短縮名も表示されます）を、kubectl explain deployment.spec.strategy で項目の説明を確認できます。手元のクラスタの版に合った説明が出るので、ネットの古い記事より信頼できます。
名前空間のイベントを時系列で見たいときは、次のコマンドを使います。
kubectl get events --sort-by=.lastTimestampマニフェストを適用する（apply / diff / delete）
kubectl diff -f deployment.yaml # 適用したら何が変わるかを表示
kubectl apply -f deployment.yaml # 適用（なければ作成、あれば更新）
kubectl apply -f k8s/ # ディレクトリ内をまとめて
kubectl delete -f deployment.yaml # ファイルに書かれたリソースを削除本番では、apply の前に diff で差分を確かめる流れにしておくと、意図しない変更に気づけます。さらに kubectl apply -f deployment.yaml --dry-run=server を使うと、サーバー側の検証（スキーマや Admission の確認）だけを行い、実際には変更しません。
マニフェストを一から書くのが手間なときは、create で雛形を出力させる方法があります。
kubectl create deployment web --image=nginx --dry-run=client -o yaml > web.yamlkubectl edit でクラスタ上のリソースを直接書き換えることもできますが、変更がマニフェストのファイルに残らず、次の apply で元に戻ってしまう原因になります。緊急時以外は、ファイルを直して apply する運用をおすすめします。
delete は取り消しができません。特に kubectl delete namespace は中のリソースをすべて削除し、PersistentVolumeClaim を通じてデータが失われる場合もあります。実行前にコンテキストと名前空間を声に出して確認するくらいの慎重さが必要です。
ログとシェルで中を見る（logs / exec / port-forward）
kubectl logs <Pod名> # ログを表示
kubectl logs -f <Pod名> # 追従して表示
kubectl logs <Pod名> -c <コンテナ名> # 複数コンテナの Pod で指定
kubectl logs <Pod名> --previous # 再起動前のコンテナのログ
kubectl logs deploy/web --since=10m # Deployment 配下の Pod の1つから直近10分
kubectl logs -l app=web --since=10m # ラベルに一致する複数の Pod から
kubectl exec -it <Pod名> -- sh # コンテナ内でシェルを開く
kubectl port-forward svc/web 8080:80 # 手元の 8080 をサービスの 80 につなぐ再起動を繰り返している Pod では、今のコンテナはまだ何も出力していないことが多く、--previous を付けて直前に落ちたコンテナのログを見るのがこつです。
exec の -- 以降がコンテナ内で実行するコマンドです。シェルが入っていない最小構成のイメージでは sh が使えないため、その場合は kubectl debug でデバッグ用のコンテナを追加して調べます。
port-forward は、Ingress や LoadBalancer を用意せずに手元からサービスを確かめたいときに便利です。コマンドを止めると接続も切れます。
kubectl cp でファイルをコピーすることもできますが、コンテナ内に tar が入っている必要があります。
ロールアウトを管理する（rollout / scale / set image）
kubectl rollout status deploy/web # 更新の完了を待つ
kubectl rollout history deploy/web # 更新の履歴
kubectl rollout undo deploy/web # 1つ前の版に戻す
kubectl rollout restart deploy/web # Pod を順に作り直す
kubectl scale deploy/web --replicas=3 # レプリカ数を変える
kubectl set image deploy/web web=nginx:1.27 # イメージを変えるrollout restart は、ConfigMap や Secret を変えたあとに Pod へ反映させたいときによく使います。環境変数として読み込んだ ConfigMap は、Pod を作り直すまで変更が反映されないためです。
scale や set image はその場で効きますが、マニフェストのファイルとずれが生じます。HorizontalPodAutoscaler を使っている場合は、scale で変えたレプリカ数も自動で上書きされます。恒久的な変更はファイルに反映しておきます。
リソース使用量と権限の確認
kubectl top pods # Pod の CPU・メモリ使用量
kubectl top nodes # ノードの使用量
kubectl auth can-i delete pods -n my-app # 自分にその操作の権限があるかkubectl top は、クラスタに metrics-server などのメトリクス API が入っていないと使えません。auth can-i は、RBAC の設定を確かめるときや、操作が拒否された理由を調べるときに役立ちます。
安全に使うための習慣
- 変更系のコマンドの前に
kubectl config current-contextで接続先を確かめる - 本番では
diffや--dry-run=serverで影響を確認してからapplyする deleteやdrainは、対象と名前空間を明示して実行する- 直接の
editやscaleで済ませた変更は、マニフェストのファイルにも反映する - 重要なデータを持つリソースの削除やクラスタの変更の前には、バックアップの有無を確かめる
まとめ
- まず
config current-contextとget-contextsで接続先を確認する - 状態は
getで一覧、describeの Events で原因を見る。分からない項目はexplainで調べる - 変更は
diff→applyの順で行い、マニフェストのファイルを正とする - ログは
logs（再起動後は--previous）、中の確認はexecとport-forward - 更新は
rollout statusで完了を確かめ、問題があればrollout undoで戻す topは metrics-server が前提、権限はauth can-iで確かめる