Azure Kubernetes Service (AKS) の積極的監視のベスト プラクティス
この記事では、Azure Kubernetes Service (AKS) での積極的な監視のベスト プラクティスについて説明し、AKS で監視することが推奨される重要なシグナルの包括的なリストを提供します。
AKS クラスターの積極的な監視は、ダウンタイムを減らし、アプリケーションのビジネスの中断を減らす上で重要です。 このプロセスには、重大な問題やダウンタイムにつながる可能性があるクラスター内の異常な動作の主要なインジケーターの特定と監視が含まれます。
監視とアラートの概要
AKS での監視では、メトリック、ログ、イベントを使用して、クラスターの正常性とパフォーマンスを確保する必要があります。 監視の一般的なシナリオには、ノードのパフォーマンス、ポッドの状態、クラスター内の全体的なリソース利用が含まれます。 ログは、システム イベントとクラスターの操作とアクティビティに関する分析情報を提供します。 AKS が提供する監視用のメソッドとシグナルの詳細については、「Azure Kubernetes Service (AKS) の監視」を参照してください。
クラスターを積極的に監視する最善の方法は、Azure Monitor アラートを構成することです。 アラートは、潜在的な問題や異常が重大な問題にエスカレートする前に、ユーザーにそれらに関する通知を行うための予防的な対策として機能します。 主要なメトリックとログのしきい値を定義することで、これらのシグナルが定義済みの制限を超え、リソースの枯渇やアプリケーション障害などの問題の可能性が示唆される場合に、即座のアラートを受け取ることができます。 サービスのパフォーマンスと信頼性を測定するために、アプリケーションに対するサービス レベル目標 (SLO) を定義することを強くお勧めします。 SLO の主要なシグナルに対してアラートを構成することで、顧客にとってのアプリケーションのサービス品質の低下をすばやく検出できます。 全体として、タイムリーなアラートを設定することで、問題をすばやく調査して修復し、ダウンタイムを最小限に抑え、AKS クラスターで実行されているアプリケーションの高可用性を確保できます。
特定のメトリックの種類に対してアラートを構成する方法
メトリックの種類 | これらのメトリックの場所 | アラートを構成する方法 |
---|---|---|
AKS プラットフォーム メトリック | Azure portal の [メトリック] ブレードを通してプラットフォーム メトリックを表示します。 | メトリック アラートの作成、更新、削除は、Azure portal を通して行うことができます。 詳細については、「Azure リソースのメトリック アラートを作成する」を参照してください。 |
Azure Managed Prometheus メトリック | Prometheus メトリックにアクセスするには、Managed Prometheus を有効にする必要があります。 Prometheus メトリックを有効にして表示する方法の詳細については、「Azure Monitor と Prometheus」を参照してください。 | Prometheus アラートの構成に関するガイダンスについては、「Prometheus 用 Azure Monitor マネージド サービスのルール グループ」を参照してください。 |
Azure Activity Logs | Azure portal を通してアクティビティ ログを表示します。 詳細については、「AKS に関する Azure アクティビティ ログ」を参照してください。 | Azure portal を通してアクティビティ ログに対するアラートを構成します。 詳細については、「アクティビティ ログ アラート」をご覧ください。 |
Azure 仮想マシン スケール セット メトリック | Azure portal を通して仮想マシン スケール セット メトリックを表示します。 | 1.ノード プールに関連付けられている仮想マシン スケール セット インスタンスを見つけるには、Azure portal で AKS クラスターの [設定] > [プロパティ] ブレードに移動します。 2.インフラストラクチャ リソース グループを選択して、クラスターに関連付けられているインフラストラクチャ リソースを表示します。 3.アラートを作成する対象のノード プールの名前と一致する仮想マシン スケール セット インスタンスを選択します。 4.[アラート] ブレードに移動してメトリック アラートを作成します。 |
ロード バランサー メトリック | Azure portal の [ロード バランサー] ページを通してロード バランサー メトリックを表示します。 | 1.ノード プールに関連付けられているロード バランサー インスタンスを見つけるには、Azure portal で AKS クラスターの [設定] > [プロパティ] ブレードに移動します。 2.インフラストラクチャ リソース グループを選択して、クラスターに関連付けられているインフラストラクチャ リソースを表示します。 3.ロード バランサー インスタンスを選択して、ロード バランサーの Azure portal ページを表示します。 4.[アラート] ページに移動して、ロード バランサー メトリック アラートを作成します。 |
ログとイベント | ログとイベントに関するアラートを行うには、Container Insights を有効にする必要があります。 詳細については、「Azure Monitor リソース ログ」を参照してください。 | ログとイベントに関するアラートの作成に関するガイダンスについては、「Container Insights からのログ検索アラートの作成」を参照してください。 |
アラートを構成するための重要なシグナル
AKS 環境を包括的にカバーするには、以下に示すクラスターの 3 つの主要なコンポーネントでアラートを構成する必要があります。
- クラスター インフラストラクチャ: ノード、ディスク、ネットワークなどのクラスターの基盤インフラストラクチャを対象とするアラート。
- アプリケーションの正常性: ポッドとアプリケーションの正常性を監視するためのアラート。 異常なアプリケーションの一般的なインジケーターには、ポッドのメモリ不足による強制終了 (OOMKills) や、準備ができていない状態のポッドなどがあります。
- Kubernetes コントロール プレーン: API サーバー、etcd、その他のコンポーネントの正常性とパフォーマンスを監視するための AKS コントロール プレーンに関するアラート。
以下のセクションには、すべての AKS のお客様が注意深く監視することが推奨される重要なシグナルが含まれています。 AKS チームは、すべての重要なシグナルを、ワンクリック エクスペリエンスですべてのシグナルに関するアラートを簡単に有効にすることができる既存の推奨アラート機能に追加するよう取り組んでいます。 Prometheus メトリック アラートは現在パブリック プレビューで利用でき、残りのアラートは 2025 年初頭に利用可能になる予定です。 現時点では、重要なシグナルに関するアラートは手動で構成することができます。
クラスター インフラストラクチャ アラート
アラート シナリオ | ソース | Signal | 推奨されるしきい値 |
---|---|---|---|
クラスターが失敗状態 | Azure Activity Logs | マネージド クラスターの作成または更新 | ログの状態は "失敗" であり、クラスターのアップグレードまたは作成のアクションが失敗したことを示しています。 |
ノード プールが失敗状態 | Azure Activity Logs | エージェント プールを作成または更新する | ログの状態は "失敗" であり、作成、読み取り、アップグレード、削除 (CRUD) 操作のいずれかの失敗が原因で、ノード プールが失敗状態であることを示しています。 |
ノード OS ディスクによる高い帯域幅の使用率 | 仮想マシン スケール セット メトリック | OS ディスク帯域幅の消費率 | ノード OS ディスクの帯域幅使用率が 95% を超えています。 |
ノード OS ディスクによる高い IOPS の使用率 | 仮想マシン スケール セット メトリック | [OS Disk IOPS Consumed Percentage](OS ディスク IOPS の消費率) | ノード OS ディスクの IOPS 使用率が 95% を超えています。 |
ノード OS ディスクによる高い領域の使用率 | AKS プラットフォーム メトリック | ディスク使用率 | ノード OS ディスク領域の使用率が 90% を超えています。 |
高いノード CPU 使用率 | AKS プラットフォーム メトリック | CPU 使用率 (%) | ノード CPU 使用率が 90% を超えています。 |
高いノード メモリ使用率 | AKS プラットフォーム メトリック | メモリ ワーキング セットの割合 (%) | ノード メモリ使用率が 90% を超えています。 |
ノードが NotReady 状態である | AKS プラットフォーム メトリック | さまざまなノード条件の状態 | ノードが 20 分間以上 NotReady 状態になっています。 |
SNAT ポートの枯渇 | ロード バランサー (LB) メトリック | SNAT Connection Count (SNAT 接続数) | 接続 = "失敗" のフィルター |
アプリケーション正常性アラート
アラート シナリオ | ソース | Signal | 推奨されるしきい値 |
---|---|---|---|
異常なポッドの数が多い | Azure Managed Prometheus メトリック | アラート名: KubePodReadyStateLow | AKS 推奨アラートとして利用できます。 このアラートを有効にするには、「Kubernetes クラスターで推奨されるアラート ルール」を参照してください。 |
1 つ以上のポッドが再起動中 | Azure Managed Prometheus メトリック | アラート名: KubePodContainerRestart | AKS 推奨アラートとして利用できます。 このアラートを有効にするには、「Kubernetes クラスターで推奨されるアラート ルール」を参照してください。 |
1 つ以上のポッドが CrashLoop 状態である | Azure Managed Prometheus メトリック | アラート名: KubePodCrashLooping | AKS 推奨アラートとして利用できます。 このアラートを有効にするには、「Kubernetes クラスターで推奨されるアラート ルール」を参照してください。 |
Kubernetes コントロール プレーン アラート
アラート シナリオ | ソース | Signal | 推奨されるしきい値 |
---|---|---|---|
ETCD が容量オーバー | Azure Managed Prometheus メトリック | etcd_mvcc_db_total_size_in_use_in_bytes | ETCD 使用量が 2 GB を超えている |
API サーバー過剰要求エラー | Azure Managed Prometheus メトリック | apiserver_request_total | エラー コード 429 のフィルター |
API サーバーの Webhook とトンネルのエラー | Azure Managed Prometheus メトリック | apiserver_request_total | エラー コード 500 と 503 のフィルター |
次のステップ
AKS の監視については、以下の記事をご覧ください。
Azure Kubernetes Service