kube-aws から EKS に移行した話

Kubernetes Meetup Tokyo 19

Transcript

1. 1 kube-aws から EKS に移行した話
 Kubernetes Meetup Tokyo 19 - 2019/05/30

2. 2 2015年12月 ~ freeeに入社
 2018年11月 ~ SRE
 
 
 • 3年ぐらいフロントエンドとサーバサイドの開発
 • SREに移ってからEKS移行やマルチクラスタデプロイツール の開発など
 • 趣味
 ◦ 自動化
 ◦ キーボード制作/設計
 Kosuke Adachi @foostan freee株式会社 
 SRE
 2
3. EKSリリース以前
 AWS に Managed K8s がなかった時代
 AWS で Kubernetes を使うためには Master Components を含めて全て自分 たちで運用する必要があった

4. ap-northeast-1a Kubernetes master Kubernetes master Kubernetes node kube-aws
 Kubernetes master kube-controller-manager kube-scheduler kube-apiserver Kubernetes master etcd Kubernetes node container runtime kube-proxy kubelet ap-northeast-1c Kubernetes master Kubernetes master Kubernetes node Kubernetes master kube-controller-manager kube-scheduler kube-apiserver Kubernetes master etcd Kubernetes node container runtime kube-proxy kubelet ap-northeast-1d Kubernetes master Kubernetes master Kubernetes node Kubernetes master kube-controller-manager kube-scheduler kube-apiserver Kubernetes master etcd Kubernetes node container runtime kube-proxy kubelet
5. EKS
 2018/12/20 Tokyo Region
 freee では 3/13 に kube-aws -> EKS 移行を完了し、Master Component の 管理から開放された

6. ap-northeast-1a Kubernetes master Kubernetes master Kubernetes node kube-aws
 Kubernetes master kube-controller-manager kube-scheduler kube-apiserver Kubernetes master etcd Kubernetes node container runtime kube-proxy kubelet ap-northeast-1c Kubernetes master Kubernetes master Kubernetes node Kubernetes master kube-controller-manager kube-scheduler kube-apiserver Kubernetes master etcd Kubernetes node container runtime kube-proxy kubelet ap-northeast-1d Kubernetes master Kubernetes master Kubernetes node Kubernetes master kube-controller-manager kube-scheduler kube-apiserver Kubernetes master etcd Kubernetes node container runtime kube-proxy kubelet
7. マルチテナントからシングルテナントへ
 kube-aws -> EKS 移行にあたり運用方針も変更
 プロダクト単位でシングルテナント運用にすることで
 
 • Blast radius の考慮
 • セキュリティの境界線の明確化
 • インフラ運用の権限委譲を推進
8. マルチテナントとシングルテナント
 K8s cluster Product A Service A-1 Service A-2 Service A-3 Product B Service B-1 ServiceB-2 Service B-3 Product C Service C-1 Service C-2 Service C-3 K8s cluster Product A Service A-1 Service A-2 Service A-3 K8s cluster Product B Service B-1 Service B-2 Service B-3 K8s cluster Product C Service C-1 Service C-2 Service C-3 プロダクト単位で
 クラスタを分離
 
 

9. Blast radius(障害時の影響範囲) の考慮
 K8s cluster Product A Service A-1 Service A-2 Service A-3 Product B Service B-1 ServiceB-2 Service B-3 Product C Service C-1 Service C-2 Service C-3 K8s cluster Product A Service A-1 Service A-2 Service A-3 K8s cluster Product B Service B-1 Service B-2 Service B-3 K8s cluster Product C Service C-1 Service C-2 Service C-3 K8sのバグ オペミス K8sのバグ オペミス いのちだいじに
 -> 障害範囲を最小限に
 -> 心理的安全性を確保

10. Product A SG SG SG Kubernetes node Kubernetes node セキュリティの境界線を明確化
 Service A-1 Service A-2 Service A-3 Product B SG SG SG Kubernetes node Kubernetes node Service B-1 Service B-2 Service B-3 Product C SG SG SG Kubernetes node Kubernetes node Service C-1 Service C-2 Service C-3
11. Product A SG SG SG Kubernetes node Kubernetes node インフラ運用の権限委譲を推進
 Service A-1 Service A-2 Service A-3 Product B SG SG SG Kubernetes node Kubernetes node Service B-1 Service B-2 Service B-3 Team A Team B IAM Role ops via kubectl assume role SG/IAMで明確な権限分離 GitOps RBAC with aws-auth PR / Commands actions コマンド実行/ログ調査/障害対応 ops Deploy(helmfile sync)/terraform apply/定常操作 helmfile sync apply
12. まとめ kube-aws -> EKS 移行で運用コストを削減
 
 1クラスタの運用コストが下がるのでシングルテナント運用/権限委譲が現 実的に
 
 シングルテナント運用でコストとリスクを分散
 
 • Blast radius の考慮
 • セキュリティの境界線を明確化
 • インフラ運用の権限委譲を推進