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登壇資料

9996db3588c75fb4f2b582fa4021cfdb?s=128

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
  2. 2 CircleCIについて ✓ 世界最大規模のクラウド CI/CD サービス ✓ より良いコードをより速く、簡単にリリースすることを可能に ✓ 2011年設立、サンフランシスコ本社

    ✓ 300人+の社員(米国、東京、英国にオフィス) ✓ 2020年4月 1億ドルのシリーズEを実施 Representative Customers
  3. 3 コミュニティーもやっています CircleCI・connpassで検索!

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

  5. 5 Kim, Hirokuni (金 洋国) Staff Site Reliability Engineer SREチーム

    CircleCIで5年ほど働いています。サポート、開発、 日本支社立ち上げ、色々やってきました 自己紹介
  6. 6 Problems

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

  8. 8 注ぎ足しで運用してきたK8Sクラスターの限界 • ワーカー数 (EC2インスタンス): ~100 • K8Sのバージョンが古い ◦ いろいろなものがサポートされてない

    (e.g. Helm 3) • 自動化されてない ◦ ワーカーのローリングアップデートが大変
  9. 9 移行先: EKS GKEも検討したがEKSを選択 • Managed K8S単体ではGKEがよかった ◦ 特に欲しかったのはワーカーの自動アップデート •

    ジョブの実行基盤はAWSにすでにある • GKEに移行したときのAWS <-> GCP間のトラフィックコストが莫大に
  10. 10 やりたいこと EC2で稼働しているK8Sをどうやって ダウンタイムなしでEKSへ移行するか

  11. 11 Plans

  12. 12 プランA: Big Bang Migration 新しいクラスターを用意してDNSで一気に切り替える Pros: • シンプル •

    移行作業が早く終わる Cons: • EKSでは動かないサービスがあるかもしれない • 影響範囲が大きすぎる。ダウンタイムの可能性大
  13. 13 プランB: Gradual Migration サービスごとに新しいクラスターに移行する Pros: • 影響範囲を限定できる • 切り戻しが簡単

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

    Cons: • 時間がかかる • 各サービスのオーナーと調整する必要がある
  15. 15 プランBでの課題 スパゲッティー化する懸念 service1 service2 service3 service4

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

  17. 17 Self-service Migration • SREの稼働を減らしたい • できるだけサービスオーナーに移行作業をしてもらう • 移行するためのツールはSREが用意 •

    実作業は各チームのタイミングに任せる
  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/
  19. 19 Traefikの特徴 ✓ NginxみたいなReverse Proxy ✓ HAProxyみたいなLoad Balancer ✓ Container

    Native ✓ 動的な設定のリロード ◦ MFの変更ごとに再起動しなくてもいい ◦ Nginxだと設定変更の度に再起動が必要 詳しくはCloudNative Days 2020 Tokyoの スライドで!! https://speakerdeck.com/kimh/k8stotrae fikdetukurumaikurohurontoendo
  20. 20 K8s上ではIngress Controllerとして動作 今回の移行作業ではHost-Based Routingを使用

  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マニフェストのラッパーツールにいれるだけ
  22. 22 HPA (水平 Pod 自動スケーリング)の導入 • 移行作業前に負荷テストを実施 • テストには https://locust.io/

    を使用 • 高負荷時にはTraefik PodのCPUがボトルネックになった • HPAで自動でスケーリング 負荷テストで CPUがボトルネックになり Traefikが自動スケールする様子
  23. 23 移行作業

  24. 24 移行をステップで管理 1. EKSをたてる 2. サービス間通信に使うアドレスをPrivate DNSへ変更 3. 旧K8SとEKSにデプロイするようにする 4.

    トラフィックの一部をEKSへ切り替え 5. 全トラフィックをEKSへ切り替え
  25. 25 ステップ 1: EKSをたてる ELB service1 ELB service2.migration.infra.circleci.com 旧K8S EKS

    service2 service2.default.svc.cluster.local
  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へ変更
  27. 27 ステップ3: 旧K8SとEKSへ同時デプロイ サービスオーナー ELB service1 service2 ELB service2.migration.infra.circleci.com service2

    デプロイシステムで 両クラスタへつねにデプロイする 旧K8S EKS
  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へ流れる
  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へ流れる
  30. 30 振り返り

  31. 31 Traefik • Host Based Routingを使うことでELBを節約 • 移行状況をサービスのコード (K8Sのマニュフェスト) で管理できる

    • HTTPとgRPCの両方をサポート • HPAで負荷の増減にも対応 • 遅延は発生したが問題になるほどではなかった
  32. 32 チーム間コミュニケーション - • 実際にはほとんどのサービスオーナーは移行してくれなかった 😞 • 移行作業の多くはSREが実施 • 努力したつもりだったけどコミュニケーションが足りなかったよう

    次は「移行しないとサービス落とす」くらいやる
  33. 33 What’s Next?

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

  35. Thank you. 35