Kubernetes リソース アラート

k8s.rules、kube-apiserver-availability.rules、kube-apiserver-slos

KubeAPIErrorBudgetBurn

Kubernetes API サーバーの消費しているエラー バジェットが多すぎます。

kube-state-metrics

KubeStateMetricsListErrors, KubeStateMetricsWatchErrors

kube-state-metrics コレクターがクラスターからメトリックを収集しようとすると必ずエラーが発生します。これは、重要なアラートが発生しない可能性があることを意味します。UiPath® サポートにお問い合わせください。

公開中の kube-state-metrics もご覧ください。

KubernetesMemoryPressure

このアラートは、Kubernetes ノードでのメモリ使用量が非常に高いことを示しています。

インシデントの種類 MemoryPressure Kubernetes ノードは、Kubernetes クラスター ノードのメモリが不足している場合に発生し、アプリケーションのメモリ リークが原因である可能性があります。 この種類のインシデントでは、ダウンタイムを防ぎ、Kubernetes クラスターが適切に機能するように、早急な対応が必要です。

このアラートが発生した場合は、以下の手順を実行して、より多くのメモリを消費しているノード上のポッドを特定してみてください。

1. ノードの CPU とメモリの統計情報を取得します。

   kubectl top node

2. ノードで実行されているポッドを取得します。

   kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=${NODE_NAME}

3. 名前空間内のポッドのメモリ使用量を確認するには、以下を使用します。

   kubectl top pod --namespace <namespace>
   kubectl logs -f <pod-name> -n <ns>

メモリ使用量が多いポッドを特定できる場合は、そのポッドのログをチェックして、メモリ リーク エラーを探します。

この問題を解決するには、可能であればノードのメモリ仕様を増やします。

問題が解決しない場合は、 サポート バンドル を生成して UiPath® サポートにお問い合わせください。

kubernetes-apps

KubePodCrashLooping

予期せず再起動を繰り返すポッドです。メモリ不足 (OOM) エラーが原因で発生する可能性があり、その場合には制限を調整できます。kubectl describe でポッド イベントをチェックし、kubectl logs でログを記録して考えられるクラッシュの詳細を確認します。問題が解決しない場合は UiPath® サポートにお問い合わせください。

KubePodNotReady

ポッドは起動していますが、正常性プローブに応答できていません。ポッドがスタックし、トラフィックを処理できないことを意味している可能性があります。kubectl logs でポッド ログをチェックして、進展がないか確認できます。問題が解決しない場合は UiPath® サポートにお問い合わせください。

KubeDeploymentGenerationMismatch, KubeStatefulSetGenerationMismatch

デプロイまたはステートフルセットの更新が試行されていますが、失敗しており、ロールバックがまだ発生していません。UiPath® サポートにお問い合わせください。

KubeDeploymentReplicasMismatch, KubeStatefulSetReplicasMismatch

複数のレプリカを持つ高可用性クラスターでは、レプリカの数が最適でない場合に、このアラートが発生します。クラスター内にスケジュールするためのリソースが十分にない場合に発生する可能性があります。リソースの使用状況をチェックし、必要に応じて容量を追加します。それ以外の場合は、UiPath® サポートにお問い合わせください。

KubeStatefulSetUpdateNotRolledOut

ステートフルセットの更新に失敗しました。UiPath® サポートにお問い合わせください。

「StatefulSets」もご覧ください。

KubeDaemonSetRolloutStuck

デーモンセットのロールアウトに失敗しました。UiPath® サポートにお問い合わせください。

「DaemonSet」もご覧ください。

KubeContainerWaiting

待機中のステートでコンテナーがスタックしています。ワーカー ノードにスケジュールされていますが、そのマシン上で実行できません。詳細については、ポッドの kubectl describe をチェックしてください。コンテナーが待機中になる最も一般的な原因は、イメージのプルの失敗です。エアギャップ クラスターの場合は、ローカル レジストリが利用できないことを意味している可能性があります。問題が解決しない場合は UiPath® サポートにお問い合わせください。

KubeDaemonSetNotScheduled, KubeDaemonSetMisScheduled

いずれかのノードの問題を示している可能性があります。各ノードの正常性をチェックし、既知の問題を修正してください。それ以外の場合は、UiPath® サポートにお問い合わせください。

KubeJobCompletion

ジョブの完了までの時間が 12 時間を超えています。これは想定外です。UiPath® サポートにお問い合わせください。

KubeJobFailed

ジョブが失敗しましたが、ほとんどのジョブは自動的にリトライされます。問題が解決しない場合は UiPath® サポートにお問い合わせください。

KubeHpaReplicasMismatch

オートスケーラーがターゲットのリソースを構成どおりにスケーリングできません。実際の値よりも要求値のほうが大きい場合は、リソース不足の可能性があります。実際の値よりも要求値のほうが小さい場合は、シャットダウン中にポッドがスタックしている可能性があります。問題が解決しない場合は UiPath® サポートにお問い合わせください。

「Horizontal Pod Autoscaling」もご覧ください。

KubeHpaMaxedOut

指定されたサービスのレプリカの数が最大数に達しています。これは、クラスターに対する要求の数が非常に多い場合に発生します。高いトラフィックが予想される場合、一時的には、このアラートを抑制できます。ただし、このアラートは、クラスターがフル稼働で、それ以上のトラフィックを処理できないということを示しています。さらに多くのリソース容量がクラスターで利用できる場合は、以下の操作を実行してサービスの最大レプリカ数を増やすことができます。

# Find the horizontal autoscaler that controls the replicas of the desired resource
kubectl get hpa -A
# Increase the number of max replicas of the desired resource, replacing <namespace> <resource> and <maxReplicas>
kubectl -n <namespace> patch hpa <resource> --patch '{"spec":{"maxReplicas":<maxReplicas>}}'

「Horizontal Pod Autoscaling」もご覧ください。

kubernetes-resources

KubeCPUOvercommit, KubeMemoryOvercommit

これらの警告は、クラスターがノードの障害に耐えられないことを示しています。シングルノードの評価クラスターの場合、これは既知であり、これらのアラートは抑制できます。マルチノードの HA 対応の運用環境の設定の場合、あまりにも多くのノードが異常になって高可用性をサポートできないときにこれらのアラートが発生し、ノードを正常に戻すか交換する必要があることを示します。

KubeCPUQuotaOvercommit, KubeMemoryQuotaOvercommit, KubeQuotaAlmostFull, KubeQuotaFullyUsed, KubeQuotaExceeded

これらのアラートは、カスタマイズを通じて追加された場合にのみクラスターに存在する、名前空間のリソース クォータに関連します。名前空間のリソース クォータは、Automation Suite のインストールの一環として追加されません。

「リソース クォータ」もご覧ください。

AggregatedAPIErrors, AggregatedAPIDown, KubeAPIDown, KubeAPITerminatedRequests

Kubernetes コントロール プレーンに問題があることを示しています。マスター ノードの正常性をチェックし、未解決の問題を解決します。問題が解決しない場合は、UiPath® サポートにお問い合わせください。

以下の記事もご覧ください。

The Kubernetes API (Kubernetes API)

Kubernetes API Aggregation Layer (アグリゲーション レイヤーを使った Kubernetes API の拡張)

kubernetes-system-kubelet

KubeNodeNotReady, KubeNodeUnreachable, KubeNodeReadinessFlapping, KubeletPlegDurationHigh, KubeletPodStartUpLatencyHigh, KubeletDown

これらのアラートは、ノードに問題があることを示しています。マルチ モードの HA 対応の運用クラスターにおいて、ポッドが他のノードにスケジュール変更される可能性があります。問題が解決しない場合は、ノードの削除およびドレインを行い、クラスターの正常性を維持する必要があります。容量が追加されていないクラスターでは、まず別のノードをクラスターに参加させる必要があります。

問題が解決しない場合は UiPath® サポートにお問い合わせください。

KubeletTooManyPods

指定したノードで実行されているポッドが多すぎます。

クラスターに別のノードを参加させます。

kubernetes-system

KubeVersionMismatch

異なるセマンティック バージョンの Kubernetes コンポーネントが実行中です。これは、Kubernetes のアップグレードに失敗した結果として生じることがあります。

KubeClientErrors

Kubernetes API サーバー クライアントでのエラー発生率が 1% を超えています。このクライアントが実行されているノード、またはKubernetes API サーバー自体に問題がある可能性があります。

etdc のアラート

EtcdInsufficientMembers

このアラートは、etcd クラスターのメンバー数が不十分であることを示します。クラスターのメンバー数は奇数である必要があります。このアラートの重要度は「Critical」です。

クラスター内のサーバー ノード数が奇数で、すべてのノードが正常に動作していることを確認してください。

EtcdNoLeader

このアラートは、etcd クラスターにリーダーがないことを示しています。このアラートの重要度は「Critical」です。

EtcdHighNumberOfLeaderChanges

このアラートは、etcd リーダーが 10 分間で 2 回以上変わることを示します。このアラートの重要度は「Warning」です。

EtcdHighNumberOfFailedGrpcRequests

このアラートは、etcd で一定の割合の GRPC 要求の失敗が検出されたことを示します。

EtcdGrpcRequestsSlow

このアラートは、etcd の GRPC 要求が低速であることを示します。このアラートの重要度は「Warning」です。

このアラートが解決しない場合は UiPath® サポートにお問い合わせください。

EtcdHighNumberOfFailedHttpRequests

このアラートは、etcd で一定の割合の HTTP エラーが検出されたことを示します。

EtcdHttpRequestsSlow

このアラートは、HTTP 要求の速度が低下していることを示します。このアラートの重要度は「Warning」です。

EtcdMemberCommunicationSlow

このアラートは etcd メンバーの通信が遅くなっていることを示します。このアラートの重要度は「Warning」です。

EtcdHighNumberOfFailedProposals

このアラートは、etcd サーバーが過去 1 時間に 5 件以上の提案に失敗したことを示します。このアラートの重要度は「Warning」です。

EtcdHighFsyncDurations

このアラートは、etcd の WAL fysnc 期間が増加していることを示します。このアラートの重要度は「Warning」です。

EtcdHighCommitDurations

このアラートは、etcd のコミット期間が増加していることを示します。このアラートの重要度は「Warning」です。

kube-api

KubernetesApiServerErrors

このアラートは、Kubernetes API サーバーのエラー率が高いことを示しています。この問題は他の障害につながる可能性があるため、問題を事前に調査することをお勧めします。

kubectl logs <pod-name> -n kube-system コマンドを使用してapi-server ポッドのログを確認し、問題の根本原因を特定します。