安心・安全な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.
   

   View Slide

2. 2
   ⾃⼰紹介
   

   View Slide

3. View Slide

4. 4
   絶賛Kubernetesに移⾏中
   EC2
   (VM)
   EKS
   (Kubernetes)
   + Istio
   

   View Slide

5. 5
   絶賛Kubernetesに移⾏中
   EC2
   (VM)
   EKS
   (Kubernetes)
   移⾏後のバージョンアップ戦略も
   検討中
   + Istio
   

   View Slide

6. 6
   安⼼・安全なバージョンアップ戦略をとりたい
   ＝オペレーションが
   • （準備を含めて）簡易であること
   • できるだけ⾃動であること
   • ロールバック可能であること
   

   View Slide

7. 7
   EKSのバージョンアップ⽅針案①︓ 既存のNodeGroupをアップデート
   Control Plane
   Node
   Group
   簡易さ
   ロールバック
   その他 EKSのAddOnの
   ⼿動アップデートが必要
   

   View Slide

8. 8
   EKSのバージョンアップ⽅針案②︓ 新規 NodeGroupへの切り替え
   Control Plane
   Node
   Group
   Node
   Group
   old new
   簡易さ
   ロールバック
   その他 EKSのAddOnの
   ⼿動アップデートが必要
   

   View Slide

9. 9
   EKSのバージョンアップ⽅針案③︓ 新規Clusterに移⾏
   In-Place-Upgradeを避けたい
   ツール（Istioなど）の
   バージョンアップも
   実施しやすい
   簡易さ
   ロールバック
   その他
   old new
   

   View Slide

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はこれを採⽤
    

    View Slide

11. 11
    Cluster移⾏時はPull型のデプロイ⽅式が便利
    Git Repo CI/CD
    CD
    Git Repo
    CD
    Push型のデプロイ⽅式 Pull型のデプロイ⽅式
    デプロイJob毎に
    設定を変更 各Clusterで
    同じデプロイ設定
    

    View Slide

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/
    

    View Slide

13. 13
    Terraform / ArgoCD でコード化された設定を元にセットアップ
    Terraform
    old new
    

    View Slide

14. 14
    Terraform / ArgoCD でコード化された設定を元にセットアップ
    ArgoCD
    Terraform
    old new Istio
    Log Aggregator
    Cluster Autoscaler
    Application 1
    Application 2
    :
    :
    ↑
    ここの話を詳しく
    

    View Slide

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
    

    View Slide

16. 16
    1. Applicationのデプロイ順序制御
    例）MutatingWebhook⽤のControllerは先にDeployしておきたい
    Application
    A
    Application
    B
    Deployment A
    ConfigMap A
    Deployment B
    ConfigMap B
    ①
    

    View Slide

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
    ①
    ②
    ③
    ③
    ④
    ⑤
    ⑤
    

    View Slide

18. 18
    2-1. Cluster毎に変更したい設定︓Cluster名
    • Cluster名を利⽤したい箇所
    • Logのメタ情報
    • Cluster Autoscaler の対象NodeGroup
    • EKSの場合、EC2のタグ情報からCluster名を取得できる
    Namespace: A
    Namespace: B
    Pod A
    Pod B
    

    View Slide

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
    

    View Slide

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では更新箇所の差分を無視
    

    View Slide

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
    

    View Slide

22. 22
    まとめ
    • 安⼼・安全なバージョンアップ戦略としてCluster移⾏を採⽤
    • Cluster移⾏時のk8s内部のセットアップにArgoCDを利⽤
    • App of Apps パターンと Sync Wave を利⽤したデプロイの順序制御
    • Cluster毎に変更したかった設定
    • Cluster名 → CustomControllerを作成
    • Controllerのバージョン → Jobで更新
    • CronJobのSuspend → MutatingWebhookでtrueに設定
    

    View Slide

23. View Slide