EBS CSI driverを利用しているEKSクラスターをEKS Auto Modeにインプレースで移行してみる

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 2025 Classmethod, Inc. EKS Auto Mode 2 従来よりマネージドな部分を増やした形でEKSを利⽤可能。主なメリットとしては下記。 ● EC2ノードの管理をAWSに委任できる (Amazon EC2 マネージドインスタンス) ● 各種コンポーネントと同等の機能をマネージドな形で最初から利⽤できる ○ EBS CSI driver ○ AWS Load Balancer Controller ○ Karpenter ○ VPC CNI Plugin ○ CoreDNS ○ kube-proxy ○ Pod Identityエージェント ○ Node Monitoring Agent

Slide 3

Slide 3 text

© 2025 Classmethod, Inc. EBS CSI driverについて 3 ● EKSからEBSを扱うためのCSI (Container Storage Interface) 仕様に準拠したドライバー ○ CSI仕様に準拠したドライバーを使うことでKubernetesが各種ストレージを扱うことが可能 ● 従来はEKSアドオンとして明⽰的にインストールが必要だった ○ アドオンを追加するだけではあるものの、権限周りやKubernetesアップグレード時の互換性調査が少し⾯倒だった ● EKS Auto Modeでは管理不要に！！ ※ EFS CSI driverやFSx CSI driver、MountPoint for Amazon S3 CSI driverなどストレージを扱うためのドライバーは他にも存在し、これらはAuto Modeでも明⽰的なインストールが必要

Slide 4

Slide 4 text

© 2025 Classmethod, Inc. 既存のEKSクラスターをAuto Modeに移⾏したい 4 下記2パターンの移⾏⽅針がある ● インプレースでAuto Modeを有効化して移⾏ ● Auto Modeのクラスターを新規作成して、Blue/Green⽅式で移⾏インプレース移⾏は可能なものの、下記はサポートされていない ● EBS CSI コントローラー管理のPVCをEKS Auto Mode管理に移⾏ ● ALB Load Balancer Controller管理のロードバランサーをEKS Auto Mode管理に移⾏ ● VPC CNI driver以外のネットワーク構成を採⽤したEKSクラスターの移⾏既存の EKS クラスターで EKS ⾃動モードを有効にする | Amazon EKS

Slide 5

Slide 5 text

© 2025 Classmethod, Inc. インプレース移⾏のイメージ 5 ● マネージドグループやFargateなどで管理されているノードとAuto Mode管理のノードを混在させることが可能 ● Auto Modeでは、従来DaemonSetとして展開されていたaws-node(VPC CNI driver)、 kube-proxy、Pod Identity エージェント、Node Monitoringエージェントに加えてCoreDNSも systemd サービスとして実装されている

Slide 6

Slide 6 text

© 2025 Classmethod, Inc. マネージドインスタンスのログをエクスポートすればプロセスを⾒れる 6 kube-proxy root 1170 0.0 1.4 1738012 56396 ? Ssl 07:53 0:01 /usr/bin/kube-proxy --hostname-override i-04239f7bdcfa45781 --config=/usr/share/kube-proxy/kube-proxy-config --kubeconfig=/etc/kubernetes/kube-proxy/kubeconfig CoreDNS coredns 1604 0.1 1.5 1813796 59840 ? Ssl 07:53 0:10 /usr/bin/coredns -conf=/etc/coredns/Corefile

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© 2025 Classmethod, Inc. EBS CSIコントローラー関連の注意点 9 ● Auto Mode上で利⽤する場合は別のStorageClassを利⽤したPVCとして再作成が必要 ○ EKS Auto Mode管理のノードに配置された際に、上⼿く新しいStrageClassを参照する機構は存在しない⾮Auto Mode Auto Mode EKS Autoモード独⾃のprovisionerを指定する必要あり

Slide 10

Slide 10 text

© 2025 Classmethod, Inc. 基本的には新規構築してBlue/Green形式の移⾏がおすすめ 10 ● 問題があった際に切り戻しがしやすい ● 特にLB周りのハンドリングは楽 ○ 諸々新しく構築してDNSベースで切り替えれば良い ● ちゃんと切り戻しを考慮しようとすると、ストレージ周りは若⼲⾯倒... ○ Veleroを使って復元したり、EBSから直接スナップショットを取得して復元するなどの考慮が必要 ■ そこまでしてダウンタイムを短くしたいワークロードかどうかは検討が必要

Slide 11

Slide 11 text

© 2025 Classmethod, Inc. インプレース移⾏はPV/PVCに関して下記操作が必要 11 1. PVのpersistentVolumeReclaimPolicyをRetainに変更 2. 古いPVを削除 3. 古いPVから切り離したEBS ボリュームを参照して、新しいPVを作成 4. 作成したPV を明⽰的に参照する新しいPVCを作成ストレージを移⾏する必要があって、ダウンタイムを⼤きく取れるならインプレース移⾏もアリ

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© 2025 Classmethod, Inc. 検証してみる 13 1. EKS Auto Modeを有効化 2. Auto Mode⽤のStorageClassを作成 3. 既存のDeploymentをスケールインしてPodを削除 4. eks-auto-mode-ebs-migration-toolを実⾏ (EBSはそのままでPVCが再作成される) 5. DeploymentのNodeSelectorでAuto Mode上で起動するよう設定 6. Deploymentをスケールアウト

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text