クラスターイベント、リソースメトリック、コンポーネントの健全性を、設定可能な CRD ベースのアラートルールで監視します。
課金
アラート機能は、Log Service SLS、Managed Service for Prometheus、および CloudMonitor のデータを使用します。SMS や音声通話などの通知には追加料金が発生します。デフォルトのアラートルールテンプレートを確認し、アラートのソースを特定して必要なサービスを有効にしてください。
|
アラートデータソース |
設定要件 |
課金詳細 |
|
Log Service SLS |
イベントモニタリングを有効にします。アラート機能を有効にすると、イベントモニタリングはデフォルトで有効になります。 |
|
|
Managed Service for Prometheus |
ご利用のクラスターに対して Managed Service for Prometheus を設定します。 |
無料 |
|
CloudMonitor |
ご利用の ACK クラスターに対して CloudMonitor を有効にします。 |
アラート管理の有効化
クラスターリソースのメトリックアラートを設定し、異常が発生した際に自動的に通知を受け取ることで、より効率的なクラスター管理と安定したサービスオペレーションを実現できます。リソースアラートの詳細については、「デフォルトのアラートルールテンプレート」をご参照ください。
ACK マネージドクラスター
既存のクラスターまたは新規クラスター作成時にアラート設定を有効にできます。
既存のクラスター
ACK コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。
クラスターリスト ページで、ご利用のクラスター名をクリックします。左側のナビゲーションウィンドウで、 をクリックします。
-
アラート ページで、画面上の指示に従って必要なコンポーネントをインストールまたはアップグレードします。
-
インストールまたはアップグレード後、アラート ページに移動してアラートを設定します。
タブ
説明
アラートルール
-
ステータス：アラートルールセットを有効または無効にします。
-
連絡先グループの編集：アラート通知の連絡先グループを設定します。
通知は連絡先グループのみに送信されます。事前に連絡先とグループを作成してください。個人に通知する場合は、その連絡先専用のグループを作成します。
アラート履歴
過去 24 時間以内の最大 100 件のアラートレコードを表示します。
-
アラートルール 列のリンクをクリックして、対応するモニタリングシステムのルール設定を表示します。
-
詳細 をクリックして、異常に関連するリソースページに移動します。
-
インテリジェント分析 をクリックして、AI による問題分析とトラブルシューティングを実行します。
アラート連絡先
連絡先の作成、編集、または削除を行います。
連絡方法：
-
音声通話/SMS：連絡先に携帯電話番号を設定して、音声通話および SMS でアラート通知を受け取ります。
音声通話通知を受信できるのは、検証済みの携帯電話番号のみです。「携帯電話番号の検証」をご参照ください。
-
メール：連絡先にメールアドレスを設定して、アラート通知を受け取ります。
-
チャットボット：DingTalk チャットボット、WeCom チャットボット、および Lark チャットボット。
DingTalk チャットボットの場合、セキュリティキーワードとして「alert」「dispatch」を追加してください。
メールおよびチャットボット通知は、CloudMonitor コンソールの で事前に検証してください。
アラート連絡先グループ
連絡先グループの作成、編集、または削除を行います。
連絡先グループが存在しない場合、コンソールは Alibaba Cloud アカウントからデフォルトのグループを作成します。
-
新規クラスター
クラスター作成時、コンポーネント設定 ページで、アラート を選択し、続けて デフォルトのアラートテンプレートを使用 を選択します。アラート通知連絡先グループ を選択します。「ACK マネージドクラスターの作成」をご参照ください。
アラート設定を有効にすると、デフォルトルールが適用され、デフォルトの連絡先グループが通知を受け取ります。アラート連絡先または連絡先グループを変更できます。
ACK 専用クラスター
ACK 専用クラスターでは、デフォルトのアラートルールを有効にする前に、Worker RAM ロールに権限を付与する必要があります。
Worker RAM ロールへの権限付与
ACK コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。
クラスターリスト ページで、ご利用のクラスター名をクリックします。左側のナビゲーションウィンドウで、クラスター情報 をクリックします。
-
クラスター情報 ページの クラスターリソース セクションで、Worker RAM ロール の横にある名前をコピーし、リンクをクリックして RAM コンソールを開きます。
-
以下のカスタムポリシーを作成します。「カスタムポリシーの作成」をご参照ください。
{ "Action": [ "log:*", "arms:*", "cms:*", "cs:UpdateContactGroup" ], "Resource": [ "*" ], "Effect": "Allow" } -
役割 ページで Worker RAM ロールを見つけ、カスタムポリシーをアタッチします。「RAM ロールの権限管理」をご参照ください。
注：この例では簡略化のために広範な権限を使用しています。本番環境では、最小権限の原則に従ってください。
-
-
アラート権限が正しく設定されていることを確認します。
-
クラスター管理ページの左側ナビゲーションウィンドウで、 を選択します。
-
名前空間 ドロップダウンリストから
kube-systemを選択し、名前 列で alicloud-monitor-controller をクリックします。 -
ログ タブをクリックして、正常な権限付与を示すポッドログを確認します。
-
デフォルトのアラートルールの有効化
-
クラスターページの左側ナビゲーションウィンドウで、操作 > アラート を選択します。
-
アラート ページで、アラート設定を構成します。
タブ
説明
アラートルール
-
ステータス：アラートルールセットを有効または無効にします。
-
連絡先グループの編集：アラート通知の連絡先グループを設定します。
通知は連絡先グループのみに送信されます。事前に連絡先とグループを作成してください。個人に通知する場合は、その連絡先専用のグループを作成します。
アラート履歴
過去 24 時間以内の最大 100 件のアラートレコードを表示します。
-
アラートルール 列のリンクをクリックして、対応するモニタリングシステムのルール設定を表示します。
-
詳細 をクリックして、異常に関連するリソースページに移動します。
-
インテリジェント分析 をクリックして、AI による問題分析とトラブルシューティングを実行します。
アラート連絡先
連絡先の作成、編集、または削除を行います。
連絡方法：
-
音声通話/SMS：連絡先に携帯電話番号を設定して、音声通話および SMS でアラート通知を受け取ります。
音声通話通知を受信できるのは、検証済みの携帯電話番号のみです。「携帯電話番号の検証」をご参照ください。
-
メール：連絡先にメールアドレスを設定して、アラート通知を受け取ります。
-
チャットボット：DingTalk チャットボット、WeCom チャットボット、および Lark チャットボット。
DingTalk チャットボットの場合、セキュリティキーワードとして「alert」「dispatch」を追加してください。
メールおよびチャットボット通知は、CloudMonitor コンソールの で事前に検証してください。
アラート連絡先グループ
連絡先グループの作成、編集、または削除を行います。
連絡先グループが存在しない場合、コンソールは Alibaba Cloud アカウントからデフォルトのグループを作成します。
-
アラートルールの設定
アラート設定を有効にすると、kube-system 名前空間に default という名前の AckAlertRule CRD リソースがデフォルトのアラートルールテンプレートとともに作成されます。この CRD を変更して、アラートルールをカスタマイズできます。
コンソール
ACK コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。
クラスターリスト ページで、ご利用のクラスター名をクリックします。左側のナビゲーションウィンドウで、 をクリックします。
-
アラートルール タブで、右上隅の アラートルールの設定 をクリックします。次に、対象のルールの アクション 列で YAML をクリックして、
AckAlertRuleCRD リソースの設定を表示します。 -
YAML ファイルを変更します。パラメーターの詳細については、「デフォルトのアラートルールテンプレート」をご参照ください。
以下は、アラートルールの YAML 設定の例です。
rules.thresholdsを使用して、アラートのしきい値をカスタマイズできます。たとえば、上記の設定では、ノードの CPU 使用率が 85% を 3 回連続で超過し、かつ前回のアラートから 900 秒以上経過した場合にアラートがトリガーされます。パラメーター
必須
説明
デフォルト
CMS_ESCALATIONS_CRITICAL_Thresholdはい
アラートルールのしきい値。このパラメーターを省略すると、ルールの同期に失敗し、ルールは無効になります。
-
unit：しきい値の単位。有効な値：percent、count、および qps。 -
value：しきい値の値。
デフォルトのアラートルールテンプレートに基づいて異なります。
CMS_ESCALATIONS_CRITICAL_Times任意
CloudMonitor がアラートをトリガーする前に、条件が連続して満たされる必要がある回数。このパラメーターを省略すると、デフォルト値が使用されます。
3
CMS_RULE_SILENCE_SEC任意
初期アラートが報告された後、継続的にトリガーされる CloudMonitor ルールに対するサイレンス期間（秒）。これにより、アラート疲弊を防ぎます。このパラメーターを省略すると、デフォルト値が使用されます。
900
-
CLI
-
アラートルールの YAML ファイルを編集します。
kubectl edit ackalertrules default -n kube-system -
YAML ファイルを変更し、保存して終了します。パラメーターの詳細については、「デフォルトのアラートルールテンプレート」をご参照ください。
rules.thresholdsを使用して、アラートのしきい値をカスタマイズできます。たとえば、上記の設定では、ノードの CPU 使用率が 85% を 3 回連続で超過し、かつ前回のアラートから 900 秒以上経過した場合にアラートがトリガーされます。パラメーター
必須
説明
デフォルト
CMS_ESCALATIONS_CRITICAL_Thresholdはい
アラートルールのしきい値。このパラメーターを省略すると、ルールの同期に失敗し、ルールは無効になります。
-
unit：しきい値の単位。有効な値：percent、count、および qps。 -
value：しきい値の値。
デフォルトのアラートルールテンプレートに基づいて異なります。
CMS_ESCALATIONS_CRITICAL_Times任意
CloudMonitor がアラートをトリガーする前に、条件が連続して満たされる必要がある回数。このパラメーターを省略すると、デフォルト値が使用されます。
3
CMS_RULE_SILENCE_SEC任意
初期アラートが報告された後、継続的にトリガーされる CloudMonitor ルールに対するサイレンス期間（秒）。これにより、アラート疲弊を防ぎます。このパラメーターを省略すると、デフォルト値が使用されます。
900
-
デフォルトのアラートルールテンプレート
以下のアラートは、Log Service、Prometheus Service、および CloudMonitor から同期されます。アラート ページの アラート 列で、詳細設定 をクリックしてルール設定を表示できます。
アラートのトラブルシューティング
ディスク圧迫による Pod エビクション
アラートメッセージ
(類似イベントをまとめました): 必要な量のイメージのガベージコレクトに失敗しました。XXX バイトの解放を試みましたが、解放可能なバイト数は 0 バイトでした症状
Pod ステータスが Evicted です。ノードにディスク圧迫が発生しています (The node had condition: [DiskPressure].)。
原因
ノードのディスク使用率がエビクションしきい値（デフォルト 85%）に達すると、kubelet が圧迫ベースのエビクションを開始し、イメージのガベージコレクションを実行し、場合によっては Pod をエビクトします。対象ノードにログインして、df -h コマンドを実行してディスク使用率を確認してください。
解決方法
-
対象ノード（containerd ランタイム）にログインし、次のコマンドを実行して未使用のイメージを削除します。
crictl rmi --prune -
ログをクリーンアップするか、ノードのディスク容量を拡張します。
-
ノードディスクのスナップショットを作成し、不要なファイルを削除します。「Linux インスタンスのディスクフル問題の解決」をご参照ください。
-
ノードのシステムディスクまたはデータディスクをオンラインで拡張して、ストレージ容量を増やします。
-
-
関連するしきい値を調整します。
-
kubelet のイメージガベージコレクションしきい値を調整して、Pod エビクションを減らします。「ノードプールの kubelet 設定のカスタマイズ」をご参照ください。
-
デフォルトのアラートしきい値は 85% です。アラートルールの設定で、
node_disk_util_highアラートルールを変更します。
-
推奨事項と予防策
-
ノードが頻繁にこのアラートをトリガーする場合は、アプリケーションのストレージ要件を評価し、ノードディスク容量を適切に計画してください。
-
ノードストレージモニタリングダッシュボードを通じて、定期的にストレージ使用量を監視してください。
Pod OOMKilling
アラートメッセージ
pod was OOM killed. node:xxx pod:xxx namespace:xxx uuid:xxx
症状
Pod ステータスが異常で、イベント詳細に PodOOMKilling が含まれています。
解決方法
メモリ不足 (OOM) イベントは、ノードレベルまたはコンテナ cgroup レベルでトリガーされる可能性があります。
-
原因：
-
コンテナ cgroup レベルの OOM：Pod のメモリ使用量が設定された制限を超えたため、Kubernetes が終了させました。
-
ノードレベルの 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 killer イベントの原因と解決策」をご参照ください。
Pod が CrashLoopBackOff 状態
Pod 内のプロセスが予期せず終了すると、ACK はそれを再起動します。Pod が安定しない状態を繰り返すと、CrashLoopBackOff 状態になります。次のようにトラブルシューティングを行ってください。
ACK コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。
クラスターリスト ページで、ご利用のクラスター名をクリックします。左側のナビゲーションウィンドウで、 をクリックします。
-
影響を受ける Pod を見つけ、詳細 を アクション 列でクリックします。
-
イベント タブで、異常イベントの詳細を確認します。
-
ログ タブで、失敗の原因を確認します。
説明Pod が再起動している場合は、最後のコンテナーが終了した時のログを表示する を選択してください。
コンソールには最新の 500 件のエントリのみが表示されます。古いログについては、ログ永続化を設定してください。