
AUTO_REPAIR_NODES
過去 1 か月間に、GKE クラスターで 4 つのイベント (コマンドによって明らかに)が発生しましたgcloud container operations list
。ノード自動修復の結果、ノードが再作成され、新しい外部 IP が割り当てられましたが、サードパーティのサービスによってホワイトリストに登録されていない新しい外部 IP によって、新しいノードで実行されているサービスに最終的に障害が発生しました。
「自動ノード修復Kubernetes クラスターで有効になっており、無効にしたいと思いましたが、その前に状況を詳しく知る必要があります。
私の質問は次のとおりです:
- そもそもノードが不健全になる一般的な原因は何ですか?この記事は知っていますhttps://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-repair#node_repair_process「ノードは準備ができていない指定された時間しきい値を超える連続チェックでステータスが「0」になると自動修復がトリガーされます。しかし、ノードが準備ができていない?
- 私もこの記事を知っていますノードステータスこれには、ノード ステータスの完全なリストが記載されています: {OutOfDisk、Ready、MemoryPressure、PIDPressure、DiskPressure、NetworkUnavailable、ConfigOK}。ノードに対して {OutOfDisk、MemoryPressure、PIDPressure、DiskPressure、NetworkUnavailable} のいずれかが true になった場合、そのノードは NotReady になるのでしょうか?
- クラスターで「自動ノード修復」を無効にすると、どのような悪影響が生じる可能性がありますか?私は基本的に、自動修復されたノードと新しく接続されたホワイトリストに登録されていないIPよりも悪い状況に陥る可能性があるかどうか疑問に思っています。「自動ノード修復」が無効になると、自動修復されるはずだった不健全なノードで実行されているポッドに対して、Kubernetes は他のノードに新しいポッドを作成しますか?
答え1
マスターは基本的にノードのヘルス チェックを実行します。ノードが応答できない場合、またはノードが NotReady であると宣言した場合は、ノードの自動修復によって修復されます。GKE ノードには、OS の問題を検出できるノード問題検出器もあります。
上記のいずれかの条件により、ノードが NotReady 状態になる可能性があります。OS レベルでのエラーの繰り返しなど、他の要因も考えられます。
ノードの自動修復をオフにすると、ノードがNotReady状態になり、そのままの状態が続く可能性があります。多くの場合、ノードはポッドまたはプロセスを強制終了することで問題に対処しようとしますが、ノードがNotReady状態のままになる可能性もあります。
ノードの自動修復を無効にするのではなく、ホワイトリストの要件に応じて設定を変更することをお勧めします。代わりに、すべてのGKE送信トラフィック用のNATゲートウェイを設定する; NAT に静的 IP を割り当てて、その IP をホワイトリストに登録することだけを心配することができます。ノードが IP を変更することを心配する必要はなくなります。