安心・安全なCluster移行で実現する Kubernetesのバージョンアップ / Kubernetes upgrade with cluster migration

CloudNativeDaysTokyo 2021での発表資料です。
https://event.cloudnativedays.jp/cndt2021/talks/1189

Transcript

1. 安⼼・安全なCluster移⾏で実現する Kubernetesのバージョンアップ CloudNative Days Tokyo 2021 Shota Shirayama EC Incubation Department Rakuten Group, Inc.
2. 2 ⾃⼰紹介
4. 4 絶賛Kubernetesに移⾏中 EC2 (VM) EKS (Kubernetes) + Istio
5. 5 絶賛Kubernetesに移⾏中 EC2 (VM) EKS (Kubernetes) 移⾏後のバージョンアップ戦略も 検討中 + Istio
6. 6 安⼼・安全なバージョンアップ戦略をとりたい ＝オペレーションが • （準備を含めて）簡易であること • できるだけ⾃動であること • ロールバック可能であること
7. 7 EKSのバージョンアップ⽅針案①︓ 既存のNodeGroupをアップデート Control Plane Node Group 簡易さ ロールバック その他 EKSのAddOnの ⼿動アップデートが必要
8. 8 EKSのバージョンアップ⽅針案②︓ 新規 NodeGroupへの切り替え Control Plane Node Group Node Group old new 簡易さ ロールバック その他 EKSのAddOnの ⼿動アップデートが必要
9. 9 EKSのバージョンアップ⽅針案③︓ 新規Clusterに移⾏ In-Place-Upgradeを避けたい ツール（Istioなど）の バージョンアップも 実施しやすい 簡易さ ロールバック その他 old new
10. 10 EKSのバージョンアップ戦略 Control Plane Node Group Control Plane Node Group Node Group old new old new ① 既存のNodeGroupをアップデート ② 新規 NodeGroupへの切り替え ③ 新規Clusterに移⾏ 簡易さ ロールバック その他 EKSのAddOnの ⼿動アップデートが必要 Istioなどのバージョンアッ プも同時に可能 EKSのAddOnの ⼿動アップデートが必要 Rakumaはこれを採⽤
11. 11 Cluster移⾏時はPull型のデプロイ⽅式が便利 Git Repo CI/CD CD Git Repo CD Push型のデプロイ⽅式 Pull型のデプロイ⽅式 デプロイJob毎に 設定を変更 各Clusterで 同じデプロイ設定
12. 12 ArgoCD “Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes” https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/ https://argo-cd.readthedocs.io/en/stable/getting_started/
13. 13 Terraform / ArgoCD でコード化された設定を元にセットアップ Terraform old new
14. 14 Terraform / ArgoCD でコード化された設定を元にセットアップ ArgoCD Terraform old new Istio Log Aggregator Cluster Autoscaler Application 1 Application 2 : : ↑ ここの話を詳しく
15. 15 ArgoCDでのCluster初期セットアップ時の考慮ポイント 1. デプロイ順序の制御 2. Cluster毎に変更したい設定 1. Cluster名を利⽤したい設定値 2. Controllerのバージョン 3. CronJobのSuspend old new Git Repo ArgoCD ArgoCD k8s resources k8s resources k8s resources k8s resources k8s resources k8s resources
16. 16 1. Applicationのデプロイ順序制御 例）MutatingWebhook⽤のControllerは先にDeployしておきたい Application A Application B Deployment A ConfigMap A Deployment B ConfigMap B ①
17. 17 1. Applicationのデプロイ順序制御 例）MutatingWebhook⽤のControllerは先にDeployしておきたい • App of Apps パターン︓Applicationで別のApplicationを管理・デプロイ • Sync Wave︓リソースのデプロイ順序を制御することができる Root Application Application A Application B Deployment A ConfigMap A Deployment B ConfigMap B sync-wave: 1 sync-wave: 2 ① ② ③ ③ ④ ⑤ ⑤
18. 18 2-1. Cluster毎に変更したい設定︓Cluster名 • Cluster名を利⽤したい箇所 • Logのメタ情報 • Cluster Autoscaler の対象NodeGroup • EKSの場合、EC2のタグ情報からCluster名を取得できる Namespace: A Namespace: B Pod A Pod B
19. 19 2-1. Cluster毎に変更したい設定︓Cluster名 • Cluster名を利⽤したい箇所 • Logのメタ情報 • Cluster Autoscaler の対象NodeGroup • EKSの場合、EC2のタグ情報からCluster名を取得できる • Cluster名を各NamespaceにConfigMapとして保存するCustomControllerを作成 • → どのPodからもCluster名を参照しやすくした ClusterName Controller ConfigMap (Cluster Name) Namespace: A Namespace: B ConfigMap (Cluster Name) Pod A Pod B create read read
20. 20 2-2. Cluster毎に変更したい設定︓Controllerのバージョン • Cluster移⾏時にバージョンアップを⾏いたいController • Cluster Autoscaler • Istio • Cluster名毎の設定値を持つConfigMapを利⽤し、Jobでリソースを更新 • 更新対象のリソース作成直後に実⾏する ConfigMap (Cluster Name) ConfigMap (Version Info) data: cluster-name: prd-cluster-02 data: prd-cluster-01: v1.9 prd-cluster-02: v1.11 Job Target Resource “v1.11” で更新 ※ArgoCDでは更新箇所の差分を無視
21. 21 • 複数のClusterで同じCronJobを実⾏させたくない • MutatingWebhook の機能を活⽤し、CronJob作成時にsuspend: trueを設定する • 旧ClusterでCronJobをsupend → 新ClusterのCronJobをsuspend解除 • kyvernoを利⽤ 2-3. Cluster毎に変更したい設定︓CronJobのSuspend ※RakumaではCronJobではなく、ArgoWorkflowのCronWorkflowを主に利⽤している Git Repo ArgoCD kyverno CronJob (susptend: true) Modify : suspend = true
22. 22 まとめ • 安⼼・安全なバージョンアップ戦略としてCluster移⾏を採⽤ • Cluster移⾏時のk8s内部のセットアップにArgoCDを利⽤ • App of Apps パターンと Sync Wave を利⽤したデプロイの順序制御 • Cluster毎に変更したかった設定 • Cluster名 → CustomControllerを作成 • Controllerのバージョン → Jobで更新 • CronJobのSuspend → MutatingWebhookでtrueに設定