**このページの改善にご協力ください** 

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。

# 既存の EKS クラスターで EKS 自動モードを有効にする
<a name="migrate-auto"></a>

既存の EKS クラスターで EKS 自動モード を有効にできます。

 ** AWS では次の移行がサポートされています。**
+ Karpenter から EKS 自動モードノードへの移行。詳細については、「[kubectl を使用して Karpenter から EKS 自動モードl に移行する](auto-migrate-karpenter.md)」を参照してください。
+ EKS マネージドノードグループから EKS 自動モードノードへの移行。詳細については、「[EKS マネージドノードグループから EKS Auto Mode に移行する](auto-migrate-mng.md)」を参照してください。
+ EKS Fargate から EKS 自動モードへの移行。詳細については、「[EKS Fargate から EKS Auto Mode に移行する](auto-migrate-fargate.md)」を参照してください。

 ** AWS では以下の移行はサポートされていません。**
+ EBS CSI コントローラー (Amazon EKS アドオンを使用) から EKS 自動モード EBS CSI コントローラー (EKS 自動モードで管理) へのボリュームの移行。これらは 2 つの異なる Kubernetes ボリュームプロビジョナーを使用するため、一方で作成された PVC をもう一方でマウントすることはできません。
  + [https://github.com/awslabs/eks-auto-mode-ebs-migration-tool](https://github.com/awslabs/eks-auto-mode-ebs-migration-tool) (AWS Labs プロジェクト) により、標準の EBS CSI StorageClass (`ebs.csi.aws.com`) と EKS Auto EBS CSI StorageClass (`ebs.csi.eks.amazonaws.com`) 間の移行が可能になります。移行では、既存の PersistentVolumeClaim/PersistentVolume リソースを削除して再作成する必要があるため、実装前に非本番環境での検証が不可欠です。
+ AWS ロードバランサー コントローラー から EKS 自動モード へのロードバランサーの移行

  Amazon EKS 自動モード クラスターに AWS ロードバランサー コントローラー をインストールできます。`IngressClass` または `loadBalancerClass` のオプションを使用して、サービスリソースとイングレスリソースを ロードバランサー コントローラー または EKS 自動モード のいずれかに関連付けます。
+ 代替 CNI またはその他のサポートされていないネットワーク設定を使用した EKS クラスターの移行

## 移行のリファレンス
<a name="migration-reference"></a>

次の移行のリファレンスを使用して、Kubernetes リソースをセルフマネージドコントローラーまたは EKS 自動モードが所有するように設定します。


| 機能 | [リソース]  | フィールド | セルフマネージド型 | EKS 自動モード | 
| --- | --- | --- | --- | --- | 
|  ブロックストレージ  |   `StorageClass`   |   `provisioner`   |   `ebs.csi.aws.com`   |   `ebs.csi.eks.amazonaws.com`   | 
|  負荷分散  |   `Service`   |   `loadBalancerClass`   |   `service.k8s.aws/nlb`   |   `eks.amazonaws.com/nlb`   | 
|  負荷分散  |   `IngressClass`   |   `controller`   |   `ingress.k8s.aws/alb`   |   `eks.amazonaws.com/alb`   | 
|  負荷分散  |   `IngressClassParams`   |   `apiversion`   |   `elbv2.k8s.aws/v1beta1`   |   `eks.amazonaws.com/v1`   | 
|  負荷分散  |   `TargetGroupBinding`   |   `apiversion`   |   `elbv2.k8s.aws/v1beta1`   |   `eks.amazonaws.com/v1`   | 
|  コンピューティング  |   `NodeClass`   |   `apiVersion`   |   `karpenter.sh/v1`   |   `eks.amazonaws.com/v1`   | 

## EBS ボリュームの移行
<a name="_migrating_ebs_volumes"></a>

ワークロードを EKS 自動モードに移行する場合、CSI ドライバープロビジョナーが異なるため、EBS ボリュームの移行を処理する必要があります。
+ EKS 自動モードのプロビジョナー: `ebs.csi.eks.amazonaws.com` 
+ オープンソース EBS CSI のプロビジョナー: `ebs.csi.aws.com` 

永続ボリュームを移行するには、次の手順を実行します。

1.  **ボリューム保持ポリシーの変更**: 既存のプラットフォームバージョン (PV) の `persistentVolumeReclaimPolicy` を `Retain` に変更して、基盤となる EBS ボリュームが削除されないようにします。

1.  **Kubernetes からの PV の削除**: 実際の EBS ボリュームはそのまま保持しながら、古い PV リソースを削除します。

1.  **静的プロビジョニングを使用した新規 PV の作成**: 同じ EBS ボリュームを参照するが、ターゲット CSI ドライバーで動作する新しい PV を作成します。

1.  **新規 PVC へのバインド**: `volumeName` フィールドを使用して、特定の PV を明示的に参照する新しい PVC を作成します。

### 考慮事項
<a name="_considerations"></a>
+ この移行を開始する前に、アプリケーションが停止していることを確認します。
+ 移行プロセスを開始する前に、データをバックアップします。
+ このプロセスは、永続ボリュームごとに実行する必要があります。
+ 新しい PVC を使用するようにワークロードを更新する必要があります。

## ロードバランサーの移行
<a name="_migrating_load_balancers"></a>

AWS セルフマネージドロードバランサーコントローラーから EKS 自動モード に既存のロードバランサーを直接転送することはできません。代わりに、ブルー/グリーンデプロイ戦略を実装する必要があります。これはマネージドコントローラーで新しいロードバランサーを作成しながら、既存のロードバランサー設定を維持することになります。

サービスの中断を最小限に抑えるにはDNS ベースのトラフィックシフトアプローチをお勧めします。まず、既存の設定を稼働させたまま、EKS 自動モードを使用して新しいロードバランサーを作成します。次に、DNS ルーティング (Route 53 など) を使用して、古いロードバランサーから新しいロードバランサーにトラフィックを徐々に移行します。トラフィックが正常に移行され、新しい設定を確認したら、古いロードバランサーとセルフマネージドコントローラーを廃止できます。