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

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**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 自動モードのいずれかに関連付けます。規範的なガイダンスについては、[https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html) を参照してください。
+ 代替 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.  **ボリューム保持ポリシーの変更**: 既存の PersistentVolume (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 など) を使用して、古いロードバランサーから新しいロードバランサーにトラフィックを徐々に移行します。トラフィックが正常に移行され、新しい設定を確認したら、古いロードバランサーとセルフマネージドコントローラーを廃止できます。