Kubernetesのようなツールは高可用性を提供し、このようなシナリオでの信頼性の高い操作と自動回復のために設計されており、Kubernetesはそれをすべてうまく実行します。
ただし、ノードが落ちても、壊れたノードの炉床はしばらくの間動作し続け、実行されなくなった要求を受信します。
そして、デフォルトでは、今回はそれが長すぎるようです-減らすことができます。 KubeletおよびController Managerで構成されたいくつかのパラメーターの影響を受けます。
以下は、ノードが落ちたときに発生するプロセスの説明です。
1 Kubeletは、ステータスを-node-status-update-frequency = 10sでウィザードに送信します。
2 。 Kubernetesのノードは死にかけています。
３ 。 間隔-node-monitor-period = 5sでノードを監視するkube-controller-managerデーモンは、ウィザードでKubeletから受信したノードのステータスをチェックします。
4 。 Kube-controller-managerはノードが応答していないことを確認し、ソフトインターバル中に-node-monitor-grace-period = 40sはノードに問題があると見なされるかどうかを予測します。 このパラメーターは、 node-status-update-frequencyにNを掛けた値に等しくする必要があります。Nは、Kubeletがノードのステータスを送信することを許可する回数です。 Nは、コードで値5が定義されている定数です（ kubelet / kubelet.goの変数nodeStatusUpdateRetryを参照） 。
次の理由により、デフォルト値はドキュメントの内容と一致しないことに注意してください。
ノード状態更新頻度×N！=ノード監視猶予期間（10×5！= 40）
私が理解する限り、5回のステータス送信試行（それぞれ10秒）は40秒で完了します。これは、1回目はすぐに実行され、2回目以降は10秒実行されるためです。 その結果、40秒で5回の試行が完了します。
つまり、実際の式は次のとおりです。
ノード状態更新頻度×（N-1）！=ノード監視猶予期間
詳細は、コードcontroller / node / nodecontroller.goで確認できます。
5 。 ノードに問題があるとマークされている場合、kube-controller-managerは-pod-eviction-timeout = 5m0sパラメーターを使用してポッドを削除します 。
これは非常に重要なタイムアウトであり、デフォルトでは5分です。これは私の意見では非常に重要です。 ノードにはすでに問題があるとマークされていますが、kube-controller-managerは指定された時間内にポッドを削除しないため、サービスを介してポッドを使用できますが、それらに対する要求は実行されません。
6 。 Kube-proxyはAPIを通じて常にステータスを監視するため、ポッドが無効になった瞬間にすぐに気付き、ノードのiptablesルールを更新します。その後、倒れたポッドは使用できなくなります。
したがって、前述の値を変更して、ノードが落ちたときに未処理の要求の数を減らすことができます。
Kubernetesクラスターでは、次のように構成しました。
- kubelet ： node-status-update-frequency = 4s （10秒ではなく）
- controller-manager ： node-monitor-period = 2s （5 秒ではなく）
- controller-manager ： node-monitor-grace-period = 16秒 （40 秒ではなく）
- controller-manager ： pod-eviction-timeout = 30s （5mではなく）
結果は十分良好です。ノードのドロップは5分40秒ではなく、46秒で決定されます。
PS翻訳者から：ネットワーク構成（1つまたは異なるデータセンター、1つのラックなど）に応じて自分自身の最適値を選択し、実験で得られた調査結果（つまり最適値）を共有する計画。