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
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