KEP から眺める Kubernetes

Copyrights©3-shake Inc. All Rights Reserved. KEP から眺める Kubernetes 2023/7/19 Kubernetes
Meetup Tokyo #59 (30 min)

Copyrights©3-shake Inc. All Rights Reserved. 2 Tsubasa Nagasawa (@toversus26) 株式会社スリーシェイク
Sreake 事業部スマホ向けゲームの Kubernetes エンジニアを経て、 2023 年 3 月から SRE 見習いをやっています。 Kubernetes やエコシステム周りを観察するのが好きです。 SIG Network をメインで見ています。 whoami

Copyrights©3-shake Inc. All Rights Reserved. 3 Table of Contents •
KEP-3673: Kubelet limit of Parallel Image Pulls (~ 2min) • KEP-3063: Dynamic Resource Allocation (~ 5min) • KEP-3960: Sleep Action for PreStop Hook (~ 2min) • KEP-753: Sidecar Containers (~ 8min) • Official support for restoring Kubernetes cluster • Migrate Karpenter Core to SIG Autoscaling Subproject (~ 2min) • Revive WG-LTS (~ 5min) • KEP-2433: Topology Aware Routing (~ 8min)

Copyrights©3-shake Inc. All Rights Reserved. 4 今日話す内容に関わる KEP • KEP-3673:
Kubelet limit of Parallel Image Pulls • KEP-3573: Device Plugins • KEP-3063: Dynamic Resource Allocation • KEP-3960: Sleep Action for PreStop Hook • KEP-753: Sidecar Containers • KEP-2872: Keystone containers • KEP-3582: Terminate pod on container completion • KEP-3935: Support Oldest Node And Newest Control Plane • KEP-3008: QoS Class Resource • KEP-3744: Stay on supported go versions • KEP-2433: Topology Aware Routing • KEP-895: Pod Topology Spread • KEP-1669: Proxy Terminating Endpoints • KEP-1672: Tracking Terminating Endpoints • KEP-2086: Service Internal Traffic Policy • KEP-536: Topology-aware Service Routing • KEP-3685: Move EndpointSlice Reconciler into Staging ※名前しか触れないものもあります

Copyrights©3-shake Inc. All Rights Reserved. 5 KEP-3673: Kubelet limit of
Parallel Image Pulls • Kubelet はデフォルトでコンテナイメージを直列にプル ◦ 並列でコンテナイメージをプルするオプションもあったが ... ◦ 並列ダウンロード数を制限する機能がないのでディスク I/O に負荷が掛かる ▪ コンテナランタイムの API 呼び出しの QPS を制限する機能しかなかった • Kubelet のコンテナイメージの並列プル数を制限する機能 ◦ Pod が一斉に起動する場合に起動時間の短縮が期待できる ◦ alpha 機能だが、GKE は 1.27 から有効化 ▪ 最大並列プル数を 2 に制限して試験運用をしているみたい ※ デフォルト無効 alpha: 1.27 beta: 1.28 (https://issue.k8s.io/112044) / # cat /home/kubernetes/kubelet-config.yaml maxParallelImagePulls: 2 serializeImagePulls: false https://kep.k8s.io/3673

Copyrights©3-shake Inc. All Rights Reserved. 6 KEP-3063: Dynamic Resource Allocation
• 任意のリソースを要求するための仕組み ◦ KEP-3573: Device Plugins の進化系 (https://kep.k8s.io/3573) ▪ NVIDIA / Intel GPU, FPGA などのアクセラレータを Pod で使う仕組み ◦ StorageClass / PV / PVC を一般化したイメージ • デバイスの動的な初期化、Pod 停止後のお掃除、リソース共有が特徴 ◦ NVIDIA Multi-Instance GPUs (MIGs) や Intel GPU Virtual Function など • Container Device Interface (CDI) によるコンテナランタイムとの協調 ◦ OCI Runtime Specification に追加設定をマージする仕組み ▪ デバイス、環境変数、マウントポイント、 Hook alpha: 1.26 beta: 1.29 https://kep.k8s.io/3063

• 自作したドライバで動作イメージを見ていく ◦ ダミーなデバイスを払い出して Pod に割り当ててくれる • ResourceClass ◦ クラスタ管理者が作成 ▪ IngressClass / StorageClass と同じ ◦ ドライバの選択 ▪ NVIDIA / Intel GPU, … ◦ ドライバが使うグローバルなパラメータを紐付け可能 ▪ e.g.) ConfigMap, カスタムリソース ◦ スケジュール対象のノードの制限 ▪ ラベルセレクタでデバイスのある特定のノードに制限 apiVersion: resource.k8s.io/v1alpha2 driverName: fake.resource.3-shake.com kind: ResourceClass metadata: # 各ベンダーが実装した Resource Driver の名前を指定 # クラスタ内に複数の ResourceClass を作成して、 # ユーザー側で Resource Driver を選択することも可能 name: fake.3-shake.com

• FakeClaimParameters ◦ 独自実装したカスタムリソース ▪ ドライバ側で自由に実装可能 ◦ ドライバが使う任意のパラメータを渡せる • ResourceClaimTemplate ◦ 任意のリソースの設計図 ◦ ドライバが使うパラメータの紐付けも可能 ▪ e.g.) ConfigMap, カスタムリソース ◦ PVC の一般化 apiVersion: fake.resource.3-shake.com/v1alpha1 kind: FakeClaimParameters metadata: namespace: test5 name: multiple-fakes spec: count: 4 # count で作成されたデバイスを親デバイスとして split で # 指定した数だけダミーなデバイスを作成する # 今回だと合計 8 個のダミーなデバイスが動的に生成される split: 2 --- apiVersion: resource.k8s.io/v1alpha2 kind: ResourceClaimTemplate metadata: namespace: test5 name: multiple-fakes spec: spec: resourceClassName: fake.3-shake.com parametersRef: apiGroup: fake.resource.3-shake.com kind: FakeClaimParameters name: multiple-fakes

• Pod の .spec.resourceClaims ◦ ResourceClaimTemplate を複数紐付け ◦ VolumeClaimTemplate と同じ ◦ インラインで埋め込みはできない • Pod の .spec.containers[].resources.claims ◦ resourceClaims からリソースを参照 ◦ 複数のコンテナが同じリソースを参照可能 ◦ 1 つのコンテナが複数のリソースを参照可能 apiVersion: v1 kind: Pod metadata: namespace: test5 name: pod0 labels: app: pod spec: terminationGracePeriodSeconds: 3 containers: - name: ctr0 image: cgr.dev/chainguard/wolfi-base:latest command: ["ash", "-c"] args: ["export; sleep infinity"] resources: # 新たに resources.claims フィールドが追加され、 # resourceClaims からコンテナ毎に割り当てるリソースを参照 # resources.limits や resources.requests と併用も可能 claims: # resourceClaims の名前と一致させること - name: fakes resourceClaims: - name: fakes source: # ResourceClaimTemplate を参照するパターン # 参照された Pod 単位で異なるテンプレートから # ResourceClaim が自動生成されて紐付く resourceClaimTemplateName: multiple-fakes

• 動的にダミーのデバイスを生成して、ノード上で利用可能に • 今回は 4 個の親デバイスをそれぞれ 2 個の子デバイスに分割 ◦ 合計 8 個のデバイスが Pod にマウントされる ◦ ダミーの Driver なので環境変数を CDI で差し込むだけの実装 • 詳しくは [Kubernetes 1.27] Dynamic Resource Allocation のいまを参照 ❯ stern -n test5 . pod0 ctr0 export DRA_RESOURCE_DRIVER_NAME='fake.resource.3-shake.com' pod0 ctr0 export FAKE_DEVICE_0='FAKE-22a36a85-d3f7-d9cd-3fa4-e96f63591bb1' pod0 ctr0 export FAKE_DEVICE_1='FAKE-48f03bf4-8ada-e156-d3de-4a543eecd3cb' pod0 ctr0 export FAKE_DEVICE_2='FAKE-6000b709-3418-4a8c-42a4-fabfa269bcca' pod0 ctr0 export FAKE_DEVICE_3='FAKE-90207d0e-cfb9-08b6-67a3-48f412318baa' pod0 ctr0 export FAKE_DEVICE_4='FAKE-45d09bc0-a6e6-5e1f-0b1d-91628b513a2c' pod0 ctr0 export FAKE_DEVICE_5='FAKE-e473e7e3-53b8-cfdc-cf48-34c1c85f8312' pod0 ctr0 export FAKE_DEVICE_6='FAKE-c02b74da-85de-6b1c-df13-e1cfe32c1eec' pod0 ctr0 export FAKE_DEVICE_7='FAKE-e49d9dc8-2368-6403-d080-b0d3672f5a1c' pod0 ctr0 export FAKE_NODE_NAME='kind-worker'

• 1.28 に向けた主な変更点 ◦ Pod のスケジュールに 5 秒程度掛かっていたのを短縮 (https://pr.k8s.io/119078) ◦ Scheduler が関わらない時にも DRA が利用可能に (https://pr.k8s.io/118209) ▪ ノード名を明示的に指定する場合 ◦ リソース要求をまとめて処理で高速化 (https://pr.k8s.io/118862) ◦ デバイスの初期化/お掃除をまとめて処理で高速化 (https://pr.k8s.io/119012) ◦ Pod が使わなくなったリソースをすぐにお掃除 (https://pr.k8s.io/118936) ▪ WaitForFirstConsumer (遅延割り当て) の場合のみ ◦ Pod が停止もしくはスケジュールの途中で削除された場合にお掃除 (https://pr.k8s.io/118817) ◦ テンプレートから生成する ResourceClaim にランダム文字列追加 (https://pr.k8s.io/117351) ▪ オブジェクト名が衝突するのを避ける

Copyrights©3-shake Inc. All Rights Reserved. 12 KEP-3960: Sleep Action for
PreStop Hook • PreStop Hook の Exec Action での sleep ◦ ネットワークプログラミングレイテンシ ▪ コントローラの同期が遅れる (e.g. iptables, LB, …) ◦ すぐに Graceful Shutdown に入るとリクエストを取りこぼす ◦ 悪い意味で暗黙のデファクトスタンダード化 • PreStop Hook に sleep アクションを指定できるようになる ◦ コンテナイメージに sleep バイナリを含めなくて良い ◦ 無駄なバイナリを含まないベースイメージ (e.g. distroless) • terminationGracePeriodSeconds との関係 ◦ 作成時は sleep <= terminationGracePeriodSeconds を検証 ◦ kubectl delete pods –grace-period=Xs での上書きは許容 alpha: 1.28 beta: 1.29 apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: (…) template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.25.1 lifecycle: preStop: sleep: seconds: 10 https://kep.k8s.io/3960 1.29

Copyrights©3-shake Inc. All Rights Reserved. 13 KEP-753: Sidecar Containers •
サイドカーコンテナを Init コンテナとして起動する機能 ◦ Init コンテナで restartPolicy に Always を指定 ▪ Pod レベルの restartPolicy とは別に Init コンテナレベルで指定可能に ▪ restartPolicy を指定しない場合は通常の Init コンテナの挙動 ◦ スケジューラの判断材料のリソース要求の計算が複雑化 • ユースケース ◦ サービスメッシュのプロキシや証明書管理 ◦ ログやメトリクス収集のエージェント ◦ サイドカーコンテナを含んだ Job の停止 ◦ Init コンテナがサイドカーコンテナを必要とするパターン alpha: 1.28 beta: 1.29 https://kep.k8s.io/753

Kind でローカル環境にクラスタを作成 ◦ Kind で Kubernetes をセルフビルド ◦ 以下の変更を含むブランチでビルド ▪ メインの実装 (https://pr.k8s.io/116429) ▪ Probe / Lifecycle Hook 対応 (https://pr.k8s.io/119168) ◦ control plane + worker node の構成 ◦ SidecarContainers の FeatureGate を有効化 kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 featureGates: SidecarContainers: true nodes: - role: control-plane - role: worker kubeadmConfigPatches: - | kind: JoinConfiguration nodeRegistration: kubeletExtraArgs: v: "4"

サイドカーで使える設定 ◦ restartPolicy ◦ Probe ◦ Lifecycle Hook • Init コンテナを間に挟める apiVersion: v1 kind: Pod metadata: name: pod-with-sidecar spec: initContainers: - name: init-1 image: cgr.dev/chainguard/wolfi-base:latest command: ["ash", "-c", "echo Started; echo Sleep 5s; sleep 5; echo Terminated"] - name: sidecar-1 image: cgr.dev/chainguard/wolfi-base:latest restartPolicy: Always command: ["ash", "-c", "trap 'echo Terminated; exit' TERM; echo Started; while true; do sleep 1; done"] lifecycle: preStop: exec: command: ["ash", "-c", "echo PreStop Executed > /proc/1/fd/1; sleep 5; echo PreStop Done > /proc/1/fd/1"] - name: init-2 image: cgr.dev/chainguard/wolfi-base:latest command: ["ash", "-c", "echo Started; echo Sleep 5s; sleep 5; echo Terminated"] - name: sidecar-2 image: cgr.dev/chainguard/wolfi-base:latest restartPolicy: Always command: ["ash", "-c", "trap 'echo Terminated; exit' TERM; echo Started; while true; do sleep 1; done"] containers: - name: regular-1 image: cgr.dev/chainguard/wolfi-base:latest command: ["ash", "-c", "trap 'echo Terminated; exit' TERM; echo Started; while true; do sleep 1; done"] lifecycle: postStart: exec: command: ["ash", "-c", "echo PostStart Executed > /proc/1/fd/1"] ※ 2023/7/19 時点の実装

Init コンテナが停止してから次の処理へ • アルファ時点でコンテナの停止順は今まで通りランダム ◦ killContainersWithSyncResult に渡す runningPod.Containers にまだ変更はなし pod-with-sidecar init-1 2023-07-19T10:35:26.225559175+09:00 Started pod-with-sidecar init-1 2023-07-19T10:35:26.225606632+09:00 Sleep 5s pod-with-sidecar init-1 2023-07-19T10:35:31.225685707+09:00 Terminated pod-with-sidecar sidecar-1 2023-07-19T10:35:33.310518497+09:00 Started pod-with-sidecar init-2 2023-07-19T10:35:35.283603016+09:00 Started pod-with-sidecar init-2 2023-07-19T10:35:35.283613891+09:00 Sleep 5s pod-with-sidecar init-2 2023-07-19T10:35:40.285017813+09:00 Terminated pod-with-sidecar sidecar-2 2023-07-19T10:35:42.298094645+09:00 Started pod-with-sidecar regular-1 2023-07-19T10:35:44.242024465+09:00 Started pod-with-sidecar regular-1 2023-07-19T10:35:44.251138321+09:00 PostStart Executed … pod-with-sidecar sidecar-2 2023-07-19T10:35:53.405213960+09:00 Terminated pod-with-sidecar regular-1 2023-07-19T10:35:53.407761283+09:00 Terminated pod-with-sidecar sidecar-1 2023-07-19T10:35:53.418470149+09:00 PreStop Executed pod-with-sidecar sidecar-1 2023-07-19T10:35:58.419571745+09:00 PreStop Done pod-with-sidecar sidecar-1 2023-07-19T10:35:58.433210468+09:00 Terminated

サイドカーに Probe 設定 ◦ Startup ◦ Readiness apiVersion: v1 kind: Pod metadata: name: pod-with-sidecar spec: initContainers: - name: sidecar-1 image: cgr.dev/chainguard/wolfi-base:latest restartPolicy: Always command: ["ash", "-c", "trap 'echo Terminated; exit' TERM; echo Started; while true; do sleep 1; done"] startupProbe: exec: command: ["ash", "-c", "echo StartupProbe Started > /proc/1/fd/1; sleep 5; echo Ready > /proc/1/fd/1"] initialDelaySeconds: 5 timeoutSeconds: 8 periodSeconds: 10 - name: sidecar-2 image: cgr.dev/chainguard/wolfi-base:latest restartPolicy: Always command: ["ash", "-c", "trap 'echo Terminated; exit' TERM; echo Started; while true; do sleep 1; done"] readinessProbe: exec: command: ["ash", "-c", "echo ReadinessProbe Started > /proc/1/fd/1; sleep 5; echo Ready > /proc/1/fd/1"] initialDelaySeconds: 5 timeoutSeconds: 8 periodSeconds: 10 containers: - name: regular-1 image: cgr.dev/chainguard/wolfi-base:latest command: ["ash", "-c", "trap 'echo Terminated; exit' TERM; echo Started; while true; do sleep 1; done"] ※ 2023/7/19 時点の実装

サイドカーの Startup Probe が成功してから次のサイドカーを起動 ◦ Init コンテナがサイドカーコンテナに依存している場合は使える • サイドカーの Readiness Probe の成功を待たずにメインを起動 ◦ Liveness Probe も同様に成功を待たない pod-with-sidecar sidecar-1 2023-07-19T10:41:41.149427271+09:00 Started pod-with-sidecar sidecar-1 2023-07-19T10:41:49.999416000+09:00 StartupProbe Started pod-with-sidecar sidecar-1 2023-07-19T10:41:55.000988954+09:00 Ready pod-with-sidecar sidecar-2 2023-07-19T10:41:56.037333917+09:00 Started pod-with-sidecar regular-1 2023-07-19T10:41:57.682351314+09:00 Started pod-with-sidecar sidecar-2 2023-07-19T10:42:09.999915870+09:00 ReadinessProbe Started pod-with-sidecar sidecar-2 2023-07-19T10:42:15.000654193+09:00 Ready … pod-with-sidecar regular-1 2023-07-19T10:42:20.167238932+09:00 Terminated pod-with-sidecar sidecar-1 2023-07-19T10:42:20.167235599+09:00 Terminated pod-with-sidecar sidecar-2 2023-07-19T10:42:20.168897834+09:00 Terminated

Job にサイドカーを挟む ◦ Job のメインのコンテナが終了してもサイドカーが停止しない問題は？ apiVersion: batch/v1 kind: Job metadata: name: pod-with-sidecar spec: template: spec: initContainers: - name: init-1 image: cgr.dev/chainguard/wolfi-base:latest command: ["ash", "-c", "echo Started; echo Sleep 5s; sleep 5; echo Terminated"] - name: sidecar-1 image: cgr.dev/chainguard/wolfi-base:latest restartPolicy: Always command: ["ash", "-c", "trap 'echo Terminated; exit' TERM; echo Started; while true; do sleep 1; done"] containers: - name: regular-1 image: cgr.dev/chainguard/wolfi-base:latest command: ["ash", "-c", "echo Started; echo Sleep 5s; sleep 5; echo Terminated"] restartPolicy: Never backoffLimit: 4 ※ 2023/7/19 時点の実装

メインのコンテナが停止するとサイドカーに SIGTERM が飛ぶ ◦ 現在 Job を止めるためにやっているハックが不要になる！ ▪ 終了時ファイル検出 ▪ PID namespace 共有 + シグナル通知 pod-with-sidecar-nn4zh init-1 2023-07-19T10:47:03.613131134+09:00 Started pod-with-sidecar-nn4zh init-1 2023-07-19T10:47:03.613188550+09:00 Sleep 5s pod-with-sidecar-nn4zh init-1 2023-07-19T10:47:08.614265132+09:00 Terminated pod-with-sidecar-nn4zh sidecar-1 2023-07-19T10:47:09.753494135+09:00 Started pod-with-sidecar-nn4zh regular-1 2023-07-19T10:47:11.878372366+09:00 Started pod-with-sidecar-nn4zh regular-1 2023-07-19T10:47:11.878387241+09:00 Sleep 5s pod-with-sidecar-nn4zh regular-1 2023-07-19T10:47:16.882976981+09:00 Terminated pod-with-sidecar-nn4zh sidecar-1 2023-07-19T10:47:17.809750902+09:00 Terminated

実装は全く違うが、1.18 (2019 年) に一度入りかけた機能 ◦ lifecycle.type に Sidecar を指定 ◦ コンテナのライフサイクル周りの変更の懸念から断念 • 影響範囲を限定した KEP-2872: Keystone containers (https://kep.k8s.io/2872) ◦ Job のサイドカー問題の解決のみに絞った KEP ◦ lifecycle.type に keystone を指定したコンテナが停止したら他も停止 ▪ restartPolicy が Never or OnFailure の場合のみ (Job) ◦ 解決できる問題が限定的かつ今後の拡張性も低く停滞 ... ▪ 起動停止順を解決するフェーズ、 DAG など拡張性の高い案もあった ◦ 2022 年 10 月に Runlevel に変更して Sidecar や App を指定する案も

KEP-3582: Terminate pod on container completion (https://kep.k8s.io/3582) ◦ Pod レベルの restartPolicy をコンテナ単位で上書きする機能 ▪ (Pod, Container) = (Never, OnFailure or Always) or (OnFailure, Always) ◦ 今回の Sidecar Containers の機能のベースとなった KEP ◦ KEP-3582 の動きは止まっていて、 Sidecar Containers 以外のユースケースを収集中 • 2022/11 に SIG Node に WG Sidecar が発足 ◦ Init コンテナに restartPolicy を追加するだけで API の変更は最小限に • 2023/2 に KEP-753 の内容が更新される • Kubernetes 1.27 のリリースサイクルではマージされず

Alpha に向けた実装予定 ◦ PodStatus に RequestedResources を追加 (https://pr.k8s.io/115643) ▪ init / regular コンテナと Pod Overhead を含むリソース要求の合計 • Pod がスケジュールできていない原因をユーザーが確認しやすいように • Cluster Autoscaler や Karpenter がノードを追加する際の計算で使えるように • Beta に向けた実装や変更の予定 ◦ コンテナの停止順 ▪ アルファ以降でフィードバックを受ける予定 (regular-1 -> sidecar-2 -> sidecar-1 ?) ◦ restartPolicy のデフォルト値 (OnFailure?) の設定 ▪ initContainer が再実行されない問題の解決にも繋がるかも？ ◦ Init コンテナからの分離 (e.g. infrastructureContainers) ▪ initContainers にサイドカーを指定することで混乱が生じた場合のみ

Copyrights©3-shake Inc. All Rights Reserved. 24 Official support for restoring
Kubernetes cluster • Kubernetes 公式でクラスタのリストアをサポートする動き ◦ 各ベンダーや管理者の多くが間違った方法で etcd をリストアしている ◦ etcd に変更を加えつつ、公式ガイダンスを出したい ▪ etcd への変更が大部分なので KEP は今のところなし • 時を戻すことによる Controller / Operator のキャッシュ (Informer) への影響 ◦ etcd 内のオブジェクトの Revision が過去に戻る => キャッシュ無効化が必要 • 対応予定 ◦ リストア後に etcd 内のオブジェクトの Revision を任意の数だけ増やす ◦ リストア後に etcd 内のオブジェクトの過去の Revision を Compaction https://issue.k8s.io/118501

Copyrights©3-shake Inc. All Rights Reserved. 25 • AWS が Karpenter
のコア部分を SIG Autoscaling に寄贈しようとしている ◦ 2019 年と 2020 年に AWS が Cluster Autoscaler (CA) の課題や改善案を共有 ◦ CA の互換性を保ちつつ組み込むのは難しいので別プロジェクト化 ◦ 2021 年に本番利用可能になってからも順調に開発が進んでいる ◦ コミュニティ主導で AWS 以外の対応も進めていきたい ▪ Azure は乗り気、既にコア部分にパッチを送っているらしい ▪ Google Cloud は公式ですぐに取り組む予定はなく、コミュニティ次第 https://github.com/kubernetes/org/issues/4258 Migrate Karpenter Core to SIG Autoscaling Subproject

Copyrights©3-shake Inc. All Rights Reserved. 26 Migrate Karpenter Core to
SIG Autoscaling Subproject • CA vs Karpenter ◦ CA はノードプール単位でスケール ▪ 事前にノードプールを定義する必要がある ▪ GKE の Node Auto-Provisioning だとノードプールを自動作成 ◦ Karpenter はノード単位で作成・追加する ◦ Karpenter はノードのカスタマイズやライフサイクル管理もやる • 今後の動きは？ ◦ CA と Karpenter の持つ共通の機能を標準化していきたい ◦ まずは WG を作って議論を進めていく ▪ Karpenter の CRD の v1beta1 のレビューを一緒にやるらしい

Copyrights©3-shake Inc. All Rights Reserved. 27 Revive WG-LTS • 2023/4/18
AKS (Azure) の LTS サポートの発表 • 2023/4/18 KubeCon Europe 2023 Contributor Summit での議論 • Azure / AWS / Google Cloud を中心に WG-LTS が復活しました ◦ 政府関係・通信業界など 12 ヶ月サイクルの更新が厳しいユーザーがいる ◦ エンドユーザーの現状と求める LTS を情報収集するところから ◦ 情報を元に Kubernetes に反映できる変更を考えていく ▪ マイナーバージョンのサポート期間の延長？ ▪ LTS ブランチに脆弱性修正や致命的なバグ修正を反映していく？ ▪ バージョンスキューポリシーの変更？ ▪ … https://github.com/kubernetes/community/issues/7259

Copyrights©3-shake Inc. All Rights Reserved. 28 • LTS から LTS
へのアップグレードのパスをどうする？ ◦ 一気に更新できるようにはしたいらしいが、まだ決まっていない ◦ まだ決まっていない • LTS のバージョンをどう決める？ ◦ 1.15 や 1.21 など API バージョンの廃止前のバージョンに居座りがちな雰囲気 ◦ まだ決まっていない • LTS ではベータ機能は無効化する？ ◦ Beta API は Kubernetes 1.24 からデフォルトで有効化されない ◦ これは Beta API じゃなくてベータ機能の話 ◦ ベータ機能に破壊的変更が入る可能性があるため Revive WG-LTS

Copyrights©3-shake Inc. All Rights Reserved. 30 • KEP-3935: Support Oldest
Node And Newest Control Plane (https://kep.k8s.io/3935) ◦ WG-LTS とは別に進んでいるバージョンスキューポリシーの拡張 ◦ コントロールプレーンとノードのバージョンスキューを n-2 から n-3 に ▪ 1.43 のコントロールプレーンと 1.40 のノードでの動作を保証 ◦ Kubernetes のサポートバージョンへの追従 ▪ 毎年 3 バージョン更新する必要がある (1.40 -> 1.43) ▪ 現在の in-place 更新のパス • コントロールプレーンを 1.40 -> 1.41 -> 1.42 に更新 • ノードを 1.40 -> 1.42 に更新 • コントロールプレーンを 1.42 -> 1.43 に更新 • ノードを 1.42 -> 1.43 に更新 WG-LTS に関連する動き stable: 1.28

Copyrights©3-shake Inc. All Rights Reserved. 31 • KEP-3935: Support Oldest
Node And Newest Control Plane ◦ Kubernetes のサポートバージョンへの追従 ▪ 今後の in-place 更新のパス • コントロールプレーンを 1.40 -> 1.41 -> 1.42 -> 1.43 に更新 • ノードを 1.40 -> 1.43 に更新 ▪ ノードの更新回数を減らすことでサービス影響や運用コストを抑えられる ◦ バージョンスキューのテストに (1.27, 1.24) と (1.28, 1.25) を追加 ▪ 絶賛実装中の機能でバージョンスキューの拡張による影響を見る • どのバージョンからスキューポリシーの拡張を始めるか決めるため • (1.27, 1.24) と (1.28-alpha, 1.25) は問題なかったらしい WG-LTS に関連する動き

Copyrights©3-shake Inc. All Rights Reserved. 32 WG-LTS に関連する動き • KEP-3744:
Stay on supported go versions (https://kep.k8s.io/3744) ◦ Kubernetes 1.x ブランチは特定の Go マイナーバージョンでビルドされてきた ◦ Go の後方互換性の改善 ▪ Kubernetes から Go 開発チームに提言 ▪ GODEBUG (or //go:debug) による Go の破壊的変更の On/Off 実装の強制 ◦ Kubernetes 1.x ブランチを最新の Go マイナーバージョンでビルドできるように ▪ 開発ブランチでの事前検証、 Kubernetes 1.x ブランチへの取り込みの条件の定義など • CRI API のバージョンスキューポリシーの策定 (https://pr.k8s.io/107190) ◦ CRI に影響する KEP も当然ある ▪ KEP-3008: QoS Class Resource, KEP-3063: DRA, … ◦ 同じ CRI API のバージョン (v1) で実装された Kubelet とコンテナランタイムの互換性 ▪ 3 バージョンまでは互換性を持たせる (e.g. [email protected] <-> Kubelet v0.26.0) stable: 1.27

Copyrights©3-shake Inc. All Rights Reserved. 33 KEP-2433: Topology Aware Hints
Routing • Pod を Zone に分散して配置することで可用性を担保 ◦ トラフィックは iptables / IPVS のルールでランダムに振り分け ▪ Zone を跨いだ通信によるコストの増加 ▪ Zone を跨いだ通信によるレイテンシの悪化 • Topology (Zone) を考慮してトラフィックを振り分けたい ◦ 同一 Zone 内の Pod に出来るだけトラフィックを流したい ◦ 特定の Zone に負荷が偏るのを避けたい • Zone 内の CPU 数でトラフィックを振り分ける機能 ◦ Headless Service はクラスタ DNS が Pod IP を解決するので対応外 ◦ 拡張性よりも利便性を優先 (設定のシンプルさ) ◦ 1.27 で Topology Aware Hints から Topology Aware Routing に改名 alpha: 1.21 beta: 1.23 stable: ??? https://kep.k8s.io/2433

Copyrights©3-shake Inc. All Rights Reserved. 34 KEP-2433: Topology Aware Routing
• Kind でローカル環境にクラスタを作成 ◦ Kubernetes 1.27.3 ◦ control plane + 3 worker node 構成 ◦ worker node に Topology ラベルを付与 ◦ worker node の割り当て可能な CPU は同じ ▪ status.allocatable.cpu: 8 kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane - role: worker kubeadmConfigPatches: - | kind: JoinConfiguration nodeRegistration: kubeletExtraArgs: node-labels: "topology.kubernetes.io/zone=zone-a" - role: worker kubeadmConfigPatches: - | kind: JoinConfiguration nodeRegistration: kubeletExtraArgs: node-labels: "topology.kubernetes.io/zone=zone-b" - role: worker kubeadmConfigPatches: - | kind: JoinConfiguration nodeRegistration: kubeletExtraArgs: node-labels: "topology.kubernetes.io/zone=zone-c" ❯ kubectl get nodes -l topology.kubernetes.io/zone NAME STATUS ROLES AGE VERSION kind-worker Ready <none> 3m v1.27.3 kind-worker2 Ready <none> 3m v1.27.3 kind-worker3 Ready <none> 3m v1.27.3

• テスト用の Pod を 10 台起動 ◦ /hostname でホスト名 (Pod 名) を返す ◦ Topology Spread Constraints で Zone 分散 • Topology Aware Routing の annotation 指定 apiVersion: apps/v1 kind: Deployment metadata: name: backends spec: selector: matchLabels: app: backends replicas: 10 template: metadata: labels: app: backends spec: containers: - name: agnhost image: k8s.gcr.io/e2e-test-images/agnhost:2.39 args: - netexec - --http-port=80 - --delay-shutdown=30 topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app: backends apiVersion: v1 kind: Service metadata: name: backends annotations: service.kubernetes.io/topology-mode: "auto" spec: type: ClusterIP selector: app: backends ports: - protocol: TCP port: 80 targetPort: 80

• クライアントの Pod を起動して curl でリクエストを投げる ◦ クライアントの Pod と同じ Zone の Pod にしかリクエストが流れていない ❯ kubectl get pods -l app=backends \ -ojsonpath='{range .items[?(@.spec.nodeName=="kind-worker")]}{@.metadata.name}{"\n"}{end}' backends-5dd7cf99fd-gxdg2 backends-5dd7cf99fd-kz7td backends-5dd7cf99fd-zvbrz ❯ kubectl run -it --rm curl --image registry.k8s.io/e2e-test-images/agnhost:2.39 --command -- ash If you don't see a command prompt, try pressing enter. / # while sleep 1; do curl -sSL -w "\n" http://backends/hostname; done backends-5dd7cf99fd-zvbrz backends-5dd7cf99fd-gxdg2 backends-5dd7cf99fd-gxdg2 backends-5dd7cf99fd-kz7td backends-5dd7cf99fd-zvbrz backends-5dd7cf99fd-gxdg2

• EndpointSlice コントローラが EndpointSlice にヒントを埋め込む ◦ .hints.forZones に Topology キーの値を埋める ❯ kubectl get endpointslice -l kubernetes.io/service-name=backends \ -ojsonpath='{.items[0].endpoints[4]}' | jq { (...) "hints": { "forZones": [ { "name": "zone-a" } ] }, "nodeName": "kind-worker", "targetRef": { "kind": "Pod", "name": "backends-5dd7cf99fd-kz7td", "namespace": "default", "uid": "5a867de0-23cc-4ec5-bce8-ab8ca9eae8a9" }, "zone": "zone-a" }

• EndpointSlice の利用者がヒントを考慮して経路を作成 ◦ kube-proxy の iptables のルールが追加される ▪ Service Endpoint 用のルールが 3 つある ▪ zone-a のノード上の Pod も 3 つで Pod IP も一致 (省略) /# KUBE_SVC_RULE_NAME=$(iptables -t nat -L KUBE-SERVICES -n | grep default/backends | awk '{print $1}') /# iptables -t nat -L ${KUBE_SVC_RULE_NAME} -n Chain KUBE-SVC-OHSSMBHE4NED4LG4 (1 references) target prot opt source destination KUBE-MARK-MASQ tcp -- !10.244.0.0/16 10.96.103.227 tcp dpt:80 KUBE-SEP-3SNEMA3ONBVUUURN all -- 0.0.0.0/0 0.0.0.0/0 statistic mode random probability 0.33333333349 KUBE-SEP-56SQBRZDKAUDDJOW all -- 0.0.0.0/0 0.0.0.0/0 statistic mode random probability 0.50000000000 KUBE-SEP-FZOGABAOPIZI2Z7W all -- 0.0.0.0/0 0.0.0.0/0

• Topology Aware Routing が発動する条件 ◦ 全ての Zone が満たさない場合は発動しない ◦ Pod の数が多い場合は発動しやすい Zone a b c vCPU 8 8 8 Endpoint 数 3 3 4 CPU 比率 8 / 24 = 33.33% 8 / 24 = 33.33% 8 / 24 = 33.33% 過負荷の閾値 0.2 必要な Endpoint 数 (小数点切り上げ) (10 * 0.3333) / 1.2 ~ 3 (10 * 0.3333) / 1.2 ~ 3 (10 * 0.3333) / 1.2 ~ 3 発動するか？ (EP >= 必要な EP) ⭕ ⭕ ⭕ 参考: https://aws.amazon.com/jp/blogs/containers/exploring-the-effect-of-topology-aware-hints-on-network-traffic-in-amazon-elastic-kubernetes-service/ https://go.dev/play/p/GZmgcTb50x7

Copyrights©3-shake Inc. All Rights Reserved. 41 Topology Aware Routing の発動を予測し辛い
• Kind でローカル環境にクラスタを作成 ◦ Kubernetes 1.27.3 ◦ control plane + 3 worker node 構成 ◦ worker node に Topology ラベルを付与 ◦ worker node の割り当て可能な CPU を調整 kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane - role: worker kubeadmConfigPatches: - | kind: JoinConfiguration nodeRegistration: kubeletExtraArgs: node-labels: "topology.kubernetes.io/zone=zone-a" # ノードの割り当て可能な CPU 数を減らすためのハック system-reserved: "cpu=6" - role: worker kubeadmConfigPatches: - | kind: JoinConfiguration nodeRegistration: kubeletExtraArgs: node-labels: "topology.kubernetes.io/zone=zone-b" system-reserved: "cpu=6" - role: worker kubeadmConfigPatches: - | kind: JoinConfiguration nodeRegistration: kubeletExtraArgs: node-labels: "topology.kubernetes.io/zone=zone-c" system-reserved: "cpu=4" kubectl get nodes -l topology.kubernetes.io/zone \ -ojsonpath='{range .items[*]}{.metadata.name}: cpu={.status.allocatable.cpu}{"\n"}{end}' kind-worker: cpu=2 kind-worker2: cpu=2 kind-worker3: cpu=4

• Topology Aware Routing が発動する条件 ◦ NodeResourceFit: LeastAllocated (デフォルト) の場合は発動する ◦ クラスタ内に他のワークロードが動いている場合は発動しない可能性もある参考: https://aws.amazon.com/jp/blogs/containers/exploring-the-effect-of-topology-aware-hints-on-network-traffic-in-amazon-elastic-kubernetes-service/ Zone a b c vCPU 2 2 4 Endpoint 数 1 1 2 CPU 比率 2 / 8 = 25% 2 / 8 = 25% 4 / 8 = 50% 過負荷の閾値 0.2 必要な Endpoint 数 (小数点切り上げ) (4 * 0.25) / 1.2 ~ 1 (4 * 0.25) / 1.2 ~ 1 (4 * 0.5) / 1.2 ~ 2 発動するか？ (EP >= 必要な EP) ⭕ ⭕ ⭕

• Topology Aware Routing が発動する条件 ◦ 5 台だとどう足掻いても発動しない ... ◦ HPA でスケールする場合や vCPU の異なるノードが複数あると予測し辛い参考: https://aws.amazon.com/jp/blogs/containers/exploring-the-effect-of-topology-aware-hints-on-network-traffic-in-amazon-elastic-kubernetes-service/ Zone a b c vCPU 2 2 4 Endpoint 数 1 2 2 CPU 比率 2 / 8 = 25% 2 / 8 = 25% 4 / 8 = 50% 過負荷の閾値 0.2 必要な Endpoint 数 (小数点切り上げ) (5 * 0.25) / 1.2 ~ 2 (5 * 0.25) / 1.2 ~ 2 (5 * 0.5) / 1.2 ~ 3 発動するか？ (EP >= 必要な EP) ❌ ⭕ ❌

• テスト用の Pod を 4 台起動 ◦ /hostname でホスト名 (Pod 名) を返す ◦ NodeAffinity で zone-a と zone-b に 2 台ずつ • Topology Aware Routing の annotation 指定 apiVersion: v1 kind: Service metadata: name: backends annotations: service.kubernetes.io/topology-mode: "auto" spec: type: ClusterIP selector: app: backends ports: - protocol: TCP port: 80 targetPort: 80 apiVersion: apps/v1 kind: Deployment metadata: name: backends spec: selector: matchLabels: app: backends replicas: 4 template: metadata: labels: app: backends spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: topology.kubernetes.io/zone operator: In values: ["zone-a", "zone-b"] containers: - name: agnhost image: k8s.gcr.io/e2e-test-images/agnhost:2.39 args: - netexec - --http-port=80 - --delay-shutdown=30

• Topology Aware Routing が発動する条件 ◦ zone-a と zone-b は条件を満たしているが zone-c が満たしていない？ ◦ TAR は賢いので、zone-a と zone-b から Endpoint を 1 つずつ zone-c に回す Zone a b c vCPU 2 2 4 Endpoint 数 2 2 0 CPU 比率 2 / 8 = 25% 2 / 8 = 25% 4 / 8 = 50% 過負荷の閾値 0.2 必要な Endpoint 数 (小数点切り上げ) (4 * 0.25) / 1.2 ~ 1 (4 * 0.25) / 1.2 ~ 1 (4 * 0.5) / 1.2 ~ 2 ヒント 1 1 2 発動するか？ (EP >= 必要な EP) ⭕ ⭕ ⭕ ❯ kubectl get endpointslices -l kubernetes.io/service-name=backends \ -ojsonpath='{range .items[*].endpoints[*]}{.targetRef.name}: {.hints.forZones[*].name}{"\n"}{end}' backends-zone-a-8644bdf9c9-4rxwr: zone-c backends-zone-a-8644bdf9c9-9xcwq: zone-a backends-zone-b-cdc5ff985-pmpmf: zone-c backends-zone-b-cdc5ff985-jm9dk: zone-b

Copyrights©3-shake Inc. All Rights Reserved. 48 Service の既存のトポロジー制御との兼ね合い • Service
のトポロジー制御のおさらい ◦ externalTrafficPolicy (eTP) eTP=Cluster eTP=Local https://kep.k8s.io/1669 https://kep.k8s.io/1672 ノード上に Terminating 状態の Pod しかいない場合でも、サービスアウトしていない Pod にフォールバック (KEP-1669 + KEP-1672)

Copyrights©3-shake Inc. All Rights Reserved. 49 Service の既存のトポロジー制御との兼ね合い • Service
のトポロジー制御のおさらい ◦ internalTrafficPolicy (iTP) iTP=Cluster iTP=Local ノード上に正常な Pod がいない場合はパケットがドロップされるので注意 (KEP-2086) https://kep.k8s.io/2086

Copyrights©3-shake Inc. All Rights Reserved. 50 Service の既存のトポロジー制御との兼ね合い • xTP=Local
の場合、xTP=Local を優先 ◦ Topology Aware Routing にフォールバックしない • iTP には以前 PreferLocal モードの提案もあったが消えた ◦ Topology Aware Routing で実現した方が良いという話になった https://github.com/kubernetes/kubernetes/blob/v1.27.3/pkg/proxy/topology.go#L40-L53 func CategorizeEndpoints(...) (...) { var useTopology, useServingTerminatingEndpoints bool if svcInfo.UsesClusterEndpoints() { useTopology = canUseTopology(endpoints, svcInfo, nodeLabels) clusterEndpoints = filterEndpoints(endpoints, func(ep Endpoint) bool { if !ep.IsReady() { return false } if useTopology && !availableForTopology(ep, nodeLabels) { return false } return true }) …

Copyrights©3-shake Inc. All Rights Reserved. 51 KEP-536: Topology-aware Service Routing
の亡霊 • KEP-536 で出来ていた挙動を実現できない • ユーザーが Service に topologyKeys を指定 ◦ 上から順番に評価してフォールバックする ◦ 同一ノード -> ゾーン -> リージョン -> 通常 • 柔軟性はあるが冗長 ◦ アルファの段階で非推奨に ◦ KEP-2433 Topology Aware Hints に置き換わった ▪ ゾーンのみかつ CPU 数で計算される ▪ KEP-536 の挙動を再現できない ▪ 非推奨化を取り下げる要望も (https://pr.k8s.io/116300) apiVersion: v1 kind: Service metadata: name: backends spec: selector: app: backends ports: - protocol: TCP port: 80 targetPort: 80 topologyKeys: - "kubernetes.io/hostname" - "topology.kubernetes.io/zone" - "topology.kubernetes.io/region" - "*"

Copyrights©3-shake Inc. All Rights Reserved. 52 Topology Aware Routing のモードの追加
• ヒントを設定するコンポーネントと消費するコンポーネント ◦ e.g.) EndpointSlice Controller と kube-proxy • ヒントを設定する独自 EndpointSlice Controller の開発 ◦ KEP-3685: Move EndpointSlice Reconciler into Staging ▪ EndpointSlice を触るライブラリを他のプロジェクトでも使えるように • kube-proxy の機能を自前実装しているケースも出てきている ◦ e.g.) Cilium の Kubernetes without kube-proxy ◦ kube-proxy にだけ機能を入れれば良いという訳でもない ◦ サードパーティのツールにもモードの追加を強制するか？

• 1.29 に向けた主な改善予定 ◦ 新しいモードである PreferZone の追加 ▪ 純粋にゾーン内の Pod にトラフィックを流す • ゾーン内に Pod がいない場合は通常の挙動 ▪ Topology Spread Constraints + Desceduler などで Pod が均等に分散されている前提 • 今後の予定 ◦ KEP-2433 Topology Aware Routing の GA は PreferZone の実装を待つ予定 ▪ KEP-2433 は永遠のベータ化しかけているので GA 化を目指す ◦ 同一ノード -> ゾーン -> リージョン -> クラスタ全体のフォールバックや重み付けは？ ▪ 誰かが独自実装の EndpointSlice コントローラーで検証後にコア機能化を検討？ • KEP-3685 EndpointSlice Reconciler into Staging

KEP から眺める Kubernetes

KEP から眺める Kubernetes

More Decks by Tsubasa Nagasawa

Other Decks in Technology

Featured

Transcript