Upgrade to Pro — share decks privately, control downloads, hide ads and more …

KEP から眺める Kubernetes

KEP から眺める Kubernetes

Tsubasa Nagasawa

July 19, 2023
Tweet

More Decks by Tsubasa Nagasawa

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

  3. 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)

    View Slide

  4. 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
    ※名前しか触れないものもあります

    View Slide

  5. 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

    View Slide

  6. 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

    View Slide

  7. 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

    View Slide

  8. 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

    View Slide

  9. 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

    View Slide

  10. 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'

    View Slide

  11. 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)
    ■ オブジェクト名が衝突するのを避ける

    View Slide

  12. 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

    View Slide

  13. 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

    View Slide

  14. 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"

    View Slide

  15. 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 時点の実装

    View Slide

  16. 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

    View Slide

  17. 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 時点の実装

    View Slide

  18. 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

    View Slide

  19. 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 時点の実装

    View Slide

  20. 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

    View Slide

  21. 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 を指定する案も

    View Slide

  22. 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 のリリースサイクルではマージされず

    View Slide

  23. 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 にサイドカーを指定することで混乱が生じた場合のみ

    View Slide

  24. 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

    View Slide

  25. 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

    View Slide

  26. 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 のレビューを一緒にやるらしい

    View Slide

  27. 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

    View Slide

  28. 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

    View Slide

  29. Copyrights©3-shake Inc. All Rights Reserved. 29
    Revive WG-LTS
    https://twitter.com/brendandburns/status/1679618024398270464

    View Slide

  30. 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

    View Slide

  31. 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 に関連する動き

    View Slide

  32. 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

    View Slide

  33. 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

    View Slide

  34. 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

    View Slide

  35. 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

    View Slide

  36. 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

    View Slide

  37. 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"
    }

    View Slide

  38. 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

    View Slide

  39. 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

    View Slide

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

    View Slide

  41. 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

    View Slide

  42. 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

    View Slide

  43. 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)
    ⭕ ⭕ ⭕

    View Slide

  44. 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

    View Slide

  45. 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)
    ❌ ⭕ ❌

    View Slide

  46. 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

    View Slide

  47. 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

    View Slide

  48. 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)

    View Slide

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

    View Slide

  50. 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
    })

    View Slide

  51. 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"
    - "*"

    View Slide

  52. 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 にだけ機能を入れれば良いという訳でもない
    ○ サードパーティのツールにもモードの追加を強制するか?

    View Slide

  53. 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

    View Slide