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

Copyrights©3-shake Inc. All Rights Reserved. 7 KEP-3063: Dynamic Resource Allocation ● 自作したドライバで動作イメージを見ていく ○ ダミーなデバイスを払い出して 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

Copyrights©3-shake Inc. All Rights Reserved. 8 KEP-3063: Dynamic Resource Allocation ● 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

Copyrights©3-shake Inc. All Rights Reserved. 9 KEP-3063: Dynamic Resource Allocation ● 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

Copyrights©3-shake Inc. All Rights Reserved. 10 KEP-3063: Dynamic Resource Allocation ● 動的にダミーのデバイスを生成して、ノード上で利用可能に ● 今回は 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'

Copyrights©3-shake Inc. All Rights Reserved. 11 KEP-3063: Dynamic Resource Allocation ● 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

Copyrights©3-shake Inc. All Rights Reserved. 14 KEP-753: Sidecar Containers ● 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"

Copyrights©3-shake Inc. All Rights Reserved. 15 KEP-753: Sidecar Containers ● サイドカーで使える設定 ○ 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 時点の実装

Copyrights©3-shake Inc. All Rights Reserved. 16 KEP-753: Sidecar Containers ● 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

Copyrights©3-shake Inc. All Rights Reserved. 17 KEP-753: Sidecar Containers ● サイドカーに 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 時点の実装

Copyrights©3-shake Inc. All Rights Reserved. 18 KEP-753: Sidecar Containers ● サイドカーの 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

Copyrights©3-shake Inc. All Rights Reserved. 19 KEP-753: Sidecar Containers ● 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 時点の実装

Copyrights©3-shake Inc. All Rights Reserved. 20 KEP-753: Sidecar Containers ● メインのコンテナが停止するとサイドカーに 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

Copyrights©3-shake Inc. All Rights Reserved. 21 KEP-753: Sidecar Containers ● 実装は全く違うが、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 を指定する案も

Copyrights©3-shake Inc. All Rights Reserved. 22 KEP-753: Sidecar Containers ● 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 のリリースサイクルではマージされず

Copyrights©3-shake Inc. All Rights Reserved. 23 KEP-753: Sidecar Containers ● 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. 29 Revive WG-LTS https://twitter.com/brendandburns/status/1679618024398270464

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 3m v1.27.3 kind-worker2 Ready 3m v1.27.3 kind-worker3 Ready 3m v1.27.3

Copyrights©3-shake Inc. All Rights Reserved. 35 KEP-2433: Topology Aware Routing ● テスト用の 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

Copyrights©3-shake Inc. All Rights Reserved. 36 KEP-2433: Topology Aware Routing ● クライアントの 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

Copyrights©3-shake Inc. All Rights Reserved. 37 KEP-2433: Topology Aware Routing ● 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" }

Copyrights©3-shake Inc. All Rights Reserved. 38 KEP-2433: Topology Aware Routing ● 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

Copyrights©3-shake Inc. All Rights Reserved. 39 KEP-2433: Topology Aware Routing ● 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. 40 Topology Aware Routing の課題 ● Topology Aware Routing の発動を予測し辛い ○ 時間の関係で割愛 ● Service の既存のトポロジー制御との兼ね合い ● KEP-536: Topology-aware Service Routing の亡霊

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

Copyrights©3-shake Inc. All Rights Reserved. 42 Topology Aware Routing の発動を予測し辛い ● テスト用の Pod を 4 台起動 ○ /hostname でホスト名 (Pod 名) を返す ○ Topology Spread Constraints で Zone 分散 ● Topology Aware Routing の annotation 指定 apiVersion: apps/v1 kind: Deployment metadata: name: backends spec: selector: matchLabels: app: backends replicas: 4 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

Copyrights©3-shake Inc. All Rights Reserved. 43 Topology Aware Routing の発動を予測し辛い ● 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) ⭕ ⭕ ⭕

Copyrights©3-shake Inc. All Rights Reserved. 44 Topology Aware Routing の発動を予測し辛い ● テスト用の Pod を 5 台起動 ○ /hostname でホスト名 (Pod 名) を返す ○ Topology Spread Constraints で Zone 分散 ● Topology Aware Routing の annotation 指定 apiVersion: apps/v1 kind: Deployment metadata: name: backends spec: selector: matchLabels: app: backends replicas: 5 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

Copyrights©3-shake Inc. All Rights Reserved. 45 Topology Aware Routing の発動を予測し辛い ● 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) ❌ ⭕ ❌

Copyrights©3-shake Inc. All Rights Reserved. 46 Topology Aware Routing の発動を予測し辛い ● テスト用の 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

Copyrights©3-shake Inc. All Rights Reserved. 47 Topology Aware Routing の発動を予測し辛い ● 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 にだけ機能を入れれば良いという訳でもない ○ サードパーティのツールにもモードの追加を強制するか？

Copyrights©3-shake Inc. All Rights Reserved. 53 KEP-2433: Topology Aware Routing ● 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