クラスターの更新 - Amazon EKS
Kubernetes バージョンの更新アドオンの設定Amazon EKS

「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」

クラスターの更新

既存のクラスターを新しい Kubernetes バージョンに更新するか、クラスターにマネージドアドオンを設定できます。

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

新しい Kubernetes バージョンが Amazon EKS で利用できるようになると、クラスターを最新バージョンに更新することができます。

重要

新しい Kubernetes バージョンに更新する前に、「Amazon EKS Kubernetes バージョン」とこのトピックの更新ステップの情報を確認することをお勧めします。

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

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

クラスターをアップグレードするには、クラスターの作成時に指定したサブネットから 2～3 個の空き IP アドレスが Amazon EKS に必要です。これらのサブネットに使用可能な IP アドレスがない場合、アップグレードが失敗することがあります。さらに、クラスターの作成時に指定されたいずれかのサブネットやセキュリティグループが削除された場合、クラスターのアップグレードが失敗することがあります。

注記

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

Amazon EKS は、クラスターの更新時に Kubernetes アドオンを変更しません。クラスターの更新後、更新後の新しいバージョンの Kubernetes 用に、アドオンを次の表に記載のバージョンに更新することをお勧めします。これを実行するためのステップは、更新手順に含まれています。

Kubernetes バージョン 1.18 1.17 1.16 1.15
Amazon VPC CNI プラグイン 1.7.5 1.7.5 1.7.5 1.7.5
DNS (CoreDNS) 1.7.0 1.6.6 1.6.6 1.6.6
KubeProxy 1.18.9 1.17.12 1.16.15 1.15.12

上記の表に記載されていない追加のアドオンをクラスターに使用する場合は、クラスターの更新後にそれらを最新の互換バージョンに更新します。

既存のクラスターの更新

クラスターおよび Kubernetes アドオンを更新します。

既存のクラスターを更新するには

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

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

      kubectl version --short

    • 以下のコマンドで、Kubernetes バージョンのノードを取得します。

      kubectl get nodes

    ノードがコントロールプレーンよりも古い複数の Kubernetes マイナーバージョンの場合は、クラスターの Kubernetes バージョンを更新する前に、ノードを新しい Kubernetes マイナーバージョンにアップグレードする必要があります。詳細については、Kubernetes ドキュメントの「Kubernetes のバージョンおよびバージョンスキューのサポートポリシー」を参照してください。

    クラスターを更新する前に、ノードをクラスターの現在の更新前の Kubernetes マイナーバージョンに更新することをお勧めします。コントロールプレーンより新しい Kubernetes バージョンをノードで実行しないでください。たとえば、コントロールプレーンでバージョン 1.17 を実行し、ノードでバージョン 1.15 を実行している場合は、クラスターの Kubernetes バージョンを 1.18 に更新する前に、ノードをバージョン 1.16 または 1.17 (推奨) に更新します。詳細については、セルフマネージド型ノードの更新 を参照してください。

  2. ポッドセキュリティポリシーのアドミッションコントローラーは、Kubernetes バージョン 1.13 以降を実行している Amazon EKS クラスターに対して有効になります。クラスターを Kubernetes バージョン 1.13 以降にアップグレードする場合は、問題を回避するために、適切なポッドセキュリティポリシーが設定されていることを確認してから、その更新を行います。以下のコマンドを使用して、デフォルトのポリシーを表示できます。 

    kubectl get psp eks.privileged

    以下のエラーが表示された場合は、先に進む前に「デフォルトのポッドセキュリティポリシーをインストールまたは復元するには」を参照してください。 

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

  3. クラスターを最初に Kubernetes 1.17 以前のバージョンにデプロイした場合、廃止された用語を CoreDNS マニフェストから削除する必要がある場合があります。

    1. マニフェストに行があるかどうかを確認します。CoreDNS

      kubectl get configmap coredns -n kube-system -o yaml |grep upstream

      出力が返されない場合、マニフェストに行はなく、次の手順に進んでクラスターを更新できます。出力が返された場合は、行を削除する必要があります。

    2. configmap を編集し、ファイルに upstream という単語が含まれている行を削除します。ファイル内の他のものは変更しないでください。行が削除されたら、変更を保存します。 

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

  4. 、eksctl、または AWS マネジメントコンソール を使用して、クラスターを更新します。AWS CLI

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

      eksctl version

      eksctl のインストールまたはアップグレードの詳細については、eksctl のインストールまたはアップグレード を参照してください。

      注記

      この手順は、eksctl で作成されたクラスターに対してのみ機能します。

      以下のコマンドを使用して、Amazon EKS クラスターの Kubernetes バージョンを、現在のバージョンより 1 マイナーバージョン後のバージョンに更新します。をクラスター名に置き換えます。<dev>Amazon EKS は可用性の高いコントロールプレーンを実行しているため、一度に更新できるのは 1 マイナーバージョンのみです。この背後にある論理的根拠については、「Kubernetes Version and Version Skew Support Policy (Kubernetes のバージョンおよびバージョンスキューのサポートポリシー)」を参照してください。

      重要

      1.16 に更新するには、事前にデプロイ済みのリソースの一部を更新する必要があります。詳細については、「Kubernetes 1.16 にアップグレードにするための前提条件」を参照してください。ポッドのいずれかの kubelet マイナーバージョンが 1.16 より前のものである場合、クラスターを 1.16 から 1.17 にアップグレードすると失敗します。AWS Fargateクラスターを 1.16 から 1.17 にアップグレードする前に、kubelet が 1.16 になるように Fargate ポッドをリサイクルする必要があります。 

      eksctl upgrade cluster --name <dev> --approve

      このプロセスが完了するまでに数分かかります。

    • AWS マネジメントコンソール

      1. Open the Amazon EKS console at https://console.aws.amazon.com/eks/home#/clusters.

      2. 更新するクラスターの名前を選択し、[Update cluster version (クラスターバージョンの更新)] を選択します。

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

        重要

        • いずれかの AWS Fargate ポッドに 1.16 より前の kubelet マイナーバージョンがある場合、1.16 から 1.17 へのクラスターのアップグレードは失敗します。クラスターを 1.16 から 1.17 にアップグレードする場合、クラスターを 1.17 にアップグレードする前に、Fargate ポッドをリサイクルし、kubelet ポッドを 1.16 にする必要があります。

        • 1.16 に更新するには、事前にデプロイ済みのリソースの一部を更新する必要があります。詳細については、「Kubernetes 1.16 にアップグレードにするための前提条件」を参照してください。

        重要

        Amazon EKS は可用性の高いコントロールプレーンを実行しているため、一度に更新できるのは 1 マイナーバージョンのみです。この背後にある論理的根拠については、「Kubernetes Version and Version Skew Support Policy (Kubernetes のバージョンおよびバージョンスキューのサポートポリシー)」を参照してください。したがって、現在のバージョンが 1.16 で、1.18 にアップグレードする場合は、最初にクラスターを 1.17 にアップグレードし、その後 1.17 から 1.18 にアップグレードする必要があります。1.16 から 1.18 に直接アップデートしようとすると、バージョン更新コマンドからエラーがスローされます。

      4. [クラスター名] にクラスターの名前を入力し、[確認] を選択します。

        注記

        クラスターの更新は、数分で終了します。

    • AWS CLI

      1. 次の AWS CLI コマンドを使用して、クラスターを作成します。クラスター名と目的の Kubernetes マイナーバージョンを置き換えます。

        重要

        1.16 に更新するには、事前にデプロイ済みのリソースの一部を更新する必要があります。詳細については、「Kubernetes 1.16 にアップグレードにするための前提条件」を参照してください。ポッドのいずれかの kubelet マイナーバージョンが 1.16 より前のものである場合、クラスターを 1.16 から 1.17 にアップグレードすると失敗します。AWS Fargateクラスターを 1.16 から 1.17 にアップグレードする前に、kubelet が 1.16 になるように Fargate ポッドをリサイクルする必要があります。

        重要

        Amazon EKS は可用性の高いコントロールプレーンを実行しているため、一度に更新できるのは 1 マイナーバージョンのみです。この背後にある論理的根拠については、「Kubernetes Version and Version Skew Support Policy (Kubernetes のバージョンおよびバージョンスキューのサポートポリシー)」を参照してください。したがって、現在のバージョンが 1.16 で、1.18 にアップグレードする場合は、最初にクラスターを 1.17 にアップグレードし、その後 1.17 から 1.18 にアップグレードする必要があります。1.16 から 1.18 に直接アップデートしようとすると、バージョン更新コマンドからエラーがスローされます。 

        aws eks --region <region-code> update-cluster-version --name <my-cluster> --kubernetes-version <1.18>

        出力は次のとおりです。

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

      2. 次のコマンドを使用して、クラスター更新のステータスをモニタリングします。前のコマンドで返されたクラスター名と更新 ID を使用します。ステータスが Successful となったら、更新は完了です。

        注記

        クラスターの更新は、数分で終了します。

        aws eks --region <region-code> describe-update --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.18"
            },
            {
                "type": "PlatformVersion",
                "value": "eks.1"
            }
        ],
...
        "errors": []
    }
}

  5. クラスターのリージョンと現在の Kubernetes バージョン (この例では 1.18.9) に対応するイメージを使用するには、kube-proxy デーモンセットにパッチを適用します。

    Kubernetes バージョン 1.18 1.17 1.16 1.15
    KubeProxy 1.18.9 1.17.12 1.16.15 1.15.12

    1. まず、現在の kube-proxy イメージを取得します。 

      kubectl get daemonset kube-proxy --namespace kube-system -o=jsonpath='{$.spec.template.spec.containers[:1].image}'

    2. kube-proxy を推奨バージョンに更新します。これには、前のステップの出力を取得し、バージョンタグを、クラスターに対して推奨される kube-proxy バージョンに置き換えます。 

      kubectl set image daemonset.apps/kube-proxy \
    -n kube-system \
    kube-proxy=<602401143452.dkr.ecr.us-west-2.amazonaws.com>/eks/kube-proxy:v<1.18.9>-eksbuild.1

      アカウント ID とリージョンは、上記の例と異なる場合があります。

    3. (オプション) 同じクラスターで x86 ノードと Arm ノードを使用していて、そのクラスターが 2020 年 8 月 17 日より前にデプロイされていた場合。次に、次のコマンドを使用して kube-proxy マニフェストを編集し、複数のハードウェアアーキテクチャのノードセレクタを含めます。これは 1 回限りのオペレーションです。マニフェストにセレクタを追加した後、アップグレードのたびに行う必要はありません。クラスターが 2020 年 8 月 17 日以降にデプロイされた場合、kube-proxy はすでにマルチアーキテクチャに対応しています。 

      kubectl edit -n kube-system daemonset/kube-proxy

      次のノードセレクタをエディタのファイルに追加し、ファイルを保存します。このテキストをエディタに含める場所の例については、 の CNI マニフェストGitHubファイルを参照してください。 これにより、Kubernetes がノードのハードウェアアーキテクチャに基づいて正しいハードウェアイメージをプルできるようになります。 

      - key: "beta.kubernetes.io/arch"
                    operator: In
                    values:
                      - amd64
                      - arm64

  6. クラスターの DNS プロバイダーを確認します。Kubernetes バージョン 1.10 で作成されたクラスターは、デフォルトの DNS およびサービス検出プロバイダーとして kube-dns に付属していました。1.10 クラスターを新しいバージョンに更新し、DNS とサービス検出に CoreDNS を使用する場合は、CoreDNS をインストールして、kube-dns を削除する必要があります。

    クラスターですでに CoreDNS が実行されているかどうかを確認するには、次のコマンドを使用します。

    kubectl get pod -n kube-system -l k8s-app=kube-dns

    出力のポッド名に coredns と示されている場合、CoreDNS はすでにクラスターで実行されています。それ以外の場合は、「CoreDNS のインストールまたはアップグレード」を参照してクラスターに CoreDNS をインストールし、推奨バージョンに更新します。次に、ここに戻ってステップ 7～8 をスキップします。

  7. クラスターの coredns デプロイの現在のバージョンを確認します。 

    kubectl describe deployment coredns --namespace kube-system | grep Image | cut -d "/" -f 3

    出力:

    coredns:v<1.1.3>

    対応する Kubernetes バージョンに対して推奨される coredns のバージョンは以下のとおりです。

    Kubernetes バージョン 1.18 1.17 1.16 1.15
    CoreDNS 1.7.0 1.6.6 1.6.6 1.6.6

  8. coredns の現在のバージョンが 1.5.0 以降かつ推奨バージョンより前の場合、このステップをスキップしてください。現在のバージョンが 1.5.0 より前の場合、proxy プラグインではなく forward プラグインを使用するように coredns の設定マップを変更する必要があります。

    1. 次のコマンドを使用して設定マップを開きます。

      kubectl edit configmap coredns -n kube-system

    2. 次の行の proxy を forward に置き換えます。ファイルを保存し、エディタを終了します。 

      proxy . /etc/resolv.conf

  9. 現在の coredns イメージを取得します。 

    kubectl get deployment coredns --namespace kube-system -o=jsonpath='{$.spec.template.spec.containers[:1].image}'

  10. coredns を推奨バージョンに更新します。これには、前のステップの出力を取得し、<1.7.0> (<> を含む) を、クラスターに対して推奨される coredns バージョンに置き換えます。 

    kubectl set image --namespace kube-system deployment.apps/coredns \
            coredns=<602401143452.dkr.ecr.us-west-2.amazonaws.com>/eks/coredns:v<1.7.0>-eksbuild.1

  11. (オプション) 同じクラスターで x86 ノードと Arm ノードを使用していて、クラスターが 2020 年 8 月 17 日より前にデプロイされている場合は、次のコマンドを使用して coredns マニフェストを編集し、複数のハードウェアアーキテクチャのノードセレクタを含めます。これは 1 回限りのオペレーションです。マニフェストにセレクタを追加した後、アップグレードのたびに行う必要はありません。クラスターが 2020 年 8 月 17 日以降にデプロイされた場合、coredns はすでにマルチアーキテクチャに対応しています。 

    kubectl edit -n kube-system deployment/coredns

    次のノードセレクタをエディタのファイルに追加し、ファイルを保存します。このテキストをエディタに含める場所の例については、 の CNI マニフェストGitHubファイルを参照してください。 

    - key: "beta.kubernetes.io/arch"
                    operator: In
                    values:
                      - amd64
                      - arm64

  12. クラスターの Amazon VPC CNI Plugin for Kubernetes のバージョンを確認します。次のコマンドを使用して、クラスターの CNI バージョンを出力します。

    kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2

    出力は次のとおりです。

    amazon-k8s-cni:<1.6.3>

    CNI が 1.7.5 より前のバージョンである場合は、以下のうち適切なコマンドを使用して、CNI バージョンを最新の推奨バージョンに更新します。

    • 米国西部 (オレゴン) (us-west-2) 

      kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/v1.7.5/config/v1.7/aws-k8s-cni.yaml

    • 中国 (北京) (cn-north-1) または 中国 (寧夏) (cn-northwest-1) 

      kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/v1.7.5/config/v1.7/aws-k8s-cni-cn.yaml

    • AWS GovCloud (米国東部) (us-gov-east-1) 

      kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/v1.7.5/config/v1.7/aws-k8s-cni-us-gov-east-1.yaml

    • AWS GovCloud (US-West) (us-gov-west-1) 

      kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/v1.7.5/config/v1.7/aws-k8s-cni-us-gov-west-1.yaml

    • その他のすべてのリージョンの場合

      • マニフェストファイルをダウンロードします。

        curl -o aws-k8s-cni.yaml https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/v1.7.5/config/v1.7/aws-k8s-cni.yaml

      • 以下のコマンドの <region-code> をクラスターがあるリージョンに置き換えます。次に、変更されたコマンドを実行してファイル内のリージョンコードを置き換えます (現在は us-west-2)。 

        sed -i -e 's/us-west-2/<region-code>/' aws-k8s-cni.yaml

      • 変更したマニフェストファイルをクラスターに適用します。

        kubectl apply -f aws-k8s-cni.yaml

  13. (オプション) クラスターのアップグレード前にクラスターに Kubernetes Cluster Autoscaler をデプロイした場合は、アップグレードした Kubernetes メジャーバージョンとマイナーバージョンに一致する最新バージョンに Cluster Autoscaler を更新します。

    重要

    Kubernetes Cluster Autoscaler を Arm で使用することはできません。

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

    2. 次のコマンドを使用して、Cluster Autoscaler イメージタグを、前のステップで書き留めたバージョンに設定します。<1.18.n> を独自の値に置き換えます。は、us または <asia> に置き換えることができます。<eu>

      kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=<us>.gcr.io/k8s-artifacts-prod/autoscaling/cluster-autoscaler:v<1.18.n>
      注記

      必要とするバージョンによっては、以前のアドレスを gcr.io/google-containers/cluster-autoscaler:v1.<n.n> に変更する必要があります。イメージアドレスは、リリースページに一覧表示されています。

  14. (GPU ノードのみを持つクラスター) クラスターに GPU をサポートしているノードグループ (p3.2xlarge など) がある場合は、以下のコマンドを使用して、クラスターの NVIDIA device plugin for Kubernetes DaemonSet を更新する必要があります。 

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

  15. クラスターの更新が完了したら、更新されたクラスターの同じ Kubernetes バージョンにノードを更新します。詳細については、「セルフマネージド型ノードの更新」または「マネージド型ノードグループの更新」を参照してください。Fargate で起動される新しいポッドには、クラスターのバージョンと一致する kubelet バージョンがあります。既存の Fargate ポッドは変更されません。

Kubernetes 1.16 にアップグレードにするための前提条件

Kubernetes 1.15 の変更ログと 廃止された 1.16 での削除APIs: こちらのドキュメントで、既存のクラスターがある場合、クラスターを 1.16 にアップグレードする前に、以下のデプロイ済みリソースに対して API の変更が必要です。

警告

1.16 にアップグレードする前にこれらの APIs を変更しないと、アップグレードの完了後にワークロードが失敗します。

  • v1.16 では、NetworkPolicy extensions/v1beta1 リソースは から提供されなくなります。v1.8 以降で利用可能な networking.k8s.io/v1 API に移行してください。既存の永続化データは、networking.k8s.io/v1 API を介して取得できます。

  • v1.16 では、PodSecurityPolicy extensions/v1beta1 リソースは から提供されなくなります。v1.10 以降で利用可能な policy/v1beta1 API に移行してください。既存の永続化データは、policy/v1beta1 API を介して取得できます。

  • DaemonSet、デプロイ、StatefulSet、および ReplicaSet リソースは v1.16 では extensions/v1beta1、apps/v1beta1、または apps/v1beta2 から提供されなくなります。v1.9 以降で利用可能な apps/v1 APIに移行してください。既存の永続化データは、apps/v1 API を介して取得できます。たとえば、apps/v1beta1 を現在使用している Deployment を変換するには、次のコマンドを入力します。 

    kubectl convert -f ./<my-deployment.yaml> --output-version apps/v1
    注記

    上のコマンドで使用しているデフォルト値は、現在のマニフェストファイルに設定されているデフォルト値とは異なる場合があります。特定のリソースの詳細については、Kubernetes API リファレンスを参照してください。

最初に Kubernetes バージョン 1.11 以前で Amazon EKS クラスターを作成し、--resource-container kube-proxy から DaemonSet フラグを削除していない場合、Kubernetes 1.16 にアップデートすると kube-proxy エラーが発生します。このフラグは Kubernetes 1.16 で廃止されました。詳細については、「kube-proxyKubernetes 1.16 Deprecations and removals」の「」を参照してください。Kubernetes 1.16 にアップデートする前に、このフラグを削除する必要があります。

1.16 にアップグレードする前に行う必要があること

  • 新しい APIs を参照するように YAML ファイルを変更します。

  • カスタム統合とコントローラーを更新して、新しい APIs を呼び出します。

  • Ingress Controller、継続的配信システム、新しい APIs を呼び出すその他のツールなど、サードパーティー製ツールの最新バージョンを使用していることを確認します。

    クラスターで非推奨の API が使用されているかどうかを簡単に確認するには、audit コントロールプレーンログが有効になっていることを確認し、イベントのフィルターとして v1beta を指定します。すべての代替 APIs は、Kubernetes バージョン 1.10 より後のバージョンにあります。サポートされているバージョンの Amazon EKS のアプリケーションは、更新された APIs を使用できるようになりました。

  • クラスターが最初に Kubernetes 1.11 以前でデプロイされているか、kube-proxy 設定ファイルを使用する場合は、--resource-container="" kube-proxy から DaemonSet フラグを削除します (推奨)。現在のバージョンの kube-proxy にフラグがあるかどうかを確認するには、次のコマンドを入力します。 

    kubectl get daemonset kube-proxy --namespace kube-system -o yaml | grep 'resource-container='

    出力を受け取らなければ、何も削除する必要はありません。のような出力を受け取ったら、フラグを削除する必要があります。--resource-container=""次のコマンドを入力して、現在の kube-proxy 設定を編集します。 

    kubectl edit daemonset kube-proxy --namespace kube-system

    エディタを開いた状態で、--resource-container="" 行を削除し、ファイルを保存します。代わりに kube-proxy 設定ファイルの使用を開始することをお勧めします。これを行うには、次のマニフェストをダウンロードします。 

    curl -o kube-proxy-daemonset.yaml https://amazon-eks.s3-us-west-2.amazonaws.com/cloudformation/2020-06-10/kube-proxy-daemonset.yaml

    次のコマンドを使用して、クラスターのエンドポイントを確認します。

    aws eks describe-cluster \
    --name <cluster-name> \
    --region <region-code> \
    --query 'cluster.endpoint' \
    --output text

    出力は次のとおりです。

    https://<A89DBB2140C8AC0C2F920A36CCC6E18C>.sk1.<region-code>.eks.amazonaws.com

    ダウンロードした kube-proxy-daemonset.yaml ファイルを編集します。エディタで、<MASTER_ENDPOINT> (<> を含む) を前のコマンドからの出力に置き換えます。をクラスターのリージョンに置き換えます。<REGION>同じ行で、必要に応じてバージョンをクラスターのバージョンに置き換えます。次のコマンドを使用してファイルを適用します。 

    kubectl apply -f kube-proxy-daemonset.yaml

アドオンの設定Amazon EKS

アドオンは、Kubernetes 運用ソフトウェアで、AWS クラスターの監視性、スケーリング、ネットワーキング、および Amazon EKS クラウドサービス統合などの機能を提供します。アドオンを自分で管理したり、プラットフォームバージョン Amazon EKS 以降で Kubernetes バージョン 1.18 を実行しているクラスターの Amazon EKS API を介してアドオンの起動とバージョンを eks.3 で管理したりできます。Amazon EKS アドオンは Kubernetes サーバー側適用機能のみを使用し、Kubernetes バージョン 1.18 以降で利用できます。詳細については、Kubernetes ドキュメントの「Server-Side Apply」を参照してください。

を使用して Amazon EKS アドオンを設定するにはAWS マネジメントコンソール

  1. Open the Amazon EKS console at https://console.aws.amazon.com/eks/home#/clusters.

  2. 左側のナビゲーションで [クラスター] を選択し、Amazon EKS アドオンを設定するクラスターの名前を選択します。

  3. [Configuration] タブを選択し、[Add-ons] タブを選択します。

  4. アドオンの設定 新しい Amazon EKS アドオンを追加するには、[Add new (新規追加)] を選択します。既存の Amazon EKS アドオンを変更するには、アドオンを選択し、[編集] を選択します。アドオンを削除するには、アドオンを選択し、[削除] を選択します。アドオンを削除すると、クラスターからも削除されます。アドオンは、いつでも手動でクラスターに再度追加できますが、削除および追加するとクラスターのサービスが中断される場合があることに注意してください。

    1. 追加または編集する アドオンの [名前Amazon EKS] を選択します。

    2. 使用する アドオンの [バージョンAmazon EKS] を選択します。

    3. アドオンを実行する [サービスアカウントロール] を選択します。既存の IAM ロールを選択しないと、Amazon EKS ノードの IAM ロール が使用されます。ただし、ノードの IAM ロールに必要な最小限のアクセス許可を超えないように、独自のロールを指定することをお勧めします。

      どのロールを選択しても、アドオンに必要なアクセス権限を割り当てる必要があります。たとえば、vpc-cni アドオンに指定するロールには、AmazonEKS_CNI_Policy IAM ポリシーが割り当てられている必要があり、ロールには信頼関係で一意の設定がある必要があります。詳細については、「を使用して CNI プラグイン IAM ロールを作成するにはAWS マネジメントコンソール」を参照してください。アドオンで使用される Kubernetes サービスアカウントが、現在指定した IAM ロールで注釈されていない場合、API は IAM ロールでサービスアカウントに注釈を付けます。

      重要

      ロールを指定するには、クラスターに IAM IAM Connect (OIDC) プロバイダーが必要です。OpenIDOIDC プロバイダーを作成するには、「クラスターの IAM OIDC プロバイダーの作成」を参照してください。

    4. 現在、クラスターにアドオンをデプロイし、自分で管理して、Amazon EKS でアドオンを管理する場合は、「クラスターでこのアドオンの既存の設定を上書きする」ことができます。このオプションを有効にすると、既存のアドオンのすべての設定を Amazon EKS アドオンの設定で上書きできます。現在、クラスターにアドオンがデプロイされ、このオプションを有効にせず、Amazon EKS アドオン設定が既存の設定と競合する場合、アドオンを Amazon EKS アドオンに移行することは失敗し、競合の解決に役立つエラーメッセージを受け取ります。

    5. [Add] または [Update] を選択します。

を使用して Amazon EKS アドオンを設定するにはeksctl

(<example values> を含む) を独自の値に置き換えます。<>

  1. アドオンをクラスターに追加します。Amazon EKS

    1. クラスターで使用可能な Amazon EKS アドオンを確認します。

      eksctl utils describe-addon-versions --cluster <name-of-your-cluster>

    2. アドオンをクラスターに追加します。Amazon EKSを指定するときは、前のコマンドから返された名前を指定します。<name-of-addon>アドオンがクラスターにインストール済みで、自分で管理している場合は、--force オプションによって既存の設定が上書きされます。ロール、ポリシー、またはその両方の ARN を指定できます。IAMその後、アドオンの Kubernetes サービスアカウントにロールの注釈が付けられます。既存のロールまたはポリシーを指定しない場合、eksctl はデフォルトのロールを作成し、必要なポリシーをアタッチします。 

      eksctl create addon --name <name--of-addon-from-previous-command> --cluster <name-of-your-cluster> --force

  2. アドオンを新しいバージョンに更新できます。で他の更新オプションを参照してください。eksctl update addon -h

    1. アドオンに使用できるバージョンを決定します。

      eksctl utils describe-addon-versions --name <name-of-addon> --cluster <name-of-your-cluster>

    2. アドオンを新しいバージョンに更新します。

      eksctl update addon --name <name-from-previous-command> --version <version-from-previous-command> --cluster <name-of-your-cluster>

  3. クラスターから Amazon EKS アドオンを削除します。

    1. クラスターで現在有効になっているアドオンを確認します。

      eksctl get addons --cluster <name-of-your-cluster>

    2. クラスターから Amazon EKS アドオンを削除します。アドオンを削除すると、それに関連付けられているすべての IAM ロールも削除されます。

      eksctl delete addon --cluster <name-of-your-cluster> --name <addon-name-from-previous-command>