How We Migrated K8S Without Downtime

CloudNative Days 2021登壇資料

Transcript

1. 1
   How We Migrated K8S
   Without Downtime
   Hirokuni Kim
   CircleCI, Staff Site Reliability Engineer
   #CNDO2021
   

   View Slide

2. 2
   CircleCIについて
   ✓ 世界最大規模のクラウド CI/CD サービス
   ✓ より良いコードをより速く、簡単にリリースすることを可能に
   ✓ 2011年設立、サンフランシスコ本社
   ✓ 300人+の社員（米国、東京、英国にオフィス）
   ✓ 2020年4月 1億ドルのシリーズEを実施
   Representative Customers
   

   View Slide

3. 3
   コミュニティーもやっています
   CircleCI・connpassで検索!
   

   View Slide

4. 4
   このプレゼンテーションについて
   ● インハウスのK8SからEKSへ移行した時の話
   ● シームレスな移行方法
   ● これから移行する予定がある人の参考になれば
   

   View Slide

5. 5
   Kim, Hirokuni (金 洋国)
   Staff Site Reliability Engineer
   SREチーム
   CircleCIで5年ほど働いています。サポート、開発、
   日本支社立ち上げ、色々やってきました
   自己紹介
   

   View Slide

6. 6
   Problems
   

   View Slide

7. 7
   CircleCIの構成
   ● マイクロサービス (約70)
   ● 各チームは複数のサービスを管理
   ● SREがK8Sの構築・運用を担当
   

   View Slide

8. 8
   注ぎ足しで運用してきたK8Sクラスターの限界
   ● ワーカー数 (EC2インスタンス): ~100
   ● K8Sのバージョンが古い
   ○ いろいろなものがサポートされてない (e.g. Helm 3)
   ● 自動化されてない
   ○ ワーカーのローリングアップデートが大変
   

   View Slide

9. 9
   移行先: EKS
   GKEも検討したがEKSを選択
   ● Managed K8S単体ではGKEがよかった
   ○ 特に欲しかったのはワーカーの自動アップデート
   ● ジョブの実行基盤はAWSにすでにある
   ● GKEに移行したときのAWS <-> GCP間のトラフィックコストが莫大に
   

   View Slide

10. 10
    やりたいこと
    EC2で稼働しているK8Sをどうやって
    ダウンタイムなしでEKSへ移行するか
    

    View Slide

11. 11
    Plans
    

    View Slide

12. 12
    プランA: Big Bang Migration
    新しいクラスターを用意してDNSで一気に切り替える
    Pros:
    ● シンプル
    ● 移行作業が早く終わる
    Cons:
    ● EKSでは動かないサービスがあるかもしれない
    ● 影響範囲が大きすぎる。ダウンタイムの可能性大
    

    View Slide

13. 13
    プランB: Gradual Migration
    サービスごとに新しいクラスターに移行する
    Pros:
    ● 影響範囲を限定できる
    ● 切り戻しが簡単
    Cons:
    ● 時間がかかる
    ● 各サービスのオーナーと調整する必要がある
    

    View Slide

14. 14
    プランB: Gradual Migration
    サービスごとに新しいクラスターに移行する
    Pros:
    ● 影響範囲を限定できる
    ● 切り戻しが簡単
    Cons:
    ● 時間がかかる
    ● 各サービスのオーナーと調整する必要がある
    

    View Slide

15. 15
    プランBでの課題
    スパゲッティー化する懸念
    service1 service2 service3
    service4
    

    View Slide

16. 16
    スパゲッティー化しないために考えたこと
    ● 各クラスター間にプロキシをはさむ
    ● 他のサービスと通信する時は必ずプロキシを通るようにする
    ● 移行のステップを明確にする
    ● 全てのサービスが終わるまで次のステップには進まないようにする
    

    View Slide

17. 17
    Self-service Migration
    ● SREの稼働を減らしたい
    ● できるだけサービスオーナーに移行作業をしてもらう
    ● 移行するためのツールはSREが用意
    ● 実作業は各チームのタイミングに任せる
    

    View Slide

18. 18
    Træfɪk
    Traefik is a leading modern reverse proxy
    and load balancer that makes deploying
    microservices easy. Traefik integrates
    with your existing infrastructure
    components and configures itself
    automatically and dynamically.
    https://containo.us/traefik/
    

    View Slide

19. 19
    Traefikの特徴
    ✓ NginxみたいなReverse Proxy
    ✓ HAProxyみたいなLoad Balancer
    ✓ Container Native
    ✓ 動的な設定のリロード
    ○ MFの変更ごとに再起動しなくてもいい
    ○ Nginxだと設定変更の度に再起動が必要
    詳しくはCloudNative Days 2020 Tokyoの
    スライドで!!
    https://speakerdeck.com/kimh/k8stotrae
    fikdetukurumaikurohurontoendo
    

    View Slide

20. 20
    K8s上ではIngress Controllerとして動作
    今回の移行作業ではHost-Based Routingを使用
    

    View Slide

21. 21
    MigrationのIngressを作成
    # GRPC
    traefikMigration:
    - host: my-service.migration.infra.circleci.com
    - servicePort: 80
    - protocol: h2c
    # HTTP
    traefikMigration:
    - host: my-service.migration.infra.circleci.com
    - servicePort: 80
    これを各サービスのK8Sマニフェストのラッパーツールにいれるだけ
    

    View Slide

22. 22
    HPA (水平 Pod 自動スケーリング)の導入
    ● 移行作業前に負荷テストを実施
    ● テストには https://locust.io/ を使用
    ● 高負荷時にはTraefik PodのCPUがボトルネックになった
    ● HPAで自動でスケーリング
    負荷テストで CPUがボトルネックになり Traefikが自動スケールする様子
    

    View Slide

23. 23
    移行作業
    

    View Slide

24. 24
    移行をステップで管理
    1. EKSをたてる
    2. サービス間通信に使うアドレスをPrivate DNSへ変更
    3. 旧K8SとEKSにデプロイするようにする
    4. トラフィックの一部をEKSへ切り替え
    5. 全トラフィックをEKSへ切り替え
    

    View Slide

25. 25
    ステップ 1: EKSをたてる
    ELB
    service1
    ELB
    service2.migration.infra.circleci.com
    旧K8S EKS
    service2
    service2.default.svc.cluster.local
    

    View Slide

26. 26
    ステップ2: xxx.migration.infra.circleci.comへ切り替え
    ELB
    service1
    ELB
    service2.migration.infra.circleci.com
    旧K8S EKS
    service2
    ❌
    通信経路
    service2.migration.infra.circleci.com
    ↓
    ELB
    ↓
    Traefik (Host-based routing)
    ↓
    service2のPods
    service2.default.svc.cluster.localから
    service2.migration.infra.circleci.comへ変更
    

    View Slide

27. 27
    ステップ3: 旧K8SとEKSへ同時デプロイ
    サービスオーナー
    ELB
    service1 service2
    ELB
    service2.migration.infra.circleci.com
    service2
    デプロイシステムで
    両クラスタへつねにデプロイする
    旧K8S EKS
    

    View Slide

28. 28
    ステップ4: Weighted DNSでカナリー
    ELB
    service1 service2
    ELB
    service2.migration.infra.circleci.com
    # service2.migration.infra.circleci.com
    # 旧k8sのELBへ
    weighted_routing_policy {
    weight = 90
    }
    # service2.migration.infra.circleci.com
    # EKSのELBへ
    weighted_routing_policy {
    weight = 10
    }
    旧K8S EKS
    service2
    Weighted DNS
    10%のトラフィックがEKSの
    service2へ流れる
    

    View Slide

29. 29
    ステップ5: EKSへトラフィックを切り替え
    ELB
    service1 service2
    ELB
    service2.migration.infra.circleci.com
    旧K8S EKS
    service2
    # service2.migration.infra.circleci.com
    # 旧k8sのELBへ
    weighted_routing_policy {
    weight = 0
    }
    # service2.migration.infra.circleci.com
    # EKSのELBへ
    weighted_routing_policy {
    weight = 100
    }
    Weighted DNS
    100%のトラフィックがEKSの
    service2へ流れる
    

    View Slide

30. 30
    振り返り
    

    View Slide

31. 31
    Traefik
    ● Host Based Routingを使うことでELBを節約
    ● 移行状況をサービスのコード (K8Sのマニュフェスト) で管理できる
    ● HTTPとgRPCの両方をサポート
    ● HPAで負荷の増減にも対応
    ● 遅延は発生したが問題になるほどではなかった
    

    View Slide

32. 32
    チーム間コミュニケーション
    -
    ● 実際にはほとんどのサービスオーナーは移行してくれなかった 😞
    ● 移行作業の多くはSREが実施
    ● 努力したつもりだったけどコミュニケーションが足りなかったよう
    次は「移行しないとサービス落とす」くらいやる
    

    View Slide

33. 33
    What’s Next?
    

    View Slide

34. 34
    移行後の課題
    ● EKSの安全なバージョンアップ
    ● Service Meshを使ってマルチクラスターのサポート
    

    View Slide

35. Thank you.
    35
    

    View Slide