KubeCon Recap -Platform migration at Scale-

Transcript

1. KubeCon Recap -Platform migration at Scale- Kubernetes Meetup #51 Kohei Ota, Architect at HPE/CNCF Ambassador
2. © 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
3. © 2022 Cloud Native Computing Foundation 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
4. Migrating 700 Kubernetes Clusters to Cluster API with Zero Downtime after 7 years operation at Mercedes-Benz
5. 7年間稼働してきたメルセデスベンツの700に もわたるクラスターを、ダウンタイムなしで Cluster APIに移行した事例
6. © 2022 Cloud Native Computing Foundation 6
7. © 2022 Cloud Native Computing Foundation 7
8. © 2022 Cloud Native Computing Foundation 8
9. © 2022 Cloud Native Computing Foundation 9 2015年ごろからOpenStack上に複数の Kubernetesクラスターを運用 移行当時は計700個近くのクラスターが OpenStack基盤の地域に点在 現在は900近くまで増えた🎉
10. © 2022 Cloud Native Computing Foundation 10 エンタープライズ規模でのFOSS(Fully Open Source) • ダイムラーでもかつてはクローズドな技術スタックを使っていた • 2014年ごろから自動化を含めOSSをエンタープライズで使うための取り組みを Green field approachを用いて開始 • オープンソース利用のガイドラインを策定 ◦ https://opensource.mercedes-benz.com/manifesto/ • コミュニティへの貢献を怠らない
11. インフラ構成 (Before/After)
12. © 2022 Cloud Native Computing Foundation 12
13. © 2022 Cloud Native Computing Foundation 13 OpenStack + Terraformで仮想マシンの管理 AnsibleでOS上のランタイムを展開 💡VM時代の典型的な管理方法
14. © 2022 Cloud Native Computing Foundation 14
15. © 2022 Cloud Native Computing Foundation 15 Cluster APIでクラスターの管理 カスタムコントローラーとFluxCDの組合せ 💡GitOpsでKubernetesネイティブな管理方法
16. Why Cluster API?
17. © 2022 Cloud Native Computing Foundation 17
18. © 2022 Cloud Native Computing Foundation 18 Cluster APIを使うと... 1. クラスターのライフサイクル 2. クラスターに参加するマシンの管理 3. 構成設定(kubeadm config) これらがすべてKubernetesのCRDで管理できる
19. © 2022 Cloud Native Computing Foundation 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
20. © 2022 Cloud Native Computing Foundation 20
21. © 2022 Cloud Native Computing Foundation 21 管理用クラスターの亀 (Cluster API)の 力を使って、全ゾーンの中で最大 200 近くのワークロードクラスターを集約し て管理するようになった
22. © 2022 Cloud Native Computing Foundation 22 管理用クラスターの亀 (Cluster API)の 力を使って、全ゾーンの中で最大 200 近くのワークロードクラスターを集約し て管理するようになった 200ものクラスターを既存の Terraform + Ansibleで管理するくらいだったら Cluster APIでシュッてやりたい気持ちは本当にそう だねという感じ
23. ゼロダウンタイムに関する考慮事項
24. © 2022 Cloud Native Computing Foundation 24 ゼロダウンタイムの要件と実現方法 • 要件 ◦ ユーザー(クラスター利用者/開発者)はワークロードのデプロイが不要 ◦ コントロールプレーン・ワーカーどちらも無停止で実施 • Why? ◦ 基盤の根本技術を変えるというインフラの理由でワークロードを停止させるべきでない ◦ 開発環境やバッチ処理など様々なワークロードが世界中にある • 実現方法 ◦ OpenStackで管理されているKubernetesクラスターのVM、ルーター、 LBaaSなどのオブジェクトをTerraformによる管理からCluster API管理に置換 ◦ クラスターの構成管理はAnsible + kubeadmだが、そこも全部Cluster API管理に置換
25. © 2022 Cloud Native Computing Foundation 25 ゼロダウンタイムの要件と実現方法 • 要件 ◦ ユーザー(クラスター利用者/開発者)はワークロードのデプロイが不要 ◦ コントロールプレーン・ワーカーどちらも無停止で実施 • Why? ◦ 基盤の根本技術を変えるというインフラの理由でワークロードを停止させるべきでない ◦ 開発環境やバッチ処理など様々なワークロードが世界中にある • 実現方法 ◦ OpenStackで管理されているKubernetesクラスターのVM、ルーター、 LBaaSなどのオブジェクトをTerraformによる管理からCluster API管理に置換 ◦ クラスターの構成管理はAnsible + kubeadmだが、そこも全部Cluster API管理に置換 💡`terraform import` みたいなやつで 　 メタデータを取り込めば実現できそう
26. © 2022 Cloud Native Computing Foundation 26 メタデータの移行 • すべてのOpenStackリソースはTerraformで管理されている • OpenStack上にはAnsible + kubeadmで作られたクラスターが既にある • Cluster APIはInfra Providerによるインフラリソースのカスタムリソース管理と、クラ スター自体の管理をkubeadmの力で実現している → Terraform stateにあるマシンのメタデータをCluster API Provider OpenStackに食 わせて、kubeadm configをKubeadmControlPlaneに食わせればええやん！！！
27. クラスター移行のステップ
28. © 2022 Cloud Native Computing Foundation 28
29. © 2022 Cloud Native Computing Foundation 29 1. OpenStack側のメタデータをCluster APIのオ ブジェクトに置換 2. ワーカーノード及びマシンセットをCluster API のオブジェクトに置換 3. コントロールプレーンとKubeadmの構成情報 をCluster APIのオブジェクトに置換
30. © 2022 Cloud Native Computing Foundation 30
31. © 2022 Cloud Native Computing Foundation 31
32. © 2022 Cloud Native Computing Foundation 32
33. © 2022 Cloud Native Computing Foundation 33
34. © 2022 Cloud Native Computing Foundation 34
35. © 2022 Cloud Native Computing Foundation 35 そんなこんなでクラスターの移行自体は完了 ・OpenStack上のリソース ・Kubernetesの構成設定 の両方がKubernetesのカスタムリソースで 管理できるようになった🥳🥳
36. 学びと今後の予定
37. © 2022 Cloud Native Computing Foundation 37 移行作業時の学び • ちゃんとゼロダウンタイムだったのか？ ◦ クラスター: Yes ◦ ワークロード: No • なんで？ ◦ Pod Disruption Budgets(PDB)などの、利用者側で仕込んでおくべき設定が入っていないワー クロードが存在 ◦ クラスターのバージョンアップ時などに停止時間が発生(Node drain処理) ◦ Cluster API側でできること ▪ Pre-Drain/Pre-Terminateアノテーションの付与 ▪ Cluster APIのカスタムコントローラー側で、クラスター構成変更に伴って発生する drainやボ リュームデタッチなどの処理について考慮してくれるようになる • クラスター移行はちゃんと演習しておきましょう ◦ 完全自動化された日常的なビルドテスト ▪ レガシー構成からCluster APIへの移行 ▪ Cluster APIを用いた新規クラスターの作成やバージョンアップなど
38. © 2022 Cloud Native Computing Foundation 38 今後の展望 • AnsibleからFluxへの完全な移行 • Cluster API 新機能の導入 • Cluster API Metrics Exporterへの貢献 • 既存基盤と同じ利用ができるような仕組みを備えた上で パブリッククラウド利用も視野に
39. Migrating Running Docker to Containerd at Scale
40. そこそこの規模で稼働中のDockerを Containrdに置き換える話
41. © 2022 Cloud Native Computing Foundation 41 Intuitのインフラについて • 財務関係のSaaS・ソフトウェアを展開するテックカンパニー • 200以上のクラスター • 16000以上のノード • 5000人以上の開発者が利用
42. © 2022 Cloud Native Computing Foundation 42
43. © 2022 Cloud Native Computing Foundation 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
44. © 2022 Cloud Native Computing Foundation 44
45. インフラ構成 (Before/After)
46. © 2022 Cloud Native Computing Foundation 46
47. © 2022 Cloud Native Computing Foundation 47
48. © 2022 Cloud Native Computing Foundation 48 主な影響範囲 • Logging (JSON -> TEXT format) • Docker CLI (CLIが変わるだけなので割愛) • kubelet config (設定変更だけなので割愛) • CNI(時間があれば後で詳しく説明します)
49. Logging
50. © 2022 Cloud Native Computing Foundation 50 Docker logging vs CRI logging • Fluentd DaemonSetsをクラスターアドオンとしてデプロイ ◦ ログの収集、パース、アグリゲーターへの転送を担当 • Fluentdで収集するログの中でもコンテナログが最も重要度が高い ◦ Docker -> Containerdでロギングフォーマットが変更された
51. © 2022 Cloud Native Computing Foundation 51
52. © 2022 Cloud Native Computing Foundation 52 • CRIのログには標準フォーマットがある ◦ “timestamp stream tag logMessage” ◦ fluentdでフォーマットを定めて解決 • パースの処理をfluentdでさせたら パフォーマンスの劣化を観測 • DaemonSetのfluentdはPodで動くので、 上記設定は事前に反映しておかないとログの 欠損が発生
53. CNIに関する考慮
54. © 2022 Cloud Native Computing Foundation 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アドレスを割当
55. © 2022 Cloud Native Computing Foundation 55 CNIについて • 外の世界のネットワークとKubernetesのネットワークをつなげる役割 ◦ クラウドのVPCやノードの制御に使うBGP、あるいはVXLANなどのホストレベルの ネットワークを認識できる • 各Podに割り当てる仮想NICの管理 ◦ コンテナ作成時にランタイムが作ったNW namespaceに対してvNICをアタッチ • 各PodのIPアドレス管理(要するにIPAM) ◦ コンテナは揮発性が高いので、CNIがIPAMのデーモンを管理してIPアドレスを管理し、Service のエンドポイント情報を書き換える
56. © 2022 Cloud Native Computing Foundation 56 CNIについて • 外の世界のネットワークとKubernetesのネットワークをつなげる役割 ◦ クラウドのVPCやノードの制御に使うBGP、あるいはVXLANなどのホストレベルの ネットワークを認識できる • 各Podに割り当てる仮想NICの管理 ◦ コンテナ作成時にランタイムが作ったNW namespaceに対してvNICをアタッチ • 各PodのIPアドレス管理(要するにIPAM) ◦ コンテナは揮発性が高いので、CNIがIPAMのデーモンを管理してIPアドレスを管理し、Service のエンドポイント情報を書き換える 今回のポイント
57. © 2022 Cloud Native Computing Foundation 57 CNI IPAM-Dのライフサイクル • KubernetesでPodを作成するとき、 内部的にはkubeletがCRIランタイムに 命令を発行 ◦ CRIランタイムでは、コンテナ作成時に namespaceを作成し、CNIのIPAMが 利用可能なアドレスをそこに割り当てる
58. © 2022 Cloud Native Computing Foundation 58 CNI IPAM-Dのライフサイクル • KubernetesでPodを作成するとき、 内部的にはkubeletがCRIランタイムに 命令を発行 ◦ CRIランタイムでは、コンテナ作成時に namespaceを作成し、CNIのIPAMが 利用可能なアドレスをそこに割り当てる 同じノード上で明示的にランタイムを 変えると、既存のコンテナが見えなく なるので一時的にいなかったことに なってしまう(IPAMが壊れる)
59. © 2022 Cloud Native Computing Foundation 59
60. © 2022 Cloud Native Computing Foundation 60 ジェネリックな名前でランタイムを指定する ことで、kubeletとCNIがそこの変更を意識 しなくてもいいようにする
61. 性能変化
62. © 2022 Cloud Native Computing Foundation 62
63. © 2022 Cloud Native Computing Foundation 63 一応ちゃんとよくなった、らしい。
64. まとめ
65. © 2022 Cloud Native Computing Foundation 65 所感 • 今回はBlue GreenやCanaryではなくin-placeで全部を移行する事例を紹介 • Cluster APIに移行する方法はかなり知恵を絞った感じがして面白い • ランタイム移行のアプローチも王道といえば王道だが、ノードを作成して入れ替えて もよさそうなのにin-placeでやったのはかなり頑張ったなと思った ◦ 実際に確認したわけではなく想像だが、ノード数・クラスタ数ともに規模が大きいのでインフラコ ストも新規作成の管理コストもかさむことを懸念したのかなと思う
66. © 2022 Cloud Native Computing Foundation 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 ◦ 動画リンクは現時点ではまだ上がっていないので割愛
67. 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.