皆さん、こんにちは！「ゴールデン・クバーストロノート」を目指して一緒に走っている皆さん、お会いできて嬉しいです。👋
今日は、CKAD(Certified Kubernetes Application Developer)試験範囲の中でも、実務で最も頻繁に使用されるテーマである「アプリケーションモニタリングのためのk8s内蔵CLIツール」について、深く掘り下げていきます。🕵️♂️
PrometheusやGrafanaなどの重いモニタリングソリューションを別途導入することなく、kubectlだけでクラスターとアプリケーションの状態を診断する核心技術をまとめてご紹介します。
🚀 k8s内蔵CLIツールでアプリケーションをモニタリングする
Kubernetes環境でアプリケーションが「正常に動作しているか？」を確認することは、単にRunning状態を見る以上の意味を持ちます。リソース使用量、ログ分析、そして内部状態診断まで、CLIを通じて完璧に制御できる必要があります。
1. リソースモニタリングの基本: kubectl top 📊
最初に確認すべきはCPUとMemoryです。アプリケーションがもたついたり、理由なく停止したりする場合、リソース不足（OOMなど）である可能性が高いからです。
💡 注意: kubectl topコマンドを使用するには、クラスターにMetrics Serverが必ずインストールされている必要があります。
- Podごとのリソース使用量を確認
現在のネームスペースのすべてのPodリソースを確認
kubectl top pod
特定のPodのコンテナごとの使用量を確認 (マルチコンテナPodの場合に便利！)
kubectl top pod
- Nodeごとの負荷を確認 アプリケーションだけでなく、インフラ全体の健全性をチェックする際に使用します。
kubectl top node
2. 生きた証拠の確保: kubectl logs 📝
アプリケーション内部で何が起こっているかを知る最も直接的な方法は、標準出力(stdout/stderr)ログを見ることです。
- リアルタイムログストリーミング (-f)
リアルタイムでログを追跡
kubectl logs -f
- マルチコンテナPodのログ Pod内にサイドカーコンテナがある場合、コンテナ名を明示する必要があります。
kubectl logs
- 以前のコンテナのログを確認 (-p) アプリケーションがクラッシュして再起動した場合、現在のログではなく、停止直前のログを見ることで原因を特定できます。CKAD試験で非常に重要なポイントです！
kubectl logs
3. 詳細情報とイベント診断: kubectl describe 🔍
PodがPending状態であったり、ImagePullBackOffエラーが発生したりした場合、ログには何も記録されません。この場合は、Kubernetesシステムが記録したEventを確認する必要があります。
kubectl describe pod
このコマンドを実行したら、下部のEventsセクションを最初に確認してください。
- FailedScheduling: ノードリソース不足
- FailedMount: ConfigMap/Secret/PV接続失敗
- Back-off restarting failed container: アプリケーションランタイムエラー
4. リアルタイム状態監視: –watchフラグ ⏳
デプロイ直後にアプリケーションが正常に稼働しているか、あるいはローリングアップデートが順調に進んでいるか、1秒ごとにコマンドを打っていますか？–watch (または -w) を使用してください。
kubectl get pod -w
5. 直接侵入: kubectl exec & debug 🛠️
ネットワーク接続の問題や内部設定ファイルを直接確認する必要がある場合は、コンテナ内部に入る必要があります。
- 対話型ターミナル接続
kubectl exec -it
- 一時的なデバッグコンテナの実行 (v1.18+) イメージが非常に軽量で(distrolessなど) shすら含まれていない場合、kubectl debugを使ってデバッグ用ツールを含む一時コンテナをアタッチできます。
kubectl debug -it
🎯 CKAD合格のための実践ヒント
試験では、単にコマンドを知っているだけでなく、「どのような状況でどのツールを使うべきか」を判断するスピードが重要になります。
- Podの状態がRunningでない場合: describe -> Eventsを確認。
- Runningだが接続できない場合: logsを確認。
- CrashLoopBackOffが発生した場合: logs –previousで以前のログを確認。
- 性能低下が疑われる場合: top podでリソース割り当て量(Limit/Request)に対する使用量を確認。
💡 終わりに
Kubernetesの内蔵ツールをうまく活用するだけで、ほとんどのアプリケーション障害の80%以上を診断できます。特にtop、logs、describeの「三銃士」は、指が覚えるまで練習しておくことをお勧めします。⌨️
コメントを残す