Amazon EKS クラスターの Kubernetes バージョンの更新

Amazon EKS で利用可能な新しい Kubernetes バージョンがある場合には、Amazon EKS クラスターを最新バージョンに更新できます。

重要

新しい Kubernetes バージョンに更新する前に、「Amazon EKS Kubernetes のバージョン」で情報を確認し、さらに本トピック内の更新手順でも確認することをお勧めします。バージョン 1.22 に更新する場合、更新前に Kubernetes バージョン 1.22 の前提条件 にリストされている変更をクラスターに適用する必要があります。

新しい Kubernetes バージョンでは、大幅な変更が加えられている場合があります。このため、本稼働用クラスターで更新を行う前に、新しいバージョンの Kubernetes に対するアプリケーションの動作をテストしておくことをお勧めします。この際は、継続的な統合ワークフローを構築し、新しい Kubernetes バージョンに移行する前にアプリケーションの動作をテストします。

更新プロセスに含まれている Amazon EKS が、更新された Kubernetes バージョンを使用しながら新しい API サーバーノードを起動することで、既存のバージョンを置き換えます。Amazon EKS は、これらの新しいノードで、ネットワークトラフィックの標準インフラストラクチャと準備状況に関するヘルスチェックを実行し、想定どおりに動作していることを確認します。これらのヘルスチェックのいずれかが失敗すると、Amazon EKS はインフラストラクチャのデプロイを元に戻します。クラスターは前の Kubernetes バージョンのままになります。この際も、実行中のアプリケーションは影響を受けません。また、クラスターが不確定または回復不可能な状態のままになることもありません。Amazon EKS は定期的にすべてのマネージド型クラスターをバックアップします。さらに、必要に応じてクラスターを復元するメカニズムも存在します。Kubernetes インフラストラクチャの管理プロセスは、継続的に評価、改善されています。

クラスターをアップグレードする際、Amazon EKS には、クラスターの作成時に指定したサブネット内に、最大で 5 つの使用可能な IP アドレスが必要となります。Amazon EKS は、指定したサブネットのいずれかに、新しいクラスターの Elastic Network Interface (ネットワークインターフェイス) を作成します。新しいネットワークインターフェイスは、既存のネットワークインターフェイスがあるのとはｂサブネット内に作成される場合があります。ですので、クラスター作成時に指定したサブネットのいずれでも必要なクラスターとの通信が許可されるよう、セキュリティグループルールを設定します。クラスターの作成時に指定したサブネットのいずれかが存在しない、使用できる十分な IP アドレスがない、または必要なクラスターとの通信を許可するセキュリティグループルールがない場合、更新が失敗する可能性があります。

注記

Amazon EKS では、可用性の高いコントロールプレーンが実行されていますが、更新時にはサービスが短時間中断する可能性はあります。例えば、API サーバーを終了し、Kubernetes の新しいバージョンを実行している新しい API サーバーに置き換え、API サーバーへの接続を試みたとします。このとき、API 呼び出しエラーや接続の問題が発生する可能性があります。この場合は、成功するまで API オペレーションを繰り返し実行します。

Amazon EKS クラスターに必要な Kubernetes バージョンを更新する

クラスターに必要な Kubernetes のバージョンの更新方法

1. クラスターコントロールプレーンの Kubernetes バージョンと、ノードの Kubernetes バージョンを比較します。

   • クラスターコントロールプレーンの Kubernetes バージョンを取得します。

     kubectl version --short
     

   • ノードの Kubernetes バージョンを取得します。このコマンドでは、セルフマネージド型およびマネージド型の Amazon EC2 および Fargate ノードがすべて表示されます。各 Fargate pod は、独自のノードとしてリストされます。

     kubectl get nodes
     

   コントロールプレーンを新しい Kubernetes バージョンに更新する前に、クラスター内のマネージド型ノードと Fargate ノードの双方の Kubernetes マイナーバージョンが、コントロールプレーンのバージョンと同じであることを確認してください。例えば、コントロールプレーンがバージョン 1.25 を実行し、かつノードの 1 つがバージョン 1.24 を実行している場合、コントロールプレーンを 1.26 に更新する前に、ノードをバージョン 1.25 に更新する必要があります。また、コントロールプレーンを更新する前に、セルフマネージド型ノードをコントロールプレーンと同じバージョンに更新することをお勧めします。詳細については、マネージド型ノードグループの更新 および セルフマネージド型ノードの更新 を参照してください。Fargate ノードのマイナーバージョンがコントロールプレーンのバージョンよりも古い場合、まずノードの示す pod を削除します。次に、コントロールプレーンを更新します。残りの pods は、再デプロイ後に新しいバージョンに更新されます。

2. デフォルトでは、Amazon EKS クラスターで pod セキュリティポリシーのアドミッションコントローラーが有効化されています。クラスターを更新する前に、適切な pod セキュリティポリシーが指定されていることを確認してください。これは、潜在的なセキュリティの問題を回避するためのものです。kubectl get psp eks.privileged コマンドを使用して、デフォルトのポリシーを確認できます。

   kubectl get psp eks.privileged
   

   以下のエラーが表示された場合は、先に進む前に「デフォルトの pod セキュリティポリシー」を確認してください。

   Error from server (NotFound): podsecuritypolicies.extensions "eks.privileged" not found

3. 最初にクラスターにデプロイした Kubernetes バージョンが Kubernetes 1.18 以降だった場合、このステップをスキップしてください。

   CoreDNS マニフェストから、廃止された単語を削除する必要がある場合があります。

   1. CoreDNS マニフェストに、upstream というワードのみの行があるかどうかを確認します。

      kubectl get configmap coredns -n kube-system -o jsonpath='{$.data.Corefile}' | grep upstream
      

      出力が返されない場合は、マニフェストにこの行は含まれていません。この場合は、次のステップに進みます。upstream というワードが返された場合は、その行を削除します。

   2. ConfigMap ファイルで、ファイルの先頭付近にある、upstream のみを含む行を削除します。このファイル内の他の部分は変更しないでください。行を削除したら、変更を保存します。

      kubectl edit configmap coredns -n kube-system -o yaml
      

4. eksctl、AWS Management Console、またはAWS CLI を使用してクラスターを更新します。

   重要

   • バージョン 1.22 に更新する場合、更新前に Kubernetes バージョン 1.22 の前提条件 にリストされている変更をクラスターに適用する必要があります。

   • バージョン 1.23 に更新してクラスターで Amazon EBS ボリュームを使用する場合は、ワークロードの中断を避けるために、クラスターをバージョン 1.23 に更新する前にクラスターに Amazon EBS CSI ドライバーをインストールする必要があります。詳細については、Kubernetes 1.23 および Amazon EBS CSI ドライバー を参照してください。

   • Amazon EKS は可用性の高いコントロールプレーンを実行しているため、一回に更新できるのはマイナーバージョン 1 つのみです。この要件の詳細については、「Kubernetes Version and Version Skew Support Policy」(Kubernetes のバージョンおよびバージョンスキューのサポートポリシー) を参照してください。現在のクラスターバージョンが 1.24 であり、1.26 に更新することを仮定します。最初にバージョン 1.24 クラスターをバージョン 1.25 に更新し、次にバージョン 1.25 クラスターをバージョン 1.26 に更新する必要があります。

   • 更新を行う前に、マネージド型および Fargate ノードの kubelet が コントロールプレーンと同じ Kubernetes バージョンであることを確認してください。セルフマネージド型ノードは、コントロールプレーンと同じバージョンにしておくことをお勧めします。コントロールプレーンの現在のバージョンより最大 1 つ前のものにすることも可能です。

   • クラスターが 1.8.0 より前のバージョンの Amazon VPC CNI plugin for Kubernetes で設定されている場合、クラスターをバージョン 1.21 以降に更新する前に、プラグインを最新バージョンに更新することをお勧めします。プラグインのアップデートについては、「」を参照してくださいAmazon VPC CNI plugin for Kubernetes Amazon EKS アドオンの使用。

   • クラスターをバージョン 1.25 以降に更新しようとしており、クラスターに AWS Load Balancer Controller をデプロイしている場合は、クラスターのバージョンを 1.25 に更新する前に、コントローラーをバージョン 2.4.7 以降に更新してください。詳細については、Kubernetes 1.25 のリリースノートを参照してください。

   eksctl

   この手順には、eksctl バージョン 0.138.0 以降が必要です。お使いのバージョンは、以下のコマンドを使用して確認できます。

   eksctl version
   

   eksctl のインストールまたは更新の手順については、「eksctl のインストールまたは更新」を参照しください。

   Amazon EKS コントロールプレーンの Kubernetes バージョンを更新します。my-cluster をクラスター名に置き換えます。1.26 を、クラスターの更新対象となる Amazon EKS がサポートするバージョン番号に置き換えてください。サポートされているバージョン番号のリストについては、「Amazon EKS Kubernetes のバージョン」を参照してください。

   eksctl upgrade cluster --name my-cluster --version 1.26 --approve
   

   この更新は完了までに数分かかることがあります。

   AWS Management Console

   1. https://console.aws.amazon.com/eks/home#/clusters で Amazon EKS コンソールを開きます。

   2. 更新する Amazon EKS クラスター名を選択し、[クラスターバージョンの更新] を選択します。

   3. [Kubernetes version] (Kubernetes バージョン) で、バージョンを選択してクラスターを更新し、[Update] (更新) を選択します。

   4. [Cluster name] (クラスター名) にクラスター名を入力し、[Confirm] (確認) を選択します。

      この更新は完了までに数分かかることがあります。

   AWS CLI

   1. 次の AWS CLI コマンドを使用して、Amazon EKS クラスターを更新します。example values を自分の値に置き換えます。1.26 を、クラスターの更新対象となる Amazon EKS がサポートするバージョン番号に置き換えてください。サポートされているバージョン番号のリストについては、「Amazon EKS Kubernetes のバージョン」を参照してください。

      aws eks update-cluster-version --region region-code --name my-cluster --kubernetes-version 1.26
      

      出力例を次に示します。

      {
          "update": {
              "id": "b5f0ba18-9a87-4450-b5a0-825e6e84496f",
              "status": "InProgress",
              "type": "VersionUpdate",
              "params": [
                  {
                      "type": "Version",
                      "value": "1.26"
                  },
                  {
                      "type": "PlatformVersion",
                      "value": "eks.1"
                  }
              ],
      ...
              "errors": []
          }
      }

   2. クラスター更新のステータスをモニタリングするには、次のコマンドを使用します。前のコマンドから返されたクラスター名と更新 ID を使用します。Successful ステータスが表示されると、更新は完了です。この更新は完了までに数分かかることがあります。

      aws eks describe-update --region region-code --name my-cluster --update-id b5f0ba18-9a87-4450-b5a0-825e6e84496f
      

      出力例を次に示します。

      {
          "update": {
              "id": "b5f0ba18-9a87-4450-b5a0-825e6e84496f",
              "status": "Successful",
              "type": "VersionUpdate",
              "params": [
                  {
                      "type": "Version",
                      "value": "1.26"
                  },
                  {
                      "type": "PlatformVersion",
                      "value": "eks.1"
                  }
              ],
      ...
              "errors": []
          }
      }

5. クラスターの更新が完了したら、更新したクラスターでの Kubernetes と同じマイナーバージョンに、ノードを更新する必要があります。詳細については、セルフマネージド型ノードの更新 および マネージド型ノードグループの更新 を参照してください。Fargate で起動される新しい pods であれば、クラスターのバージョンと一致する kubelet バージョンを持っています。それまでに存在していた Fargate pods は変更されていません。

6. (オプション) クラスターを更新する前に、そのクラスターに Kubernetes Cluster Autoscaler をデプロイしてある場合は、更新後の Kubernetes のメジャーバージョンとマイナーバージョンに一致するように、Cluster Autoscaler を最新バージョンに更新します。

   1. ウェブブラウザで Cluster Autoscaler リリース ページを開き、クラスターの Kubernetes メジャーバージョンとマイナーバージョンに一致する最新の Cluster Autoscaler バージョンを見つけます。例えば、クラスターの Kubernetes バージョンが 1.26 である場合、1.26 で始まる最新の Cluster Autoscaler リリースを見つけます。次のステップで使用するため、そのリリースのセマンティックバージョン番号 (例: 1.26.n) を書き留めておきます。

   2. 次のコマンドを使用して、Cluster Autoscaler イメージタグを、前のステップで書き留めたバージョンに設定します。必要に応じて、1.26.n を独自の値に置き換えます。

      kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=registry.k8s.io/autoscaling/cluster-autoscaler:v1.26.n
      

7. (GPU ノードを含むクラスターのみ) クラスターに GPU 対応のノードグループ (p3.2xlarge など) がある場合は、次のコマンドを使用して、クラスターの NVIDIA device plugin for Kubernetes DaemonSet を更新する必要があります。

   kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.9.0/nvidia-device-plugin.yml
   

8. Amazon VPC CNI plugin for Kubernetes、CoreDNS、および kube-proxy アドオンを更新する クラスターをバージョン 1.21 以降に更新した場合、アドオンをサービスアカウントトークンにリストされている最小バージョンに更新することをお勧めします。

   • Amazon EKS アドオンを使用している場合は、Amazon EKS コンソールで [Clusters] (クラスター) をクリックし、左のナビゲーションペインで更新したクラスター名を選択します。通知がコンソールに表示されます。更新可能なアドオンごとに、新しいバージョンが利用可能であることが通知されます。アドオンを更新するには、[Add-ons] (アドオン) タブを選択します。更新があるアドオンが表示されているボックスで [今すぐ更新] を選択し、使用可能なバージョンを選択してから、[更新] を選択します。

   • 別の方法として、AWS CLI または eksctl を使用してアドオンを更新することもできます。詳細については、「アドオンの更新」を参照してください。

9. 必要に応じて、kubectl のバージョンを更新します。Amazon EKS クラスターコントロールプレーンとのマイナーバージョンの相違が 1 つ以内である kubectl バージョンを使用する必要があります。例えば、1.25 kubectl クライアントは Kubernetes、1.24、1.25 および 1.26 クラスターで動作します。現在インストールされているバージョンは、次のコマンドで確認できます。

   kubectl version --short --client
   

Kubernetes バージョン 1.22 の前提条件

いくつかの非推奨のベータ版 API (v1beta1) がバージョン 1.22 で削除され、同じ API の GA (v1) バージョンに置き換えられました。Kubernetes バージョン 1.22 の「API and Feature removal blog」(API と機能の削除についてのブログ)、および非推奨の「API migration guide」(API 移行についてのガイド) で述べられているとおり、クラスターをバージョン 1.22 に更新する前に、次のデプロイ済みリソースに対して API を変更する必要があります。

クラスターを Kubernetes バージョン 1.22 に更新する前に、必ず以下を実行してください。

• 新しい API を参照するよう YAML マニフェストファイルとクライアントを変更します。

• 新しい API を呼び出すようにカスタムインテグレーションとコントローラーを更新します。

• サードパーティーのツールはどれも最新バージョンを使用していることを確認してください。これらのツールには、イングレスコントローラー、サービスメッシュコントローラー、継続的デリバリーシステム、新しい API を呼び出すその他のツールが含まれます。クラスターで非推奨の API が使用されているかどうかを確認するには、コントロールプレーンの監査ログを有効にし、イベントフィルターとして v1beta を指定します。いくつかのバージョンの Kubernetes で代替 API が利用できます。

• 現在クラスターに AWS ロードバランサーコントローラーがデプロイされている場合、クラスターを Kubernetes バージョン 1.22 に更新する前に、これをバージョン 2.4.1 に更新する必要があります。

• クラスターをバージョン 1.22 に更新する場合、既存の永続的なオブジェクトへは新しい API を使用してアクセスできます。ただし、これらの新しい API を使用するには、マニフェストを移行してクライアントを更新する必要があります。クラスターを更新すると、潜在的なワークロードの障害を防止できます。詳細については、「Kubernetes API グループとバージョニング」を参照してください。例えば、Amazon EKS クラスターを 1.20 以前のバージョンで作成した場合、クラスターに次のオブジェクトが表示されます。

  
  +--------------------------------------------+------------------------------------+------------------------------------------+
  |                     Kind                   |             Name                   |      API Version                         |
  +---------------------------------------------------------------+-------------------------------+----------------------------+
  | CustomResourceDefinition                   |  eniconfigs.crd.k8s.amazonaws.com  |  apiextensions.k8s.io/v1beta1            |
  | MutatingWebhookConfiguration               |  pod-identity-webhook              |  admissionregistration.k8s.io/v1beta1    |
  |  ...                                       |  ...                               |  ...                                     |
  +--------------------------------------------+------------------------------------+------------------------------------------+

  クラスターがバージョン 1.22 に更新された後、Kubernetes が自動的に v1 API バージョンに提供するため、これらのリソースに何もする必要はありません。サードパーティツールがこれらのリソースを 1.22 にアップグレード後の問題としてフラグ付けしないようにするには、以下の例を使用してリソースをクラスターに再適用できます。

  kubectl get crd eniconfigs.crd.k8s.amazonaws.com -o json | kubectl replace -f -
  kubectl get mutatingwebhookconfiguration pod-identity-webhook -o json | kubectl replace -f -

Kubernetes バージョン 1.22 では、以下のベータ版 API はサポートされません。以下の情報に基づいて、マニフェストと API クライアントを移行します。

リソース	ベータのバージョン	GA のバージョン	メモ
ValidatingWebhookConfiguration MutatingWebhookConfiguration	admissionregistration.k8s.io/v1beta1	admissionregistration.k8s.io/v1	webhooks[*].failurePolicy のデフォルトは v1 で Ignore から Fail へ変更されました。 webhooks[*].matchPolicy のデフォルトは v1 で Exact から Equivalent へ変更されました。 webhooks[*].timeoutSeconds のデフォルトは v1 で 30s から 10s へ変更されました。 webhooks[*].sideEffects のデフォルト値は削除され、v1 ではフィールドが必須になり、None および NoneOnDryRun のみが許可されます。 webhooks[*].admissionReviewVersions のデフォルト値は削除され、v1 ではフィールドが必須になりました (AdmissionReview でサポートされているバージョンは v1 および v1beta1 です)。 webhooks[*].name は、admissionregistration.k8s.io/v1 によって作成されたオブジェクトのリスト内で一意にする必要があります。
CustomResourceDefinition	apiextensions.k8s.io/v1beta1	apiextensions.k8s.io/v1	spec.scope のデフォルトは Namespaced ではなくなり、明示的に指定する必要があります。 spec.version は v1 で削除されました。代わりに spec.versions を使用します。 spec.validation は v1 で削除されました。代わりに spec.versions[*].schema を使用します。 spec.subresources は v1 で削除されました。代わりに spec.versions[*].subresources を使用します。 spec.additionalPrinterColumns は v1 で削除されました。代わりに spec.versions[*].additionalPrinterColumns を使用します。 v1 で、spec.conversion.webhookClientConfig は spec.conversion.webhook.clientConfig に移動されました。 v1 で、spec.conversion.conversionReviewVersions は spec.conversion.webhook.conversionReviewVersions に移動されました。 spec.versions[*].schema.openAPIV3Schema は、v1 CustomResourceDefinition オブジェクトの作成時に必須になり、構造スキーマにする必要があります。 spec.preserveUnknownFields: true は v1 CustomResourceDefinition オブジェクトの作成時に許可されません。スキーマ定義内で x-kubernetes-preserve-unknown-fields: true として指定する必要があります。 v1 では、additionalPrinterColumns 項目の JSONPath フィールド名が jsonPath に変更されました (修正内容 #66531)。
APIService	apiregistration.k8s.io/v1beta1	apiregistration.k8s.io/v1	なし
TokenReview	authentication.k8s.io/v1beta1	authentication.k8s.io/v1	なし
SubjectAccessReview LocalSubjectAccessReview SelfSubjectAccessReview	authorization.k8s.io/v1beta1	authorization.k8s.io/v1	spec.group は spec.groups に名前が変更されました
CertificateSigningRequest	certificates.k8s.io/v1beta1	certificates.k8s.io/v1	証明書をリクエストする API クライアントの場合: spec.SignerName が必須になりました (既知の Kubernetes 署名者を参照)。kubernetes.io/legacy-unknown に対するリクエストは、certificates.k8s.io/v1 API を介して作成することはできません。 spec.usages は必須になりました。重複する値を含めることはできず、既知の使用方法のみを含める必要があります 証明書を承認または署名する API クライアントの場合: status.conditions に重複するタイプを含めることはできません status.conditions[*].status が必須になりました status.certificate は PEM でエンコードされ、CERTIFICATE ブロックのみを含める必要があります
Lease	coordination.k8s.io/v1beta1	coordination.k8s.io/v1	なし
Ingress	extensions/v1beta1 networking.k8s.io/v1beta1	networking.k8s.io/v1	spec.backend は spec.defaultBackend に名前が変更されました バックエンドの serviceName フィールドは、 service.name に名前が変更されました 数値バックエンドの servicePort フィールドは、service.port.number に名前が変更されました 文字列バックエンドの servicePort フィールドは、service.port.name に名前が変更されました pathType は、指定されたパスごとに必須になりました。オプションは Prefix、Exact、ImplementationSpecific です。未定義の v1beta1 動作と一致させるには、ImplementationSpecific を使用します
IngressClass	networking.k8s.io/v1beta1	networking.k8s.io/v1	なし
RBAC	rbac.authorization.k8s.io/v1beta1	rbac.authorization.k8s.io/v1	なし
PriorityClass	scheduling.k8s.io/v1beta1	scheduling.k8s.io/v1	なし
CSIDriver CSINode StorageClass VolumeAttachment	storage.k8s.io/v1beta1	storage.k8s.io/v1	なし

API の削除の詳細については、「Deprecated API migration guide」(廃止された API の移行ガイド) を参照してください。