Container Service のアラート管理機能を有効にすると、コンテナーのアラートを一元管理できます。この機能は、コンテナーサービスにおける異常イベント、基本的なクラスターリソースの主要メトリック、およびクラスターのコアコンポーネントとアプリケーションのメトリックをモニタリングします。また、カスタムリソース定義 (CRD) を使用して、クラスター内のデフォルトのアラートルールを変更することもできます。これにより、クラスターの異常を迅速に検出できます。
課金
アラート機能は、Simple Log Service (SLS)、Managed Service for Prometheus、および CloudMonitor からのデータを使用します。アラートがトリガーされたときに送信されるショートメッセージや電話などの通知には、追加料金が課金されます。アラート機能を有効にする前に、デフォルトのアラートルールテンプレートの各アラート項目のデータソースを確認し、必要なサービスを有効化してください。
アラートソース | 設定要件 | 課金の詳細 |
Simple Log Service (SLS) | イベントモニタリングを有効にします。イベントモニタリングは、アラート管理機能を有効にするとデフォルトで有効になります。 | |
Managed Service for Prometheus | クラスターの Prometheus モニタリングを設定します。 | 無料 |
CloudMonitor | クラスターの場合: Container Service for Kubernetes クラスターの Cloud Monitor 機能を有効にする。 |
アラート管理機能を有効にする
アラート管理機能を有効にすると、クラスター内の指定されたリソースに対してメトリックベースのアラートを設定できます。異常が発生すると、アラート通知が自動的に受信されます。これにより、クラスターをより効率的に管理およびメンテナンスし、サービスの安定性を確保できます。リソースアラートの詳細については、「デフォルトのアラートルールテンプレート」をご参照ください。
ACK マネージドクラスター
既存のクラスターまたは新しいクラスターを作成するときに、アラート設定を有効にできます。
既存のクラスターで機能を有効にする
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
クラスター ページで、目的のクラスターを見つけてその名前をクリックします。左側のペインで、 を選択します。
[アラート] ページで、画面の指示に従ってコンポーネントをインストールまたはスペックアップします。
インストールまたはスペックアップが完了したら、[アラート] ページに移動してアラート情報を設定します。
タブ
説明
アラートルール管理
ステータス: ターゲットのアラートルールセットをオンまたはオフにします。
通知オブジェクトの編集: アラート通知のアラートグループを設定します。
これを設定する前に、連絡先とグループを作成し、連絡先をグループに追加します。通知オブジェクトとして選択できるのはアラートグループのみです。個人に通知するには、その連絡先のみを含むグループを作成し、そのグループを選択します。
アラート履歴
過去 24 時間の最新 100 件のアラートレコードを表示できます。
[アラートルール] 列のリンクをクリックして、対応するモニタリングシステムに移動し、詳細なルール設定を表示します。
[トラブルシューティング] をクリックして、異常が発生したリソース (異常なイベントまたはメトリック) をすばやく特定します。
[インテリジェント分析] をクリックして、AI アシスタントを使用して問題を分析し、トラブルシューティングのガイダンスを提供します。
連絡先管理
連絡先を管理します。連絡先の作成、編集、削除ができます。
連絡方法:
電話/ショートメッセージ: 連絡先に携帯電話番号を設定すると、連絡先は電話とショートメッセージでアラート通知を受信できます。
電話通知の受信に使用できるのは、確認済みの携帯電話番号のみです。携帯電話番号の確認方法の詳細については、「携帯電話番号の確認」をご参照ください。
メール: 連絡先にメールアドレスを設定すると、連絡先はメールでアラート通知を受信できます。
ロボット: DingTalk ロボット、WeCom ロボット、Lark ロボット。
DingTalk ロボットの場合、セキュリティキーワードとして Alerting、Dispatch を追加する必要があります。
メールとロボットの通知を設定する前に、CloudMonitor コンソールで確認してください。 を選択して、アラート情報を受信できることを確認します。
連絡先グループの管理
アラートグループを管理します。アラートグループの作成、編集、削除ができます。[通知オブジェクトの編集] では、アラートグループのみを選択できます。
アラートグループが存在しない場合、コンソールは Alibaba Cloud アカウント情報に基づいてデフォルトのアラートグループを作成します。
クラスター作成時に機能を有効にする
クラスター作成ウィザードの [コンポーネント設定] ページで、[アラート] の [デフォルトのアラートテンプレートを使用してアラートを設定] を選択し、[アラート通知連絡先グループ] を選択します。詳細については、「ACK マネージドクラスターの作成」をご参照ください。
クラスター作成中にアラート設定を有効にすると、システムはデフォルトのアラートルールを有効にし、デフォルトのアラートグループにアラート通知を送信します。また、アラート連絡先またはアラートグループを変更することもできます。
ACK 専用クラスター
ACK 専用クラスターの場合、まずワーカー RAM ロールに権限を付与し、次にデフォルトのアラートルールを有効にする必要があります。
ワーカー RAM ロールへの権限付与
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
クラスター ページで、ターゲットクラスターを見つけてその名前をクリックします。左側のナビゲーションウィンドウで、クラスター情報 をクリックします。
[クラスター情報] ページの [クラスターリソース] セクションで、[ワーカー RAM ロール] の名前をコピーし、リンクをクリックして [Resource Access Management (RAM)] コンソールを開き、ロールに権限を付与します。
カスタムポリシーを作成します。詳細については、「JSON タブでカスタムポリシーを作成する」をご参照ください。
{ "Action": [ "log:*", "arms:*", "cms:*", "cs:UpdateContactGroup" ], "Resource": [ "*" ], "Effect": "Allow" }[ロール] ページで、ワーカー RAM ロールを見つけて、カスタムポリシーを付与します。詳細については、「方法 1: RAM ロールページで RAM ロールに権限を付与する」をご参照ください。
注: このドキュメントでは、簡潔にするために広範な権限を付与しています。本番環境では、最小権限の原則に従い、必要な権限のみを付与することを推奨します。
[ロール] ページで、ワーカー RAM ロールを見つけて、カスタムポリシーを付与します。詳細については、「方法 1: RAM ロールページで RAM ロールに権限を付与する」をご参照ください。
ログをチェックして、アラート機能のアクセス権限が設定されていることを確認します。
クラスター管理ページの左側のナビゲーションウィンドウで、 を選択します。
[名前空間] を kube-system に設定し、ステートレスアプリケーションのリストにある alicloud-monitor-controller アプリケーションの [名前] をクリックします。
[ログ] タブをクリックします。Pod のログは、権限付与が成功したことを示します。
デフォルトのアラートルールを有効にする
クラスター管理ページの左側のナビゲーションウィンドウで、[O&M] > [アラート] を選択します。
[アラート] ページで、次のアラート情報を設定します。
タブ
説明
アラートルール管理
ステータス: ターゲットのアラートルールセットをオンまたはオフにします。
通知オブジェクトの編集: アラート通知のアラートグループを設定します。
これを設定する前に、連絡先とグループを作成し、連絡先をグループに追加します。通知オブジェクトとして選択できるのはアラートグループのみです。個人に通知するには、その連絡先のみを含むグループを作成し、そのグループを選択します。
アラート履歴
過去 24 時間の最新 100 件のアラートレコードを表示できます。
[アラートルール] 列のリンクをクリックして、対応するモニタリングシステムに移動し、詳細なルール設定を表示します。
[トラブルシューティング] をクリックして、異常が発生したリソース (異常なイベントまたはメトリック) をすばやく特定します。
[インテリジェント分析] をクリックして、AI アシスタントを使用して問題を分析し、トラブルシューティングのガイダンスを提供します。
連絡先管理
連絡先を管理します。連絡先の作成、編集、削除ができます。
連絡方法:
電話/ショートメッセージ: 連絡先に携帯電話番号を設定すると、連絡先は電話とショートメッセージでアラート通知を受信できます。
電話通知の受信に使用できるのは、確認済みの携帯電話番号のみです。携帯電話番号の確認方法の詳細については、「携帯電話番号の確認」をご参照ください。
メール: 連絡先にメールアドレスを設定すると、連絡先はメールでアラート通知を受信できます。
ロボット: DingTalk ロボット、WeCom ロボット、Lark ロボット。
DingTalk ロボットの場合、セキュリティキーワードとして Alerting、Dispatch を追加する必要があります。
メールとロボットの通知を設定する前に、CloudMonitor コンソールで確認してください。 を選択して、アラート情報を受信できることを確認します。
アラートグループ管理
アラートグループを管理します。アラートグループの作成、編集、削除ができます。[通知オブジェクトの編集] では、アラートグループのみを選択できます。
アラートグループが存在しない場合、コンソールは Alibaba Cloud アカウント情報に基づいてデフォルトのアラートグループを作成します。
アラートルールの設定
アラート設定機能を有効にすると、kube-system 名前空間に AckAlertRule カスタムリソース定義 (CRD) リソースが作成されます。このリソースには、デフォルトのアラートルールテンプレートが含まれています。この CRD リソースを変更して、デフォルトのアラートルールをカスタマイズし、要件を満たすコンテナーサービスのアラートを設定できます。
コンソール
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
クラスター ページで、目的のクラスターを見つけてその名前をクリックします。左側のペインで、 を選択します。
[アラートルール管理] タブで、右上隅の [アラート設定の編集] をクリックします。次に、ターゲットルールの [アクション] 列にある [YAML] をクリックして、現在のクラスターの AckAlertRule リソース設定を表示します。
必要に応じて YAML ファイルを変更します。詳細については、「デフォルトのアラートルールテンプレート」をご参照ください。
次のコードは、アラートルールのサンプル YAML 設定を示しています。
rules.thresholdsを使用して、アラートのしきい値をカスタマイズできます。パラメーターの詳細については、次の表をご参照ください。たとえば、前述の設定では、クラスターノードの CPU 使用率が 3 回連続で 85% を超え、前回のアラートが 900 秒以上前にトリガーされた場合にアラート通知がトリガーされます。パラメーター
必須
説明
デフォルト値
CMS_ESCALATIONS_CRITICAL_Threshold必須
アラートのしきい値。このパラメーターが設定されていない場合、ルールの同期に失敗し、無効になります。
unit: 単位。percent、count、または qps に設定できます。value: しきい値。
デフォルトのアラートテンプレートの設定に依存します。
CMS_ESCALATIONS_CRITICAL_Times任意
CloudMonitor ルールのリトライ回数。設定されていない場合は、デフォルト値が使用されます。
3
CMS_RULE_SILENCE_SEC任意
CloudMonitor が異常によりルールを継続的にトリガーした場合に、最初のアラートが報告された後の解約待機期間 (秒単位)。これにより、アラート疲れを防ぎます。設定されていない場合は、デフォルト値が使用されます。
900
kubectl
次のコマンドを実行して、アラートルールの YAML ファイルを編集します。
kubectl edit ackalertrules default -n kube-system必要に応じて YAML ファイルを変更し、保存して終了します。詳細については、「デフォルトのアラートルールテンプレート」をご参照ください。
rules.thresholdsを使用して、アラートのしきい値をカスタマイズできます。たとえば、前述の設定では、クラスターノードの CPU 使用率が 3 回連続で 85% を超え、前回のアラートが 900 秒以上前にトリガーされた場合にアラート通知がトリガーされます。パラメーター
必須
説明
デフォルト値
CMS_ESCALATIONS_CRITICAL_Threshold必須
アラートのしきい値。このパラメーターが設定されていない場合、ルールの同期に失敗し、無効になります。
unit: 単位。percent、count、または qps に設定できます。value: しきい値。
デフォルトのアラートテンプレートの設定に依存します。
CMS_ESCALATIONS_CRITICAL_Times任意
CloudMonitor ルールのリトライ回数。設定されていない場合は、デフォルト値が使用されます。
3
CMS_RULE_SILENCE_SEC任意
CloudMonitor が異常によりルールを継続的にトリガーした場合に、最初のアラートが報告された後の解約待機期間 (秒単位)。これにより、アラート疲れを防ぎます。設定されていない場合は、デフォルト値が使用されます。
900
デフォルトのアラートルールテンプレート
アラートルールは、Simple Log Service (SLS)、Managed Service for Prometheus、および CloudMonitor から同期されます。[アラート] ページで、[アラート管理] 列の [詳細設定] をクリックして、各アラートルールの設定を表示できます。
アラートのトラブルシューティングガイド
ノードのディスク使用量がしきい値に達したことによる Pod のエビクション
アラートメッセージ
(combined from similar events): Failed to garbage collect required amount of images. Attempted to free XXXX bytes, but only found 0 bytes eligible to free現象
Pod のステータスは Evicted です。ノードでディスクプレッシャーが発生しています (The node had condition: [DiskPressure].)。
原因
ノードのディスク使用量がエビクションのしきい値 (デフォルトは 85%) に達すると、kubelet はプレッシャーベースのエビクションと GC を実行して、未使用のイメージファイルを再利用します。このプロセスにより、Pod がエビクションされます。ターゲットノードにログインし、df -h コマンドを実行してディスク使用量を確認できます。
ソリューション
ターゲットノード (containerd コンテナーランタイム環境) にログインし、次のコマンドを実行して未使用のコンテナイメージを削除し、ディスク領域を解放します。
crictl rmi --pruneログをクリーンアップするか、ノードディスクのサイズを変更します。
ターゲットノードのデータディスクまたはシステムディスクの スナップショットバックアップ を作成します。バックアップが完了したら、不要になったファイルまたはフォルダを削除します。詳細については、「Linux インスタンスのディスク領域不足の問題を解決する」をご参照ください。
ターゲットノードのシステムディスクまたはデータディスクをオンラインでスケールアウトして、ストレージ容量を増やします。詳細については、「ノードのシステムディスクまたはデータディスクをスケールアウトする」をご参照ください。
関連するしきい値を調整します。
必要に応じて kubelet イメージ GC のしきい値を調整して、ノードの高いディスク使用率が原因で発生する Pod のエビクションを減らします。 詳細については、「ノードプールの kubelet 構成をカスタマイズする」をご参照ください。
ノードのディスク使用率が 85% 以上に達すると、アラートが通知されます。 ビジネスニーズに基づいて、YAML 構成の
node_disk_util_highアラートルールでアラートのしきい値を変更できます。 詳細については、「アラートルールを設定する」をご参照ください。
推奨事項と予防策
この問題が頻繁に発生するノードについては、アプリケーションの実際のストレージニーズを評価し、リソースリクエストとノードのディスク容量を適切に計画することをお勧めします。
ストレージ使用量を定期的にモニターして、潜在的な脅威を迅速に特定して対処することをお勧めします。詳細については、「ノードストレージダッシュボード」をご参照ください。
Pod の OOMKilling
アラートメッセージ
pod was OOM killed. node:xxx pod:xxx namespace:xxx uuid:xxx
症状
Pod のステータスが異常で、イベントの詳細に PodOOMKilling が含まれています。
ソリューション
Out of Memory (OOM) イベントは、ノードレベルまたはコンテナー cgroup レベルでトリガーされます。
原因:
コンテナー cgroup レベルの OOM: Pod の実際のメモリ使用量がメモリ制限を超えています。その後、Pod は Kubernetes cgroup によって強制的に終了させられます。
ノードレベルの OOM: これは通常、リソース制限 (リクエスト/制限) のない Pod が多すぎてノードで実行されている場合や、一部のプロセス (Kubernetes によって管理されていない可能性があります) が大量のメモリを消費する場合に発生します。
方法: ターゲットノードにログインし、
dmesg -T | grep -i "memory"コマンドを実行します。出力にout_of_memoryが含まれている場合、OOM イベントが発生しています。ログ出力にMemory cgroupも含まれている場合、イベントはコンテナー cgroup レベルの OOM です。それ以外の場合、イベントはノードレベルの OOM です。提案:
コンテナー cgroup レベルの OOM の場合:
必要に応じて Pod のメモリ制限を増やします。実際の使用量は、指定された制限の 80% を超えないようにしてください。詳細については、「Pod の管理」および「ノードリソースのアップグレードまたはスペックダウン」をご参照ください。
リソースプロファイリングを有効にして、コンテナーのリクエストと制限の推奨構成を取得します。
ノードレベルの OOM の場合:
ノードのメモリリソースをスケールアウトするか、ワークロードをより多くのノードに分散します。詳細については、「ノードリソースのアップグレードまたはスペックダウン」および「特定のノードへのアプリケーションのスケジューリング」をご参照ください。
ノード上でメモリ使用量が多い Pod を特定し、それらに適切なメモリ制限を設定します。
OOM イベントの原因とそのソリューションの詳細については、「OOM Killer の原因とソリューション」をご参照ください。
Pod のステータスが CrashLoopBackOff である
Pod 内のプロセスが予期せず終了すると、ACK は Pod の再起動を試みます。複数回再起動しても Pod が望ましい状態に達しない場合、そのステータスは CrashLoopBackOff に変わります。トラブルシューティングを行うには、次のステップに従います。
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
クラスター ページで、目的のクラスターを見つけてその名前をクリックします。左側のペインで、 を選択します。
リストで異常な Pod を見つけ、アクション 列の 詳細 をクリックします。
Pod の [イベント] を確認し、異常なイベントの説明を分析します。
Pod の [ログ] を表示します。これには異常なプロセスの原因が記録されている場合があります。
説明Pod が再起動されている場合は、最後のコンテナーが終了した時のログを表示する を選択して、前の Pod のログを表示します。
コンソールには、最新のログエントリが最大 500 件表示されます。より多くの履歴ログを表示するには、ログ永続化ソリューションを設定して、統一された収集とストレージを行うことをお勧めします。