Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
KubeCon Recap -Platform migration at Scale-
Kohei Ota
May 26, 2022
Technology
0
440
KubeCon Recap -Platform migration at Scale-
Kohei Ota
May 26, 2022
Tweet
Share
More Decks by Kohei Ota
See All by Kohei Ota
コンテナビルド最新事情 2022年度版 / Container Build 2022
inductor
2
57
データベースとストレージのレプリケーション入門 / Intro-of-database-and-storage-replication
inductor
22
4.7k
KubeConのケーススタディから振り返る、Platform for Platforms のあり方と その実践 / Lessons from KubeCon case studies: Platform for Platforms and its practice
inductor
2
340
オンラインの技術カンファレンスを安定稼働させるための取り組み / SRE activity for online conference platform
inductor
1
730
Kubernetesネットワーキング初級者脱出ガイド / Kubernetes networking beginner's guide
inductor
15
4k
コンテナネイティブロードバランシングの話 / A story about container native load balancing
inductor
0
870
DockerCon Live 2021 Recap
inductor
2
800
Kubernetesをとりまくコンテナランタイムの栄枯盛衰 / The rise and fall of the container runtimes surrounding Kubernetes
inductor
14
3.9k
Resource Requests and Limits Under the Hood: The Journey of a Pod Spec
inductor
0
1k
Other Decks in Technology
See All in Technology
MRTK3 - DataBinding and Theming 入門
futo23
0
160
SlackBotで あらゆる業務を自動化。問い合わせ〜DevOpsまで #CODT2022
kogatakanori
0
300
音のような言葉 〜ちゃちゃっとチャットで楽しむちょっとしたコツ〜 / words like sounds
satoryu
1
1.3k
JDK Flight Recorder入門
chiroito
1
490
LINEのB2Bプラットフォームにおけるトラブルシューティング2選
line_developers
PRO
3
280
Camp Digital 2022: tailored advice
kyliehavelock
0
140
1人目QAエンジニアよもやま話 / QA Test Talk Vol.1
nametake
4
220
データエンジニアリングの潮流を俯瞰する
tetsuroito
1
720
UIKitのアップデート #WWDC22
akatsuki174
3
180
複数のスクラムチームをサポートするエンジニアリングマネジメントの話
okeicalm
0
1k
現状のFedCMの動作解説と OIDCとの親和性について- OpenID TechNight vol.19
ritou
2
430
Power AutomateでのAdaptive Cards-基本編
miyakemito
1
230
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
351
21k
Happy Clients
brianwarren
89
5.6k
Web development in the modern age
philhawksworth
197
9.3k
How to name files
jennybc
40
60k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
104
16k
Debugging Ruby Performance
tmm1
65
10k
Music & Morning Musume
bryan
35
4.2k
How GitHub (no longer) Works
holman
296
140k
Code Review Best Practice
trishagee
43
9.2k
The Invisible Side of Design
smashingmag
290
48k
Git: the NoSQL Database
bkeepers
PRO
415
59k
The Language of Interfaces
destraynor
148
20k
Transcript
KubeCon Recap -Platform migration at Scale- Kubernetes Meetup #51 Kohei
Ota, Architect at HPE/CNCF Ambassador
© 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
© 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
Migrating 700 Kubernetes Clusters to Cluster API with Zero Downtime
after 7 years operation at Mercedes-Benz
7年間稼働してきたメルセデスベンツの700に もわたるクラスターを、ダウンタイムなしで Cluster APIに移行した事例
© 2022 Cloud Native Computing Foundation 6
© 2022 Cloud Native Computing Foundation 7
© 2022 Cloud Native Computing Foundation 8
© 2022 Cloud Native Computing Foundation 9 2015年ごろからOpenStack上に複数の Kubernetesクラスターを運用 移行当時は計700個近くのクラスターが
OpenStack基盤の地域に点在 現在は900近くまで増えた🎉
© 2022 Cloud Native Computing Foundation 10 エンタープライズ規模でのFOSS(Fully Open Source)
• ダイムラーでもかつてはクローズドな技術スタックを使っていた • 2014年ごろから自動化を含めOSSをエンタープライズで使うための取り組みを Green field approachを用いて開始 • オープンソース利用のガイドラインを策定 ◦ https://opensource.mercedes-benz.com/manifesto/ • コミュニティへの貢献を怠らない
インフラ構成 (Before/After)
© 2022 Cloud Native Computing Foundation 12
© 2022 Cloud Native Computing Foundation 13 OpenStack + Terraformで仮想マシンの管理
AnsibleでOS上のランタイムを展開 💡VM時代の典型的な管理方法
© 2022 Cloud Native Computing Foundation 14
© 2022 Cloud Native Computing Foundation 15 Cluster APIでクラスターの管理 カスタムコントローラーとFluxCDの組合せ
💡GitOpsでKubernetesネイティブな管理方法
Why Cluster API?
© 2022 Cloud Native Computing Foundation 17
© 2022 Cloud Native Computing Foundation 18 Cluster APIを使うと... 1.
クラスターのライフサイクル 2. クラスターに参加するマシンの管理 3. 構成設定(kubeadm config) これらがすべてKubernetesのCRDで管理できる
© 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
© 2022 Cloud Native Computing Foundation 20
© 2022 Cloud Native Computing Foundation 21 管理用クラスターの亀 (Cluster API)の
力を使って、全ゾーンの中で最大 200 近くのワークロードクラスターを集約し て管理するようになった
© 2022 Cloud Native Computing Foundation 22 管理用クラスターの亀 (Cluster API)の
力を使って、全ゾーンの中で最大 200 近くのワークロードクラスターを集約し て管理するようになった 200ものクラスターを既存の Terraform + Ansibleで管理するくらいだったら Cluster APIでシュッてやりたい気持ちは本当にそう だねという感じ
ゼロダウンタイムに関する考慮事項
© 2022 Cloud Native Computing Foundation 24 ゼロダウンタイムの要件と実現方法 • 要件
◦ ユーザー(クラスター利用者/開発者)はワークロードのデプロイが不要 ◦ コントロールプレーン・ワーカーどちらも無停止で実施 • Why? ◦ 基盤の根本技術を変えるというインフラの理由でワークロードを停止させるべきでない ◦ 開発環境やバッチ処理など様々なワークロードが世界中にある • 実現方法 ◦ OpenStackで管理されているKubernetesクラスターのVM、ルーター、 LBaaSなどのオブジェクトをTerraformによる管理からCluster API管理に置換 ◦ クラスターの構成管理はAnsible + kubeadmだが、そこも全部Cluster API管理に置換
© 2022 Cloud Native Computing Foundation 25 ゼロダウンタイムの要件と実現方法 • 要件
◦ ユーザー(クラスター利用者/開発者)はワークロードのデプロイが不要 ◦ コントロールプレーン・ワーカーどちらも無停止で実施 • Why? ◦ 基盤の根本技術を変えるというインフラの理由でワークロードを停止させるべきでない ◦ 開発環境やバッチ処理など様々なワークロードが世界中にある • 実現方法 ◦ OpenStackで管理されているKubernetesクラスターのVM、ルーター、 LBaaSなどのオブジェクトをTerraformによる管理からCluster API管理に置換 ◦ クラスターの構成管理はAnsible + kubeadmだが、そこも全部Cluster API管理に置換 💡`terraform import` みたいなやつで メタデータを取り込めば実現できそう
© 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に食わせればええやん!!!
クラスター移行のステップ
© 2022 Cloud Native Computing Foundation 28
© 2022 Cloud Native Computing Foundation 29 1. OpenStack側のメタデータをCluster APIのオ
ブジェクトに置換 2. ワーカーノード及びマシンセットをCluster API のオブジェクトに置換 3. コントロールプレーンとKubeadmの構成情報 をCluster APIのオブジェクトに置換
© 2022 Cloud Native Computing Foundation 30
© 2022 Cloud Native Computing Foundation 31
© 2022 Cloud Native Computing Foundation 32
© 2022 Cloud Native Computing Foundation 33
© 2022 Cloud Native Computing Foundation 34
© 2022 Cloud Native Computing Foundation 35 そんなこんなでクラスターの移行自体は完了 ・OpenStack上のリソース ・Kubernetesの構成設定
の両方がKubernetesのカスタムリソースで 管理できるようになった🥳🥳
学びと今後の予定
© 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を用いた新規クラスターの作成やバージョンアップなど
© 2022 Cloud Native Computing Foundation 38 今後の展望 • AnsibleからFluxへの完全な移行
• Cluster API 新機能の導入 • Cluster API Metrics Exporterへの貢献 • 既存基盤と同じ利用ができるような仕組みを備えた上で パブリッククラウド利用も視野に
Migrating Running Docker to Containerd at Scale
そこそこの規模で稼働中のDockerを Containrdに置き換える話
© 2022 Cloud Native Computing Foundation 41 Intuitのインフラについて • 財務関係のSaaS・ソフトウェアを展開するテックカンパニー
• 200以上のクラスター • 16000以上のノード • 5000人以上の開発者が利用
© 2022 Cloud Native Computing Foundation 42
© 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
© 2022 Cloud Native Computing Foundation 44
インフラ構成 (Before/After)
© 2022 Cloud Native Computing Foundation 46
© 2022 Cloud Native Computing Foundation 47
© 2022 Cloud Native Computing Foundation 48 主な影響範囲 • Logging
(JSON -> TEXT format) • Docker CLI (CLIが変わるだけなので割愛) • kubelet config (設定変更だけなので割愛) • CNI(時間があれば後で詳しく説明します)
Logging
© 2022 Cloud Native Computing Foundation 50 Docker logging vs
CRI logging • Fluentd DaemonSetsをクラスターアドオンとしてデプロイ ◦ ログの収集、パース、アグリゲーターへの転送を担当 • Fluentdで収集するログの中でもコンテナログが最も重要度が高い ◦ Docker -> Containerdでロギングフォーマットが変更された
© 2022 Cloud Native Computing Foundation 51
© 2022 Cloud Native Computing Foundation 52 • CRIのログには標準フォーマットがある ◦
“timestamp stream tag logMessage” ◦ fluentdでフォーマットを定めて解決 • パースの処理をfluentdでさせたら パフォーマンスの劣化を観測 • DaemonSetのfluentdはPodで動くので、 上記設定は事前に反映しておかないとログの 欠損が発生
CNIに関する考慮
© 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アドレスを割当
© 2022 Cloud Native Computing Foundation 55 CNIについて • 外の世界のネットワークとKubernetesのネットワークをつなげる役割
◦ クラウドのVPCやノードの制御に使うBGP、あるいはVXLANなどのホストレベルの ネットワークを認識できる • 各Podに割り当てる仮想NICの管理 ◦ コンテナ作成時にランタイムが作ったNW namespaceに対してvNICをアタッチ • 各PodのIPアドレス管理(要するにIPAM) ◦ コンテナは揮発性が高いので、CNIがIPAMのデーモンを管理してIPアドレスを管理し、Service のエンドポイント情報を書き換える
© 2022 Cloud Native Computing Foundation 56 CNIについて • 外の世界のネットワークとKubernetesのネットワークをつなげる役割
◦ クラウドのVPCやノードの制御に使うBGP、あるいはVXLANなどのホストレベルの ネットワークを認識できる • 各Podに割り当てる仮想NICの管理 ◦ コンテナ作成時にランタイムが作ったNW namespaceに対してvNICをアタッチ • 各PodのIPアドレス管理(要するにIPAM) ◦ コンテナは揮発性が高いので、CNIがIPAMのデーモンを管理してIPアドレスを管理し、Service のエンドポイント情報を書き換える 今回のポイント
© 2022 Cloud Native Computing Foundation 57 CNI IPAM-Dのライフサイクル •
KubernetesでPodを作成するとき、 内部的にはkubeletがCRIランタイムに 命令を発行 ◦ CRIランタイムでは、コンテナ作成時に namespaceを作成し、CNIのIPAMが 利用可能なアドレスをそこに割り当てる
© 2022 Cloud Native Computing Foundation 58 CNI IPAM-Dのライフサイクル •
KubernetesでPodを作成するとき、 内部的にはkubeletがCRIランタイムに 命令を発行 ◦ CRIランタイムでは、コンテナ作成時に namespaceを作成し、CNIのIPAMが 利用可能なアドレスをそこに割り当てる 同じノード上で明示的にランタイムを 変えると、既存のコンテナが見えなく なるので一時的にいなかったことに なってしまう(IPAMが壊れる)
© 2022 Cloud Native Computing Foundation 59
© 2022 Cloud Native Computing Foundation 60 ジェネリックな名前でランタイムを指定する ことで、kubeletとCNIがそこの変更を意識 しなくてもいいようにする
性能変化
© 2022 Cloud Native Computing Foundation 62
© 2022 Cloud Native Computing Foundation 63 一応ちゃんとよくなった、らしい。
まとめ
© 2022 Cloud Native Computing Foundation 65 所感 • 今回はBlue
GreenやCanaryではなくin-placeで全部を移行する事例を紹介 • Cluster APIに移行する方法はかなり知恵を絞った感じがして面白い • ランタイム移行のアプローチも王道といえば王道だが、ノードを作成して入れ替えて もよさそうなのにin-placeでやったのはかなり頑張ったなと思った ◦ 実際に確認したわけではなく想像だが、ノード数・クラスタ数ともに規模が大きいのでインフラコ ストも新規作成の管理コストもかさむことを懸念したのかなと思う
© 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 ◦ 動画リンクは現時点ではまだ上がっていないので割愛
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.