Zenn
🦙

KubeCon EU 2023 Recap

2023/05/29に公開
Kubernetes
KubeCon
tech

これはなに

これは、Kubernetes MeetUp Tokyo #58 - KubeCon EU 2023 Recap向けの発表資料として作成した記事です。
AppleのエンジニアであるIllya Chekrygin(Github)さんによる、「Distributing and Decentralizing Pod Disruption Budget (PDB)」の発表内容を紹介します。

イントロダクション

セッションタイトル

発表の要点まとめ

  • Kubernetes標準のPod Disruption Budget(PDB)ではカバーできないユースケースがあって困っていた
    • CassandraクラスターをKubernetes上にデプロイして、PDBで保護したいケース
    • 1つのPodに対して複数のPDBを適用することができない
  • Distributed PDBというカスタムリソース&コントローラーを開発して解決した
  • クラスターを跨いでPDBを効かせるということも可能でアツい

このセッションを聴いた個人的なモチベーション

  • 普段マルチクラスタなKubernetes環境を運用しており、クラスタを跨いでいい感じにリソースを制御するという技術が気になった（将来役に立つかも）

セッション解説

ここからはセッションの中身をかいつまんで紹介します。

Pod Disruption Budget(PDB)ってこんなやつ

PDBの簡単な復習

PDB

  • PDBはNamespce Scopedなリソース
  • {.spec.maxUnavailable}または{.spec.minAvailable}フィールドで、{.spec.selector}で選択されたPodのうち同時にevictされてもいい数を指定する
  • {.status}フィールドから、対象のPod群の現在の状況（正常なPod数、期待される正常なPod数など）が分かる

PDBのいいところ、いまいちなところ

PDBのいいところ、いまいちなところ

  • PDBのいいところ
    • シンプル
  • PDBのいまいちなところ
    • Namespaceを跨いだりとかできない
    • Podの選択方法がラベルだけで、細かい指定が難しい
    • 拡張性に難がある
  • PDBの勘弁してほしいところ
    • 1つのPodに複数のPDBをマッチさせることができない（エラーになる）
    • 拡張性に難がある

標準のPDBではカバーできないユースケース

CassadraクラスターとPDB

  • Cassandraのクラスターで、Shardのレプリケーション範囲をカバーするPDBを考える
    • 5レプリカのうち3つにShardを複製するとした場合、3/5のPodに対するPDBを5つ用意することになる
    • 1つのPodが、複数のPDBの{.spec.selector}からマッチしてしまう → このようなPDBは作成できない

Federated PDBっていうのを考えてみた

Federated PDBの基本アイデア

Federated PDBの基本アイデア

  • 1つのDistributed PDBリソースに対して、1つの子PDB
  • 指定された他のPDB(Federation PDB)の{.status}に応じて、子PDBの{.spec}を書き換える
    • Federation PDBは複数でもよい
    • Federation PDBは他のDistributed PDBの子PDBでもよい(Bidirectional)

CassandraクラスターとFederated PDB

CassandraクラスターとFederated PDB

  • Distributed PDBリソース
    • {.spec.maxUnavailable}、{.spec.minAvailable}、{.spec.selector}に加えて、{.spec.federation}がある
    • {.spec.selector}1つのPodを選択する（のが基本と思われる）。このPodに対する子PDBが作られる
    • {.spec.federation}にFederation PDBとなるPDBリソースを指定する
  • Cassandraクラスターのユースケースに適用した場合
    • {.spec.selector}を1つのレプリカにマッチさせる
    • Shardの複製先のレプリカ（に対するPDB）をFederation PDBに指定する
    • この図の例では、Distributed PDBを5つapplyし、コントローラーによって子PDBがそれぞれ1つずつ作成される。それぞれのDistributed PDBは他のDPDBの子PDBをFederation PDBとして参照している
    • 1つのレプリカがevictされると、それをFedration PDBとして参照しているPDBのspecを変更して、同じShardがそれ移動evictされないようになる

Multi Namespace PDB

Multi Namespace PDB

  • Namespaceを跨いでFederation PDBを指定できる
  • これによってNamespceを跨いで作用するPDBを実現できる

Multi Cluster PDB

Multi Cluster PDB

  • クラスターを跨いでFederation PDBを指定できる
  • 各クラスターにコントローラーをデプロイしておく
  • これによってクラスターを跨いで作用するPDBを実現できる

デモ

3つのKubernetesにまたがるFederated PDBのデモ。スライドのユースケースよりも少し複雑な構成で、9レプリカで5つにShardが複製されるクラスターになっている。

  • ローカルマシン上にkindクラスタx3
$ kubeclt config get-contexts
CURRENT   NAME         CLUSTER      AUTHINFO     NAMESPACE
          kind-blue    kind-blue    kind-blue
*         kind-green   kind-green   kind-green
          kind-red     kind-red     kind-red
  • 9つのレプリカを3クラスタに分散配置
$ for i in red blue green; do kubectl --context=kind-$i get pods --show-labels; done
NAME                 READY   STATUS    RESTARTS   AGE     LABELS
database-00-10-20   1/1     Running   0          2m33s   app=database,ring=00-10-20
database-30-40-50   1/1     Running   0          2m32s   app=database,ring=30-40-50
database-60-70-80   1/1     Running   0          2m31s   app=database,ring=60-70-80
NAME                 READY   STATUS    RESTARTS   AGE     LABELS
database-10-20-30   1/1     Running   0          2m32s   app=database,ring=10-20-30
database-40-50-60   1/1     Running   0          2m32s   app=database,ring=40-50-60
database-70-80-00   1/1     Running   0          2m31s   app=database,ring=70-80-00
NAME                 READY   STATUS    RESTARTS   AGE     LABELS
database-20-30-40   1/1     Running   0          2m32s   app=database,ring=20-30-40
database-50-60-70   1/1     Running   0          2m32s   app=database,ring=50-60-70
database-80-00-10   1/1     Running   0          2m31s   app=database,ring=80-00-10
  • 各Podに対応するPDBが作られている
$ for i in red blue green; do kubectl --context=kind-$i get pdb; done
NAME                 MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
database-00-10-20   4               N/A               1                     26s
database-30-40-50   4               N/A               1                     23s
database-60-70-80   4               N/A               1                     22s
NAME                 MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
database-10-20-30   4               N/A               1                     25s
database-40-50-60   4               N/A               1                     22s
database-70-80-00   4               N/A               1                     22s
NAME                 MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
database-20-30-40   4               N/A               1                     23s
database-50-60-70   4               N/A               1                     22s
database-80-00-10   4               N/A               1                     22s
  • Podをひとつevictすると、Shardが複製されている他のPodのPDBがallowedDisruptions=0となり、それ以上Evictされないようになる
$ for i in red blue green; do kubectl --context=kind-$i get pdb; done
NAME                 MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
database-00-10-20   4               N/A               1                     3m13s
database-30-40-50   4               N/A               0                     3m10s <-- evicted pod
database-60-70-80   4               N/A               1                     3m9s
NAME                 MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
database-10-20-30   4               N/A               0                     3m12s
database-40-50-60   4               N/A               0                     3m9s
database-70-80-00   4               N/A               1                     3m9s
NAME                 MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
database-20-30-40   4               N/A               0                     3m10s
database-50-60-70   4               N/A               0                     3m9s
database-80-00-10   4               N/A               1                     3m9s

所感

  • 1つのPodのevictが他のPDBに伝搬するのにタイムラグがあり、これが実用上どの程度問題になるかが気になった
  • 全体としての挙動が予想しづらい印象を持ったがどうなのか
  • コントローラーが複数クラスタに1つずつ配置されて協調動作する、という構成をシンプルな仕組みで実現していて面白い
    • 1つのクラスタにコントローラーがいて、他クラスタのリソースをコントロールするのではない
    • コントローラーが直接やり取りするのではなく、PDBの{.status}を介して影響しあう。互いに疎結合な仕組み
    • ロマンを感じる

以上。

Discussion