分散コンテナレジストリミラーを活用したコンテナイメージ取得時間の改善

サイボウズではコンテナレジストリの可用性を高めるため、コンテナレジストリミラーをクラスタ内にデプロイしています。 しかし、大規模クラスタではコンテナイメージを大量に Pull するためレジストリミラーの負荷が高まりやすく、スケールアウトやチューニングが必要となります。

大量のコンテナイメージの Pull に伴う負荷増大に対処するため、OSS のステートレスな分散レジストリミラーである、Spegel の動作を検証しました。 また、キャッシュミス時に複数のノードが同時に Pull を実行する動作を改善するため、Kubernetes 1.26 にて alpha となった Pod Scheduling Readiness を使ったカスタムコントローラーを開発・検証しました。

Transcript

1. 分散コンテナレジストリミラーを 活⽤したコンテナイメージ 取得時間の改善 2023/10/19 サイボウズ株式会社 ⼭下 壮樹 1
2. アジェンダ 2 - ⾃⼰紹介 - Kubernetesにおけるコンテナイメージ取得 - Spegelの概要と検証 - cat-gateの概要と検証 - まとめ
3. ⾃⼰紹介 3 - ⼭下壮樹 (Soju Yamashita) - 22卒で⼊社して2年⽬ - 主にモニタリング周りのコンポーネントを担当 - VictoriaMetrics, Grafana, Loki など
4. Kubernetesにおける コンテナイメージ取得 4
5. Kubernetesにおけるイメージ取得 5 - Pod起動時、ノードのcontainerdがコンテナイメージをコンテナレジストリか ら取得する Node Container Registry Kubelet 3. Image取得 コンテナ 4. 起動 Kubernetesコントロール プレーン 2. Podの作成 を検知 ⼈ 1. Pod作成 containerd イメージ
6. ⼤規模クラスタでのイメージ取得 6 - ⼤量のコンテナがデプロイされ、⼤量のイメージが各ノードに必要となるシナ リオが存在 - これによって以下の問題が引き起こされる - クラスタ→インターネットの回線の帯域不⾜ - コンテナ起動の遅延 Kubernetes Cluster Node Node Node Node Container Registry 負荷 イメージ イメージ イメージ イメージ
7. レジストリミラーを⽤いた解決策 7 - クラスタ内にコンテナレジストリのミラーをデプロイすることで アップストリームへのアクセスを削減できる - クラスタ内ネットワークでイメージ取得が可能 - アップストリームへのアクセスは初回のみ Kubernetes Cluster Node Node Node Node Container Registry Mirror イメージ イメージ イメージ イメージ Container Registry イメージ
8. レジストリミラーを⽤いた解決策 8 - ⼀⽅で、レジストリミラーがイメージ取得のボトルネックとなることも - レジストリミラーのスケールアウト、チューニングが肝要 Kubernetes Cluster Node Node Node Node Container Registry Mirror イメージ イメージ イメージ イメージ Container Registry 負荷
9. 検討したレジストリミラー 9 - Kraken - P2Pベースのレジストリ - ミラーからイメージを取得する際にアップストリームと別のURLを指定する必要がある - Dragonfly - 豊富な機能を備えたレジストリ - HAにはキャッシュやデータベースなどのステートフルなコンポーネントが必要 - Spegel - ステートレスなコンテナレジストリ - 運⽤が複雑にならない
10. 検討したレジストリミラー 10 - Kraken - P2Pベースのレジストリ - ミラーからイメージを取得する際にアップストリームと別のURLを指定する必要がある - Dragonfly - 豊富な機能を備えたレジストリ - HAにはキャッシュやデータベースなどのステートフルなコンポーネントが必要 - Spegel - ステートレスなコンテナレジストリ - 運⽤が複雑にならない 採⽤！
11. Spegelの概要と検証 11
12. Spegelの概要 12 - Xenit社が開発するステートレスな分散コンテナレ ジストリ - https://github.com/XenitAB/spegel - ⾃前でストレージやキャッシュなどは持たない - containerdをノード間で連携させるシンプルな構成 - OCIに準拠 - 現在はcontainerdにのみ対応 https://github.com/XenitAB/spegel
13. Spegelのデプロイ構成 13 - SpegelをDaemonSetで各ノードにデプロイ - 各ノードのSpegel間はP2P通信する - Spegelとcontainerd間で通信できるように 設定 - containerd側でレジストリとしてSpegelを指定 - SpegelのAPIはcontainerdにプロキシする Kubernetes Cluster Node Node Node Spegel containerd Spegel containerd Spegel containerd
14. Spegelの動作(1) 14 - Spegelはノードで保持しているコンテ ナイメージのダイジェストをP2Pで他の Spegelに共有する - 各Spegelがどのノードにコンテナイ メージがあるか知っている状態に Node Spegel containerd Node Spegel containerd Node Spegel containerd イメージ ダイジェスト イメージ ダイジェスト イメージ ダイジェスト
15. Spegelの動作(2) 15 1. containerdはまず⾃ノードのSpegel にイメージを取りに⾏く 2. ⾃ノードのSpegelはイメージを持つ ノードのSpegelに問い合わせる 3. イメージを取得する Node Spegel containerd Node Spegel containerd Node Spegel containerd ① ② ③
16. Spegelの動作(3) 16 - どのノードにもイメージが存在しない 場合、アップストリームのレジストリ からイメージを取得 Node Spegel containerd Node Spegel containerd Node Spegel containerd Upstream Registry
17. クラスタでの検証 17 - 検証⽅法 - 80ノードほどのクラスタで検証 - テスト⽤イメージでDaemonSetをデプロイし、その後DaemonSetのイメージを更新する - デプロイ時、更新時それぞれのイメージの取得時間を計測 - 更新時は⼀台ずつRolling Updateされる - ⼤規模クラスタで⼤量にイメージ取得が発⽣するシナリオを再現 Kubernetes Cluster Node Node Node Kubernetes Cluster Node Node Node Daemonset Image A:v0.0.1 Kubernetes Cluster Node Node Node Daemonset Image A:v0.0.2 デプロイ 更新
18. クラスタでの検証 18 - 計測項⽬ - 各ノードの単体のイメージ取得時間 - デプロイ、更新の開始から完了までかかった時間 Kubernetes Cluster Node DaemonSet Image A Pod Image A Pod Image A Node Node Node Pod Image A Pod Image A DaemonSetの デプロイ/更新 Registry Registry 単体の イメージ取得
19. 検証結果: イメージ取得時間 19 - デプロイ時 - Spegelの有無に関わらず、全てのノードで並列にアップストリームへイメージを取得 - Spegelありの場合、Spegelから取得する際のtimeoutがあるため結果的に遅くなってし まった Spegel デプロイ時 Best [s] 更新時初回[s] 更新時 Best[s] なし 15 8.6 6.8 あり 52.0 49.6 5.2 Kubernetes Cluster Node Node Node Kubernetes Cluster Node Node Node DaemonSet Image A:v0.0.1 デプロイ
20. 検証結果: イメージ取得時間 20 - 更新時 - 初回はアップストリームから取得する - Spegelありの場合、2回⽬以降はキャッシュにヒットし⾼速に取得できた Spegel デプロイ時 Best [s] 更新時初回[s] 更新時 Best[s] なし 15 8.6 6.8 あり 52.0 49.6 5.2 Kubernetes Cluster Node Node Node DaemonSet Image A:v0.0.1 Kubernetes Cluster Node Node Node DaemonSet Image A:v0.0.2 更新
21. 検証結果: 合計時間 21 - デプロイ時 - 全ノードでアップストリームから取得した場合、単体での取得より時間がかかっている Spegel の有無 デプロイ時 [s] 更新時 [s] なし 27.62 839.52 あり 66.64 916.87 Kubernetes Cluster Node Node Node Kubernetes Cluster Node Node Node DaemonSet Image A:v0.0.1 デプロイ
22. 検証結果: 合計時間 22 - 更新時 - 初回の取得に時間がかかり、最終的にはSpegelなしの場合よりも時間がかかった - より⼤きなクラスタであれば、Spegelありの場合の⽅が短い時間で完了できるはず Spegel の有無 デプロイ時 [s] 更新時 [s] なし 27.62 839.52 あり 66.64 916.87 Kubernetes Cluster Node Node Node DaemonSet Image A:v0.0.1 Kubernetes Cluster Node Node Node DaemonSet Image A:v0.0.2 更新
23. 検証で⾒えてきた課題とその解決策 23 - DaemonSetなどを利⽤して⼤量のPodを同時にデプロイするとミラーを経由し ない Podスケジューリングのタイミングを調整するカスタムコントローラの作成 - レジストリミラーへの問い合わせのタイムアウト待ちに時間がかかる Spegel側でパラメータ調整をする
24. Cat-gateの概要と検証 24
25. Cat-gate 25 - ⼤量のPodの同時デプロイによるイメージ取得の負荷を軽減する⾃作カスタム コントローラ - Podを段階的にスケジュールさせる - Pod Scheduling Readinessを利⽤ - https://github.com/cybozu-go/cat-gate
26. ⼤量のPodをデプロイした時の課題 26 - 全てのPodが同時にデプロイされ、各ノードでSpegelに問い合わせる - この時点ではどのノードにもイメージが存在しないため、全てのノードでアップストリーム に問い合わせてしまう - イメージがノードに保持されてから各ノードでイメージ取得がされるように Podの作成を遅延させたい
27. - Spegelでは、イメージを取得したノードからイメージを取得できるようになる - イメージを取得したノードが増えるほど、イメージ取得先も増える - あるPodで必要とされるイメージを保持するノードの数に合わせて起動するPod の数を調整したい Pending 実現したい挙動 27 Ready Cat-gate Pod Image A Pod Image A Pod Image A Pod Image A Pod Image A Pod Image A Pod Image A Pod Image A Create
28. Pod Scheduling Readinessについて 28 - Kubernetes 1.26でAlphaになった機能 - 通常、Podは作成直後にkube-schedulerによってノードにスケジュールされる - 以下のように schedulingGates を指定すると特定のPodのスケジュールを⽌め ることができる - 削除するとスケジューリングされる apiVersion: v1 kind: Pod metadata: name: sample spec: schedulingGates: - name: my-scheduling-gate containers: - name: ubuntu image: ubuntu:22.04 これがついている間は スケジュールされない
29. Cat-gateの動作 29 - 作成されたPodに対してSchedulingGateを設定する - コンテナイメージのリストのハッシュ値ごとにPodを管理 - 適切なタイミングでSchedulingGateを外し、Podの起動タイミングを制御 Cat-gate Group A(imagehash:xxx) Group B (imagehash:yyy) Pod Image A Pod Image A Pod Image A Pod Image A Pod Image B Pod Image B Pod Image B Pod Image B
30. Node Node Cat-gateによるPodの起動制御 30 - “イメージを取得済のノード数”と”イメージ取得中のPodの数”を⾒つつ調整する - 並列に起動できるPodの数は指数的に増加する Pod Image A Pod Image A Node Node Pod Image A Pod Image A Cat-gate Pending Pod Image A 制御 watch
31. 検証 31 - 検証⽅法はSpegelの検証とほぼ同じ - DaemonSetデプロイ時のみの検証 - 今回はcat-gateを導⼊し、かつミラーのタイムアウトを短縮した - 初回のイメージ取得がタイムアウト短縮によって短くなるはず - Cat-gateの導⼊によって同時にアップストリームにリクエストすることなく、かつ⾼速化す るはず
32. 検証結果 32 - スケジュールされたPodの数が増えた後半では特にPodの起動時間を短縮できた - アップストリームへのアクセスを削減しつつDaemonSetのデプロイが⾼速化で きた - Cat-gateの起動制御による並列起動の恩恵を得られた 起動した順番 Pull の所要時間 [s] 1 25.72 2-3（計2台） 20.25 4-6（計3台） 19.39 7-9（計3台） 19.32 10-27（計18台） 6.21 28-77（計50台） 7.08 ⾼速化！
33. 検証結果 33 - 各ノードのPodがイメージを取得する経過をガントチャートで表した - 横軸は時刻、縦軸は起動したPodの順番を⽰している - Cat-gateによる並列起動の制御がうまく効いていることがわかる cat-gate導⼊時のPodのイメージのダウンロード時刻 1並列 2並列 4並列 取得時間が短くなった
34. まとめ 34
35. まとめ 35 - ステートレスな分散レジストリミラーであるSpegelを検証をしました - Pod Scheduling Readinessを利⽤したコントローラの開発と検証をし、イ メージ取得時間を短縮できた - 本発表はサイボウズサマーインターンシップ2023で実施した内容です - ブログにまとまってます - https://blog.cybozu.io/entry/2023/09/21/161930