大規模なクラスター内のノードでポッドの起動を高速化するにはどうすればよいですか? これは、エンタープライズ クラスター管理者が直面する一般的な質問です。
このブログ投稿では、kubelet 側からポッドの起動を高速化する方法に焦点を当てています。この方法では、kube-apiserver 経由でコントローラーマネージャーによってポッドが作成されるまでの時間はカバーされていません。また、ポッドがスケジュールされる時期やポッド上で Webhook が実行される時期も含まれません。
この記事では、kubelet の観点から考察し、いくつかの重要な影響要因について言及していますが、すべてのインセンティブを詳細にリストしているわけではありません。さらに、Kubernetes v1.27 が正式にリリースされました。この記事では、 ポッドの起動を高速化するのに役立つ v1.27 のいくつかの大きな変更点を取り上げます。
https://kubernetes.io/blog/ では、近い将来、このブログ投稿の中国語版と英語版も公開される予定であることに注目してください。まず、エキサイティングなコンテンツを見てみましょう。
01
コンテナ
イメージの並列プル
イメージのプルには常に時間がかかります。さらに悪いことに、イメージのプルはデフォルトでシリアルに動作することです。つまり、kubelet は一度に 1 つのイメージ プル リクエストのみをイメージ サービスに送信します。他のイメージ プル リクエストは、進行中のプル リクエストが完了するまで待つ必要があります。
並列イメージのプルを有効にするには、kubelet 構成で SerializeImagePulls フィールドを false に設定します。SerializeImagePulls が無効になっている場合、イメージ プル リクエストはイメージ サービスに即座に送信され、複数のイメージを並行してプルできます。
1.1 並列イメージ プルの最大値を設定すると、イメージ プルによるノードの過負荷を防ぐことができます
ノード レベルで並列イメージのプルに制限を設定する新しい機能を kubelet に導入しました 。この制限により、同時に取得できるイメージの最大数が制限されます。イメージ プル リクエストがこの制限を超えると、進行中のイメージ プルのいずれかが完了するまでリクエストはブロックされます。この機能を有効にする前に、コンテナー ランタイムのイメージ サービスが並列イメージ プルを効率的に処理できることを確認してください。
並列イメージ プルの数を制限するには、kubelet で maxParallelImagePulls フィールドを構成します。maxParallelImagePulls の値を n に設定した後は、並列にプルされるイメージの数が n を超えることはできません。この制限を超える追加のイメージ プル リクエストは、少なくとも 1 つの進行中のプルが完了するまで待つ必要があります。
詳細については、関連する KEP: Kubelet 並列イメージのプル制限 (KEP-3673) を参照してください。
02
1 秒あたりのkubelet の
デフォルト API クエリ値を増やします。
ノード上に複数のポッドがあるシナリオ、特に突然のスケーリングの場合にポッドの起動を高速化するには、kubelet でポッドの状態を同期し、ConfigMap、Secret、またはボリュームを準備する必要があります。これには、kube-apiserver にアクセスするために大きな帯域幅が必要です。
v1.27 より前のバージョンでは、kubeAPIQPS のデフォルト値は 5、kubeAPIBurst のデフォルト値は 10 でした。ただし、v1.27 では、ポッドの起動パフォーマンスを向上させるために、kubelet はこれらのデフォルトをそれぞれ 50 と 100 に増やしました。kubelet の API QPS 制限を増やすことだけが理由ではないことに注意してください。
1. 大幅にスロットルされる可能性があります (デフォルトの QPS = 5)。
2. 大規模なクラスターでは、クラスターの数が多いため、依然としてかなりの負荷が発生する可能性があります。
3. 専用の PriorityLevel と FlowSchema があり、簡単に制御できます
以前は、50 以上のポッドを持つノードで、ポッドの起動中に kubelet でボリューム マウント タイムアウトが発生することがよくありました。特にベア メタル ノードを使用する場合は、クラスター オペレーターが kubeAPIQPS を 20 に、kubeAPIBurst を 40 に増やすことをお勧めします。
詳細については、KEP https://kep.k8s.io/1040 および PR#116121 を参照してください。
03
イベント駆動型の
コンテナ状態更新
v1.27 では、Evented PLEG (PLEG とは英語で Pod Lifecycle Event Generator の略で、「ポッド ライフサイクル イベント ジェネレーター」を意味します) がベータ段階に進みました。Kubernetes は、 kubelet がコンテナ内の最後のプロセスのシャットダウンなどのPod ライフサイクル イベントを検出するための 2 つの方法を提供します。Kubernetes v1.27 では、イベントベースのメカニズムがベータ版に進化しましたが、デフォルトでは無効になっています。イベントベースのライフサイクル変更検出に明示的に切り替えると、kubelet はポーリングに依存するデフォルトの方法よりも速くポッドを開始できます。有効期間の変更に対するデフォルトのポーリング メカニズムは大幅なオーバーヘッドを追加し、さまざまなタスクを処理する kubelet の能力の並列性に影響を与え、パフォーマンスと信頼性の問題を引き起こします。これらの理由から、イベントベースのポッドライフサイクル変更検出を使用するようにノードを切り替えることをお勧めします。
詳細については、KEP https://kep.k8s.io/3386 と、コンテナーのステータスをポーリングから CRI イベントベースの更新に切り替えるを参照してください。
04
必要に応じて
ポッドのリソース制限を引き上げる
一部のポッドは起動時に大量の CPU またはメモリを消費する場合があります。CPU 制限が低い場合、ポッドの起動プロセスが大幅に遅くなる可能性があります。メモリ管理を改善するために、Kubernetes v1.22 ではMemoryQoS と呼ばれる機能ゲートが導入されました。この機能により、kubelet はコンテナー、ポッド、および QoS レベルでメモリー QoS を設定し、メモリー品質をより適切に保護および確保できるようになります。この機能ゲートの利点にもかかわらず、ポッドの起動で大量のメモリを消費する場合、この機能ゲートを有効にするとポッドの起動速度に影響する可能性があります。
Kubelet 構成には、memoryThrottlingFactor が含まれるようになりました。この係数にはメモリ制限またはノードの割り当て可能なメモリが乗算され、cgroupv2memory.high 値を設定して MemoryQoS を強制できます。この係数を減らすと、コンテナー cgroup の上限が低くなり、回収圧力が増加します。この係数を増やすと、回復圧力が低下します。デフォルトは元々 0.8 でしたが、Kubernetes v1.27 では 0.9 に変更されます。このパラメーターを調整すると、この機能がポッドの起動速度に及ぼす潜在的な影響を軽減できます。
詳細については、KEP https://kep.k8s.io/2570 を参照してください。
05
さらに詳しい説明
Kubernetes v1.26 では、ポッド開始遅延 SLI/SLO の詳細を表示するために、pod_start_sli_duration_seconds という名前の新しいヒストグラム インジケーターが追加されました。さらに、kubelet ログには、次のようにポッドの起動に関連するタイムスタンプがさらに表示されるようになりました。
Dec 30 15:33:13.375379 e2e-022435249c-674b9-minion-group-gdj4 kubelet[8362]: I1230 15:33:13.375359 8362
pod_startup_latency_tracker.go:102] "Observed pod startup duration" pod="kube-system/konnectivity-agent-gnc9k"
podStartSLOduration=-9.223372029479458e+09 pod.CreationTimestamp="2022-12-30 15:33:06 +0000 UTC"
firstStartedPulling="2022-12-30 15:33:09.258791695 +0000 UTC m=+13.029631711"
lastFinishedPulling="0001-01-01 00:00:00 +0000 UTC"
observedRunningTime="2022-12-30 15:33:13.375009262 +0000 UTC m=+17.145849275"
watchObservedRunningTime="2022-12-30 15:33:13.375317944 +0000 UTC m=+17.146157970"SELinux マウント オプションの再ラベル付けは、v1.27 でベータ版になりました。この機能は、ボリューム上のすべてのファイルを再帰的に変更するのではなく、正しい SELinux ラベルを使用してボリュームをマウントすることにより、コンテナーの起動を高速化します。詳細については、KEP https://kep.k8s.io/1710 を参照してください。
ポッドの起動が遅い理由を判断するには、コンテナーのランタイム、ディスク速度、ノード上の CPU およびメモリ リソースなど、ポッドの起動に影響を与える可能性のある他の要因を確認するなど、メトリクスとログを分析すると役立つ場合があります。
SIG ノードはポッドが迅速に起動するようにする責任を負いますが、大規模なクラスターの問題の解決は SIG スケーラビリティの範囲内にあります。
この記事の著者
シュ・ジュンジエ・パコ
「DaoCloud Daoke」アーキテクト / ADチームリーダー
Kubernetes Kubeadm「SIG Cluster-Lifecycle」と SIG ノード、レビューアー
翻訳者
ヤオ・ハイフェン
「DaoCloud Daoke」シニアドキュメントエンジニア
K8s-zh-owner、Istio メンテナー、otel などのメンバー