KubeCon Recap -Platform migration at Scale-

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

© 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

Slide 3

Slide 3 text

© 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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

インフラ構成 (Before/After)

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Why Cluster API?

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© 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

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

© 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に食わせればええやん！！！

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

学びと今後の予定

Slide 37

Slide 37 text

© 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を用いた新規クラスターの作成やバージョンアップなど

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Migrating Running Docker to Containerd at Scale

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

© 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

Slide 44

Slide 44 text

Slide 45

Slide 45 text

インフラ構成 (Before/After)

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Logging

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

CNIに関する考慮

Slide 54

Slide 54 text

© 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アドレスを割当

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

性能変化

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

まとめ

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

© 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 ○ 動画リンクは現時点ではまだ上がっていないので割愛

Slide 67

Slide 67 text

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.