Open130

Kubernetes - 2025

Tsubasa NagasawaTsubasa Nagasawa

2025/1/2

ContainerLogManager to rotate logs of all containers in case of disk pressure on host

Kubernetes のログローテーションが起こるのは現状コンテナのログファイルが指定したサイズ (デフォルト 10 MiB) を超えた場合とコンテナのログファイルの世代数が指定した数 (デフォルトで 5) を超えたときで、kubelet は 10 秒間隔で監視している。ログローテーションの処理は Kubernetes 1.30 から kubelet に追加された設定で調整できて、containerLogMaxWorkers で並列処理数の指定ができ、containerLogMonitorInterval で 10 秒で固定だった監視の間隔を変更可能。ただ、ホスト上のディスクが逼迫しているときにもログローテーションを行いたい要望。短期間で大量のログを書き込んだ場合 (Java の Exception が信じられない間隔で大量に書き込まれていることがあったし割とありそう) に現状だとログローテーションが間に合わず、ディスクが逼迫してしまう。コードのコメントにもともと TODO として書かれているのと SIG-Node 的にも興味あるから KEP になりそう

Tsubasa NagasawaTsubasa Nagasawa

2025/1/3

CNI plugin based on sqlite3

kind で利用されている Kubernetes network plugin (≠ CNI, CNI の操作以外にも Service の接続性や NetworkPolicy の実装などを含んでいるので) の Kindnet が既存の ptp / host-local / portmap の CNI plugin の利用をやめて、独自実装の CNI plugin (cni-kindnet) を利用するようになった。CNI plugin のコマンド (ADD, DEL) を実行した時にコンテナとホストマシンの間のネットワークをセットアップするための情報 (e.g. IPAM で利用できる IP 範囲や払い出した Pod IP) をプロセス内で起動した SQLite3 に保存して永続化する形に変更された。既存の Kubernetes network plugin の実装ではこれらの情報をインメモリ (e.g. Cilium の StateDB) や外部のデータストア (e.g. Flannel の Node annotation or etcd) に保存したり、別の常時起動のプロセスが管理しているが、CNI plugin の中で完結する形にしている。SQLite3 の中には、IPAM で払い出し可能な IP 範囲のテーブルと、Pod の情報のテーブル、コンテナ内のポートとホストマシン側でのポートのマッピング情報 (hostPort を利用する際に使用) のテーブルがある。メインの CNI の実装は ptp plugin と同じで veth のペアを作ってコンテナの network namespace 内とホストマシン側に紐付けてルートテーブルを設定している。ip コマンドと同等のことを Go の netlink のライブラリを使って実装している。IPAM に関しても実装としては host-local とほぼ同じで、node-ipam-controller が Node で利用可能な IP 範囲を管理する前提で、その IP 範囲を CNI の設定ファイルから読み込んで重複しないようにランダムで Pod IP を払い出す。Pod IP の払い出しの実装は一部 k/k の中の Service の ClusterIP の払い出しの実装 (IP Allocator) から一部拝借している。ポートマッピングの実装は nftables に独自のテーブルを作ってルールを書く形で実装されていて、prerouting / output のチェインに DNAT で特定のホスト IP とポート番号とプロトコルの通信をコンテナ内の IP とポート番号にリダイレクトしている。この PR では nftables の操作には knftables のライブラリを使っていたが、CNI plugin がホストマシン上にインストールされた nft バイナリに依存するのを排除したかったようで main ブランチだと google/nftables のライブラリを使用する形に置き換わっている。

Tsubasa NagasawaTsubasa Nagasawa

2025/1/5

In-Place kubelet 更新で Pod が再起動してしまう問題

新しい機能により Pod Spec にフィールドが追加され、かつデフォルト値が埋め込まれた場合にコントロールプレーンの更新で Pod が再起動される問題の修正が Kubernetes 1.31 で入った。以前は kubelet が Pod Spec の全てのフィールドのハッシュ値を比較して変更があるかを検知していたが、Pod Spec の中で変更可能なフィールド (現状はコンテナイメージ名のみ) とコンテナ名のハッシュ値を比較する形に変更された。これにより、In Place Pod Vertical Scaling により Pod Spec に新しく resizePolicy のフィールドが追加され、かつデフォルト値を埋め込んでいた (Kubernetes 1.30 以前では依然として Pod が再起動されてしまうので、Kubernetes 1.33 でデフォルト値を埋め込まないように修正された) ことで、FeatureGate を有効化すると kubelet が Pod Spec の変更を検知して Pod を再起動しなくなった。(k/k#124220)

ただ、この修正により kubelet が算出するハッシュ値に変更が発生するため、kubelet を Pod が起動した状態で In-Place で更新しているオンプレ勢で Kubernetes 1.31 に更新すると全ての Pod が再起動される問題が起きた。ただ、Kubernetes では公式に kubelet の In-Place 更新をサポートしておらず、必ず Node を cordon -> drain して kubelet を更新し、uncordon する手順を取るようにとなっている。ハッシュ値の計算方法の変更の部分を FeatureGate で守る案が挙げられているが、非公式な方法をサポートするために k/k に機能を入れるのは許可されなさそう。公式でサポートされていない方法は取らない方が良い (k/k#129385)

Tsubasa NagasawaTsubasa Nagasawa

2025/1/6

Cluster Autoscaler の DRA 連携の MVP 実装

Cluster Autoscaler (CA) に DRA 連携の MVP の実装が入った。Cluster Autoscaler の既存の NodeGroup をスケールアップする方式と Node Auto Provisioning (NAP) の両方のモードで対応済み (kubernetes/autoscaler#7530)

  • Kubernetes 1.32 で Scheduler Plugin に DRA Scheduler Plugin で使える DRA に関連する API リソース (ResourceSlice / ResourceClaim / DeviceClass) の情報を取得したり、インメモリ上で変更できるインターフェイスが生えた。CA は Node をスケールアウトする時に新しく追加する Node に Pod が起動できるかをシミュレーションしていて、その時に Scheduler Plugin の実装を利用している。kube-scheduler と同じでスケジュールの判断に必要な情報をスナップショットとして保持しており、その中に DRA の情報が含まれるようになり、シミュレーションを実行する際に最新の状態に書き換えられるようになった。
  • 既存の NodeGroup をスケールアウトする場合 (NAP であろうと) は、DaemonSet や static Pods が DRA を利用していてもサポート済み。既に起動済みの Node と DaemonSet / static Pods の情報をコピーしてシミュレーションを行う。
  • CA がスケールインする Node を決めるとき、Node 上の Pod に割り当てたリソースと割り当て可能な全リソースの割合をもとに使用率の閾値を下回る Node を選択している。 Node 上の DRA で払い出したリソース (e.g. GPU) の使用率は、Pod に割り当てたデバイスの数と Node の割り当て可能なデバイスの数の割合で決まり、DRA で払い出したリソースのみを現状は考慮する。(i.e. DRA で GPU を利用している場合は、CPU やメモリの割合は考慮されない)

MVP 実装なので本番利用はまだ無理で、諸々改善予定

  • Pod の PriorityClass による Preemption が発生して既存の Pod を押し退けて Node にスケジュールされる Pod が DRA を利用している場合に、ResourceClaim を考慮できておらずスケジュールが上手くいかない
  • DaemonSet や static Pods が DRA を利用していて、NodeGroup を 0 台からスケールアウトする場合はサポートしていない。Node 上で起動する DaemonSet や static Pods の情報がないので、コピーしてシミュレーションの中で使うことができないっぽい。
  • DRA を利用している Pod で CPU やメモリの割り当ても考慮して Node をスケールインできるようにする
  • DRA の Admin Access モードには未対応。クラスタ管理者がデバイスのメンテナンス作業や問題の調査したり、監視ツールでメトリクスを収集する場合など、ResourceClaim / ResourceClaimTemplate で adminAccess フィールドを有効化すると管理用の Pod にデバイスを紐付けることが可能。管理用の Pod に割り当てたデバイスは他の通常の Pod にも割り当て可能。ただし、CA のシミュレーションではまだ考慮できていない
  • Node を作成すると DRA driver が起動して ResourceSlice を作成するまでは Node が NotReady 状態になって欲しいが現状はそうなっていない。ResourceSlice が公開されないことには kube-scheduler は Pod をスケジュールできないので、Pending 状態のまましばらく待つことになる。そのため、CA が余計に Node を起動してしまう可能性があるが、手動で確認した限りはこの事象は発生していないらしい。
Tsubasa NagasawaTsubasa Nagasawa

2025/1/8

Ratcheting validation missing for CRD status subresources

CRD のフィールドのバリデーションを変更して既存のオブジェクトの値が違反するようになったときに、そのフィールド以外を変更しようとしてもエラーになってしまうのを防ぐために CRD Validation Ratcheting の機能が入っていて Kubernetes 1.30 からベータ昇格してデフォルト有効。CRD の spec 配下のフィールドに関しては問題なく動作するけど、CRD の status subresource のフィールドのバリデーションを厳しくした場合に、違反したフィールド以外を更新してもエラーになる報告

EKS Auto モードの制約

EKS Auto モードでは t3.small (t3.nano, t3.micro も) のインスタンスは使えないらしい (aws/containers-roadmap#2516 (comment))

Tsubasa NagasawaTsubasa Nagasawa

2025/1/10

KEP-2570: Memory QoS の続報

KEP-2570: Memory QoS はメモリ消費の激しいワークロードでカーネルによるページキャッシュの解放とワークロードのメモリ割り当ての要求が拮抗して処理がスロットリングしてしまう問題があってベータ昇格できずにいます。PSI メトリクスでワークロードがスタックしたことを検知して OOMKill するみたいな案もありましたが、SIG-Node の Red Hat の方が Linux のメモリサブシステムを開発している同僚に相談して、より積極的にメモリ解放が行えるオプションの追加を検討して貰っているらしい (kubernetes/enhancements#2570 (comment))

Tsubasa NagasawaTsubasa Nagasawa

2025/1/15

KEP: Adding probe status field to the ContainerStatus and the probe worker can be suspended dynamically

以前からある livenessProbe を動的に無効化したい要望。今更必要かという議論からで、すぐには KEP 化されないけど、議論が面白かったので。ユースケースとしてはアプリのデバッグ時やデータベースのリストアなどの運用作業で一時的に無効化したいというもので、現状は Pod の親リソースのマニフェストの修正が必要で面倒。Pod に動的に変更可能なフィールドを追加して、livenessProbe を ON / OFF したい。最初は suspend のフィールドを追加しようとしていたけど、新しくフィールドを追加せずに livenessProbe の既存のフィールドを Pod 作成後に後から変更可能にしたらどうかという意見が。上位の PodTemplate と差分が出るけど、それは既にイメージが書き換え可能だったり、エフェメラルコンテナや InPlacePodVerticalScaling もあるし、何なら VPA が Pod 作成時にリソース割り当て調整したり、Mutating Admission Policy でも好きにできる。あとはこういう機能の設計の時に必ず出る、livenessProbe だけで良いのか問題。readinessProbe や startupProbe も一時的に無効化できるようにした方が実装がシンプルになるし、ユーザーの驚きも小さくなる

RoleBinding / ClusterRoleBinding の実装の背景

RBAC で RoleBinding / ClusterRoleBinding を作成したときに参照している Rele / ClusterRole や ServiceAccount の存在チェックが行われないのは仕様。リソース作成順に依らずに動作を保証している。(k/k#129268 (comment))

RoleBinding で namespace が空の場合は同一 namespace であることを表しているし、subjects フィールドを指定しなくても作れるのは後からコントローラーが紐付けられるようにするためでこれも仕様 (k/k#129267 (comment))

Prevent alpha feature gates from being enabled by default

2 年前に WindowsHostNetwork のアルファ機能を入れたときに誤って FeatureGate をデフォルト有効にしてしまったらしく、今更になって実装者本人が気付いたっぽい。アルファ機能でデフォルト有効な実装が間違ってマージされないよう CI で気付けるようにしたい Issue

UPDATE: デフォルトの FeatureGate の中を見てアルファ機能なのにデフォルト有効になっている FeatureGate がないかチェックするテストが追加された (k/k#129643)

Tsubasa NagasawaTsubasa Nagasawa

2025/1/17

Service 公開時に自動で追加される環境変数

Service で公開した IP アドレスやポート番号が Pod 内のコンテナのいくつかの環境変数 (e.g. REDIS_PRIMARY_SERVICE_PORT: tcp://10.0.0.11:6379) として自動的に設定される機能は Docker のレガシーなコンテナリンクの機能をそのまま Kubernetes に移植したもので黒歴史なので使うべきではない話。PORT なのにプロトコルと IP アドレスとポート番号が含まれていてフォーマットがおかしくないって言われてるけど、Docker が決めたことだから…らしい。Pod 作成時に差し込まれる環境変数なので、後から Service を更新したり作り直しても環境変数は新しい値に更新されない。Pod の enableServiceLinks フィールドを無効化することで環境変数が設定されないようにできる。本当はデフォルト無効にしたいけど、破壊的変更になってしまうし、その価値があるか微妙なので難しい。もう少しすると Mutating Admission Policy が利用できるようになるので、それで無効化を強制するのが望ましい。(k/k#129077 (comment))

Tsubasa NagasawaTsubasa Nagasawa

2025/1/19

Document why kernel tunable kernel/panic needs to be set to 10

kubelet はホストマシンのカーネルパラメータの一部が期待した値に設定されているかを確認していて、protectKernelDefaults が有効になっているとエラー終了する。protectKernelDefaults はデフォルト無効で、その場合 kubelet がカーネルパラメーターを変更しようとする。カーネルパラメータの中で kernel.panic_on_oops=1 と kernel.panic = 10 の指定を必須としているのはなぜかと Netflix の方からの質問。カーネルでパニックが起きたときに、コンテナを実行している Docker のプロセス (当時) がスタックし続けるのを避けるために、ホストマシンが再起動するよう設定している。
GCE だとカーネルでパニックが起きてもホストマシンは再起動されず、CPU 使用率が 100% に永遠に張り付くようになっているらしい。(GCE も Borg 上のプロセスとして動いているはずで、カーネルパラメータを変えても挙動は変わらない？) カーネルパニックが起きると kubelet が Node の状態を時間内に報告できなくなり、状態が Unknown になるだけで、それを検知する仕組みがないことが当時の懸念点として挙がっていた。当時は Node controller が更に 5 分後に Unknown 状態の Node から Pod を退避させる機能はなかった？

Tsubasa NagasawaTsubasa Nagasawa

2025/1/21

クラスタ全体に Pod の DNS 設定を強制する方法

Pod の DNS 設定の ndots を 5 から 1 に変えたい話がまた。クラスタレベルで設定できるようにしたいって話だけどやっぱり今更新しい設定を入れるのは難しくて Mutating Admission Policy でやって欲しいみたい。Mutating Admission Policy で Deployment / StatefulSets / DaemonSets の dnsConfig で ndots を強制的に 1 に指定させるポリシー。この場合、既存のリソースは kubectl get <resource> -A -o json | kubectl replace -f - で変更なし更新してあげないといけないし、CronJob / Job / Pod を作るカスタムリソースの対応も必要、Argo CD とかで管理していたら差分も出る。大規模だとスループットが気になるけど Pod レベルの方が楽そう (k/k#127137 (comment))

SIG-Scheduling の新しい Lead 予定の方の動き

Aldo さんの後任になる予定の macsko さん、SIG-Scheduling の approver まで来た (k/k#129720)

GKE の containerd 2.0 移行のタイミング

GKE は 1.33 (Kubernetes の upstream は 4 月頃リリース予定) から containerd 2.0 を使う予定なのか
(release notes)

Tsubasa NagasawaTsubasa Nagasawa

2025/1/23

[KEP-4205] Concerns on using CPU PSI pressure to taint nodes

KEP-4205: PSI Based Node Condition で Node レベルの PSI メトリクスの値が高い時にリソースの取り合いが起きていることを示す Node のステータス (e.g. KubepodsCPUContentionPressure) や taints (e.g. node.kubernetes.io/memory-contention-pressure=:NoSchedule) を付与する予定。ただ、Node レベルの PSI メトリクスだと CPU 上限を設定した Pod でスロットリングが発生している状態と本当に高負荷で複数のプロセスが CPU を取り合っている状態とを区別できないんじゃないかという指摘。

PSI メトリクスはリソース毎に下記のような情報を記録していて、some の行に処理が止まってしまった時間を示す訳だけど、その Node 上にリソース上限を間違って設定した Pod がいると Node レベルの PSI メトリクスの値に影響する。

some avg10=0.00 avg60=0.00 avg300=0.00 total=0
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

例えば、CPU 要求と上限をかなり小さく設定している状態で、8 つの CPU コアに対して stress-ng で負荷を掛けてみる。

apiVersion: v1
kind: Pod
metadata:
  name: stress-ng
spec:
  containers:
    - name: stress-ng
      image: quay.io/tiraboschi/stress-ng
      command: ['/usr/bin/stress-ng', '--temp-path', '/var/tmp/', '--cpu', '8']
      resources:
        requests:
          cpu: "10m"
        limits:
          cpu: "20m"

上記の Pod の CPU 負荷の状況を見てみると確かに高負荷状態であることが観測できる。

sh-5.1# cat /sys/fs/cgroup/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod5d95f454_57f6_4fc3_b5d4_6c7cf673b0cd.slice/cpu.pressure
some avg10=99.00 avg60=98.93 avg300=98.83 total=109943161035
full avg10=99.00 avg60=98.93 avg300=98.83 total=109935133476

ただ、Node レベルの PSI メトリクスを見てみるとこちらにも当然影響が見える。

sh-5.1# cat /sys/fs/cgroup/kubepods.slice/cpu.pressure
some avg10=88.89 avg60=89.90 avg300=92.84 total=678445993193
full avg10=3.13 avg60=4.25 avg300=17.54 total=645991129996

実際には Pod のリソース上限が想定よりも低く設定されたことによるスロットリングであって、Node 上のリソースが逼迫している訳ではない。KEP-4205 が入るとすると、Pod のリソース割り当ての設定ミスで、Node の状態を過負荷に変更され、taints が付けられて Pod が退避してしまうことになる。

Tsubasa NagasawaTsubasa Nagasawa

2025/1/24

KEP-4444: Traffic Distribution for Services の行く末

KEP-4444: Traffic Distribution for Services に同一ノード -> 同一ゾーンにフォールバックする PreferSameNode のモードを新しく追加しようとしていて、既存の PreferClose の名前が変更になる可能性がある。賢く良い感じにルーティングするという意味合いで PreferClose という名前にしていて、kube-proxy などの実装によって挙動は変わってくる。今回の PreferSameZone も PreferClose の賢いルーティング決めの中に組み込もうとしていたけど、同一ノードにルーティングされると困るケース (e.g. トラフィックが特定のノードに偏る) があるのではという話になった。で、昔の Topology Aware Routing 時代にゾーン毎の CPU 数で調整を入れたようなガードレールの話に戻り、あれはユーザーを混乱させただけだからやめようとなった。そうなると、賢く判断には限界があるからユーザーが PreferSameZone か PreferSameNode を指定する形の方が良いのではとなり、既存の PreferClose は PreferSameZone に名前を変える (既にベータ昇格済みで互換性から PreferClose が消えることはない？) かもしれない。最終的にどういう結論になるかは気になる (kubernetes/enhancements#4931 (comment))

Tsubasa NagasawaTsubasa Nagasawa

2025/1/25

Cilium で AdminNetworkPolicy 実装の動き

KEP-2091: AdminNetworkPolicy の機能がアルファで止まっているのを Google の SIG-Network の方が再始動しようとしているのと、Cilium でも対応させようとしている。NetworkPolicy は namespace 単位で設定するものでクラスタ全体に反映はできない。また、NetworkPolicy は allowlist で Deny のルールは書けない。AdminNetworkPolicy はクラスタ管理者が全ての namespace に強制したいガードレールなルールを設定できる。ルールに優先順位が指定でき、AdminNetworkPolicy の優先順位が高いルールから順に適用して、それが終わったら NetworkPolicy を適用する。また、Action の概念が追加され、Allow / Deny のルールが書けるのと、Pass というそのルールより優先度の低いルールは反映しないというルールも書ける。Cilium の場合は ClusterNetworkPolicy が既にあるけど連携はどうするんだろ (cilium/cilium#23380 (comment))

Tsubasa NagasawaTsubasa Nagasawa

2025/1/26

KEP 5067: Pod Generation

KEP-1287: In-Place Update of Pod Resources で Pod の status に新しく ResizeStatus が追加されて、リソース割り当ての変更が何らかの原因でブロック状態にないか、問題なくリソース割り当ての変更が完了したかを追跡できるようにした。最初に kube-apiserver が ResizeStatus を Proposed (リソース割り当ての変更を要求された時に指定) に指定し、その後で kubelet が変更状況に応じて InProgress (リソース割り当ての変更が可能で変更を反映中の状態)、Deferred (Node 上のリソースに空きがなく変更できない状態) や Infeasible (指定されたリソース割り当ての値が Node の容量を超えていて変更がそもそも不可能な状態)、"" (リソース割り当ての変更が反映完了した状態) に書き換える。そのため、kube-apiserver と kubelet の二人が ResizeStatus を更新することになり、競合する可能性がある。それに、ユーザーが Pod のリソース割り当ての変更を要求した後に再度別のリソース割り当ての変更を要求された場合に、ResizeStatus だけだと今どうなっているか (最初の要求は InProgress で次の要求は Deferred とか) が追跡できない。まず、競合を避けるために ResizeStatus の Proposed を削除する予定 (これは KEP-1287 の中で行われる)。また、他のコアリソース同様に Pod Status に新しく status.observedGeneration を追加して、kube-apiserver が Pod の更新 (一部の annotation を除く metadata と status の更新は除外) で metadata.generation を自動インクリメントするように変更する。で、kubelet が reconciliation 処理 (podSyncLoop) を実行している時に別のリソース割り当ての変更の要求が来ても、metadata.generation と status.observedGeneration の値を比較することで次のリソース割り当ての変更の要求の処理がまだことが把握できるようになる。で、kubelet は reconciliation 処理が終わったら status.observedGeneration を reconciliation 開始時に記録しておいた metadata.generation の値に更新する。この Pod の generation / observedGeneration を有効化する機能は ResizeStatus に限らず、今後 Pod の spec を後から更新できるようにする機能で有効なので、別の KEP-5068 Pod Generation として分離して提案されている。

Tsubasa NagasawaTsubasa Nagasawa

2025/1/27

Fix ephemeral container secret references

Ephemeral Container を起動するときに Secret などから環境変数を埋め込むとコンテナが起動できないバグがあったみたいで修正された。kubelet は system:node グループに所属する system:node:<node_name> のユーザーの権限を使って、Pod にマウントする Secret などの情報を kube-apiserver から読み取っている。で、kubelet には Node Authorizer の仕組みがあって、自分の Node で実行されている Pod 以外の Secret などのリソースは読めないように自動的に制限されてる。これにより、仮に kubelet が利用しているトークンが流出しても影響をその Node にとどめることができる。その Node Authorizer の実装の中で Pod の更新イベントを検知して Secret を読み込めるようにしているけど、更新イベントの中に Ephemeral Container の追加が漏れていて問題が起きていた

Tsubasa NagasawaTsubasa Nagasawa

2025/1/28

client-side apply と server-side apply でのリソース作成時の認可の違い

RBAC で特定のリソース名に対する create 操作を許可しても client-side apply だと権限エラーになる。Kubernetes の認可の仕組みは API リクエストのパスしか見なくて、リクエストの body は見ない。client-side apply でリソースを create した場合、POST リクエストのパスにはリソース名は含まれないので権限エラーになる。server-side apply の場合はパスにリソース名が含まれるので権限エラーは発生しない (k/k#80295 (comment))

Tsubasa NagasawaTsubasa Nagasawa

2025/1/29

Version 2.0.1+ freezes when initially deploying

containerd 2.0.1 以降で初回起動時に CNI の操作と競合してスタックする問題。複数 CNI で containerd を再起動すると発生する報告も。CNI のライブラリで最近入った変更でデッドロックが発生するバグが混入した影響。CNI のライブラリ側は修正版リリース済みで、containerd 2.0.3 (2025/2/13 リリース？) で修正版がリソース予定でそれまでは上げない方が良さそう

Tsubasa NagasawaTsubasa Nagasawa

2025/1/31

Kubernetes 公式のプロジェクトの命名規則の推奨

Kubernetes 公式のサブプロジェクト (e.g. kubernetes-sigs 配下のプロジェクト) を作る時のプロジェクトの命名のガイドライン。歴史的に kube の文字列を含むことが多いから推奨するよって話と kube / k8s / kubernetes などの文字列を含んでいる紛らわしいサードパーティのプロジェクトがあって、名前変えろとは言わないけど k8s と kubernetes は商標登録されているから気をつけてねと。Kubernetes だけじゃなくて K8s も商標登録されてるんだ

"Kubernetes" and "K8s" are registered trademarks under the Linux Foundation.

Tsubasa NagasawaTsubasa Nagasawa

2025/2/1

Consistent Reads cause increased Pod creation latency

Kubernetes 1.31 からデフォルト有効になっている KEP-2340: Consistent Read from Cache の機能は etcd >= v3.5.13 になると自動的に有効になる。Kubernetes のコンポーネントが最新の情報をもとに処理するか判断したい場合、etcd の Quorum Read (クラスタ内の大多数のメンバーがデータを持っていることを確認) を利用することになるが重い処理となる。特に namespace 以外のラベルやフィールドセレクタでリソースを除外する場合、kube-apiserver 上にリソースを一旦全て取得してインメモリ上でフィルターを掛けるのでボトルネックになる。特に kubelet が自身の Node にスケジュールされた Pod のみを取得する場合、etcd と kube-apiserver に負荷が掛かっていた。KEP-2340: はこの問題を解決するためのもので、すべてのリソースを毎回取得するのではなく、etcd の watch リクエストを通して定期的に最新の情報を取得してキャッシュを最新化する。問題なのはキャッシュが最新化をどう判断するかで、そのために etcd の Progress Notification の機能を使っている。Progress Notification によりキャッシュの中のデータが etcd の中のデータに比べてどれだけ遅れているかが分かる。キャッシュが最新じゃないことが分かれば、あとは Progress Notification を使って最新の状態になるまで確認すれば良い。これによって、Quarum Read を必要とする場合でも、kube-apiserver はキャッシュの差分だけを更新すれば良くなる。とはいえ、何か魔法があってキャッシュが瞬時に最新の状態になるわけではなく、あくまでキャッシュが最新化されるのを待つだけではある。少なくとも大規模なクラスタでリソースを全て取得して処理するよりは早い。で、この Progress Notification が 100 ms 間隔で実行されるのだが、これが原因で Pod 作成のレイテンシが悪化した問題の報告。Google の内部の負荷テストで見つかった問題で、namespace が数百個ある環境で ResourceQuota を設定するとその検証に 2 秒から 3 秒かかる。問題は namespace に ResourceQuota がない場合で、フォールバックしてResourceQuota を Quorum Read で無駄に読もうとして Progress Notification の間隔 (100 ms) のペナルティを食らって処理が遅れる。さらに悪いことに 5 並列でしか namespace を処理しないので namespace が数百個あるとその分遅くなる。それが積もって Pod 作成のレイテンシが悪化したらしい

Tsubasa NagasawaTsubasa Nagasawa

2025/2/2

EKS の匿名ユーザーに対する制限

EKS v1.32 からベータ昇格してデフォルト有効になった KEP-4633: Only allow anonymous auth for configured endpoints を利用して、匿名ユーザーがアクセスできるエンドポイントを制限している。kube-apiserver の前段の LB のヘルスチェックで使うエンドポイント (/healthz, /livez, /readyz) 以外で匿名ユーザーは使えない。匿名ユーザーに強い権限を付与されてもクラスタ内で悪さできなくなる (aws/containers-roadmap#532 (comment))

Kubernetes の VAP で Pod に対するルールを書くときに PodTemplate が埋め込まれている上位のリソース (e.g. ReplicaSet, Deployments, StatefulSets) などに対しても同様のルールを書く必要があり、ポリシー内の CEL 式が複雑になる。それを避けるために CEL の Kubernetes 拡張として extractPodSpec(object) 的な関数を用意してくれないかという要望。KEP-5040: Remove gitRepo volume driver を進めている Google の方が gitRepo を作れなくする VAP を用意していてその時に気になった感じか。確かに可読性が悪くなるし、面倒なので欲しい

Before:

  validations:
    - expression: |-
        object.kind != 'Pod' ||
        !object.spec.?volumes.orValue([]).exists(v, has(v.gitRepo))
      message: "gitRepo volumes are not allowed."
    - expression: |-
        object.kind != 'PodTemplate' ||
        !object.template.spec.?volumes.orValue([]).exists(v, has(v.gitRepo))
      message: "gitRepo volumes are not allowed."
    - expression: |-
        !['Deployment','ReplicaSet','DaemonSet','StatefulSet','Job', 'ReplicationController'].exists(kind, object.kind == kind) ||
        !object.spec.template.spec.?volumes.orValue([]).exists(v, has(v.gitRepo))
      message: "gitRepo volumes are not allowed."
    - expression: |-
        object.kind != 'CronJob' ||
        !object.spec.jobTemplate.spec.template.spec.?volumes.orValue([]).exists(v, has(v.gitRepo))
      message: "gitRepo volumes are not allowed."

After:

  validations:
    - expression: |-
        !extractPodSpec(object).?volumes.orValue([]).exists(v, has(v.gitRepo))
      message: "gitRepo volumes are not allowed."
Tsubasa NagasawaTsubasa Nagasawa

2025/2/4

Streaming json list encoder

大量のリソース (特に CRD) を LIST したときに kube-apiserver は受け取った items をインメモリに置いて一気に JSON にシリアライズするため、メモリ使用量がかなり高くなる。Go の JSON の標準ライブラリは現状 streaming でシリアライズする機能がないので、独自に JSON の streaming でエンコードする処理を書いて、items を一つ一つシリアライズすることでメモリ使用量を大幅に削減した。負荷テストでピーク時のメモリ使用量は 1/10 から 1/20 に減っていて、レイテンシも改善している。あくまでピークのメモリ使用量を減らしているだけで処理時間を通して平準化されている。結構インパクトのある変更なので、デフォルト有効で FeatureGate が追加されていて、何かあれば無効化は可能。元々は KEP は書かないつもりだったけど、KEP-5119: Streaming response encoding として詳細もまとめられている。Go の JSON の標準ライブラリが v2 を絶賛開発中で、streaming エンコードもサポートしており、試しに使ってみたら良い感じだったようで、将来的にはカスタムのエンコーダーの実装を置き換える予定 (k/k#129334 (comment))

KEP-127: update beta to be on by default

Kubernetes の User Namespaces の機能はバージョンスキューのしがらみがなくなる Kubernetes 1.33 でデフォルト有効になる予定

Tsubasa NagasawaTsubasa Nagasawa

2025/2/5

Excessive conntrack cleanup causes high memory (12GB) and CPU usage when any Pod with a UDP port changes

Kubernetes 1.32 から kube-proxy の UDP の conntrack reconciler の処理が追加されていて、UDP を喋る Pod (e.g. CoreDNS への問い合わせ) が頻繁にスケールする場合に kube-proxy のメモリ使用量が高騰して OOM が頻発する問題の報告。limits 指定しないとピーク時に 12 GiB 消費。conntrack テーブルの中の stale な UDP のエントリをお掃除するのに netlink の Go のライブラリを使っていて、削除に失敗した時にエラーメッセージを slice に溜め込んでおり、肥大化してしまっている。kube-proxy のオプションで無効化することができないので、サービス影響が出ていて困っているらしい。ある程度の規模のクラスタじゃないと起きなさそうではあるけどやばそう。EKS クラスタの利用者からの報告。

Promote SidecarContainers feature to GA

Sidecar Containers の GA の PR マージされました。特に問題なければ Kubernetes 1.33 で GA します

Tsubasa NagasawaTsubasa Nagasawa

2025/2/6

KEP-5080: Ordered Namespace Deletion

Namespace を削除した時にリソースが削除される順番をちゃんと決めて、セキュリティ的な問題 (e.g. Pod が残っている状態で NetworkPolicy が消える) や意図しない挙動を起こさないようにする KEP。現状はリソースがランダムに削除されている。Namespace を削除した流れはシンプルで以下の通りになる予定。

  1. Namespace 内の Pod をランダムに全て削除
  2. Namespace 内の Pod が全て削除されるまで待つ
  3. Namespace 内の Pod 以外のリソースをランダムで全て削除

元々は全てのリソースを考慮した完璧な削除順を考えていたけど、複数のリソースが絡むと競合する可能性があること、机上だけでは正しさが保証できないことから断念。Pod と NetworkPolicy の削除順によるセキュリティ上の問題を何より解決したかったので、スコープを狭めることにした。

Tsubasa NagasawaTsubasa Nagasawa

2025/2/8

KEP-4939: Support TLS in gRPC probe

Pod Spec で指定可能な既存の gRPC probe は TLS が有効でないサーバでしか使えず、TLS 化している場合は exec probe で grpc_health_probe のバイナリを TLS 証明書を検証しないモードで実行するしかない。せっかく gRPC probe があっても使えず不便なので、gPRC probe に新しく TLS オプションを追加して証明書の検証なしでヘルスチェックのリクエストを投げられるようにする予定

EDIT: 2025/2/16 現在 KEP の例外申請が出されていないので、Kubernetes 1.33 では入らなそう

Tsubasa NagasawaTsubasa Nagasawa

2025/2/9

KEP-3015: PreferSameZone/PreferSameNode traffic distribution

KEP-4444: Traffic Distribution とは別に KEP-3015: PreferSameZone/PreferSameNode traffic distribution が作られて、現状の PreferClose のエイリアスとして PreferSameZone を追加する予定。また、新しく PreferSameNode が追加され、同一 Node -> 同一 Zone -> 適当な Endpoint にフォールバックするモードが追加される。PreferClose は削除されないが非推奨となり、ゆくゆくは PreferSameZone の利用を推奨。PreferClose の意味合いは今後変えず、PreferSameZone と同じ意味合いとなる。元々は PreferClose の解釈をサービスプロキシの実装者に任せて柔軟性を与える方針だったが、不明瞭なだけで新しいモードを追加しづらかった。今回 PreferSameNode を新しく追加する時に PreferClose の意味合いを変えることで引き起こされる影響を気にした。同一 Node -> 同一 Zone -> 適当な Endpoint のフォールバックにしてしまうと、Pod の分散状況によっては特定の Node の Endpoint にトラフィックが偏ってしまう可能性がある。そうなると、以前の Topology Aware Routing の時の過ちと同じくガードレール (Endpoint を CPU コア数で補正) を敷く必要あるか問題に戻り、サービスプロキシが自動的にユーザーが求める賢いトラフィックを選択することに限界があった。モードをいくつか用意してユーザーが選ぶ形式の方が柔軟性がある。kube-proxy や Cilium などの PreferClose は PreferSameZone の意味合いで実装されているので KEP-3015 の追加で実装を変更する必要はないが、他のサービスプロキシの実装が仮に PreferSameZone モードを想定して実装していないとすると変更が必要となる。PreferSameNode の追加では、EndpointSlice の中の Endpoint の情報に新しく ForNodes (PreferSameZone における ForZones) のヒントが追加され、Endpoint (Pod) が存在する Node の情報 (将来的な拡張のために slice になっているが、現状は slice の長さは 0 or 1 を想定) が記録される。kube-proxy の実装では CategorizeEndpoints の関数に変更が入って、Endpoint の ForNodes の情報を見て送信元の Pod と同じ Node の Endpoint が存在したら、その中からトラフィックを流す Endpoint を決める。Kubernetes 1.33 で KEP-2433: Topology Aware Hints は EndpointSlice の Hints のフィールドのみ GA し、KEP-4444: は trafficDistribution のフィールドと PreferClose モードのみ GA する予定

Tsubasa NagasawaTsubasa Nagasawa

2025/2/11

[Proposal]Introduce a Header to Indicate Image Pull Intent

コンテナレジストリで OCI イメージを管理するときにそのイメージが今も使われているかを最後にプルされた時刻で確認するが、定期的に脆弱性スキャンを実行していると定期的にプルされるので最後にユーザーにプルされた時刻が更新されてしまう。なので、脆弱性スキャンなど本来と違う用途で OCI イメージをプルする時の HTTP ヘッダーを標準化したい (X-OCI-Pull-Robot) って話みたいだけど、User-Agent のヘッダーで良くないって言われている。脆弱性スキャンも効率化のためにイメージレイヤーのダウンロードは 1 度だけにして、そのレイヤーに関連する SBOM をキャッシュしておいて、以降のスキャンでは HEAD リクエストでイメージのダイジェストに変更がないか確認してキャッシュしておいた SBOM に対して脆弱性スキャンを掛けたりしているらしい。そもそも、用途が不明なイメージのプルには Docker CLI や crane などを使ってイメージを別のコンテナレジストリに移動させるたことも含まれるし、プルする時の HTTP ヘッダーから用途を明らかにするのが難しいケースもあるよねと。なので、レジストリ側で User-Agent のヘッダーとか IP アドレスとかの情報を使ってイメージプルのメトリクスのカウントから除外するようにした方が良い。

Tsubasa NagasawaTsubasa Nagasawa

2025/2/12

KEP-5008: Introduce Kubernetes Desktop

Kubernetes Dashboard の代替のような GUI アプリを提供 (Web アプリとしても動かせるらしい) している Headlamp を SIG-UI のサププロジェクトとして寄贈するらしい。元々は Kubernetes Desktop に名前を変える予定でなぜか KEP にもなっていたけど、その辺りは慎重に方針を決めないとユーザーも混乱するので改めて考える予定

Tsubasa NagasawaTsubasa Nagasawa

2025/2/13

Introduce kuberc as new flag to customize defaulting and define aliases in kubectl

KEP-3104: Introduce kuberc が Kubernetes 1.33 でアルファ機能として入る予定。kubectl のエイリアスやデフォルトで追加したい引数の設定を YAML 形式で宣言的に書けるようになる。kubeconfig でも元々 preferences に設定できるが、余り使われていない。kubeconfig はクラスタの認証情報を追加したり削除したり、中身が動的に変わる。kubectl のエイリアスなどの設定は変更も少ないし配布もしやすいので、別のファイルで管理した方が良い。デフォルトは ~/.kube/kuberc から読み込んで、—-kuberc のフラグで設定ファイルを渡すことも可能。kubeconfig で kuberc との紐付けを設定することはできなさそう。kubectl delete で事故が起きないようにデフォルトで interactive モードにしてくれと昔から要望があったが、今更変えると破壊的変更になるので kuberc が使えるようになるのを待てと言われていた機能。アルファの間は KUBECTL_KUBERC=true の環境変数を指定しないと使えないようになっている

Tsubasa NagasawaTsubasa Nagasawa

2025/2/14

CVE-2025-0426: Node Denial of Service via kubelet Checkpoint API

2025/2/7に予約されていた CVE が公開。ContainerCheckpoint の kubelet の API (/checkpoint) が kubelet の読み取り専用ポート (認証認可なしで公開 OK な API 用のポート) から誤って公開されていて、DDoS 攻撃を受けると大量のチェックポイントの tar がホストのディスクを占有して影響する。ContainerCheckpoint の機能が有効な場合、かつ containerd 2.0 以降じゃないといけないので、GKE や EKS だと影響なさそう

Tsubasa NagasawaTsubasa Nagasawa

2025/2/16

KEP-4742: Expose Node labels via downward API

kube-apiserver に新しく組み込みの Admission plugin を実装して、Node のトポロジに関連する公式のラベル (topology.k8s.io/zone, topology.k8s.io/region, kubernetes.io/hostname) を Pod のラベルに追加する。Downward API で Pod の任意のラベルから環境変数やファイルに値を埋め込むことが可能なため、トポロジのラベルも Downward API で利用可能となる。トポロジに関するラベルは Node オブジェクトから取得する必要があり、Pod を作成した時点では Node の情報は分からず、Pod がスケジュールされる Node が決まった後でしか情報を埋め込めない。なので、kube-scheduler が Pod を配置する Node を決めた後の Bind 拡張点で呼び出される pods/binding サブリソース (Pod Spec の nodeName を指定) の作成要求に割り込んで、Node のラベルの情報を Pod のラベルにコピーする。pods/binding サブリソースでは Binding オブジェクトを介して、対象の Pod の nodeName や Pod UID、Binding オブジェクトに設定された annotations をマージする。現状は Binding オブジェクトに設定されたラベルを Pod のラベルにマージする機能がないので、KEP-4742 で追加される予定。諸々の情報が追加された Pod はそのまま etcd に保存される。KEP-4742 で追加される Admission plugin は Binding オブジェクトのラベルに公式の Node のラベルを伝搬する形。公式のラベル以外のカスタムラベルに関しては独自に pods/binding のサブリソースに対して Mutating Admission Webhook を実装することで追加可能。セキュリティ上の懸念から許可されたラベルのみをコピーする形にしている。ユースケースとしては同一ゾーン内の GPU を使って AI / ML の分散ジョブを実行したい場合に、フレームワークレベルでゾーンやラックなどの情報を使ってお互いにやり取りできるようにしたいとか、分散システム (e.g. Kafka) でトポロジの情報を元に異なるゾーンにシャードを作成することで耐障害性を向上したいとか、CNI plugin がトポロジの情報を利用して Pod 間の通信を最適化したいというのが挙げられている。個人的には Pod のラベルに Node の名前やゾーンの情報が付くので、メトリクスやログにも Node のトポロジの情報が自動的に付与されるようになる。特に、ゾーンやノード毎のアプリケーションのレイテンシなどのメトリクスを見たい時に Node のメトリクスとの JOIN が不要になるはず。Kubernetes 1.33 でアルファ機能として入ることを目指している。

Tsubasa NagasawaTsubasa Nagasawa

2025/2/18

[FG:InPlacePodVerticalScaling] Forbid memory limit decrease

KEP-1287: In-place Pod Resource Update は Kubernetes 1.33 でベータ昇格を目指しているけど、一旦再起動を伴わないメモリ上限の変更はできない形で行くのか。現在のメモリ使用量に合わせて徐々にメモリ上限を減らしていくので指定された値に減らすまでに時間がかかる。どうするのが良いかまだ迷ってる感じで、将来的には対応予定。

Tsubasa NagasawaTsubasa Nagasawa

2025/2/19

Add OCI/Image Volume Source support

containerd の OCI Image Volume Source の実装マージされました。使えるようになるのは次のマイナーバージョン？

Mark v1.Endpoints deprecated

KEP-4974: Deprecate v1.Endpoints and Associated Controllers が Kubernetes 1.33 でアルファ機能として入ります。Kubernetes 1.21 で EndpointSlice が GA してから結構経ち、新しい機能は EndpointSlice にしか追加されていない (e.g. IPv4 / IPv6 Dual-stack, Topology Aware Hints) かつ kube-proxy などの EndpointSlice 移行も終わり外部のツールの移行も落ち着いたであろう段階なので、ついに非推奨となります。KEP-4974 で Endpoint の API リソース自体は削除されず、あくまで非推奨になるだけです。KCM で Endpoint / EndpointSlice Mirroring controller を無効化しても Kubernetes は壊れずに動くはず。Endpint オブジェクトに対して操作を行うと警告ログが返されるようになります。気をつけないと GKE の非推奨検知が無駄に発動してクラスタが自動で更新されなくなるかも？クラスタ内から kube-apiserver に接続するために使う default namespace に作成される kubernetes の Service の Endpoint / EndpointSlice は kube-apiserver が作成しているのですが、Endpoint controller を将来的に廃止するときにこの Endpoint どうするかはまだ考え中。etcd の中に残る既存の Endpoint オブジェクトのお掃除をどうするかも考え中だけど、今のところクラスタ管理者が手動で削除する案が有力そう。

Revert userns kernel check

Kubernetes の User Namespaces の機能で kubelet の起動時に勝手にカーネルのバージョンを確認して警告ログを書き込む処理が追加されていて、それに半年以上経って気付いた rata さんが結構熱くなってる。tmpfs で id-mapped mount がサポートされた Linux Kernel 6.3 以上かのチェックが今は入っていて (Pod の基本的な機能である Secret や Service Account トークンが tmpfs でマウントされるから)、それを revert しようとしている PR。Linux ディストリビューションによっては tmpfs の id-mapped mount のサポートを backport している可能性があるので、sysctl で確認するのが確実。Kubernetes 1.33 で User Namespaces の機能はデフォルト有効になるので、Linux Kernel 6.3 より前の OS で kubelet を動かすと警告ログが必ず書き込まれてノイズになる。Pod を作成するとエラーが返ってくるので、それで良くない？というスタンス。ダミーのファイルシステムを id-mapped mount でマウントできるか確認する処理に変えたらって言われているけど、Linux カーネル側でファイルシステム毎にサポートされるバージョンが違っていて、全てのファイルシステムを起動時にチェックするのは現実的じゃないって反対している。

Tsubasa NagasawaTsubasa Nagasawa

2025/2/20

Update kubectl subresource to stable

Kubernetes 1.27 でベータ昇格して長らく留まっていた kubectl の subresource のサポートが Kubernetes 1.33 で GA します。kubectl get —raw でサブリソース (e.g. status) の取得は可能でしたが、更新するには curl で頑張るしかなかったです。kubectl get だけでなく patch や apply などにも —subresource のオプションを指定できるようになったので、更新も行えます。In-place Pod Vertical Scaling の機能が有効になれば、kubectl で resize のサブリソースも呼び出せます。

Tsubasa NagasawaTsubasa Nagasawa

2025/2/22

OpenReports Proposal

Kubernetes に PolicyReport API を追加して Kyverno や Trivy Operator、Falco などのポリシーベースで検知した結果を通知する話は OpenPolicy として CNCF の別のプロジェクトとしてやっていくみたい。Report のカスタムリソースの標準化に加えて検知結果の保存方法や通知、UI も含む。特に検知結果のオブジェクトサイズが膨大になりがちなので、etcd のオブジェクトの保存限界の 8GiB を超えうる。なので、Aggregation Layer で新しく API のみを追加して、検知結果を PostgreSQL に保存できるようにする (規模が大きくない場合は etcd に保存するオプションもある) Reports Server を Kyverno の人が開発している

Tsubasa NagasawaTsubasa Nagasawa

2025/2/24

Add Pressure Stall Information Metrics

cAdvisor についにコンテナレベルの PSI メトリクスが追加された

  • container_pressure_cpu_stalled_seconds_total
    • コンテナ内の全てのタスクが他の処理 (i.e. 他の cgroup 内のタスクもしくは cpu.max を超えたことによるスロットリング) のせいで CPU を利用できなかった (stalled 状態となった) 時間の合計
  • container_pressure_cpu_waiting_seconds_total
    • コンテナ内のタスクのいくつかで処理待ちが発生した時間の合計。cgroup 内の一部のタスクは処理を進められている可能性がある点で FULL (stalled) と異なる
  • container_pressure_memory_stalled_seconds_total
  • container_pressure_memory_waiting_seconds_total
  • container_pressure_io_stalled_seconds_total
  • container_pressure_io_waiting_seconds_total

EDIT: Kubernetes 1.33 に組み込まれそう (cAdvisor v0.52.0 release notes)

Tsubasa NagasawaTsubasa Nagasawa

2025/2/27

OCI Image Volume の改善

OCI Image Volume の機能が PSA の restricted レベルが設定された namespace で不明なボリューム扱いになり使えない問題が修正された。OCI Image Volume は 1.33 でベータ昇格予定で、ImageLocality plugin のスコア計算で考慮されない問題もベータ昇格前に修正されるはず

Tsubasa NagasawaTsubasa Nagasawa

2025/2/28

kube-proxy 1.32 の UDP conntrack reconciler のバグ - その 2

kube-proxy 1.32 でメモリ使用量が高騰するバグとは別に新しく報告があった conntrack reconciler の問題。RKE2 で Flannel CNI を利用している場合に、kube-proxy の conntrack reconciler が Flannel の VXLAN (ノード間で overlay でパケットをやり取りするためのトンネル) の UDP エントリを全て削除しちゃって、Flannel CNI が busy になり livenessProbe に失敗して再起動を繰り返す。conntrack reconciler で kube-proxy のルールに関連するエントリかをフィルターする処理が甘く、送信先の Service の仮想 IP アドレスに加えてポート番号も見るように修正が必要。ただし、既に 2 回もリグレッションが発生しているので、一度 conntrack reconciler の変更を revert して KEP 化して FeatureGate で守りながら実装を進めることになるっぽい (k/k#129982 (comment))

EDIT:
stall な UDP の conntrack エントリを削除するときに大量のエラーログが出ていた (大量の netlink の呼び出しがあった) 原因が分かって、送信先の Service のポート番号を考慮していなかったので全ての UDP のエントリを定期的に (—-iptables-min-sync-periodの間隔) 削除してしまっていた。なので、以前の修正でメモリ使用量の問題は解消されても CPU 使用率は以前より高くなっており、ノイジーネイバーになっていると思われる。ユニットテストで大量の netlink の呼び出しが発生していたことも再現できたので、1.32 の UDP の conntrack reconciler の処理の追加は revert せずに修正を backport する形でいくみたい (k/k#129982 (comment))

Tsubasa NagasawaTsubasa Nagasawa

2025/3/2

Add progress tracking permission change

Kubernetes 1.33 から FSGroup を利用して Pod にマウントしたボリュームの内のファイルの所有者を再起的に変更するのに 30 秒以上掛かっていると、処理したファイル数を 1 分置きに Kubernetes イベントとして書き込むようになる

Tsubasa NagasawaTsubasa Nagasawa

2025/3/4

KEP-5073: Declarative Validation: Add validation generator

KEP-5073: Declarative Validation of Kubernetes Native Types With validation-gen が Kubernetes 1.33 でアルファ機能として入る予定。Kubernetes 専用のタグ (+k8s: で始まるコメント) を指定することで、API の各フィールドのバリデーションのコードを自動生成する validation-gen が追加される。現状 Kubernetes のコードベースには 1181 個のバリデーションルール (15k 行のコード) が存在しており、人手で書いているので面倒だし、バグも混入しやすいので改善するための KEP。元々は CEL 式を書く形を予定していたみたいだけど、Go でコード生成する方が柔軟性が高いのでそちらを採用。slice や map の一部のキーや値の制約を書いたり、フィールドが必須か必須でないか、指定したフィールドが禁止された値 (e.g. ゼロ値、nil) でないかを検証するタグが実装されている。今後は Enum や Union 型 (e.g. 〜のうちのどれか、〜のうちの全てに一致) のための検証ロジックも生成できるようになる。将来的には CRD でコア API リソースを埋め込んでいる場合 (e.g. PodTemplate) にバリデーションのロジックを書く必要がなくなるかも。

Tsubasa NagasawaTsubasa Nagasawa

2025/3/5

問題のある EKS Node のログを S3 に自動アップロード

KS で Node Monitoring Agent をインストールしておくと問題の起きた Node の各種ログを S3 にアップロードできる。事前に S3 バケットを作って pre-signed S3 URL を払い出して、NodeDiagnostic のカスタムリソースを作成する流れ (aws/containers-roadmap#2199 (comment))

multicluster-runtime/multicluster-runtime

https://x.com/everpeace/status/1897093258226102382?s=46&t=3jENizNuk3ODUC2chpnF8Q

Tsubasa NagasawaTsubasa Nagasawa

2025/3/7

kubernetes-sigs/network-policy-finalizer

namespace を削除した時に Pod よりも先に NetworkPolicy が削除される (許可されていない通信ができてしまう) のを防ぐためのシンプルなコントローラー。全ての NetworkPolicy に finalizer を付与して、namespace controller が NetworkPolicy を削除している場合にその namespace 内の Pod が全て削除されるまで待ってから NetworkPolicy に設定された finalizer を取り除く。namespace controller が NetworkPolicy を削除しているかは namespace に deletionTimestamp が設定されているかで確認し、設定されていない場合は NetworkPolicy をユーザーやそれ以外の controller が削除しているので finalizer をすぐに取り除く。

KEP-5080: Ordered namespace deletion が利用できるようになる (Kubenretes 1.33 でデフォルト有効予定) と不要になるが、Security Committee から SIG-Network に話が言ったようで急遽作った感じかな kubernetes/org#5433。KEP-5080: Ordered namespace deletion は元々 Kubernetes 1.33 でアルファ機能で入る (デフォルト無効) だったけど、デフォルト有効に急に変更された (k/k#130507)。現在サポートしている Kubernetes のバージョンにも backport されて、デフォルト無効で FeatureGate が追加されているので、古いバージョンでも Ordered namespace deletion は有効化できる状態。この感じ Kubernetes の CVE として登録されるんじゃないかな (k/k#130508)

EDIT (2025/3/21): スコアは低いけど CVE-2024-7598 として登録された

Tsubasa NagasawaTsubasa Nagasawa

2025/3/10

Fix kubelet restart unmounts volumes of running pods if the referenced PVC is being deleted by the user

ボリュームをマウントしている Pod が動いている時にユーザーが PVC を削除し、そのあとで kubelet が再起動すると動いている Pod のボリュームがアンマウントされるバグの修正。kubelet が再起動した後に DSW (Desired State of World) で Pod にマウントすべきボリュームの情報を生成するが、その中に PVC が Terminating 状態で stuck しているボリューム (pvc-protection の Finalizer が設定されている PVC) が含まれておらず、Pod からアンマウントされていた。派生して、Pod が動いている状態で PVC を削除するとそれ以降 Pod にマウントされた ServiceAccount のトークンが更新されなくなる問題 (k/k#130442) も一緒に解決されているらしい

Tsubasa NagasawaTsubasa Nagasawa

2025/3/13

[KEP-4639] Graduate image volume sources to beta

KEP-4639: OCI Image Source がこのまま何もなければ Kubernetes 1.33 でベータに昇格。ただし、FeatureGate はデフォルトで無効。ボリュームをマウントする際に subpath を指定可能になり、OCI Image の中の特定のパスだけをマウントできる。ただ、コンテナランタイム側の対応が必要で CRI-O は PR 上がっていて、それを使ってテストもしてそうだけど、containerd はまだ対応していない

Tsubasa NagasawaTsubasa Nagasawa

2025/3/14

CVE-2025-1767: GitRepo Volume Inadvertent Local Repository Access

GitRepo Volume でまた別の脆弱性が見つかっている。GitRepo を利用している Pod と同じ Node で動いている別の Pod が Node 上に clone された Git リポジトリにアクセスできてしまう問題。GitRepo Volume は以前から非推奨となっているので、修正パッチは適用されない。VAP で GitRepo を指定した Pod を作成できないようにすることが推奨されている。それとは別に KEP-5040: Remove gitRepo volume driver で Kubernetes からの完全な削除が進められている。Kubernetes 1.33 で GitRepoVolumeDriver の FeatureGate がデフォルト無効で追加されて使えなくなる予定。完全な削除は今のところ Kubernetes 1.39 を予定。

Tsubasa NagasawaTsubasa Nagasawa

2025/3/16

DNS latency when a CoreDNS pod is deleted

CoreDNS の Pod を再起動したときに名前解決が上手くいかずにレイテンシが一時的に悪化する問題も kube-proxy の UDP の conntrack reconciler の機能の諸々の修正 (>= 1.32.3) で改善したらしい。CoreDNS の古い Pod の tuple への conntrack エントリが残っていて名前解決がタイムアウトしていたのが原因。nf_conntrack_udp_timeout のカーネルパラメータを短くする (デフォルト 30 秒) して UDP エントリの TTL を短くすれば回避は可能。EKS で報告されているけど、kube-proxy を利用しているプロバイダーだと影響を受ける。

Better handling of YAML that tastes like JSON

Kubernetes 1.33 から YAML の Flow Style (= JSON の拡張記法) を正式にサポート。YAML は JSON のスーパーセットと言われているけど、Flow Style で書くと JSON と同じ形で書けてコメントや最後のコンマを書いても怒られない。例えば、以下の YAML を yq で読み込んでも正常に認識される。

{
  # This is valid YAML with Flow Style
  "apiVersion": "v1",
  "kind": "Pod",
  "metadata": {
    "name": "nginx"
  },
  "spec": [
    {
      "containers": [
        {
          "name": "nginx",
          "image": "nginx:1.14.2",
          "ports": [
            {
              "containerPort": 80,
            },
          ],
        },
      ],
    },
  ],
}

ただ、これを kubectl apply するとこれまでは JSON と判断されて以下のエラーになっていたけど、YAML として認識されて反映できるようになる。

error: error parsing STDIN: json: offset 5: invalid character '#' looking for beginning of object key string

今更なぜこんな変更が入っているかというと kubectl の出力フォーマット (-o) に新しく kyaml を追加しようとしていて (WIP: Add "kyaml" support to kubectl) その副産物。kyaml のサポートに関しては 1.34 で KEP を書いて進める予定。kyaml は YAML の下位集合で YAML の自由さを制限した Kubernetes の方言で、YAML の仕様の曖昧な部分や空白地獄を改善するために提案されている。将来的には公式ドキュメントの YAML が kyaml 形式に置き換わるかも。

  • パッチを当てる時に記述しやすいように JSON のようにインデントはあってもなくても良い
  • フィールドのキーの名前は " で囲う必要がないが、誤って別の型 (e.g. Boolean の yes / no) として読み取られないように文字列を " で囲うことを強制
  • Map 型の値を記述するときは必ず {} で囲う
  • 配列の値を記述するときは必ず [] で囲う
  • #!yaml の shebang をヘッダーとして付与 (これはなくなるかも)
  • コメントを記載可能
  • 配列などの最後の要素に , を付けても良い
  • 一部の括弧を寄せて空白地獄にならないように (e.g. [{)
Tsubasa NagasawaTsubasa Nagasawa

2025/3/20

[FG:InPlacePodVerticalScaling] Graduate to Beta

Kubernetes 1.33 で今度こそ In-place Pod Vertical Scaling がベータ昇格してデフォルト有効になりそう。まだ 1.33 に向けた残作業あるみたいだけど

Add workqueue for node updates in DaemonSetController

DaemonSet controller のパフォーマンス改善で PodInformer にノード名で Index を付けて自身の Node で動作している Pod のみを取得するようにしたのと、Node の更新イベントを受け取る workqueue を別で用意して Node 名でタスクを積むようにすることで Node のイベントが大量に発生しても重複排除して余計な処理が走らないようにしている。同様の変更が StatefulSet controller にも入る予定。

feat(nodeadm): enable CDI for 1.32+

EKS でも DRA サポートの準備が進んでいて AL2023 の containerd で CDI を有効化

Tsubasa NagasawaTsubasa Nagasawa

2025/3/23

ConfigMap SubPath Volume Mount failed on util-linux=2.41

mount コマンドが含まれている util-linux の 2.41 でリグレッションがあったらしく、ConfigMap を subpath でマウントすると CreateContainerConfigError で Pod が起動できなくなる問題が報告されている。今のところ util-linux のバージョンをロールバックするしかない

Tsubasa NagasawaTsubasa Nagasawa

2025/3/24

Kubernetes の脆弱性報告用の Placeholder Issue

Kubernetes の脆弱性報告のために予約される Issue が一気に 5 つ作成されてた

EDIT (2025/3/25): 全部 Ingress NGINX Controller でした (Ingress-nginx CVE-2025-1974: What You Need to Know)

WIP: Introduce Node Lifecycle WG

WG-Node-Lifecycle が発足しそう。Pod や Node のライフサイクルの改善が目的で、KEP-4212: Declarative Node Maintenance と KEP-4563: EvictionRequest API (旧 Evacuation API) がメインな感じ。新しい API を導入するより既存の API を改善した方がいいと指摘されてたからか、一応 Eviction API と PDB の改善がスコープに入っている。どちらの KEP も関連するコンポーネントが多くて複雑なので、Kubernetes のコア機能として入れるのどうなのかな。既存の API の改善だけでも良いような

Tsubasa NagasawaTsubasa Nagasawa

2025/3/25

Mask Linux thermal interrupt info in /proc and /sys.

詳細はまだ不明だけど消費電力に関連するイベントを利用したサーマルサイドチャネル攻撃を抑制するための対応。コンテナ内に /proc/interrupts と /sys/devices/system/cpu/cpu%d/thermal_throttle (%d=cpu_num) がマウントされないように
moby / CRI-O / podman などは対応済み。それの Kubernetes 側の対応。GHSA-6fw5-f8r9-fgfm (2025/3/25 時点で非公開)

API server reflector may lose events if TransformFromStorage fails

KMS plugin を使って etcd の中のデータ (Secret) を暗号化している場合に稀にデータ欠損が発生するやばいバグの報告。kube-apiserver が HA 構成になっている時に発生しやすく再現手順がある。HA 構成の kube-apiserver から一台を選んで (A) 隣にいる KMS plugin を停止する。別の kube-apiserver (B) を再起動する。B が起動するときに新しい DEK キーが生成される。その状態で B の kube-apiserver に Secret を作成すると新しい DEK キーで暗号化されて保存される。A は KMS plugin が停止しているので新しい DEK キーをキャッシュできていない。その状態で B に接続して既存の Secret を削除する。この一連の動作で、A と B にそれぞれ watch してイベントを見てみると A の方に watch した場合は新しく作成した Secret のイベントが欠落する。kube-apiserver に対する watch が切断される前に kube-apiserver から KMS plugin への gRPC 接続が切断されてしまっているのが原因。なぜかはわかっていないけど、kube-apiserver の —-shutdown-watch-termination-grace-period を 1 秒でも良いから指定すると問題が起きにくくなるらしい。この問題とは別にリソースを watch したときに変換の処理 (e.g. Secret の複合) でエラーが起きたときにイベントが順番に届かないバグが指摘されていてそっちもやばくて修正の PR があげられている

REQUEST: Archive repo kubernetes-sigs/hierarchical-namespaces

kubernetes-sigs/hierarchical-namespaces がメンテナ不足かつ利用者が少ないためアーカイブされるみたい。アクティブなメンテナがいない状況なので譲渡も難しく、利用したい人はフォークして API リソースのドメイン変えて開発続けてもらう

Tsubasa NagasawaTsubasa Nagasawa

2025/3/27

Pod Termination Gate

Pod Termination Gate の KEP の草案。Service や Ingress などで公開している Pod を停止する時に、iptables やクラウドロードバランサーの設定更新の遅延により停止済みの Pod にリクエストが流れてしまう問題の根本解決を目指したもので AWS の方が提案している。現状は Pod に preStop hook (exec or sleep action) を指定して任意の固定時間 sleep するワークアラウンドが一般的に使われているけど、それを置き換えるもの。Pod の LifecycleAction に新しく TerminationGate を追加して、それとは別に spec.terminationGates のフィールドを追加して Condition を指定可能にする。前者はユーザーが指定して、後者はコントローラー (Admission Webhook) で差し込む形を想定。TerminationGate のフィールドは PodReadinessGate (ローリング更新時のスケールインを安全に行うための機能) と仕組みとしては大枠同じ。今の提案だと Pod 作成時にしか terminationGate を差し込んだり、Condition を追加したりできない仕様だけど PodReadinessGate と違って Pod 起動時に必要な訳ではないから後から更新しても良くないと言われている。kubelet は terminationGates に指定された Condition が全て true になるまで Pod の停止処理をブロックする。terminationGracePeriodSeconds が最大で待つ時間。他の LifecycleHook と共存できた方が良いのではとか、Ingress Controller が Pod を watch せずに EndpointSlice の Condition でやる形に変えられないかって話 (Zalando の Skipper だと PodReadinessGate 使っていない？) も上がっていて、KEP になるかは分からないけど、SIG-Network の人を中心に議論は始まっている。

Tsubasa NagasawaTsubasa Nagasawa

2025/3/29

[EKS] [announcement]: Temporary rollback of enforcing upgrade insights on update

EKS のバージョン更新の時に Upgrade Insights に引っ掛かっているクラスタをデフォルトで更新できないようにする機能がリリースされた。ただ、Terraform などのサードパーティのツールで強制的に更新する —force オプションに対応しておらず、クラスタの更新ができないユーザーが出たのでこの機能は一時的に revert されて更新できるようにする予定。—force オプション自体は残るけど、指定しても何も起こらないようにする。十分な数のサードパーティツールで対応したら機能をまた有効にする予定らしい。

Refresh API が今後実装予定で Upgrade Insight のチェックを手動で更新でき、アドオンの互換性を再度確認は可能になる予定。ただ、非推奨 API を呼び出している場合、GKE と同じで過去 30 日の監査ログを見ていてこのチェックはすぐには更新されない。非推奨 API を呼び出している場合は修正してもすぐには更新されないので、強制更新のフラグの指定が必要。Argo CD が Discovery API でクラスタ内で有効な API リソースの一覧を取得して自動で呼び出す場合、その中に非推奨 API があれば更新できないので強制更新のフラグの指定が必要そう。この機能いるのかな？GKE と同じでマイナーバージョンの自動更新だけ止めるで良くない？

Tsubasa NagasawaTsubasa Nagasawa

2025/4/2

Introducing Multi-Cluster Orchestrator: Scale your Kubernetes workloads across regions

https://x.com/everpeace/status/1907358058352685389?s=46&t=3jENizNuk3ODUC2chpnF8Q

  • 2025 年内に OSS 化を予定
  • ユースケースとしてクラウドのリージョンの GPU 枯渇問題への対応が挙げられている
  • ユーザーが API (カスタムリソース？) 経由でどう Pod を配置したいかパラメータを渡して、それを元にどのクラスタにスケジュールするのが最適か決めるだけっぽい
  • Argo CD の ApplicationSet の独自の plugin は既に公開されていて、GKE Hub API からクラスタの情報を動的に取得して、取得したクラスタに対して Application を反映して Pod を起動する形
    • Scope がないと GKE Hub に登録されているメンバークラスタを全て返す実装になっているから、GKE Hub の Scope としてユーザーがどういうクラスタにスケジュールしたいかを指定できるようになる形かな...？
Tsubasa NagasawaTsubasa Nagasawa

2025/4/3

Distibution v3.0.0

やっと distribution/distribution v3.0.0 がリリースされて IRSA 対応の AWS SDK の更新が含まれているので、Harbor で S3 パケットにイメージ保存したり、レプリケーションするときに IRSA が利用できるようになるはず。ただ、メジャーバージョンの更新なので Harbor に組み込まれるのは時間が掛かりそう

Tsubasa NagasawaTsubasa Nagasawa

2025/4/7

kubelet: oom_score_adj for Burstable pods ignores PriorityClass, causing premature kill of critical pods

kubelet がコンテナの oom_score_adj を計算するときに PriorityClass を考慮しない問題。QoS が Burstable な Pod の場合、メモリ要求の大きなコンテナの方がスコアが低く、メモリ要求の小さなコンテナの方が OOMKiller に殺されやすくなる。例えば、system-cluster-critical の PriorityClass の重要な Pod (e.g. konnecticity-agent, CoreDNS, CNI agent) が Burstable な通常のアプリケーションよりも OOMKill されやすくなり、Node の動作に影響が起きてしまう。BestEffort な QoS の場合、oom_score_adj は固定の 1000 で、Guranteed の場合、固定の -997 になる。Burstable のプロセスの計算式に PriorityClass を考慮するようにしようという提案。GKE の中の人の提案ですでに SIG-Node ミーティングの議題にもあげている。実際には PriorityClass が system-node-critical (system-node-cluster より優先度が高い) の場合は、Burstable でも -997 に設定されるようになっている。なので、system-cluster-critical やそれ以外の優先度の Pod の計算式を変えていくことになりそう

Tsubasa NagasawaTsubasa Nagasawa

2025/4/8

KEP-5091: Kubelet Checkpoint

KEP-2008: Forensic Container Checkpointing で kubelet API を呼び出すことでコンテナランタイムが CRIU を実行してコンテナの Checkpoint を取得できるようになったけど、kube-apiserver の API を呼び出して Checkpoint を取得できるようにするための KEP。checkpoint はコンテナ単位でしか取得できず、実態は Node 上に置かれて root 権限がないとアクセスできない部分は変わらない予定。ユースケースに kueue が上がっているのが気になる。Preemption で退避する Pod の checkpoint を取得してリストアすることでジョブを途中から再開できるようになる？

Tsubasa NagasawaTsubasa Nagasawa

2025/4/10

KEP-5233: Node Readiness Gates

KEP の PR はまだなく、詳細は k/k#131208 の議論用の Issue に書かれている。

Node が Ready 状態となるカスタムの条件を追加できるようにする機能を Google の方が提案している。Node を新しく追加したときに重要なコンポーネントの Pod (e.g. CNI や監視エージェント、ランタイムセキュリティ、Node の sysctl などの設定変更の DaemonSet) が先に起動してから通常のワークロードの Pod を起動できるようにしたい。現状は Cilium がやっているように Node を追加するときに NoSchedule の taints を指定しておいて、CNI の DaemonSet はその taints に耐える tolerations を指定、CNI のセットアップが終わったらコントローラーが Node から taints を削除して通常の Pod がスケジュールできるようにするしかない。ただ、このワークアラウンドには問題もあって、Pod の起動時間に影響したり、コントローラーに Node を変更する強い権限を渡す必要があったり、taints を削除するタイミングによってはスケジューラーの Pod 配置の決定と競合が起きてしまう。Node Readiness Gate は Pod Readiness Gate からインスパイアされていて、kubelet がデフォルトでチェックしている Node の Ready 条件だけでなく、kubelet の設定ファイルで指定した nodeReadinessGates に指定した条件 (kubelet が Node の spec.readinessGates に値を伝搬) を Node の正常性の判断に使用する。外部のコントローラーは Node の準備ができたら Conditions を更新して、status を true に変更する。kubelet は Node Readiness Gate で指定された Conditions が全て true になると Node が Ready 状態になって通常の Pod がスケジュールされるようになる。2019 年頃に議論されていた KEP: Node Readiness Gates が復活した形で気になる

Tsubasa NagasawaTsubasa Nagasawa

2025/4/12

SIG Scheduling Leadership updates

さんぽしさん、SIG-Scheduling の TL と Chair 両方に推薦されてる、すごい。Aldo さんが離れるから連れてきた Google のお二方もそれぞれ TL と Chair に順当に推薦されてる。Aldo さんだけじゃなくて、ahg-g さんと Huang-Wei さんも降りるのか。世代交代

Tsubasa NagasawaTsubasa Nagasawa

2025/4/18

External Secrets Operator v0.16.0

External Secrets Operator の (Cluster) ExternalSecrets / SecretStore が v1 API にリリースされた。v1beta1 と v1 で破壊的変更とかはない。External Secrets Operator v1.17.0 で v1beta1 が利用できなくなる予定っぽい

Harbor - Enhance Audit Log

Harbor v2.13.0 で監査ログが改善されてユーザーのログイン・ログアウトも記録されるようになっている。プロポーザルの中に書かれている他の操作はまだ対応してなさそう

Tsubasa NagasawaTsubasa Nagasawa

2025/4/22

allowPrivilegeEscalation の誤解について

allowPrivilegeEscalation: false を指定すると runc などがコンテナの隔離環境を作成 (runc init) する際に no_new_privs オプションが設定され、親プロセス (= コンテナ) が持つ Capability (CAP) を超えて操作が行えなくなる。通常のユーザーで実行されている Pod (e.g. runAsUser を指定) のコンテナイメージに悪意のあるプログラムが含まれていて、setreuid などで root ユーザーに昇格しようとすると元の許可されている CAP を超えて権限が付与されるので Operation not permitted のエラーになる。親プロセスが root ユーザーで実行されている場合は、元々強い CAP を持っているので意味がない。なので、securityContext で privileged: true と allowPrivilegeEscalation: false を同時に指定しようとすると API サーバのバリデーションでエラーになる。securityContext の capabilities でコンテナ (親プロセス) に対して追加で CAP を付与することは可能。ただ、allowPrivilegeEscalation を無効にすると capabilities で危険な権限を付与できなくなると勘違いしているユーザーが多くいる。誤解を招く原因になっているのが、allowPrivilegeEscalation: false かつ capabilities に CAP_SYS_ADMIN を指定することを禁止している API サーバのバリデーション。このバリデーションのせいで、CAP_SYS_ADMIN 以外にも危険な CAP があるのになぜ他の CAP は許可されているのかと誤解を助長する形になっている。そもそも、securityContext の capabilities は CAP_ の prefix を外した形で指定しないとプロセスに正しく CAP が設定されないので、API サーバのバリデーションは意味をなしていない。allowPrivilegeEscalation: false かつ capabilities に SYS_ADMIN は API サーバのバリデーションを通過して、コンテナに CAP_SYS_ADMIN が付与されてしまう。なので、この誤解を生む & 間違っている API サーバのバリデーションを削除しようぜという議論になっている。allowPrivilegeEscalation の名前も悪いから noNewPrivs に改名しようという案も出ているけど、破壊的変更で移行も含めると負担が大きいのでおそらくやらないはず

Tsubasa NagasawaTsubasa Nagasawa

2025/4/23

Exempt UDP traffic if an impacted kernel version is detected.

GKE で Intra Node Visibility を有効 (Autopilot はデフォルト有効) にした場合かつ NodeLocal DNSCache が有効な場合に名前解決が上手くいかない問題が報告されているらしい。Intra Node Visibility は同一 Node 上の Pod 間通信でも VPC フローログやファイアウォールルールの検証が行えるように Node から Google Cloud の Network Fabric にパケットが一旦出てヘアピンで戻る機能。Linux カーネル 6.6.56 で追加された変更のリグレッションっぽく、netfilter に Issue を上げつつ、ワーカアラウンドで Linux 6.6.56 以降で UDP パケットはヘアピンしないようにルーティングのルールを追加している。6.6.56 から 6.6.72 に最近更新したってあるから、 cos-117-18613-164-4 以降で影響がありそう

Tsubasa NagasawaTsubasa Nagasawa

2025/4/24

Kubernetes v1.33: Octarine

Kubernetes 1.33 が予定通りリリース。リリーステーマはオクトライン - 魔法の色で、ディスクワールドシリーズに影響を受けた。神話上の 8 番目の色で秘術に通じた魔法使いや魔女、猫にしか見えないとされる色で、iptables のルールを長時間眺めていた人に見えることも。ディスクワールドシリーズを知っている人はアンシーン大学の塔の上に小さな沼地のドラゴンが座り、アンク・モルポークの街の上空にある Kubernetes の月と、その背景にある 64 個の星を見上げているのを想起するかも。偶然今回の KEP の数も 64 個だったらしい。1.33 も前回のリリースと同様に高い品質を維持でき、Kubernetes が 20 年目に向けて進む中でメンテナの魔法や新しいコントリビュータの好奇心、プロジェクトを推し進める精神を賞賛している。それらを見ていると、ディスクワールドシリーズの作者の言葉「やり方が分かっていてもそれはやはり魔法」を思い出す。Kubernetes のコードベースを隅から隅まで把握していても、リリースサイクルの最後に俯瞰してみると Kubernetes が依然として魔法の力を持っていることに気付くとか。

[HEALTH]: NATS

NATS が CNCF のプロジェクトから外れようとしている。Synadia が NATS の開発にこれまで投資してきていて、ライセンスを変えてマネタイズ化を目指しているみたい。Synadia と NATS は CNCF のガバナンスと合わないから外れたいらしいけど、CNCF としては NATS を残したいよう。Grafana Labs が Cortex をフォークして Mimir が生まれ、Cortex のメンテナの多くが Mimir に移動したときに Cortex のメンテナを呼びかけて上手くいったときと同じようにできないか考えているみたい

UPDATE (2025/4/25): Protecting NATS and the integrity of open source: CNCF’s commitment to the community

Tsubasa NagasawaTsubasa Nagasawa

2025/4/30

Helmfile v1.0.0

1 年くらい 1.0.0-rc がリリースされてきたけど、やっと Helmfile 1.0.0 がリリースされた。破壊的変更がいくつかあるけど、移行方法はどれもある。1.0.0 に上げる前に環境変数で v1 モードで実行できるので、確かめるのが良さそう。

Tsubasa NagasawaTsubasa Nagasawa

2025/5/2

feat: Add argocd-clusterprofile-syncer

GKE の Multi Cluster Orchestrator に ClusterProfile のカスタムリソースから API サーバの接続先の情報などを取得して Argo CD の Secret を同期するコントローラーも追加されてた。Fleet に Member cluster を追加すると Hub cluster にその Member cluster の ClusterProfile が自動的に生成される感じか

Tsubasa NagasawaTsubasa Nagasawa

2025/5/6

Omit null creationTimestamp

Kubernetes 1.34 からオブジェクトの metadata.creationTimestamp が指定されていないときに値がシリアライズされなくなる。JSON タグに新しく onitzero が追加されている。kubectl create --dry-run とかで雛形を作る時や監査ログの中に creationTimestamp=null が明示的に埋め込まれなくなる

Argo CD v3.0.0

Argo CD v3.0.0 がリリースされた。破壊的変更はあるけど、デフォルトの値がよりセキュアだったり、良い感じの挙動に変更されているくらい

Tsubasa NagasawaTsubasa Nagasawa

2025/5/7

Gang Scheduling Support in Kubernetes

Kubernetes 1.34 のリソースサイクルで Pod をグループでスケジュールする Gang-scheduling の機能をコアのスケジューラーに入れるために動くみたい。スケジューラーの実装が固まってから PodGroup の API を決めていく予定。Topology Aware Routing や DRA のユースケース (Node 内や Node 間での Pod のグループでのスケジュール) など新しいワークロード単位の概念を考える必要に迫られているので、慎重に進めた方が良いという意見も

Tsubasa NagasawaTsubasa Nagasawa

2025/5/9

containerd v2.1.0

containerd v2.1.0 がリリースされたので、Forensic container checkpoint と OCI Volume Source が containerd でも利用できるようになる

AWS Load Balancer Controller v2.13.0

AWS Load Balancer Controller でも Gateway API のサポート (L4 / L7 両方) が入る予定なのか。v2.13.0 で一部の機能が実装されている。Ingress の annotation で指定できた設定は LoadBalancerConfiguration のカスタムリソースで設定して Gateway or GatewayClass に紐付ける感じか

Tsubasa NagasawaTsubasa Nagasawa

2025/5/11

KEP-5278: Use NominatedNodeName to express the expected pod placement

Cluster Autoscaler が Pod を配置する Node をスケールアウトして、kube-scheduler も Pod をその Node に配置するよう予約して Binding Cycle に遷移したが、Pod が PVC や DRA を利用していて PreBind 拡張点の処理 (PV や DRA のデバイスのプロビジョニング) に時間が掛かる場合、Cluster Autoscaler が新しく作った Node が未使用であることに気付いてスケールインしてしまう問題を解決するための KEP。Cluster Autoscaler は kube-scheduler の Scheduling Framework の一部を利用して、kube-scheduler が Pod を新しく追加した Node に配置することを事前にシミュレーションしている。Pending 状態な Pod のために自分でスケールアウトして作った Node を後でスケールインしてしまうのは変な感じだけど、Cluster Autoscaler の設計として kube-scheduler がスケジュールできない Pod しかシミュレーションの対象としていないので、PreBind 拡張点まで進んでいる予約済みの Pod (In-flight Pod) はシミュレーションで考慮されない。現状、kube-scheduler は PreBind 拡張点の Pod の情報を kube-apiserver 経由で外部に公開していない (= Pod の status などで情報を公開していない) ので、Cluster Autoscaler / Karpenter や外部のコンポーネントは Pod が PreBind フェーズで stuck していることを知る余地がない。Pod の .spec.nodeName に配置される Node 名が指定されるのも PreBind 拡張点の後の Bind 拡張点なので、情報は埋め込まれていない。それに、Cluster Autoscaler が内部のシミュレーションで新しく作った Node に配置されることを確認済みなのに、インスタンスがプロビジョニングされて、kube-apiserver に Node が登録されて、kube-scheduler が新しく Node が追加されたことを知って、再度 Scheduling Cycle を回すのは重複で処理していて非効率。なので、kube-scheduler や外部のコンポーネントが Pod の既存の .status.nominatedNodeName を更新することで、お互いに協調できるようにする予定。nominatedNodeName は kube-scheduler が Node 上の Pod を Preemtion して配置できるようになった時に、Pending 状態の Pod が他の優先度の低い Pod を追い出した Node にスケジュールされるように Scheduling Cycle をバイパスするために使用されてきたフィールドで、このフォールドを利用するユースケースを拡張する。これにより Binding Cycle の中の PreBind 拡張点で nominatedNodeName を更新し、Bind 拡張点で Pod の nodeName を更新することになるので、kube-apiserver への API 呼び出すが 2 回に増えてしまうことが懸念されているが、nominatedNodeName を更新する Pod を PVC / DRA などの PreBind 拡張点で時間が掛かる Pod に制限するなどして軽減する予定。外部のコンポーネントは Pod が Scheduling Cycle に入る前に nominatedNodeName を更新しないと Scheduling Cycle に入ってしまうとその時点の情報で Pod のスケジュールを判断するため、後付けの nominatedNodeName が考慮されなくなるが、nominatedNodeName 自体がハード要件ではなく、必ずその Node に配置されることを保証するものではないのでタイミング問題は許容する感じ。Cluster Autoscaler が nominatedNodeName を指定する時点では、Node はまだプロビジョニングされておらず、kube-scheduler は Node の存在を認識できない。存在しない Node が nominatedNodeName に指定されている場合に、kube-scheduler が nominatedNodeName を消さないようにする必要がある。Cluster Autoscaler が Node をスケールアウトして Node がクラスタに参加した直後は Node に not-ready の Taints が指定されているので、kube-scheduler は Pod をその Node に配置できず、nominatedNodeName を削除する可能性があるのでその辺も考慮しないといけないらしく、kube-scheduler が nominatedNodeName を削除しない実装にする予定っぽい。kube-scheduler が Preemption を実行して新しい Node に配置する必要がなくなった場合は、nominatedNodeName を更新しても誰も困らないので、更新は許容する。
そもそも、PreBind 拡張点で時間が掛かっていて CA で問題が起きている (GKE で観測しているらしい) のは、既存の PVC をデータソースとして参照して PVC をレプリケーションする (ReadOnlyMany をサポートしていない CSI driver でも Job で共通のデータを参照したい？) ケースや Volume Populator の仕組みでオブジェクトストレージなどからデータを PV に動的に書き込む仕組みを利用している感じかな。PreBind 拡張点で PVC から CSI の external-provisioner によって PV が作成されるまで待つのでソースのデータ容量が大きいと PV のプロビジョニングに時間が掛かる (数分) ことがあるらしい

Tsubasa NagasawaTsubasa Nagasawa

2025/5/13

VPA: Implement in-place updates support

VPA に FeatureGate で守られた形で InPlaceOrRecreate のモードが追加された。Kubernetes 1.33 以降の In-Place Pod Vertical Scaling をサポートしていて、それ以外だと動かないはず。/resize のサブリソースを通してコンテナのリソース割り当てを動的に変更して、In-Place Update の完了までに 1 時間以上掛かっている場合や、現状変更が不可能で 5 分以上待っている場合、更新が不可能な場合、In-Place 中にエラーが発生した場合は Evict する通常モードにフォールバックする。期間は後から起動オプションで変更できるようになる予定だけど、今はハードコード。なので、再起動なしで必ずリソース割り当てを変更できる保証はない。--in-recommendation-bounds-eviction-lifetime-threshold がデフォルトで 12 時間に設定されているので、12 時間以上起動していてその間に更新されていない Pod が対象

Tsubasa NagasawaTsubasa Nagasawa

2025/5/15

Use Linux CFS burst to get rid of unnecessary CPU throttling

Linux の CFS Burst には Burst の上限が Quota 未満という制約があるらしく、将来 Kubernetes でサポートされてもワークロードによっては微妙かもという指摘。Kubernetes だと CFS period がデフォルトで 100ms で、CPU のリソース上限を 50ms に指定すると 100 * (50/1000) = 5ms が Quota になるので、Burst は 5ms が上限になる。CPU 上限が 500ms なら、100 * (500/1000) = 50 ms となる。CFS period をデフォルト値から小さくしていると更に CFS period 毎に Burst で使える CPU 時間が減り、スロットリングが発生しやすくなるらしい。平均 5ms でほぼ sleep しているようなアプリケーションでリソース上限を 10ms とかにしても、Burst は 1ms が上限だから結局スロットリングが起きるかもと

Tsubasa NagasawaTsubasa Nagasawa

2025/5/16

Multi Cluster Orchestrator 0.1.0 - Overview

Multi-Cluster Orchestrator (MCO) 0.1.0 がリリースされていた。自動スケールの機能は Deployment と HPA に強く依存しているけど、自動スケールの機能が不要な JobSet でも使えなくはないのかな。MultiKubernetesClusterPlacement を通してスケジュールしたいクラスタの優先順位を指定 (ユーザーが指定したクラスタ名のリストの先頭から試行) することはできる。ワークロードを最大いくつのクラスタで動かしたいかも制限は可能。Argo CD の ApplicationSet で同期する対象のクラスタを動的に増減させているだけで、Deployment とか HPA を動的に書き換えたりはしない。スケールアウトに関しては HPA の上限に達した時の ScalingLimited 状態を検知 (Cloud Monitoring に書き込まれた kube-state-metrics の condition のメトリクスを使ってそう) で更に Pod が必要な場合に他のクラスタでワークロードを起動する。現状はスケールインに制約があって、HPA が minReplicas よりも Pod をスケールインしたい場合にしか発動しない (=ほぼ発生しない) けど、改善予定。draining plugin を実装予定で多分この中に入ってくるのかな。
GPU 枯渇したかは事前に Cloud Monitoring のログベース指標で Cluster Autoscaler のFailedScaleUp の発生をメトリクスに変換しておいて、MCO が Cloud Monitoring のメトリクスを参照して検知する形か...。ClusterProfile の status に capacity の情報とかが入って、賢くスケジューリングしてくれることを期待してたけど、泥臭いな。現状はクエリが Multi-Cluster Orchestrator の実装でハードコードされているので、指定された名前で作る必要があるけど、いずれユーザーが指定したクエリを利用はできるようになるらしい。Cloud Monitoring に依存した形で OSS 化するのかな？

Tsubasa NagasawaTsubasa Nagasawa

2025/5/17

kind v0.28.0

kind v0.28.0 で提供される Node のイメージの containerd が 2.1.0 に更新されたので、OCI Volume Source や Forensic Container Checkpoint をイメージカスタマイズせずに試せるようになった

Tsubasa NagasawaTsubasa Nagasawa

2025/5/18

[KEP-3521]: Integrate well with out-of-tree resource quota solutions

ResourceQuota の制限を超えてリソースを要求する Pod を作成するとその時点でエラーになるので、ジョブ基盤と相性が悪い。Kueue や KubeVirt の application-aware-quota は独自の Quota の仕組みを持っていて、Pod Scheduling Readiness で後から余裕ができたら Pod がスケジュールを開始するように遅延している。ただ、InPlacePodUpdate の機能が入ったことで、実行中の Pod が再スケジュールされることなく追加のリソースを獲得できるようになった。in-tree の ResourceQuota と resize の連携 (ResourceQuota を超えたリソースを resize で要求するとエラーになる) は既に入っているが、独自に実装した Quota でも resize がエラーにならずに遅延できる仕組みが必要じゃないかという要望。resizeGate を新しく追加するか readinessGate を再利用するか (readinessGate は Admission Control で追加後は削除しかできないからそこを変える必要がある) が提案されているけど、微妙な感じするしどうするんだろう

Tsubasa NagasawaTsubasa Nagasawa

2025/5/20

feature(scheduler): Customizable pod selection and ordering in DefaultPreemption plugin

kube-scheduler をカスタマイズしてセルフビルドしている場合に DefaultPreemption の挙動を弄れる変更が Kubernetes 1.34 に入った。Preemption 対象の Pod を追加で (Priority の比較 +α で) フィルタリングするための関数と Preemption 対象の Pod を重要な順番 (= Preemption の対象になりにくい順) でソートするための関数をカスタマイズ可能になる。デフォルトのソート順は Priority が高い順に並ぶようにして、同じ Priority の場合は起動時間が長い順に並ぶ。なので、Priority が低くて起動時間が短い順番に Preemption が実行される。ユースケースとしては複数の PriorityClass があるけど、その中でも Preemption を許容するのは一部の PriorityClass に制限したいらしい

Tsubasa NagasawaTsubasa Nagasawa

2025/5/21

Add kube-api-linter verify scripts

昨日の Kubernetes Meetup Tokyo でも話が出ていた kube-api-lint (KAL) が k/k 本体に導入された。API の設計のベストプラクティスをルール化して golang-ci-lint の一部として実行し、API レビューの負荷を下げるのが目的。ルールはこの PR では有効化されていなくて、後から徐々に有効化されていく。最初は構造体のフィールドに +optional か +required のマークを付けることを強制するルールと +required でマークされたフィールドに omitempty の JSON タグが付いていないことを矯正するルールが有効化される予定

[containerd] CVE-2025-47290: Host filesystem access during image unpack

containerd 2.1.0 で TOCTOU (Time-of-check to time-of-use) の競合による Critical な脆弱性が見つかったみたいで、2.1.1 で修正されてた。イメージプルでファイルシステム上にイメージを展開するときに、悪意のあるイメージを利用するとホスト上のファイルシステムを書き換えることができてしまうらしい。

Tsubasa NagasawaTsubasa Nagasawa

2025/5/24

podAffinity to non-running pods

GKE の中の人が memory backed emptyDir (tmpfs を使ってインメモリに揮発してよいデータを書き込む) に FUSE ファイルシステムをマウントしようとしている。詳細は不明。Pod 停止時に FUSE ファイルシステムをアンマウントしないと、kubelet が emptyDir ボリュームを削除できず、Pod が終了状態のままスタックする。これを避けるために PodAffinity を使ってスタックした Pod と同じ Node に Job をスケジュールして、FUSE ファイルシステムをお掃除しようとしたけど、PodAffinity は実行中の Pod しか考慮しないから上手くスケジュールされなかったので何とかならないかという要望。
PodAffinity は置いておいて tmpfs で FUSE ファイルシステムをマウントの詳細が気になる。mergefs (FUSE ベースで複数のディレクトリを束ねる) で tmpfs の上限を超えたら通常のファイルシステムにフォールバックする的なことをやろうとしているのかな

Tsubasa NagasawaTsubasa Nagasawa

2025/5/27

KEP-5343: Updates to kube-proxy backend

Kubernetes 1.33 で kube-proxy の nftables モードが GA したので、kube-proxy のバックエンド (モード) を整理する KEP。現在 kube-proxy のモードは iptables、ipvs、nftables、winkernel (Windows Node 用) の 4 つある。SIG-Network のメンテナンスコストを下げるために、ipvs と winkernel モードを非推奨にして、バイナリを分けたり、k/k から外に出してコミュニティ管理に移譲するなど、方向性を決める。iptables モードのサポートはしばらく続ける予定だが、ipvs モードは早めにサポートを切りたい。ipvs モードの利点であるスケジューリング機能も Service 単位での切り替えはモジュールのロードなど複雑化を避けるために実現しなかったし、各 Node の kube-proxy が振り分けの情報を共有している訳ではないので、全体として動作しているかは微妙。winkernel はそもそも SIG-Network のメンバーは誰も詳細を知らず、Microsoft の人しか見ていない。nftables モードを推したいが、Linux Kernel 5.13 以上が推奨バージョンで比較的新しいので、もう少し待つ必要がある。kube-proxy のデフォルトのモードに関しては、Linux Kernel の推奨バージョンが十分に浸透した後に nftables モードをデフォルトにするか、警告ログや Event を使いつつモードを明示的に指定するよう徐々に矯正するかを今後決めていく。

Tsubasa NagasawaTsubasa Nagasawa

2025/5/28

feat: graduate QueueingHint to GA

各 scheduler plugin でイベントによるフィルターを実装することでスケジュールの再試行を効率的に行える KEP-4247: QueueingHint が Kubernetes 1.34 で GA しました。ベータ昇格後は特に大きな変更はなく、予定通り 1.34 で GA した形

Tsubasa NagasawaTsubasa Nagasawa

2025/5/29

KEP-5309: Pod self-orchestration

並列処理のジョブで sidecar コンテナがタスクを管理して、regular コンテナがタスクを処理するワーカーの役割になることがある。sidecar コンテナが regular コンテナを停止しようと思うと、API サーバにリクエストを投げるか、CRI API を呼び出す必要がある。sidecar コンテナがワーカーからシグナルを受け取って regular コンテナを停止したり、再起動できると便利らしく新しく仕組みを追加する KEP。重いジョブでワーカーの一部に問題が起きた時とかに Pod 全体を再起動するより Pod 内のコンテナを再起動してチェックポイントからやり直せた方が効率が良いという感じ。Pod の containers に新しく podManagement のフィールドを追加して、指定したポート番号で kubelet と streaming で接続できる gRPC エンドポイントを公開する。podManagement を指定したコンテナからそのポートに接続することで kubelet とやり取りでき、コンテナを停止するコマンドを実行したり、コンテナの状態遷移のイベントを取得できたりする。コンテナと kubelet の間のやり取りは gRPC で定義され、バージョン化されている。podManagement のフィールドではポート番号と gRPC プロトコルのバージョンを指定する。KEP の概要にはコンテナの停止や再起動以外にコンテナを動的に作成する話も出てくるが、詳細には書かれていないので範囲外？リスクとして書かれているセキュリティ的な懸念もあるし、コンテナを停止・再起動するだけなら RPC で直接やり取りしたり、PID namespace の共有使ったり他の方法があるはずだからこんな複雑な仕組み不要な気が。
この KEP が必要な理由はこれなんだろうけど、どうなんだろう

Tsubasa NagasawaTsubasa Nagasawa

2025/6/1

KubeCon Japan Day 1 の個人的に気になるセッションと初学者向けのセッション

  • A Journey and Lessons Learned To Enable IBM AIU Accelerators in Kubernetes - Takuya Mishina & Tatsuhiro Chiba, IBM Research
    • IBM Research が提供している IBM AIU チップを利用した基盤の内部構成や学んだことを共有するセッション。AIU チップ向けの device plugin やカスタムスケジューラー、メトリクスを公開するための exporter 、Admission Webhook ベースのバリデーションを開発して一般的なユーザーやクラスタ管理者、ドライバ開発者向けの基盤を提供している。カスタムスケジューラーは RDMA のトポロジを考慮した Pod の配置が可能で高速なネットワークを利用可能で、カスタムリソースを設計してコンポーネント間でリソースの払い出しを協調可能にしている。デバッグ用の機能も提供していて、実際のデバイスを払い出さずに仮想的なデバイスを利用するモードがあってドライバの開発者とかが使っている感じか。幅広トークっぽいので概要レベルかもしれないけど気になる
  • Beyond Stock Outs: Scaling Inference on Mixed GPU Hardware With DRA - John Belamaric & Bo Fu, Google
    • 最近だと WG-Device-Managment の Chair で Dynamic Resource Allocation (DRA) 周りの設計に深く関わっている John Belamaric さんの発表。特定の GPU を使うというよりも、20 GB の RAM が使えて今利用可能な GPU の中で一番良いやつが使いたいみたいな柔軟なデバイスの選択が実現できる 1.33 でベータ昇格した DRA の話。ハードウェア毎に必要なデバイスの数が異なっても DRA だと実現が可能。1.33 でアルファ機能として入った KEP-4816: DRA Prioritized Alternatives の話や Cluster Autoscaler 連携の話も紹介される？後半は GKE の PM の方が GKE 固有の機能 (e.g. Custom Compute Class) の話とかをする感じかな。
  • Safeguarding Your Applications - Achieving Zero Downtime During Kubernetes Upgrades - Kazuki Uchima & Kakeru Ishii, Google Cloud
    • Google Cloud の内間さんたちによる Kubernetes 更新の基本的な話とダウンタイムなしで更新するための実用的なお話。Kubernetes 更新の影響を理解する上で各コアコンポーネントの役割を知っておかないといけないのでそこから。不要なダウンタイムが発生しないようにするための推奨設定の話も。Kubernetes 初学者にも優しそう
  • New Cache Hierarchy for Container Images and OCI Artifact in Kubernetes Clusters Using Containerd - Toru Komatsu & Hidehito Yabuuchi, Preferred Networks, Inc.
    • Pod の起動時間に大きく影響するコンテナイメージや OCI Artifact のプル時間の改善や巨大なイメージのプルが何度も発生するのを防ぐためにキャッシュシステムを開発した PFN さんのお話。一度プルされたイメージはその Pod が起動した Node だけでなく、クラスタ全体でキャッシュされて利用可能になる。ユーザー側で変更を加えることなく、Ninja が高速なプルを実現できるように最適化する。プッシュしたイメージをクラスタ全体でキャッシュすることでその後で発生するプルを高速化する。キャッシュのヒット率は約 95% で Pod の起動時間やレジストリとのネットワークのやり取りをかなり削減している。イメージのキャッシュや CRI を活用してどう実現しているか学べるセッション。
  • Lightning Talk: Embracing Culture and Breaking Language Barriers: A Story of Fostering Global Opensource Communities - Sreeram Venkitesh, DigitalOcean
    • Kubernetes のリリースチームを経験していたり、最近だと KEP-4818: Allow zero value for Sleep Action of PreStop Hook や KEP-4960: Container Stop Signal の実装を進めていた Sreeram Venkitesh さんによる言語の壁や文化、タイムゾーンの違いを超えてコミュニティに貢献してきた経験を共有する LT。セッションで伝えたいことを体現するためにわざわざ日本語を勉強して日本語で登壇するらしい。OSS への貢献を考えている人には良さそう。
  • No More Disruption: PlayStation Network’s Approaches To Avoid Outages on Kubernetes Platform - Tomoyuki Ehira & Shuhei Nagata, Sony Interactive Entertainment
    • PlayStation Network の Kubernetes 基盤の安定性を改善した話。複数リージョンに展開された 50+ クラスタで大量のトラフィックを捌いていて、FY2024 は 99.995% のサービス稼働を実現したらしい。アプリケーションのデプロイ戦略や大規模なスケールの方法、自動化、リージョンを跨いだ 24/7 の運用体制などの話があるらしい。大規模な Platform Engineering に興味ある人には良さそう
  • Lightning Talk: Enhanced Service Redirection: eBPF Ensures the High Availability of Node-Local DNS - Weizhou Lan, Daocloud
    • NodeLocal DNSCache の HA 化を eBPF ベースで実現した話。大規模なクラスタだと Node 単位や Pod 単位で CoreDNS のキャッシュを持つことで名前解決が安定的に行えるようにするのが一般的。ただ、NodeLocal DNSCache は DaemonSet として動作して 1 台しか起動できないので、変に死んで向き先を強制的に変えている iptables のルールがお掃除されないと影響を受けてしまう。SO_REUSEPORT を使って複数の NodeLocal DNSCache を起動する話は聞いたことあるけど、eBPF で NodeLocal DNSCache が生きているかを見つつ、動的に NodeLocal DNSCache <-> CoreDNS でルートを切り替えるようにしたらしい。どの CNI でも使えるし、kube-proxy とも互換性があるので安全に使える。
  • Lightning Talk: Providing Sufficient PVCs for Your StatefulSets: Creating New Volumes Larger Than the PVCTemplate - Kaoru Esashika, Cybozu, Inc.
    • Cybozu さんの PVC のリサイズを良い感じに行ってくれる pvc-autoresizer の話。PV のサイズをリサイズしているのに PVC のテンプレートは元の値のままになっているせいで、ボリュームのリストアやクローンに失敗する問題を解決できる。Mutating Admission Webhook と annotation を使って、同一のグループの他の PV のサイズの中から最も大きい値に PVC を書き換える感じっぽい。
  • The Grand Adventure of Production Apps: Build, Break, and Survive! ~ A Kawaii Manga Journey Through - Aoi Takahashi, Independent
    • 「つくって、壊して、直して学ぶ Kubernetes入門」の作者の方のセッション。漫画形式で本番アプリケーションで起きうる障害やトラブルシューティングの方法を紹介してくれる。初学者にも優しそう
  • Exploring Tenant-centric Strategies To Simplify Multi-cluster and Multi-cloud Complexities - Wei Huang & Fan Yang, Apple
    • 前 SIG-Scheduling の Chair の Wei Huang さんたちによる Apple の内部プラットフォームのお話。Platform Engineering の課題から入って、各ペルソナを考慮したインフラコードに対する新しいアプローチを紹介してくれるらしい。ユーザー体験を重視したテナント中心の API を設計して、ユーザーの入力の最小化や学習コストの削減、クラウドプロバイダーなど裏側を抽象化する。コード生成や Kubernetes のラベルのような仕組みを使って、テナントのリソース要求を管理している。Pkl (Apple が開発している設定言語) を使ったテンプレート化や Prow (Kubernetes で利用している CI/CD で GitHub と連携してコメントベースでジョブを実行したりマージしたりが可能) を使った GitHub のイベント駆動での自動化 、Crossplane と Argo CD を使ってテナントのリソースを管理している。
  • 2-Node Kubernetes: A Reliable and Compatible Solution - Xin Zhang & Guang Hu, Microsoft
    • etcd が利用している Raft アルゴリズムの制約で通常 Kubernetes のコントロールプレーンは 3 台構成以上になるが、2 Node でコントロールプレーンの HA 構成が可能だと 30% 程度のコスト削減 (数千クラスタあると凄い規模) になって良くない？ってお話。etcd の Raft アルゴリズムを発展させて、2 Node で Node 障害やネットワーク障害に耐えうる HA 構成を実現する。2 Node の HA クラスタは kubeadm や Cluster API (CAPI) などの一般的なツールを使って構築が可能。セッションではどう実現しているかとデモもあるみたい。
  • Addons Need Love Too: Maintaining Addons for Better Cluster Security - Stevie Caldwell & Andy Suderman, Fairwinds
    • Kubernetes クラスタ内に導入したアドオンのバージョンの追従は時間が掛かるし、面倒。ただ、アドオンを最新化することでクラスタの安定性を向上したり、セキュリティリスクを減らすことが可能。アドオンを出来るだけ少ない負担で更新するためのツールや戦略を紹介するセッション。ツールの詳細は概要に書かれていないので、ガッカリなセッションになるかもだけど少し気になる。初学者にも優しそう
Tsubasa NagasawaTsubasa Nagasawa

2025/6/2

KubeCon Japan Day 2 の個人的に気になるセッションと初学者向けのセッション

  • Multi Cluster Magics With Argo CD and Cluster Inventory or Don't Get Lost in the Clusterverse: Navig - Kaslin Fields, Google
    • SIG-Multicluster の ClusterProfile API とおそらく GKE が最近発表した Multi Cluster Orchestrator の話。SIG-Multicluster の方ではないので、詳細な話とか今後の話はなさそうだけど、デモはあるみたいなので気になる。GKE 以外のプロバイダーの話もあるのかも。
  • Project Lightning Talk: How Kubernetes Observes Containers: The Role of Container Runtime and cAdvisor in Metrics Collection - Ayato Tokubi, Maintainer
    • Red Hat で CRI-O のメンテナで Kubernetes にもコントリビューションされている bitoku さんのセッションでコンテナのメトリクスをコンテナランタイムや cAdvisor がどう収集しているかのお話。最近動きがないけど、KEP-2371: cAdvisor-less, CRI-full Container and Pod Stats の話もする感じかな。
  • Cloud Native Scalability for Internal Developer Platforms - Hiroshi Hayakawa, LY Corporation
    • LY の Internal Developer Platform (IDP) としての Kubernetes 基盤の話。Kubernetes はワークロード実行環境であって、プラットフォームの構成要素としては設計されていない。IDP を作る人は Kubernetes の上に Cloud Native な技術や独自のカスタマイズを施す必要があるが、それらがスケーラビリティのボトルネックとなりうる。LY では 140k Pod が動作する Kubernetes ベースのマルチテナントな IDP があり、オブザーバビリティのパイプラインやアクセス制御などでスケラービリティの問題に直面した。その辺りの事例などを紹介してくれるセッション。
  • BGP Peering Patterns for Kubernetes Networking at Preferred Networks - Sho Shimizu, Preferred Networks, Inc. & Yutaro Hayakawa, Isovalent at Cisco
    • PFN の清水さんと Cisco (Isovalent) で Cilium の開発をされている早川さんの Kubernetes クラスタとそれ以外の部分の BGP による繋ぎ込みの話。大規模環境やオンプレ環境だと Kubernetes のネットワークで BGP が使われることが多く、運用負荷を抑えつつ BGP のピアリングを実現する方法を紹介。Kubernetes のネットワーク関連のコンポーネントに BGP のスピーカーのサイドカーを差し込むパターンやトンネリング不要な IP CLOS ネットワークでのネイティブなルーティングなど。
  • What's New in Open Source Kubernetes? - Kaslin Fields, Google
    • SIG-ContribEx の Kaslin Fields さんによる最近 Kubernetes に入った機能の紹介セッション。AI ワークロード向けの新機能、最近 GA した Sidecar containers、In-tree の Storage Provider やベンダー固有の Cloud Controller Manager のコードを k/k から削除した話、Pod Security Policy (PSP) の削除と Pod Security Admission (PSA) への移行の話、k8s.gcr.io から registry.k8s.io に移行した話など。少し古い話が多いけど、Kubernetes が最近どういうことに注力しているか把握するために初学者には良さそう
  • Reimagining Cloud Native Networks: The Critical Role of DRA - Lionel Jouin, Ericsson Software Technology & Sunyanan Choochotkaew, IBM Research
    • Dynamic Resource Allocation (DRA) で NIC の払い出しや Pod に複数 NIC を刺す部分をやろうとしている話。AI / ML なテレコムの複雑な要件を実現するには既存の Device plugin や Multus だと限界がある。クラウドネイティブのネットワーク界隈の現状と、Kubernetes を拡張する方法とアドオンを活用する方法のメリットとデメリットを紹介する。DRA に最近入ったネットワーク関連の機能である KEP-4817: Resource Claim Status With Possible Standardized Network Interface Data の話と 1.34 で入れようとしている KEP-5075: DRA: Consumable Capacity の話をするみたい。絶賛議論 / PoC 中の CNI-DRA-driver の将来的な話も。Lionel Jouin は KEP-4817 の実装を担当していた方。
  • The Future of Prometheus Exposition Format - Arthur Sens, Grafana Labs
    • Prometheus 形式のメトリクスの標準化として進められていた OpenMetrics が CNCF の別のプロジェクトとして切り出され、仕様自体は成熟していたが、仕様に準拠したツールが出て来ずに進捗がない時間が続いた。紆余曲折あり、OpenMetrics がまた Prometheus の配下に戻ってきたらしく、OpenMetrics 2.0 として生まれ変わるらしい。Prometheus や OpenTelemetry が OpenMetrics 1.0 に準拠するのが難しかった理由や 2.0 でどう改善する予定なのかを紹介するセッション。OpenMetrics 2.0 でメトリクス形式が変わることで得られるメモリ使用量の低減のメリットについても話があるらしい。
  • Dynamic Provisioning and Capacity-Aware Scheduling for Local Storage - Yuma Ogami, Cybozu, Inc.
    • Cybozu さんが開発している高速なローカルストレージを利用できるようにする TopoLVM CSI plugin の話。現状は Scheduler Extender を実装してローカルディスクの使用量を考慮して Pod をスケジュール可能にしているが、Kubernetes 1.33 でアルファ機能として入った KEP-4049: Storage Capacity Scoring of Nodes for Dynamic Provisioning により kube-scheduler の VolumeBinding plugin のスコアの部分でローカルディスクの容量を考慮するようになる。こちらも実装者によるセッションなので内容は濃いはず。
  • Your SBOM Is Lying To You – Let’s Make It Honest - Justin Cappos & Yuchen Zhang, New York University
    • SBOM はサプライチェーンセキュリティを改善する上で重要だけど、内容が誤っていることがある。その理由やそれを攻撃者がどう悪用するか、不正確な内容をどう改善するかのお話。特に依存関係管理ファイルの解析が課題で、コンポーネントを正確に追いかけることが難しい場合がある。OpenSSF のサンドボックスプロジェクトの SBOMit は in-toto attestation 仕様を利用して暗号的に検証可能な SBOM を生成する。SBOMit はサプライチェーンの各ステップをその都度記録することで、正確性を高めて、改ざんリスクを軽減するらしくその話をするらしい。SBOMit 自体が進捗なさそうなプロジェクトなのでどうなんだろう
Tsubasa NagasawaTsubasa Nagasawa

2025/6/3

NoExecute taint should be added when a Node's ready condition becomes Unknown

kubelet が Node のステータスをデフォルト 10 秒間隔 (kubelet の nodeStatusUpdateFrequency) で更新していて、kube-controller-manager の中の node-lifecycle-controller が Node のステータスをデフォルト 5 秒間隔 (kube-controller-manager の --node-monitor-period) で監視して、デフォルト 50 秒間 (kube-controller-manager の --node-monitor-grace-period) 更新がなければ Node に問題が発生したとして、Node のステータスを Unknown に変更して Node に node.kubernetes.io/unreachable:NoExecute taint を付与する。taints が付与されると node-lifecycle-controller が Node 上の全ての Pod を NotReady 状態に変える。ただ、この 50 秒経過してから taints が付与されるまでに 5 秒の遅延が起きていた問題の修正。5 秒の遅延が起きていたのは Node の現在の condition (= Unknown) ではなく、最後に観測された condition (=Ready) を見て taints を付与するか判断していたのが原因。要するにデフォルト 5 秒間隔で Node の condition をチェックしているので、1 サイクル必ず遅延が発生していた形

Tsubasa NagasawaTsubasa Nagasawa

2025/6/4

Node memory usage on cgroupv2 reported higher than cgroupv1

kubectl top nodes などで cgroup v2 の Node のメモリ使用量が cgroup v1 よりも高く表示される問題は周り回って Kubernetes 1.33.0 で修正されたらしい。cgroup v2 だと root cgroup の memory.current が存在しないので、メモリ使用量を /proc/memonfo の total - free で計算していたけど、cgroup v1 の値と乖離していた。cgroup v1 の値に近づけるために、memory.stat から anonymous pages と file-backed の合計に変更された。その変更が runc 1.2.0 に取り込まれ、cAdvisor の runc の依存が v0.52.0 で更新され、Kubernetes 1.33.0 で cAdvisor v0.52.1 に更新されたので取り込まれた形

KEP-1287: Allow memory limit decreases

Kubernetes 1.33 時点だと KEP-1287: In-place Pod Vertical Scaling でメモリ上限を減らせないようになっているけど、 1.34 でメモリ上限もベストエフォートで変えられるようにする予定。メモリ上限を下げる前に cAdvisor or CRI からコンテナのメモリ使用量を読み取って、減らしたメモリ上限の値よりも小さければ resize を試みる。ただ、TOCTOU の問題があるので resize 時にメモリ使用量が超過することで OOMKill が発生する可能性がある。現在のメモリ使用量よりメモリ上限の値が小さい場合は、PodResizeInProgress の Pod conditions で Error の reason として現在のメモリ使用量とメモリ上限の値も併せてユーザーに通知する。

Tsubasa NagasawaTsubasa Nagasawa

2025/6/6

Add probe triggered log and shift the periodics timer after manual run

Pod の起動時間を早くするために readinessProbe は指定した間隔以外でも実行されることがあって、readinessProbe が成功していない状態かつ Pod のステータスが started に遷移した後に実行 (手動実行と呼ばれている) される。Kubernetes 1.32 より前は手動実行のあとで定期実行の ticker がリセットされていなかったので、連続で readinessProbe が実行されることがあった。1.32 で手動実行のあとに ticker がリセットされるようになったので、次の readinessProbe の実行は periodSeconds 待ってからになった。そのせいで、Pod の起動時間は実質長くなるので、OpenShift で Pod の起動時間の p99 が悪化したよという報告。挙動としては正しいから仕方ないけど、影響受けた人が他にいるかもなので報告したみたい

Tsubasa NagasawaTsubasa Nagasawa

2025/6/7

Mountpoint for Amazon S3 CSI Driver v2

Mountpoint for Amazon S3 CSI driver v2 のベータ版がリリースされた。以前はホスト上の systemd で FUSE のプロセスを管理していて、リソース割り当てが困難だったけど、Pod 内のコンテナとして動作するように変更されたので、割り当てが可能になった。データのキャッシュを emptyDir や ephemeral volume に書き込めるようになり、保存先のディレクトリも自動で生成されるようになったので使いやすくなっている。以前はノードのルートボリュームに書き込んでいて事前にディレクトリを切る必要があった。

Tsubasa NagasawaTsubasa Nagasawa

2025/6/10

Make native scheduling workload-aware

Kubernetes は現状 Pod 中心でスケジューリングしているけど、Workload-aware scheduling の可能性を議論するために問題を整理しようという Issue。Pod 単位でスケジュールする制約から、Gang-scheduling をネイティブにサポートしていない。また、ネットワークやリソースのトポロジを考慮したスケジューリングもユーザーやクラスタ管理者が必要なメタデータ (e.g. ラベル、taints) をノードに付与することで適切にスケジュールさせるように仕向ける必要がある。Dynamic Resource Allocation (DRA) が入ってきたことで現状のスケジューラーのアルゴリズムだと適切なワークロードの配置が非効率だったり、難しくなってきている。Eviction や Preemption のような再スケジューリングも Pod 単位で行っており、ワークロード全体にどう影響するかまで考慮できていない。Node 上のリソースを払い出して Pod を配置するスケジューリングは複雑で時間の掛かる処理だし、複数のスケジューラーを実行すると競合が起きてしまう。リソースのプールの中から事前に予約するような仕組みも難しい。Node の自動スケールが絡んでくると更に大変。Workload-aware scheduling を実現しようとすると Kubernetes のコアな部分をいくつか変更する必要があってユーザー影響もあるし、そもそも方向性の合意を取るのも難しい。まずはワークロードの定義から。ワークロードは「論理的なリソースのまとまりで、ライフサイクルを通して一貫して利用を保証するもの」。複数の Pod をリソースの集合として扱い、スケジューリングや再スケジューリング、再配置を決定する。ワークロードのスケジューリングは実際に Pod が作成される前にリソースを確保する方法になるかもしれないという示唆。すぐにどうこうはないだろうけど、現状のスケジューラーの設計の限界が顕在化してきてはいるのかな

Tsubasa NagasawaTsubasa Nagasawa

2025/6/11

DRA: deviceClassName field names violate API conventions documentation

リソースのフィールド名の命名規則で ${resource_name}Name (e.g. Pod の serviceAccountName, jodeName) と ${resource_name}Ref (e.g. PVC の claimRef, HTTPRoute の parentRef) の使い分けの話。参照するリソースが 1 つだけの場合は Name で参照するリソースが複数の種類ある場合は Ref。Ref の場合は ${resource_name} の部分に参照するリソースの役割とか目的とかが分かるような単語を選ぶべき

Tsubasa NagasawaTsubasa Nagasawa

2025/6/14

KEP-5365: ImageVolume with an image digest

KEP-4639: VolumeSource で OCI Image を Pod のボリュームとしてマウントできるようになった。Pod が利用しているコンテナイメージのイメージダイジェストは Pod のステータスの中の containerStatuses のフィールドに記録される。ただ、OCIVolume の場合は現状情報が記録されないので追加しようとしている KEP。Pod のステータスの中の VolumeMountStatus の中に imageRef のフィールドが追加されて、イメージダイジェストが記録される。フィールドはポインタなので、OCIVolume 以外では値がなし。ユーザーが利用している OCI Image の一意の情報を知るためと、KubeVirt で Pod の中で VM を動かしていて Node を跨いでライブマイグレーションする機能があり、新しく全く同じイメージを使って Pod を作って VM の状態を移行しているので、OCIVolume の一意の情報も欲しい感じらしい

Tsubasa NagasawaTsubasa Nagasawa

2025/6/15

KEP-5307: Container restart rules to customize the pod restart policy

Pod の restartPolicy が Never の場合に、特定の exit code で終了したコンテナを in-place で再起動 (Pod 再作成で再起動ではない) できるようにする KEP。大規模な並列処理だと途中経過をチェックポイントとして記録して途中で処理が止まっても再計算できるようにしている。長時間かかるような処理だと実行中に何かしら問題が発生することがあって、その場合に Pod の再スケジュールから再開するよりも、in-place で再起動して再開する方が時間的にもリソース的にも効率的。重要なのは再思考で直るエラーとハードウェアの問題のように再スケジュールが必要なエラーを分けて考えたい点。Pod の restartPolicy を OnFailure にしたら良いじゃんって思うけど、JobSet など複雑なジョブだと Job Failure Policy が指定されていて、どういう条件 (e.g. exit code が 2 の場合とか Pod の condition に ConfigIssue の状態がある場合とか) の時にジョブを失敗として再スケジュールで再実行するかをユーザーが定義している。要するに Job Failure Policy でハードウェアの問題を検知して再スケジュールさせている。で、この Job Failure Policy は Pod の restartPolicy が Never でないと使えない制約があるので、restartPolicy が OnFailure の場合に使えない。これは Job Failure Policy は Pod の再起動を Job controller が判断して行うけど、restartPolicy が OnFailure の場合は kubelet が判断して行うので両方指定できるようにしてしまうと競合が発生するから意図的に避けている。KEP-5307 に戻って、この KEP が restartPolicy が Never の場合だけを対象としているのはハードウェアの問題の場合は Job Failure Policy で再スケジュールさせつつ、再思考で直るような一時的なエラーの場合に in-place で再起動してすぐに処理をやり直したいから。この KEP では新しくコンテナレベルで restartPolicy が指定できるようになり、Pod レベルの restartPolicy を上書き可能になる。コンテナレベルの restartPolicy が指定されていない場合は Pod レベルの restartPolicy が使われる。initContainer で restartPolicy に Always を指定する Sidecar containers の機能も restartPolicy を上書きしているという点では違和感がない。さらにコンテナレベルで restartPolicyRules のフィールドが追加され、条件 (e.g. 特定の exit code の場合、OOMKill が発生した場合、再起動の回数) とアクション (コンテナを再起動するか完了とするか、Pod 全体を停止すなわち再スケジュールするか) を指定可能になる。アクションに関しては再起動のみ、条件も exit code のみ最初はサポートして今後他のも追加していく予定。regular init container の場合は、exit code 0 で終了するか restartPolicyRules の条件以外で終了するまで再施行される。Sidecar container の場合は restartPolicy が Always なので restartPolicyRules は無視され必ず再起動される。今日の Tim Hockin の Keynote でも話があった AI / ML ジョブのために Kubernetes に入れないといけない Kubernetes の存亡に関わるリスク (大袈裟に言っているとは言ってた) の一つ。restartPolicy が Never なのに restartPolicyRules を指定するのは気持ち悪いけど、仕方ない。Sidecar containers で restartPolicy に Always を指定するという選択を取ったことで、restartPolicy に新しい enum を実質追加できなくなった。Sidecar containers でも再起動のポリシーは今後指定できるようにする予定なので、restartPolicy に例えば Custom を追加すると Sidecar containers であることを伝える手段がなくなってしまう。

Tsubasa NagasawaTsubasa Nagasawa

2025/6/18

Slack Migration Discussion

Kubernetes の Slack からの移行先の議論。Discord の VPoE や Mattermost の CEO、Zulip のリードの人が来て呼び込みしている。Discord のアプリは会社で禁止されてるケースがあったり、ゲームのスキャン走るからブラウザ版使うしかないけど、広告もある。プロプライエタリなサービスから別のプロプライエタリなサービスに移ってもまた同じことが起きるのではって流れになってる。そもそも Slack と交渉して少し安くして払うのはなしなのって質問はスルーされてた。Slack のアーカイブは手元にあって一部の権限のある人が見れるけど、検索とかはしばらく難しい。Issue とか PR や KEP の中に Slack のリンクがあるけど、参照はできなくなるから辛い。関係ないけど、CERN で Mattermost を運用している人の体験談が面白かった。デイリーで 10k のアクティブユーザーがいて、45k チャンネルあり、DB 内に保存されたメッセージ数の合計が 115M、DB の容量は 130 GB。OpenShift の上で単一の Pod と PostgreSQL のデータベースをクラスタ外で動かしている。公式提供のビルドだと 5k ユーザーの縛りがあるので、自前でビルドが必要。水平方向にスケールできないので、ユーザーの少ない時間帯に再起動を伴うメンテ作業を行う。メッセージの検索に Elasticsearch が使えず、PostgreSQL ベースの検索機能になる。悪くはないけど、メッセージが大量にあると鈍くはなる。Bleve は試してない。アプリのプッシュ通知を使いたいなら公式アプリ + SLA なしのプッシュ通知のプロキシを使うか、自前で運用 & アプリもセルフビルド。

Tsubasa NagasawaTsubasa Nagasawa

2025/6/19

CVE-2025-4563: Nodes can bypass dynamic resource allocation authorization checks

DRA 関連の初めての CVE。API サーバの NodeRestriction admission controller の脆弱性だけど、Node が侵害されている必要がある (Node が侵害されていたら GPU などのデバイスにはアクセスできちゃう) のと後述の点から影響はなさそう。Kubernetes には static Pods の機能があって、ホスト上のマニフェストを通して kubelet が Pod のライフサイクルを管理できます。API サーバは介入しませんが、API サーバに Pod の情報を登録するために、kubelet は mirror Pods を作成する権限が与えられています。kubelet のリソース操作を制限しているのが、NodeRestriction admission controller です。で、kubelet が他の Pod に割り当てられた ResourceClaim を参照した mirror Pods を作成できてしまうのが、今回の脆弱性。ただ、DRA を使う場合、どの Pod がデバイスを使う予定かは resourceclaim controller が ResourceClaim の status 内の ReservedFor フィールドに記録されています。ReservedFor に記録されていない Pod がそのデバイスを使おうとしても kubelet 側のチェックで起動できません。static Pods は当然 ReservedFor の中にはいないので、static Pods が起動することはありません。何で CVE として登録されたのかは分からないけど、そもそも static Pods で ResourceClaim が使える状態なのは問題なのでそれを防ぐためのバリデーションが追加された形 (k/k#131844)

Linux Network Devices

アントニオさんが OCI Runtime 仕様に追加した netDevices フィールドを runc でサポートする PR もマージされてた :クラッカー: netDevices で指定したホスト側のネットワークデバイス (e.g. 物理 NIC / 仮想 NIC) を Pod の network namespace の中に渡せるようになる。DRA network driver (e.g. dranet) がホスト側のネットワークデバイスの初期化や設定を行って、CDI で OCI spec の設定ファイルに netDevices 追加のパッチを当てる。containerd は RunPodSandbox の CRI 呼び出しの中で CNI ADD を実行して Pod の network namespace 内のデフォルトのインターフェイスに Pod IP を割り当て、あとは containerd が Pod やコンテナのライフサイクルのイベントで DRA driver に実装された NRI フックを呼び出す。その時に Pod やコンテナの情報を NRI フックに渡して処理できる。NRI はコンテナの作成や更新時に OCI Spec で渡した設定を変更できるので、ホスト側で初期化したデバイスの一部をコンテナに割り当てたりできる。

Tsubasa NagasawaTsubasa Nagasawa

2025/6/22

KEP-5328: Node Capabilities の動向

KEP-5347: Node Capabilities は 1.35 に持ち越し。Kubernetes のコントロールプレーンのバージョン的にサポートしている機能でもバージョンスキューの問題などで Node (kubelet、カーネル、OS が原因) がその機能をサポートしていない場合がある。Node がサポートしている一部の機能 (e.g. Supplemental Group Policy) は現状 Node の .status.features と .status.runtimeHandlers (コンテナランタイム側の機能) に書き込まれるが、それらは kube-scheduler で考慮はされず、クラスタ管理者が問題を調査するときに使うくらい。Node の .status.capabilities に Node でサポートしている機能やカーネルの機能などを公開して、kube-scheduler がその情報を利用して Pod Spec に指定された機能から適切な Node を選択するようになるというもの。現状、公開される予定の機能の多くが FeatureGate になっていて将来的に FeatureGate が消えた時にどう対処するか SIG-Arch と話し合って詰める予定。Swap とか User namespaces とか FeatureGate でないオプトインな機能をどう扱うかも併せて議論予定。元々は Sidecar Containers の懸念 (Node が Sidecar Containers をサポートしていない時に Sidecar Containers が Init Containers として実行されてエラーになる) から始まっているが、Sidecar Containers 以外でも Pod Spec にフィールドが追加された場合などに問題になる。とはいえ、それを防ぐために複雑な仕組みが必要か？というのはあるから 1.35 に延期で良かった

Tsubasa NagasawaTsubasa Nagasawa

2025/6/24

show namespace on delete

kubectl 1.34 でリソースを削除する時にリソースの種類と名前だけじゃなくて、namespace の情報も含まれるようになる。複数 namespace の同じ命名規則のリソースを Kustomize で管理していて、特定の namespace のリソースを削除したいときにどの namespace のリソースが消える予定か dry-run で確認しづらいのでってことらしい

Tsubasa NagasawaTsubasa Nagasawa

2025/6/25

kube-proxy 1.23 → 1.28+ directly upgrade may introduce Latent failures

EKS の中の人からの報告で kube-proxy を 1.23 から 1.28 に一気に更新すると時間経過で kube-proxy が iptables の restore でエラーになる問題。Service type LoadBalancer かつ externalTrafficPolicy が Local の Service があって、後ろにいる Pod が再起動したタイミングで kube-proxy がエラーで壊れる。原因は Node ローカルのトラフィックの送信先の Pod がいないときにパケットを drop するための KUBE-XLB- の chain が 1.24 で KUBE-EXT- に変更され、1.28 から KUBE-XLB- が完全に削除されたから。1.27 以前だと KUBE-XLB- の chain のお掃除の処理は入ってるはず。1.23 から 1.28 に更新した直後は KUBE-XLB- と KUBE-EXT- の chain が残った状態で、KUBE-EXT- の chain が使われて正常に動作するけど、LB の裏側の Pod が再起動して iptables のルールを iptables restore/save で書き換える時に存在しない KUBE-XLB- の chain を参照していてエラーになる。Node の中に入って手動で iptables のルールを書き換えない限りエラーが続く。一気にバージョン更新は公式だとサポートしていないけど、EKS アドオンだと出来ちゃうから誰かがハマってそう。EKS の人もサポートされていない更新方法だから修正されなくても良いけど、報告しとくねってスタンス。少なくとも EKS のバージョンを更新する時にアドオンのバージョンも更新しないとダメ

Introduce Node Lifecycle WG

WG-Node-Lifecycle が正式に発足しました。新しい KEP だと KEP-4212: Declarative Node Maintenance (Node のメンテナンスを宣言的な API で管理) や KEP-4563: EvictionRequest API (既存の Eviction API の改善 or 改善版の新しい API) をやるのと、長らくベータに留まっている KEP-2000: Graceful Node Shutdown を GA に持っていくのが目的

Tsubasa NagasawaTsubasa Nagasawa

2025/6/27

Deny pod admission for static pods referencing API objects

監査ログとか kubelet のログには残りますが、static Pods をユーザーから見えない形 (mirror Pods は作成されない) で動かす方法があったみたいです。API リソースを参照している static Pods を作成すると mirror Pods を API サーバに登録する時にバリデーションエラーになって作成に失敗します。kubelet の NodeRestriction の Admission plugin で static Pods が他の API リソースを参照しているときに kubelet が Node 上にそのリソースを準備するために権限を貰おうとしますが、これも失敗します。ただ、static Pods が同じ Node 上の他の Pod が参照している API リソースを参照する場合は、既に Node 上に準備されているので起動できてしまうらしいです。kubelet が static Pods の YAML ファイルから Pod オブジェクトをパースする時に API リソースが参照されていてもそのまま Pod を作ろうとしていたのが原因です。Pod オブジェクトをパースするときに API リソースを参照しているとエラーになるように修正されたので、1.34 でこの穴は塞がります。ただ、後方互換性の問題で一時的に専用の FeatureGate が用意されていてオフにできるのと、1.33 以前には backport されないはずです。

Tsubasa NagasawaTsubasa Nagasawa

2025/6/28

WG-Creation-Request: Checkpoint/Restore Working Group

コンテナの Checkpoint / Restore に特化した WG ができそう。Kubernetes 1.33 時点でベータで止まっている Container checkpointing の機能は Forensic (デバッグ) 目的で追加されたため、kubelet の API を呼び出してコンテナ単位でチェックポイントの圧縮ファイルをホスト上に作成する。セキュリティ上の懸念からクラスタ管理者が特権でホスト上のファイルにアクセスする必要があり、ユースケースがかなり制約されている。ただ、昨今の AI / ML の流れで長時間 GPU を占有する大規模な分散処理で Preemption やホストのメンテナンスなどで Pod を退避する必要があると、処理を最初から再開することになる。GPU は高価なリソースなので、Container checkpointing の機能で退避した後で restore して処理を再開したい要望が増えている。カンファレンスや Slack のプライベートなチャンネルで結構議論はしてきたらしい。Container checkpointing の機能を kube-apiserver の API 経由で呼び出せるようにし、kube-scheduler の Preemption に組み込んでシームレスにノード間で Pod を移動させ、インメモリやスレッドなどの状態をリストアして処理を再開させるようにするのが目的。WG の初期メンバーが元々の Forensic container checkpointing を実装していた Red Hat の Adrian さん以外は大学の方たちなので、この辺はアカデミックな分野だ。CRIU だと CUDA の状態のチェックポイントは取れないはずだけど、どうするんだろ。チェックポイントの配布の方法とかセキュリティ周りもかなり議論することになりそう

Tsubasa NagasawaTsubasa Nagasawa

2025/7/3

kube-proxy incorrectly logs "Ignoring same-zone topology hints" when there are no endpoints

kube-proxy 1.33 に更新すると、trafficDistribution の機能を使っていなくても同一ゾーンのヒントを無視するよってログが大量に書き込まれるバグの報告。Service にぶら下がっている Pod がいない空っぽの EndpointSlice があると発生する。Endpoints でループ回してフラグをオフにしている処理があって、Endpoints がない場合はフラグがオンのままになってログが書き込まれちゃう。修正の PR は上がっていて、レビュー中。EKS 1.33 に更新して発生した報告。意図的に Deployment とかをゼロスケールしていると起きそうだから注意した方がよさそう

Tsubasa NagasawaTsubasa Nagasawa

2025/7/7

fix pod template spec validation missing in sts

StatedulSet の PodTemplate のバリデーションが今までなく、不正な PodTemplate の StatefulSet が作れてしまっていた問題の修正。作れるだけで Pod 作成時にエラーになって動作はしなかった。既存の不正な StatefulSet に対してバリデーションが行われないように、StatefulSet 更新のイベントではバリデーションをスキップ

Tsubasa NagasawaTsubasa Nagasawa

2025/7/8

Starup probe only starting after periodSeconds when initialDelaySeconds is lower than periodSeconds

liveness / readiness / startup probe の initialDelaySeconds を periodSeconds より短くすると initialDelaySeconds が無視されるの知らない人がちょくちょくいる。initialDelaySeconds 待ってからの probe の実行は Pod の startedAt を基準にするので、periodSeconds と initialDelaySeconds が同じ値の場合は最初の実行が periodSeconds + initialDelaySeconds になってしまうので注意 (k/k#130393)

Tsubasa NagasawaTsubasa Nagasawa

2025/7/9

starting many user namespace enabled pods at once causes bad mount performance

Kubernetes の User Namespace の機能を有効化してコンテナイメージのレイヤーが 50 程度ある大きなイメージの Pod を同時に 100 個くらい作成すると、containerd が CreateContainer の CRI API の処理中にスタックしてタイムアウトが発生する問題。systemd の処理も重くなり、dbus も応答がなくなり、Pod の作成に失敗して Node も正常じゃなくなる。CreateContainer の CRI の中でも prepareIDMappedOverlay の処理に最も時間が掛かっている。コンテナ内に各イメージのレイヤーをマウントする前に、ホストのユーザーやグループの ID とコンテナの User namespace 内でのマッピングを元に ID をズラす必要がある。現在ホストの mount namespace に一時的に bind マウントを作成してこの処理を行っており、systemd からもこのファイルが見えており、dbus を通して大量のイベントがやり取りされる。これが原因で systemd と dbus が重くなる。systemd が重くなるとカーネルの処理を取り合って containerd も重くなり、CRI のタイムアウトが発生する。Linux kernel v6.13 からの新しい mount API を使うとホスト上のレイヤーを fd に紐付けて、fd に対して ID 変換して、その fd を fsconfig() に渡して後の処理をする形に変わり、一時的に bind マウントする必要がなくなる。この変更前後で CPU プロファイルを取ると、今までサンプル内で prepareIDMappedOverlay の処理に全体の 60% を使っていたのが、5% 程度まで抑えられ、CreateContainer の CRI API もタイムアウトしなくなったらしい

Tsubasa NagasawaTsubasa Nagasawa

2025/7/11

In-Flight Requests to Webhook Terminated Abruptly on Pod Shutdown

EKS の Pod Identity Webhook (IRSA とか Pod Identity で使われている Mutating Webhook) の Graceful Shutdown の処理に問題があって、処理中のリクエストを抱えた状態で停止して、必要な環境変数などが差し込まれず、認証に失敗する問題。Mutating Webhook の failurePolicy が Ignore に設定されているので、リクエストが失敗しても Pod はそのまま作成される。Webhook サーバとメトリクス公開用のサーバの両方とも Graceful Shutdown の処理が入っているけど、メトリクス公開用のサーバがメインの goroutine で動いているせいで、停止するとそのまま main 関数が終了してしまうのが原因。Graceful Shutdown が完了する前に強制終了されてしまう。

Tsubasa NagasawaTsubasa Nagasawa

2025/7/12

EKS 1.33 で DRA サポート開始

DRA は Kubernetes 1.33 時点でベータだけどデフォルトで無効。ただ、EKS 1.33 から DRA の FeatureFlag を明示的に有効化したみたいで利用できるようになったらしい。GKE と同じで NVIDIA DRA driver を自分でインストールする感じ (aws/containers-roadmap#2314 (comment))

Tsubasa NagasawaTsubasa Nagasawa

2025/7/15

Add WG AI Integration

WG AI Integration が設立されそう。Kubernetes を操作する AI 組み込みのシステム (MCP サーバや A2A プロトコルによるマルチエージェント) を Kubernetes 上にデプロイしたり、運用したりするための標準的なパターンを考える。セキュリティや認証認可、Observability、ポリシー制御などが AI 組み込みのシステムにも正しく反映されるようにする。Kubernetes では公式の MCP サーバをホストする予定はなく、CNCF か Linux Foundation に既存のツール (Red Hat の人が開発している manusa/kubernetes-mcp-server が有力？) を寄贈してホストする可能性はあるらしい。

Tsubasa NagasawaTsubasa Nagasawa

2025/7/17

Under the hood: Amazon EKS ultra scale clusters | Amazon Web Services

EKS が内部的なアーキテクチャを一部変更したり、SOCI snapshotter や100k ノードに 90 k Pods の ML ジョブを動かして SLO (e.g. API サーバへの Get / Write は 1 秒未満) を満たして動かせた話。etcd は使っているけど、Raft は使わずに etcd のコンセンサスのインターフェイスを通して AWS の内部で使っているジャーナルシステム (ジャーナルログでトランザクションを管理?) を利用する形に変え、これまで EBS に保存していた BoltDB のデータをインメモリに保持する形に変えた。これにより、etcd の推奨ストレージサイズの 8 GB を超える 20 GB を利用。あとは Admission Webhook の設定の最適化や upstream に入った API サーバの最適化の機能 (Consistent Reads from cache、Streaming list responce 、CBOR シリアライゼーション) を使ったり、upstream の KCM のボトルネックを解消 (最近 AWS の人が内部の負荷試験で見つけたボトルネックやバグを修正する PR をあげていたのはこのためか) したり、Karpenter やクラスタネットワーク周り、SOCI snapshotter を使ったコンテナイメージのプルの改善など。スケジューラーのスループットも 500 pods/s 出ているので、upstream の 5000 ノードの負荷テストと同程度は出ている。この構成は新規に作成した EKS クラスタかつ ultra scale capability が有効じゃないと使えないっぽい。この負荷試験のためにかなりのコンピュートインスタンスと GPU (AWS Trainium チップ？) を占有してそうだけど、どうやっているんだろ

その他

dims さん AWS の次は NVIDIA か。EKS 大丈夫かな、また Kubernetes の upstream との関わり薄くなったりしないかな (X)

Tsubasa NagasawaTsubasa Nagasawa

2025/7/18

[KEP-3962]Promote MutatingAdmissionPolicy to Beta

このまま何もなければ Mutating Admission Policy は Kubernetes 1.34 でベータ昇格。メトリクス追加くらいで実装に大きな変化はなさそう。ただ、VAP と同じで新しい API リソースを含むのでベータ昇格でもデフォルト無効。GKE でベータ API を有効にする以外で普通に使えるようになるのは GA に昇格したあとかな

[FG:InPlacePodVerticalScaling] Support reducing memory limits

InPlace Pod Vertical Scaling でコンテナレベルのメモリ上限を減らせるようになった。メモリ上限を減らすと OOMKill の可能性があるので、リサイズの処理の中で対象のコンテナと Pod レベルのメモリ使用量が更新後のメモリ上限を超えていないかベストエフォートでチェックして、超えている場合はリサイズを行わないようになる

Tsubasa NagasawaTsubasa Nagasawa

2025/7/24

DRA API: graduation to GA

Kubernetes 1.34 で DRA の API が GA しました。ResourceClaim, ResourceClaimTemplate, ResourceSlice の基本的な機能は安定化した形です。前に話したように派生の KEP がたくさんあって API に新しいフィールドが追加されていきます。

Tsubasa NagasawaTsubasa Nagasawa

2025/7/25

Pod Level Resources のお手伝い

Kubernetes 1.34 のコードフリーズが今日の 11:00 に発動する予定で、Pod Level Resources のベータ昇格は間に合わないので例外申請が挙げられてました。

僕が担当していた軽めの変更は 3/4 マージして貰って、1 つはベータ昇格必須じゃないので 1.35 に持ち越しです。

初めて締め切りに追われながらでしたが、approver の取り合いで根回し勝負って感じでした。特に今は長期休暇の時期で人が少ないのと、DRA 関連の機能の優先度が高い & 数が多いのでそっちに持って行かれていました。Pod Level Resources は Google の方が推していて、その辺り全部 ndixita さんが裏でやってくれた (Google 内に approver が多いので助かった) ので、なんとかマージして貰えました。個人で新しい機能を追加するなら、後ろ盾を付けてからじゃないと厳しいですね。

EDIT (7/30): Pod Level Resources のベータ昇格間に合いました (k/k#132999)

Tsubasa NagasawaTsubasa Nagasawa

2025/7/30

Fixes scheduler nil panic due to empty init container request&limit

Kubernetes 1.33 のリグレッションで scheduler がリソース要求を計算する時に nil panic が発生して再起動を繰り返すことがある問題。EKS で一部の顧客のクラスタでのみ発生しており、実際の Pod の設定は不明。In-Place Pod Vertical Scaling を利用していて、Pod のリソース要求を後から消している？最大値を取得する処理でリソース要求が指定されていない場合に nil を返すようになったのが原因で修正済み。1.33 にも backport 予定

Promote PSI metrics feature to beta

Kubernetes 1.34 で KubeletPSI がベータ昇格したので、kubelet の /metrics/cadvisor のエンドポイントからノード、Pod、コンテナレベルの CPU / メモリ / IO の PSI メトリクスが公開される。例えば、処理のレイテンシの悪化が他のプロセスとの CPU リソースの取り合いが原因であれば、PSI メトリクスが指標として使える。過去 10 秒、1 分、15 分の間に CPU / メモリ / IO のリソース枯渇により処理できなかった時間がメトリクスとして公開される。Node の逼迫のステータスに PSI メトリクスを追加する件は別の KEP になったので、公開だけ先にベータ昇格した形

Tsubasa NagasawaTsubasa Nagasawa

2025/8/4

ESO v0.19.0

External Secrets Operator v0.19.0 から CRD のサイズが大きくなりすぎて Server Side Apply でしか反映できななくなっている

Tsubasa NagasawaTsubasa Nagasawa

2025/8/5

KEP-5465: Deferred ResourceQuota Enforcement for pods with SchedulingReadinessGates

ResourceQuota のバリデーションは API Server の Admission plugin として実行され、namespace のクォータ制約 (e.g. CPU やメモリ、Pod 数) の閾値を超えた Pod を作成するとその時点で API サーバから作成失敗のエラーが返ってくる。Pod Scheduling Readiness の機能を利用してスケジュールを先延ばしにしている Pending 状態の Pod も ResourceQuota の対象としてカウントされる。そのため、実際には Pod が実行されていない (CPU やメモリを消費していない) にも関わらず ResourceQuota のスロットを占有して、他の Pod のスケジュールをブロックしてしまうことがある。Pod Scheduling Readiness を利用している Pod のみ ResourceQuota のチェックを scheduler 側に移動させて、Pod Scheduling Readiness が削除された時にチェックする KEP。Pending 状態の Pod は ResourceQuota の Pod 数の対象にはなるが、CPU やメモリなどのリソースの対象にはならない予定。PoC だとクォータ制約を超過した状態で Pod Scheduling Readiness を削除すると Pod は Pending 状態のままで、Pod の Unschedulable の condition のメッセージに ResourceQuota 超過しているからスケジュールできない旨が記載されていた。マルチテナントな Kubernetes クラスタで Kubernetes ネイティブな ResourceQuota と Kueue の Resource Flavor によるクォータ制約の両方を利用している場合に、共生できるようにするのが元々の目的らしい。それもあって、最初は Pod Scheduling Readiness を利用している Pod だけを対象にする予定。最終的に全ての Pod に対する ResourceQuota のチェックを scheduler 側で行なって、違反している場合は unschedulable として扱い後で再スケジュールするようになるかも？KEP の有用性や scheduler のパフォーマンス影響を見つつ判断するらしい

Tsubasa NagasawaTsubasa Nagasawa

2025/8/5

Update NodeRestriction to prevent nodes from updating their OwnerReferences

ユーザーや controller が Node の patch 権限を持っている場合に、存在しないクラスタワイドなリソースで OwnerReference を指定すると Node を削除できてしまう脆弱性。Node の delete 権限を持っていなくても Node を削除できてしまう。API サーバの NodeRestriction の Admission plugin で OwnerReference を更新できないようにする修正はマージ & 各サポートバージョンに cherry-pick 済みで Kubernetes の新しいバージョンのリリース待ちっぽい。CVE 共有用の Issue (k/k#133471)

❯ kind create cluster --config=- <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
EOF
Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.33.1) 🖼
 ✓ Preparing nodes 📦 📦 📦
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
 ✓ Joining worker nodes 🚜
Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

Not sure what to do next? 😅  Check out https://kind.sigs.k8s.io/docs/user/quick-start/

❯ kubectl patch node kind-worker --type=merge -p '{
  "metadata": {
    "ownerReferences": [
      {
        "apiVersion": "rbac.authorization.k8s.io/v1",
        "kind": "ClusterRole",
        "name": "foo",
        "uid": "12345678-1234-1234-1234-123456789012"
      }
    ]
  }
}'
node/kind-worker patched

❯ kubectl get nodes
NAME                 STATUS   ROLES           AGE     VERSION
kind-control-plane   Ready    control-plane   3m37s   v1.33.1
kind-worker2         Ready    <none>          3m27s   v1.33.1
Tsubasa NagasawaTsubasa Nagasawa

2025/8/14

[HEALTH]: External Secrets Operator

External Secrets Operator がメンテナ不足で新しいバージョンのリリースとバグ報告や機能追加の要望への返信をしばらくやめるらしい。PR のレビューとマージは続けるらしい。ESO の Issue と Reddit のスレッドで利用している組織やユーザーにコントリビューションを呼びかけている。利用者が多いので反応はかなりあるみたいだけど、どうなるか

Tsubasa NagasawaTsubasa Nagasawa

2025/8/22

Upcoming changes to the Bitnami catalog (effective August 28th, 2025)

Bitnami のコンテナイメージもセキュリティ強化を建前に有料化するみたいで、既存のイメージは bitnamilegacy のリポジトリに移して更新を止めるらしい。セキュリティ設定を強化した Bitnami Secure Image が既存の bitnami のリポジトリのイメージを上書きするから bitnamilegacy のリポジトリへの移行は必須っぽい。Bitnami Secure Image は無料で使えるのは latest タグのイメージだけ。既存の Helm chart は今後も使えるみたいだけど、更新は止まる。ただ、ソースコードは OSS として公開を続ける。8/28 から上書きされるっぽいけどみんな気付いているのかな。一旦 bitnamilegacy のイメージを見るようにしつつ、他に移行しなきゃ

EDIT(2025/8/27):
DockerHub の bitnami リポジトリのイメージの削除も 1 ヶ月延期したみたいですね。ただ、10 個のコンテナイメージを 24 時間使えなくする措置が 3 日間行われるみたいですが (bitnami/charts#36097 (comment))

After evaluating the impact and community feedback, the Bitnami team has postponed the deletion of the Bitnami public catalog (docker.io/bitnami) until September 29th to give users more time to adapt to the upcoming changes.
To raise awareness before the registry deletion, we will run a series of brownouts over the coming weeks. During each brownout, a set of 10 container images from docker.io/bitnami will be temporarily unavailable for 24 hours. The scheduled brownouts are:

  • August 28, 08:00 UTC → August 29, 08:00 UTC
  • September 2, 08:00 UTC → September 3, 08:00 UTC
  • September 17, 08:00 UTC → September 18, 08:00 UTC
Tsubasa NagasawaTsubasa Nagasawa

2025/8/24

SIG Network leadership changes

Tim Hockin が SIG-Network の Chair を降りるらしい。後継は Google の Bowei さん。昔からいる方で最近はあまり見かけなかったけど、Network Policy 周りをやっているらしい。Chair の交代は SIG-Network に割く時間が少なくなってきたことと長いこと Chair をやっているから新しい人を入れるため。API レビューやってたり、validation-gen や KYAML やってたりで忙しそうだからかな。Kubernetes を離れる訳ではなさそう

Tsubasa NagasawaTsubasa Nagasawa

2025/8/25

REQUEST: Migrate github.com/kro-run/kro

少し前に話題になった AWS, Azure, Google Cloud で開発中の kro (Kube Resource Orchestrator) が SIG Cloud Provider のサブプロジェクトになるらしい。Crossplane の CompositeResourceDefinition / Composition と似ていて、 ResourceGraphDefinitions に Kubernetes のリソースを定義して、再利用可能な独自のカスタムリソースを作ることができる。Crossplane の場合、OpenAPI スキーマで独自のカスタムリソースを定義したり、Composition でフィールドの値の参照 / 変換したりで複雑。kro の場合、生のリソースを埋め込んだり、値の参照などに CEL を使うので直感的ではある。ただ、機能が追加されていくと複雑化しそうではある。Helm chart とか Terraform module と同じだけど、Kubernetes の API モデル / YAML として管理したい人向け。SIG Apps じゃなくて SIG Cloud Provider なのはクラウドプロバイダーに依存せずにどこでも動く世界に近づけたいからというのがあるらしい。元々、Google の Kubernetes Config Connector の開発チームがユーザーからの要望でクラウドリソースを束ねる仕組みを追加しようとした時にスケールしないってことで、AWS の AWS Controllers for Kubernetes の開発チームが似たようなツールを開発しているということで会話して一緒に作ろうとなって、そこに Azure もすぐ参加したらしい。

Tsubasa NagasawaTsubasa Nagasawa

2025/8/28

Kubernetes v1.34: Of Wind & Will (O' WaW)

予定通り Kubernetes 1.34 がリリースされました。リリーステーマは Of Wind & Will (O' WaW) で制御できない風を安定させるために、帆を調整したり、舵を切ったりする船員のおかげで Kubernetes は動き続けられていて、新しいバージョンのリリースも厳しい条件の中で何とか推し進める人たちのおかげなので、その風と前進させる意志を称えるためとか。今回は特に GA した機能が多かったです。containerd 1.7 系の EOL のタイミング的に Kubernetes でのサポートが 1.36 で終わるみたいだから、そろそろクラウドプロバイダーも containerd の 2.x 系への更新を進めそう

Tsubasa NagasawaTsubasa Nagasawa

2025/9/2

Add doc.go and ARCHITECTURE.md to apiserver

開発者向けに kube-apiserver の ARCHITECTURE.md を追加する PR。kube-apiserver の中で動いている Aggregation Layer や CRD 用の API Extension Server, kube-apiserver 外で動かしている自作の API Extension Server との連携をどうしているか、kube-apiserver がリクエストを受け取ってからの処理の流れ、API グループの登録や GroupVersionKind (GVK) と Go の型を紐づけるためのスキーマの役割、API リソースのストレージバージョンの話、kube-apiserver は watch キャッシュの仕組みを利用して etcd への負荷を軽減している話 (初回に etcd から全てのオブジェクトを取得して、後は resourceVersion を使って最新の変更のみをストリームで受け取る)、API オブジェクトを更新するときは裏側で resourceVersion を指定して PUT / PATCH しているので変更が衝突すると 409 Conflict が発生する話、Discovery API と OpenAPI スペックの自動生成の話など

Tsubasa NagasawaTsubasa Nagasawa

2025/9/5

kubelet_volume_stats_* metrics not available in 1.34

Kubernetes 1.34.0 で kubelete の /metrics で公開している volume 系のメトリクスが記録されなくなるリグレッション。kubelet が公開するメトリクスを登録するときに呼び出す Register() がメトリクスの初期化と引数で渡した追加のメトリクスを sync.Once() で一度だけ登録する実装になっていたのが原因。1.34 で DRA 関連のメトリクスを登録する処理が追加され、Register() を 2 回呼び出すようになったことで Volume 系の追加のメトリクスが上書きされて公開されなくなってしまった

CVE-2025-7445: secrets-store-sync-controller discloses service account tokens in logs

SIG-Auth が開発している Secrets Store Sync Controller でログに API トークンが書き込まれてしまう脆弱性が見つかった。まだ安定化していなくて絶賛開発中なので使っている人はほぼいないはず。Secrets Store Sync Controller は ESO と同じでユーザーが SecretSync を作成することで、いつでも (Secrets Store CSI Driver で秘密情報をマウントした Pod を起動していなくても) Kubernetes の Secrets に外部のサービスから秘密情報を同期できるコントローラー