KubeCon Recap -Platform migration at Scale-

KubeCon Recap
-Platform migration at Scale-
Kubernetes Meetup #51
Kohei Ota, Architect at HPE/CNCF Ambassador

View Slide

© 2022 Cloud Native Computing Foundation
2
自己紹介
Kohei Ota (@inductor)
•Architect at HPE
•CNCF Ambassador
•KubeCon EU 2022 Track co-chair (Operation)
•Google Developer Expert (GCP)
•CloudNative Days Tokyo organiser
•Container Runtime Meetup organiser

View Slide

3
Session info of this recap
1. Mercedes-Benzの事例
a. Keynote: 7 Years of Running Kubernetes for
Mercedes-Benz
b. How to Migrate 700 Kubernetes Clusters to
Cluster API with Zero Downtime
2. 稼働中のコンテナランタイムを変更した事例
a. Keep Calm and Containerd On! by Intuit Inc

View Slide

Migrating 700 Kubernetes Clusters to
Cluster API with Zero Downtime after 7
years operation at Mercedes-Benz

View Slide

7年間稼働してきたメルセデスベンツの700に
もわたるクラスターを、ダウンタイムなしで
Cluster APIに移行した事例

View Slide

6

View Slide

7

View Slide

8

View Slide

9
2015年ごろからOpenStack上に複数の
Kubernetesクラスターを運用
移行当時は計700個近くのクラスターが
OpenStack基盤の地域に点在
現在は900近くまで増えた🎉

View Slide

10
エンタープライズ規模でのFOSS(Fully Open Source)
● ダイムラーでもかつてはクローズドな技術スタックを使っていた
● 2014年ごろから自動化を含めOSSをエンタープライズで使うための取り組みを
Green field approachを用いて開始
● オープンソース利用のガイドラインを策定
○ https://opensource.mercedes-benz.com/manifesto/
● コミュニティへの貢献を怠らない

View Slide

インフラ構成 (Before/After)

View Slide

12

View Slide

13
OpenStack + Terraformで仮想マシンの管理
AnsibleでOS上のランタイムを展開
💡VM時代の典型的な管理方法

View Slide

14

View Slide

15
Cluster APIでクラスターの管理
カスタムコントローラーとFluxCDの組合せ
💡GitOpsでKubernetesネイティブな管理方法

View Slide

Why Cluster API?

View Slide

17

View Slide

18
Cluster APIを使うと...
1. クラスターのライフサイクル
2. クラスターに参加するマシンの管理
3. 構成設定(kubeadm config)
これらがすべてKubernetesのCRDで管理できる

View Slide

19
Cluster APIを使うと...
1. クラスターのライフサイクル
2. クラスターに参加するマシンの管理
3. 構成設定(kubeadm config)
これらがすべてKubernetesのCRDで管理できる
Cluster API Providerの存在が大きい
AWS/GCP/Azure/OpenStack
vSphere/Docker
など、APIのあるIaaSで
ノードをセットアップできる仕組み
https://cluster-api.sigs.k8s.io/reference/providers.html

View Slide

20

View Slide

21
管理用クラスターの亀 (Cluster API)の
力を使って、全ゾーンの中で最大 200
近くのワークロードクラスターを集約し
て管理するようになった

View Slide

22
管理用クラスターの亀 (Cluster API)の
力を使って、全ゾーンの中で最大 200
近くのワークロードクラスターを集約し
て管理するようになった
200ものクラスターを既存の Terraform +
Ansibleで管理するくらいだったら Cluster
APIでシュッてやりたい気持ちは本当にそう
だねという感じ

View Slide

ゼロダウンタイムに関する考慮事項

View Slide

24
ゼロダウンタイムの要件と実現方法
● 要件
○ ユーザー(クラスター利用者/開発者)はワークロードのデプロイが不要
○ コントロールプレーン・ワーカーどちらも無停止で実施
● Why?
○ 基盤の根本技術を変えるというインフラの理由でワークロードを停止させるべきでない
○ 開発環境やバッチ処理など様々なワークロードが世界中にある
● 実現方法
○ OpenStackで管理されているKubernetesクラスターのVM、ルーター、
LBaaSなどのオブジェクトをTerraformによる管理からCluster API管理に置換
○ クラスターの構成管理はAnsible + kubeadmだが、そこも全部Cluster API管理に置換

View Slide

25
ゼロダウンタイムの要件と実現方法
● 要件
○ ユーザー(クラスター利用者/開発者)はワークロードのデプロイが不要
○ コントロールプレーン・ワーカーどちらも無停止で実施
● Why?
○ 基盤の根本技術を変えるというインフラの理由でワークロードを停止させるべきでない
○ 開発環境やバッチ処理など様々なワークロードが世界中にある
● 実現方法
○ OpenStackで管理されているKubernetesクラスターのVM、ルーター、
LBaaSなどのオブジェクトをTerraformによる管理からCluster API管理に置換
○ クラスターの構成管理はAnsible + kubeadmだが、そこも全部Cluster API管理に置換
💡`terraform import` みたいなやつで
　メタデータを取り込めば実現できそう

View Slide

26
メタデータの移行
● すべてのOpenStackリソースはTerraformで管理されている
● OpenStack上にはAnsible + kubeadmで作られたクラスターが既にある
● Cluster APIはInfra Providerによるインフラリソースのカスタムリソース管理と、クラ
スター自体の管理をkubeadmの力で実現している
→ Terraform stateにあるマシンのメタデータをCluster API Provider OpenStackに食
わせて、kubeadm configをKubeadmControlPlaneに食わせればええやん！！！

View Slide

クラスター移行のステップ

View Slide

28

View Slide

29
1. OpenStack側のメタデータをCluster APIのオ
ブジェクトに置換
2. ワーカーノード及びマシンセットをCluster API
のオブジェクトに置換
3. コントロールプレーンとKubeadmの構成情報
をCluster APIのオブジェクトに置換

View Slide

30

View Slide

31

View Slide

32

View Slide

33

View Slide

34

View Slide

35
そんなこんなでクラスターの移行自体は完了
・OpenStack上のリソース
・Kubernetesの構成設定
の両方がKubernetesのカスタムリソースで
管理できるようになった🥳🥳

View Slide

学びと今後の予定

View Slide

37
移行作業時の学び
● ちゃんとゼロダウンタイムだったのか？
○ クラスター: Yes
○ ワークロード: No
● なんで？
○ Pod Disruption Budgets(PDB)などの、利用者側で仕込んでおくべき設定が入っていないワー
クロードが存在
○ クラスターのバージョンアップ時などに停止時間が発生(Node drain処理)
○ Cluster API側でできること
■ Pre-Drain/Pre-Terminateアノテーションの付与
■ Cluster APIのカスタムコントローラー側で、クラスター構成変更に伴って発生する drainやボ
リュームデタッチなどの処理について考慮してくれるようになる
● クラスター移行はちゃんと演習しておきましょう
○ 完全自動化された日常的なビルドテスト
■ レガシー構成からCluster APIへの移行
■ Cluster APIを用いた新規クラスターの作成やバージョンアップなど

View Slide

38
今後の展望
● AnsibleからFluxへの完全な移行
● Cluster API 新機能の導入
● Cluster API Metrics Exporterへの貢献
● 既存基盤と同じ利用ができるような仕組みを備えた上で
パブリッククラウド利用も視野に

View Slide

Migrating Running Docker to
Containerd at Scale

View Slide

そこそこの規模で稼働中のDockerを
Containrdに置き換える話

View Slide

41
Intuitのインフラについて
● 財務関係のSaaS・ソフトウェアを展開するテックカンパニー
● 200以上のクラスター
● 16000以上のノード
● 5000人以上の開発者が利用

View Slide

42

View Slide

43
Kubernetes 1.24で削除されるDockershim
● DockershimはKubernetes上でDockerを動作させるためのブリッジインターフェー
ス(Docker API <-> CRI)
● CRIで標準化されたランタイム規格はDocker自体とは関連がない(そもそもDocker
はKubernetesよりも昔から存在するため)
● CRIネイティブなContainerdやCRI-Oが十分枯れてきたため、メンテナンスコストが
高いDockershimをKubernetesのメインストリームから排除することでコード量が大
幅に削減される
○ https://qiita.com/y1r96/items/37483ffd17e21f060331

View Slide

44

View Slide

インフラ構成 (Before/After)

View Slide

46

View Slide

47

View Slide

48
主な影響範囲
● Logging (JSON -> TEXT format)
● Docker CLI (CLIが変わるだけなので割愛)
● kubelet config (設定変更だけなので割愛)
● CNI(時間があれば後で詳しく説明します)

View Slide

Logging

View Slide

50
Docker logging vs CRI logging
● Fluentd DaemonSetsをクラスターアドオンとしてデプロイ
○ ログの収集、パース、アグリゲーターへの転送を担当
● Fluentdで収集するログの中でもコンテナログが最も重要度が高い
○ Docker -> Containerdでロギングフォーマットが変更された

View Slide

51

View Slide

52
● CRIのログには標準フォーマットがある
○ “timestamp stream tag logMessage”
○ fluentdでフォーマットを定めて解決
● パースの処理をfluentdでさせたら
パフォーマンスの劣化を観測
● DaemonSetのfluentdはPodで動くので、
上記設定は事前に反映しておかないとログの
欠損が発生

View Slide

CNIに関する考慮

View Slide

54
Node Node
Node
Pod Pod Pod Pod
Kubernetesネットワークの構成要素: CNI
Pod network(overlay)
Service Network(overlay)
Node Network(not overlay)
veth veth veth veth
eth0 eth0 eth0
CNI (Container Network Interface)
1. ノードネットワークの疎通性を担保
(VXLAN/BGP/クラウドのVPCなどのSDN)
2. Podに仮想NICを割当
3. PodのIPアドレスを割当

View Slide

55
CNIについて
● 外の世界のネットワークとKubernetesのネットワークをつなげる役割
○ クラウドのVPCやノードの制御に使うBGP、あるいはVXLANなどのホストレベルの
ネットワークを認識できる
● 各Podに割り当てる仮想NICの管理
○ コンテナ作成時にランタイムが作ったNW namespaceに対してvNICをアタッチ
● 各PodのIPアドレス管理(要するにIPAM)
○ コンテナは揮発性が高いので、CNIがIPAMのデーモンを管理してIPアドレスを管理し、Service
のエンドポイント情報を書き換える

View Slide

56
CNIについて
● 外の世界のネットワークとKubernetesのネットワークをつなげる役割
○ クラウドのVPCやノードの制御に使うBGP、あるいはVXLANなどのホストレベルの
ネットワークを認識できる
● 各Podに割り当てる仮想NICの管理
○ コンテナ作成時にランタイムが作ったNW namespaceに対してvNICをアタッチ
● 各PodのIPアドレス管理(要するにIPAM)
○ コンテナは揮発性が高いので、CNIがIPAMのデーモンを管理してIPアドレスを管理し、Service
のエンドポイント情報を書き換える
今回のポイント

View Slide

57
CNI IPAM-Dのライフサイクル
● KubernetesでPodを作成するとき、
内部的にはkubeletがCRIランタイムに
命令を発行
○ CRIランタイムでは、コンテナ作成時に
namespaceを作成し、CNIのIPAMが
利用可能なアドレスをそこに割り当てる

View Slide

58
CNI IPAM-Dのライフサイクル
● KubernetesでPodを作成するとき、
内部的にはkubeletがCRIランタイムに
命令を発行
○ CRIランタイムでは、コンテナ作成時に
namespaceを作成し、CNIのIPAMが
利用可能なアドレスをそこに割り当てる
同じノード上で明示的にランタイムを
変えると、既存のコンテナが見えなく
なるので一時的にいなかったことに
なってしまう(IPAMが壊れる)

View Slide

59

View Slide

60
ジェネリックな名前でランタイムを指定する
ことで、kubeletとCNIがそこの変更を意識
しなくてもいいようにする

View Slide

性能変化

View Slide

62

View Slide

63
一応ちゃんとよくなった、らしい。

View Slide

まとめ

View Slide

65
所感
● 今回はBlue GreenやCanaryではなくin-placeで全部を移行する事例を紹介
● Cluster APIに移行する方法はかなり知恵を絞った感じがして面白い
● ランタイム移行のアプローチも王道といえば王道だが、ノードを作成して入れ替えて
もよさそうなのにin-placeでやったのはかなり頑張ったなと思った
○ 実際に確認したわけではなく想像だが、ノード数・クラスタ数ともに規模が大きいのでインフラコ
ストも新規作成の管理コストもかさむことを懸念したのかなと思う

View Slide

66
参考資料
● 前半事例(Cluster API)の資料
○ https://static.sched.com/hosted_files/kccnceu2022/10/KubeConEU22_MBTI_Clust
erAPI_Migrate_700_Clusters.pdf
● 前半事例(ランタイム)の資料
○ https://static.sched.com/hosted_files/kccnceu2022/2a/Containerd_KubeCon_EU
_2022.pdf
○
動画リンクは現時点ではまだ上がっていないので割愛

View Slide

Thank you for your attention!
The CNCF aims to help end users connect with other end users, recruit talent, and adopt
cloud native successfully in a vendor neutral environment.

View Slide

KubeCon Recap -Platform migration at Scale-

KubeCon Recap -Platform migration at Scale-

Kohei Ota

More Decks by Kohei Ota

Other Decks in Technology

Featured

Transcript