Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How We Migrated K8S Without Downtime

How We Migrated K8S Without Downtime

CloudNative Days 2021登壇資料

Kim, Hirokuni

March 11, 2021
Tweet

More Decks by Kim, Hirokuni

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  16. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  19. 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 full-size slide

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

    View full-size slide

  21. 23
    移行作業

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  24. 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 full-size slide

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

    View full-size slide

  26. 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 full-size slide

  27. 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 full-size slide

  28. 30
    振り返り

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  31. 33
    What’s Next?

    View full-size slide

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

    View full-size slide

  33. Thank you.
    35

    View full-size slide