Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

6 Problems

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

11 Plans

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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/

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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マニフェストのラッパーツールにいれるだけ

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

23 移行作業

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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へ変更

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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へ流れる

Slide 29

Slide 29 text

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へ流れる

Slide 30

Slide 30 text

30 振り返り

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

33 What’s Next?

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Thank you. 35