Amazon EKS クラスターの EBS ボリュームを gp2 から gp3 に移行する

本投稿は Jens-Uwe Walther による記事 “Migrating Amazon EKS clusters from gp2 to gp3 EBS volumes” の日本語翻訳文です。翻訳文は CNCF アンバサダーいんだくたー氏より寄稿されました。

Kubernetes (K8s) はオープンソースのコンテナオーケストレーションエンジンで、Cloud Native Computing Foundation (CNCF) がホストする成長の速いプロジェクトです。K8s はオンプレミス上やクラウド上でステートフルからステートレスまでコンテナワークロードを動かすために広く採用されています。ステートフルワークロードでは永続ストレージが必要です。Kubernetes においては、ストレージやネットワークのようなオンプレないしはクラウドに固有のインフラ要素をサポートすることを目的として、旧来から「in-tree プラグイン」と呼ばれる構成要素がソースコード内部に含まれていました。ストレージやクラウドの事業者が新しいストレージシステムを追加したり、バグ修正や新機能を追加したい場合、これまでは Kubernetes のリリースサイクルに頼る必要がありました。このような Kubernetes のライフサイクルを事業者に固有の実装から開放するために、Container Storage Interface (CSI) の開発が始まりました。これは、Kubernetes のようなコンテナオーケストレーションシステム上でブロックストレージやファイルストレージを利用するための標準仕様です。これを通じることによって、顧客は Kubernetes の新しいバージョンのリリースを待つこと無く最新の CSI ドライバーの恩恵を受けられるようになりました。

AWS は re:Invent 2017 においてマネージドの Kubernetes サービスである Amazon Elastic Kubernetes Service (Amazon EKS) をローンチしました。2019 年の 9 月には、Amazon EKS において Amazon Elastic Block Store (Amazon EBS) の CSI ドライバーをサポートしたことを発表しました。さらに 2021 年 5 月にはこの CSI プラグインの GA (一般提供開始)をアナウンスしました。Kubernetes 本体にも “kubernetes.io/aws-ebs” プロビジョナーとして知られる Amazon EBS 向けのプラグインが存在しましたが、この in-tree ストレージプラグインは io1、gp2、sc1、そして st1 の EBS タイプのみをサポートしており、ボリュームスナップショットに関連する機能はサポートしていません。

gp3 や io2 のような新しいボリュームタイプや Kubernetes のボリュームスナップショットのような新機能を活用したい AWS のお客様は、いつ、そしてどのようにして EKS クラスターで利用している Amazon EBS 向けの Kubernetes in-tree プラグインを Amazon EBS CSI ドライバーに移行すれば良いのかという質問を私たちに投げかけてきます。

In-tree プラグインから Container Storage Interface (CSI) に移行するための機能 (CSI Migration) は Kubernetes v1.17 から beta 機能として利用可能であり、その詳細はこちらのブログ記事に記されています。この CSI Migration は、将来的に in-tree プラグインが Kubernetes のソースコードから削除され、すべての移行されたボリュームが CSI ドライバーによって管理されるようになることを目的としており、移行した PV リソースが CSI ドライバーから提供される新しい機能や属性を使えるようになるわけではありません。こちらの GitHub コメントでも示されているように、あくまでも in-tree ドライバーによって提供されていた機能をそのまま使えるようにすることが目的です。

本ブログ記事では、移行のシナリオや概要について一通り確認し、必要なステップの詳細を示します。

前提条件

利用中の Kubernetes クラスターバージョンが 1.17 以上で、kubectl も同様であることを確認してください。また、Amazon EBS CSI に関連したオブジェクトがインストールされ、機能していることを確認してください。

Kubernetes ではストレージ移行を実装するために「フィーチャーゲート」と呼ばれる機能を使っています。Amazon EBS 用の CSIMigration と CSIMigrationAWS を有効にすると、すべてのプラグイン操作を既存の in-tree プラグインから ebs.csi.aws.com CSI ドライバーにリダイレクトします。Amazon EKS では CSIMigration 及び CSIMigrationAWS 機能が有効化されていないことにご注意ください。とはいえ、CSI ドライバーと in-tree プラグインを並行して利用することは現時点でも可能です。

まずはデモ目的で、後ほど移行対象とする動的な PersistentVolume (PV) リソースを作成します。

ここでは、K8s ドキュメントに記載されている「ボリュームの動的プロビジョニング」を使うことにします。

In-tree ストレージドライバーを利用したデフォルトの StorageClass (SC) である gp2 を使って PersistentVolumeClaim (PVC) リソースを作成します。

$ kubectl get sc
NAME                    PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
gp2   (default)     kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  242d

$ cat ebs-gp2-claim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-gp2-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: gp2 

$ kubectl apply -f ebs-gp2-claim.yaml
persistentvolumeclaim/ebs-gp2-claim created

PVC が作成され、ステータスが “pending” になっています。これは gp2 の StorageClass が Volume Binding Mode (フィールド内における volumeBindingMode) が WaitForFirstConsumer であり、まだ PVC を利用する Pod が作成されていないためです。

$ kubectl get pvc ebs-gp2-claim
NAME            STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
ebs-gp2-claim   Pending                                      gp2            45s

それでは、PVC を利用するデモアプリの Pod を作成しましょう。

$ cat test-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-gp2-in-tree
spec:
  containers:
  - name: app
    image: centos
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: ebs-gp2-claim

$ kubectl apply -f test-pod.yaml
pod/app-gp2-in-tree created

数秒すると Pod が作成されます。

$ kubectl get po app-gp2-in-tree
NAME              READY   STATUS    RESTARTS   AGE
app-gp2-in-tree   1/1     Running   0          16s

このとき、基盤となる PV pvc-646fef81-c677-46f4-8f27-9d394618f236 が動的に用意され、PVC “ebs-gp2-claim” として Pod に紐付けられます。

$ kubectl get pvc ebs-gp2-claim
NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
ebs-gp2-claim   Bound    pvc-646fef81-c677-46f4-8f27-9d394618f236   1Gi        RWO            gp2            5m3s

ボリュームが含むデータをさくっと確認します。

$ kubectl exec app-gp2-in-tree -- sh -c "cat /data/out.txt"
…
Thu Sep 16 13:56:34 UTC 2021
Thu Sep 16 13:56:39 UTC 2021
Thu Sep 16 13:56:44 UTC 2021

PV の詳細を見てみましょう。

$ kubectl get pv pvc-646fef81-c677-46f4-8f27-9d394618f236
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                   STORAGECLASS   REASON   AGE
pvc-646fef81-c677-46f4-8f27-9d394618f236   1Gi        RWO            Delete           Bound    default/ebs-gp2-claim   gp2                     2m54s

$ kubectl get pv pvc-646fef81-c677-46f4-8f27-9d394618f236 -o yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    kubernetes.io/createdby: aws-ebs-dynamic-provisioner
    pv.kubernetes.io/bound-by-controller: "yes"
    pv.kubernetes.io/provisioned-by: kubernetes.io/aws-ebs
…
  labels:
    topology.kubernetes.io/region: eu-central-1
    topology.kubernetes.io/zone: eu-central-1c
  name: pvc-646fef81-c677-46f4-8f27-9d394618f236
…
spec:
  accessModes:
  - ReadWriteOnce
  awsElasticBlockStore:
    fsType: ext4
    volumeID: aws://eu-central-1c/vol-03d3cd818a2c2def3
…
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.kubernetes.io/zone
          operator: In
          values:
          - eu-central-1c
        - key: topology.kubernetes.io/region
          operator: In
          values:
          - eu-central-1
  persistentVolumeReclaimPolicy: Delete
  storageClassName: gp2
…

この PV は (期待通り) “kubernetes.io/aws-ebs” プロビジョナーによって作成され、アノテーションに記録されています。Spec 内の “awsElasticBlockStore.volumeId” フィールドには実体となる EBS の ID “vol-03d3cd818a2c2def3” が、EBS ボリュームが作成された AWS アベイラビリティゾーン (AZ) とともに表示されています(この場合は eu-central-1c)。EBS ボリュームと EC2 インスタンスはリージョンではなく単一ゾーンで動いています。K8s 公式ドキュメントの nodeAffinity 項では kube-scheduler が Pod と PV を同じ AZ で用意するようにするための必要事項について記されています。

以下のコマンドは Amazon EBS の詳細情報を表示するための便利コマンドです。

$ kubectl get pv pvc-646fef81-c677-46f4-8f27-9d394618f236 –o jsonpath='{.spec.awsElasticBlockStore.volumeID}'
aws://eu-central-1c/vol-03d3cd818a2c2def3

我々は、この PV をのちに説明するストレージ移行シナリオで使います。この PV を使っている PVC が削除されてしまったとしても PV 自体は削除されないように、“VolumeReclaimPolicy” を “Retain” に変更しておきます。これは PV レベルの変更であり、SC レベルではないことに注意してください。

$ kubectl patch pv pvc-646fef81-c677-46f4-8f27-9d394618f236 -p '{"spec":{"persistentVolumeReclaimPol
icy":"Retain"}}'
persistentvolume/pvc-646fef81-c677-46f4-8f27-9d394618f236 patched
$ kubectl get pv pvc-646fef81-c677-46f4-8f27-9d394618f236
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                   STORAGECLASS   REASON   AGE
pvc-646fef81-c677-46f4-8f27-9d394618f236   1Gi        RWO            Retain           Bound    default/ebs-gp2-claim   gp2                     9m4s

Amazon EBS CSI ドライバーをインストールする際は、GitHub リポジトリのドキュメントに従ってください。おおまかなステップは以下のとおりです。

EBS の操作に必要な IAM 権限をインスタンスプロファイルにアタッチするか、最小権限の原則に従うためにIRSA (IAM roles for service accounts / サービスアカウントの IAM ロール) を使って適切なサービスアカウントにアノテーションを付与します
YAML を用いて external-snapshotter に関連する K8s オブジェクト (CRD、RBAC、Deployment、Validating Webhook) をインストールします
YAML を用いて Amazon EBS CSI ドライバーをインストールするか、それに対応した Helm chart をデプロイします (IRSA を使う場合、既存のサービスアカウントを使うように設定します)

Amazon EBS CSI ドライバーに関連した Kubernetes コンポーネントが K8s API サーバーに登録されていることをダブルチェックします。

$ kubectl api-resources | grep "storage.k8s.io/v1"
volumesnapshotclasses                          snapshot.storage.k8s.io/v1               false        VolumeSnapshotClass
volumesnapshotcontents                         snapshot.storage.k8s.io/v1               false        VolumeSnapshotContent
volumesnapshots                                snapshot.storage.k8s.io/v1               true         VolumeSnapshot
csidrivers                                     storage.k8s.io/v1                        false        CSIDriver
csinodes                                       storage.k8s.io/v1                        false        CSINode
csistoragecapacities                           storage.k8s.io/v1beta1                   true         CSIStorageCapacity
storageclasses                    sc           storage.k8s.io/v1                        false        StorageClass
volumeattachments                              storage.k8s.io/v1                        false        VolumeAttachment

インストールしたコンポーネントが動作していることを確認します。

$ kubectl get po -n kube-system -l 'app in (ebs-csi-controller,ebs-csi-node,snapshot-controller)'
NAME                                   READY   STATUS    RESTARTS   AGE
ebs-csi-controller-569b794b57-md99s    6/6     Running   0          6d15h
ebs-csi-controller-569b794b57-trkks    6/6     Running   0          6d15h
ebs-csi-node-4fkb8                     3/3     Running   0          6d14h
ebs-csi-node-vc48t                     3/3     Running   0          6d14h
snapshot-controller-6984fdc566-4c49f   1/1     Running   0          6d15h
snapshot-controller-6984fdc566-jlnbn   1/1     Running   0          6d15h
$ kubectl get csidrivers
NAME              ATTACHREQUIRED   PODINFOONMOUNT   STORAGECAPACITY   TOKENREQUESTS   REQUIRESREPUBLISH   MODES        AGE
ebs.csi.aws.com   true             false            false             <unset>         false               Persistent   7d19h

移行シナリオ

まずは移行シナリオについて抽象的な議論をしてみましょう。

これから、我々は in-tree ベースの PV で作成された物理ストレージ領域のデータを、in-tree プラグインにとっての “外部のスナップショット機構” である Amazon EBS のスナップショット機能を使って移行していきます (注意: in-tree の Amazon EBS ストレージプラグインではボリュームスナップショットはサポートされていません！)。そして、そのデータを Amazon EBS CSI ドライバーの CSI Volume Snapshot 機能を使ってインポートします。

ここからは、詳細な移行手順を説明していきます。

まず、in-tree プラグインベースの PV である pvc-646fef81-c677-46f4-8f27-9d394618f236 のスナップショットを、AWS API 経由で取ります。

$ kubectl get pv pvc-646fef81-c677-46f4-8f27-9d394618f236 -o jsonpath='{.spec.awsElasticBlockStore.volu
meID}'
aws://eu-central-1c/vol-03d3cd818a2c2def3

$ aws ec2 create-snapshot --volume-id vol-03d3cd818a2c2def3 --tag-specifications 'ResourceType=snapshot,Tags=[{Key="ec2:ResourceTag/ebs.csi.aws.com/cluster",Value="true"}]
{
…
    "SnapshotId": "snap-06fb1faafc1409cc5",
…
    "State": "pending",
    "VolumeId": "vol-03d3cd818a2c2def3",
    "VolumeSize": 1,
…    
}

スナップショットのステータスが “completed” になるまで待ちます。

$ aws ec2 describe-snapshots --snapshot-ids snap-06fb1faafc1409cc5
{
    "Snapshots": [
        {
…
            "Progress": "100%",
            "SnapshotId": "snap-06fb1faafc1409cc5",
..
            "State": "completed",
            "VolumeId": "vol-03d3cd818a2c2def3",
…
        }
    ]
}

スナップショット作成が終わったので、VolumeSnapshotClass リソースを作成します。

$ cat vsc-ebs-csi.yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: ebs-csi-aws
driver: ebs.csi.aws.com
deletionPolicy: Delete

$ kubectl apply -f vsc-ebs-csi.yaml
volumesnapshotclass.snapshot.storage.k8s.io/ebs-csi-aws created

$ kubectl get volumesnapshotclass
NAME          DRIVER            DELETIONPOLICY   AGE
ebs-csi-aws   ebs.csi.aws.com   Delete           12s

次に、AWS 側のスナップショットデータ snap-06fb1faafc1409cc5 を使い、なおかつ次のステップで利用する VolumeSnapshot リソースを参照するような VolumeSnapshotContent リソースを作成する必要があります。変な感じがするかもしれませんが、既存のスナップショットの VolumeSnapshotContent と VolumeSnapshot の相互的な紐付けに必要です！

$ cat vsc-csi.yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
  name: imported-aws-snapshot-content
spec:
  volumeSnapshotRef:
    kind: VolumeSnapshot
    name: imported-aws-snapshot
    namespace: default
  source:
    snapshotHandle: snap-06fb1faafc1409cc5 # <-- snapshot to import
  driver: ebs.csi.aws.com
  deletionPolicy: Delete
  volumeSnapshotClassName: ebs-csi-aws

$ kubectl apply -f vsc-csi.yaml
volumesnapshotcontent.snapshot.storage.k8s.io/imported-aws-snapshot-content created

$ kubectl get volumesnapshotcontent imported-aws-snapshot-content
NAME                            READYTOUSE   RESTORESIZE   DELETIONPOLICY   DRIVER            VOLUMESNAPSHOTCLASS   VOLUMESNAPSHOT          VOLUMESNAPSHOTNAMESPACE   AGE
imported-aws-snapshot-content   true         1073741824    Delete           ebs.csi.aws.com   ebs-csi-aws           imported-aws-snapshot   default                   12s

そうしたら、作成した VolumeSnapshotContent オブジェクトに紐づく VolumeSnapshot を作成します。

$ cat vs-csi.yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: imported-aws-snapshot
  namespace: default
spec:
  volumeSnapshotClassName: ebs-csi-aws
  source:
    volumeSnapshotContentName: imported-aws-snapshot-content

$ kubectl apply -f  vs-csi.yaml
volumesnapshot.snapshot.storage.k8s.io/imported-aws-snapshot created
$ kubectl get volumesnapshot imported-aws-snapshot
NAME                    READYTOUSE   SOURCEPVC   SOURCESNAPSHOTCONTENT           RESTORESIZE   SNAPSHOTCLASS   SNAPSHOTCONTENT                 CREATIONTIME   AGE
imported-aws-snapshot   true                     imported-aws-snapshot-content   1Gi           ebs-csi-aws     imported-aws-snapshot-content   33m            60s

移行作業をする上で、せっかく新しく使えるようになった Amazon EBS の gp3 タイプの恩恵にあずかりたいですよね。そのためには、CSI ベースの gp3 StorageClass リソースを作成する必要があります！これが今後デフォルトの SC リソースとなってほしいので、Amazon EKS のデフォルト gp2 SC から以下のアノテーションを取り除きます。

$ kubectl annotate sc gp2 storageclass.kubernetes.io/is-default-class-
storageclass.storage.k8s.io/gp2 annotated

$ kubectl get sc gp2
NAME   PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
gp2    kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  243d

$ cat gp3-def-sc.yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: gp3
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
allowVolumeExpansion: true
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: gp3

$ kubectl apply -f gp3-def-sc.yaml
storageclass.storage.k8s.io/gp3 created

$ kubectl get sc gp3
NAME            PROVISIONER       RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
gp3 (default)   ebs.csi.aws.com   Delete          WaitForFirstConsumer   true                   6s

先程のステップで作成した VolumeSnapshot は、PersistentVolumeClaim の作成に使えます。StorageClass には、CSI ベースの新しい gp3 SC を使います。

$ cat pvc-vs-csi.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: imported-aws-snapshot-pvc
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: gp3
  resources:
    requests:
      storage: 1Gi
  dataSource:
    name: imported-aws-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io

$ kubectl apply -f pvc-vs-csi.yaml
persistentvolumeclaim/imported-aws-snapshot-pvc created

$ kubectl get pvc imported-aws-snapshot-pvc
NAME                        STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
imported-aws-snapshot-pvc   Pending                                      gp3            54s

この PVC はまだ Pending のステータスのままであることに注意してください。これは、gp3 SC が volumeBindingMode を WaitForFirstConsumer で設定されているためです。PV を実際に作成するためには、アプリケーション (Pod) の作成が必要です。今回はデモのため、作成する Pod では新規データの書き込みは行わず、スナップショットから作られマウントされた PVC 中のデータを “kubectl exec”を使って確認するだけにします。

$ cat test-pod-snap.yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-imported-snapshot-csi
spec:
  containers:
  - name: app
    image: centos
    args:
    - sleep
    - "10000"
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: imported-aws-snapshot-pvc

$ kubectl apply -f test-pod-snap.yaml
pod/app-imported-snapshot-csi created

PV リソース pvc-25d2d19d-6ede-47d2-bd2e-32d45832ec20 が自動的に作成され、Pod が移行後のデータとともに立ち上がってきたことが確認できました。

$ kubectl get pvc imported-aws-snapshot-pvc
NAME                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
imported-aws-snapshot-pvc   Bound    pvc-25d2d19d-6ede-47d2-bd2e-32d45832ec20   1Gi        RWO            gp3            11m

$ kubectl get po app-imported-snapshot-csi
NAME                        READY   STATUS    RESTARTS   AGE
app-imported-snapshot-csi   1/1     Running   0          85s

$ kubectl exec app-imported-snapshot-csi -- sh -c "cat /data/out.txt" | more
Thu Sep 16 13:56:04 UTC 2021
Thu Sep 16 13:56:09 UTC 2021
Thu Sep 16 13:56:14 UTC 2021
…

PVC に関しては、期待通り、CSI ベースの gp3 SC を使っています。

$ kubectl get pv pvc-25d2d19d-6ede-47d2-bd2e-32d45832ec20
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                               STORAGECLASS   REASON   AGE
pvc-25d2d19d-6ede-47d2-bd2e-32d45832ec20   1Gi        RWO            Delete           Bound    default/imported-aws-snapshot-pvc   gp3                     3m34s

$ kubectl get pv pvc-25d2d19d-6ede-47d2-bd2e-32d45832ec20 -o yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: ebs.csi.aws.com
  creationTimestamp: "2021-09-17T09:57:15Z"
  finalizers:
  - kubernetes.io/pv-protection
  - external-attacher/ebs-csi-aws-com
  name: pvc-25d2d19d-6ede-47d2-bd2e-32d45832ec20
…
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 1Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: imported-aws-snapshot-pvc
    namespace: default
…
  csi:
    driver: ebs.csi.aws.com
    fsType: ext4
    volumeAttributes:
      storage.kubernetes.io/csiProvisionerIdentity: 1630589410219-8081-ebs.csi.aws.com
    volumeHandle: vol-036ef87c533d529de
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.ebs.csi.aws.com/zone
          operator: In
          values:
          - eu-central-1c
  persistentVolumeReclaimPolicy: Delete
  storageClassName: gp3
  volumeMode: Filesystem
status:
  phase: Bound

お掃除

余計なコストがかからないように、デモの確認が終わったらご自身の環境から削除しましょう。


$ kubectl delete pod app-imported-snapshot-csi

$ kubectl delete pvc imported-aws-snapshot-pvc

$ kubectl delete volumesnapshotcontent imported-aws-snapshot-content

$ kubectl delete volumesnapshot imported-aws-snapshot

$ aws ec2 delete-snapshot --snapshot-ids <snap-id>

$ kubectl delete pv <pvc-id>

将来また使えるように、CSI ドライバー及び EKS クラスターは残しておいてもよいでしょう。

結論

Amazon EKS はマネージドなコントロールプレーン、データプレーンを管理するための選択肢 (マネージド型ノードグループ)、そして AWS VPC CNI や CoreDNS、kube-proxy といった重要なコンポーネントを管理するためのマネージドなクラスター用アドオンをお客様に提供しています。Amazon EBS CSI の移行に関するすべての機能が仕上がれば、今回示した手順の多くを AWS からマネージドで提供できるようになる予定です！

本記事では、ご自身のワークロードを Amazon EBS CSI ドライバーが提供する新しい機能を使える PVs に移行するための今日から始められる手順をご紹介しました。

この記事が皆様の Kubernetes プロジェクトに役立つことを願っています。ご質問やご提案がございましたら、GitHub パブリックロードマップリポジトリやソーシャルでのコメントなどにてぜひお聞かせください。

翻訳文寄稿者について

いんだくたー

CNCF アンバサダーとして主に Kubernetes の動向を発信したり、カンファレンスの登壇などを行っています。AWS のサービスでは Amazon EKS とそのエコシステムに注目しており、ユーザー目線での活用法や新機能に対する考え方などを発信しています。Amazon EKS の好きな機能はマネージド型ノードグループ (Bottlerocket) です。Twitter: @_inductor_

Cookie の設定を選択する

Amazon Web Services ブログ

Amazon EKS クラスターの EBS ボリュームを gp2 から gp3 に移行する

前提条件

移行シナリオ

お掃除

結論

翻訳文寄稿者について

いんだくたー

お役立ちリンク

フォローお願いいたします