DevOpsナレッジハブ
DevOpsナレッジハブ

一般的なKubernetesのパフォーマンスボトルネックのトラブルシューティング

CPUスロットリング、メモリのOOMKill、スケジューリング遅延など、一般的なKubernetesのパフォーマンスボトルネックを体系的に診断し、解決する方法を学びます。このガイドでは、最適なアプリケーションパフォーマンスを確保するために、リソース要求の調整、HPAスケーリングの最適化、および根本的なクラスター制約の特定を行うための、実用的なコマンドとベストプラクティスを提供します。

36 ビュー

Kubernetesにおける一般的なパフォーマンスボトルネックのトラブルシューティング

Kubernetesは、コンテナ化されたアプリケーションを大規模に管理するための強力なプラットフォームですが、環境が拡大するにつれて、パフォーマンスのボトルネックが発生し、デプロイメントの遅延、サービスの応答不能、運用コストの増加につながる可能性があります。これらの問題を体系的に診断し解決する方法を理解することは、健全で効率的なクラスターを維持するために不可欠です。このガイドでは、Kubernetesスタックのさまざまなレイヤーで発生する一般的なパフォーマンスの落とし穴を掘り下げ、アプリケーションをスムーズに実行し続けるための実用的な手順と重要な診断コマンドを提供します。

この記事は、基本的な監視を超え、リソース割り当て、スケーリングメカニズム、および基本的なクラスター操作に関連する制約を特定することに特に焦点を当てる力を与えます。

フェーズ1：症状の特定

特定のコンポーネントを調査する前に、観測されたパフォーマンスの低下を明確に定義してください。一般的な症状は、多くの場合、次のいずれかのカテゴリに分類されます。

  • デプロイメント/更新の遅延： Podの作成に過度の時間がかかる、またはローリングアップデートが停滞する。
  • 応答しないアプリケーション： Podは実行されているものの、アプリケーションレベルのトラフィックへの応答に失敗する（例：高レイテンシ、5xxエラー）。
  • 高いリソーススパイク： ノードまたは特定のデプロイメント全体で、説明のつかないCPUまたはメモリ使用率のスパイクが発生する。
  • スケジューリングの遅延： 新しいPodが永続的にPending（保留中）状態のままになる。

フェーズ2：リソース制約（CPUとメモリ）の診断

リソース管理の誤りは、Kubernetesのパフォーマンス問題の最も頻繁な原因です。不適切に設定されたrequestsとlimitsは、スロットリング（調整）またはOOMKillを引き起こします。

1. リソース使用率と制限の確認

まず、kubectl describeとkubectl topを使用して、影響を受けるアプリケーションのリソース割り当てを検査します。

実行可能なチェック： requestsとlimitsを、メトリクスサーバーによって報告される実際の使用状況と比較します。

# 特定のネームスペース内の全Podのリソース使用率を取得
kubectl top pods -n <namespace>

# 特定のPodのリソースrequests/limitsを検査
kubectl describe pod <pod-name> -n <namespace>

2. CPUスロットリング

コンテナのCPU使用率が定義されたlimitに繰り返し達すると、カーネルがそれをスロットル（調整）し、ノード自体に利用可能な容量がある場合でも、深刻なレイテンシスパイクにつながります。これは、一般的なCPU不足と誤解されがちです。

診断のヒント： kubectl topがノード上でCPU使用率100%を示していない場合でも、高レイテンシの応答を探します。スロットリングはコンテナごとに発生します。

解決策：
* ワークロードが正当により多くの処理能力を必要とする場合は、CPU limitを増やします。
* アプリケーションがビジーウェイトしている場合は、単純に制限を増やすのではなく、アプリケーションコードを最適化します。

3. メモリプレッシャーとOOMKill

コンテナがメモリlimitを超えると、KubernetesはOut-Of-Memory (OOM) killを開始し、コンテナを繰り返し再起動します。

診断： Podステータスで頻繁な再起動（kubectl get podsのRESTARTS列を確認）がないか確認し、ログでOOMKilledイベントを調べます。

# OOMKillsに関する最近のイベントを確認
kubectl get events --field-selector involvedObject.name=<pod-name> -n <namespace>

解決策：
* OOMKillが頻繁に発生する場合は、直ちにメモリlimitを増やします。
* 長期的な修正策としては、アプリケーションをプロファイリングしてメモリリークを見つけて修正するか、ヒープサイズを削減します。

ベストプラクティス：Requestsを賢く設定する。 リソースrequestsが、予測される最小使用量に合理的に近い値に設定されていることを確認してください。requestsが低すぎる場合、スケジューラがノードを過剰にコミットし、すべてのPodが同時に要求を満たそうとしたときに競合を引き起こす可能性があります。

フェーズ3：スケジューリングボトルネックの調査

PodがPending（保留中）状態のままになる場合、問題はスケジューラが適切なノードを見つけられないことにあります。

1. 保留中のPodの分析

保留中のPodに対してkubectl describe podを使用し、Eventsセクションを読みます。このセクションには、通常、スケジューリングが失敗した明確な説明が含まれています。

一般的なスケジューラメッセージ：

  • 0/3 nodes are available: 3 Insufficient cpu. (ノード容量の問題)
  • 0/3 nodes are available: 3 node(s) had taint {dedicated: infra}, that the pod didn't tolerate. (Taints/Tolerationsの不一致)
  • 0/3 nodes are available: 1 node(s) had taint {NoSchedule: true}, that the pod didn't tolerate. (ノードの負荷またはメンテナンス)

2. クラスターリソースの飽和

CPU/メモリ不足のためにスケジューリングが遅延している場合、クラスター全体の集約容量が不足しています。

解決策：
* クラスターにノードを追加します。
* リソースrequestsの誤設定によりノード使用率が人為的に高くなっていないか確認します（フェーズ2を参照）。
* 保留中のPodが蓄積した場合にノードを動的に追加するために、クラウドプロバイダーで実行している場合はCluster Autoscaler (CA)を使用します。

フェーズ4：スケーリングメカニズムのパフォーマンス問題

自動スケーリングは迅速に反応するはずですが、Horizontal Pod Autoscalers (HPA) または Vertical Pod Autoscalers (VPA) の設定ミスが問題を引き起こす可能性があります。

1. Horizontal Pod Autoscaler (HPA) の遅延

HPAは、正確なCPU/メモリ使用率またはカスタムメトリクスを報告するためにMetrics Serverに依存しています。

診断手順：

  1. Metrics Serverの健全性を確認： Metrics Serverが実行中でアクセス可能であることを確認します。
    bash kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes"
  2. HPAステータスの確認： HPAの設定と最近のイベントを検査します。
    bash kubectl describe hpa <hpa-name> -n <namespace>
    メトリクスソースが利用できないか、スケーリング決定ループが機能しているかを示すメッセージを探します。

ボトルネック： カスタムメトリクスが使用されている場合、外部メトリクスプロバイダーが正しく機能しており、HPAのpollingInterval内にデータを報告していることを確認してください。

2. Vertical Pod Autoscaler (VPA) の相互作用

VPAはリソースrequestsを自動的に調整しますが、頻繁にPodを再起動またはリサイズする場合、特に再起動を許容できないステートフルなアプリケーションにとって、調整フェーズ中にパフォーマンスの不安定性を引き起こす可能性があります。

推奨事項： まずVPAをRecommenderモードで使用するか、またはupdateMode: "Off"を使用して、自動適用なしで推奨事項を観察するだけにすることで、不必要なリサイズによる混乱を軽減します。

フェーズ5：ネットワークとストレージのパフォーマンス

計算リソースに問題がないように見える場合、ネットワーキングまたは永続ストレージがチョークポイントになっている可能性があります。

1. CNI (Container Network Interface) の問題

Pod間の通信（特にノード間）が遅い、または断続的に失敗する場合、CNIプラグインが過負荷であるか、設定が誤っている可能性があります。

トラブルシューティング：
* CNIデーモンセットPod（例：Calico、Flannel）のログを確認します。
* 異なるノード上のPod間でpingまたはcurlを使用して基本的な接続性をテストします。

2. 永続ボリューム (PV) のレイテンシ

ディスクI/Oに大きく依存するアプリケーション（データベース、ロギングシステム）は、基盤となる永続ボリュームのレイテンシが高い場合にパフォーマンスが低下します。

実行可能なチェック： プロビジョナータイプ（例：AWS EBS gp3 vs. io1）を確認し、ボリュームが必要なIOPS/スループット仕様を満たしていることを検証します。

ストレージに関する警告： 基盤となるディスクのパフォーマンス特性を理解せずに、高スループットのデータベースを標準のhostPathボリュームで直接実行しないでください。要求の厳しいワークロードには、マネージドクラウドストレージソリューションまたは高性能なローカルストレージプロビジョナーを使用してください。

結論と次のステップ

Kubernetesのパフォーマンスのトラブルシューティングは、アプリケーション層からノードおよびクラスターレベルへと外向きに進む体系的なアプローチを必要とする反復プロセスです。リソース定義を綿密にチェックし、スケジューライベントを分析し、スケーリングメトリクスを検証することで、ボトルネックを効果的に特定できます。主要な診断ツールとして、kubectl describeとkubectl topを活用することを忘れないでください。

次のステップ：
1. 堅牢なResource Quotasを実装して、クリティカルなアプリケーションを「うるさい隣人」が枯渇させるのを防ぎます。
2. Podの再起動回数を定期的にレビューし、微妙なOOMやアプリケーションの障害動作を早期に捉えます。
3. 生の利用率だけでなく、CPUスロットリングメトリクスを specifically トラッキングするPrometheus/Grafanaダッシュボードを利用します。