クラスターの更新 - 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.19 1.18 1.17 1.16 1.15
Amazon VPC CNI プラグイン 1.7.5 1.7.5 1.7.5 1.7.5 1.7.5
DNS (CoreDNS) 1.8.0 1.7.0 1.6.6 1.6.6 1.6.6
KubeProxy 1.19.6 1.18.8 1.17.9 1.16.13 1.15.11

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

既存のクラスターの更新

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

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

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

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

      kubectl version --short

    • 次のコマンドを使用して、ノードの Kubernetes バージョンを取得します。このコマンドは、すべての自己管理型 および マネージド型 Amazon EC2 および Fargate ノードを返します。各Fargateポッドは、独自のノードとして一覧表示されます。 

      kubectl get nodes

    クラスター内のマネージド および Fargate ノードの Kubernetes マイナーバージョンは、コントロールプレーンを新しい Kubernetes バージョンに更新する前に、コントロールプレーンの現在のバージョンと同じバージョンである必要があります。たとえば、コントロールプレーンが バージョン を実行して1.18いて、いずれかのノードが バージョン を実行している場合は1.17、コントロールプレーンの Kubernetes バージョンを に更新1.18する前に、ノードをバージョン に更新1.19します。また、コントロールプレーンを更新する前に、自己管理型ノードをコントロールプレーンと同じバージョンに更新することをお勧めします。詳細については、「」マネージド型ノードグループの更新および「」を参照してくださいセルフマネージド型ノードの更新。Fargate ノードのバージョンを更新するには、ノードで表されるポッドを削除し、コントロールプレーンを更新した後でポッドを再デプロイします。

  2. ポッドセキュリティポリシーのアドミッションコントローラーは、 Amazon EKS クラスターでデフォルトで有効になっています。クラスターを更新する前に、問題を回避するために、適切なポッドセキュリティポリシーが設定されていることを確認してから、更新してください。以下のコマンドを使用して、デフォルトのポリシーを表示できます。

    kubectl get psp eks.privileged

    次のエラーが表示された場合は、続行する前にデフォルトのポッドセキュリティポリシーを参照してください。 

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

  3. 当初 Kubernetes 1.17 以前にクラスターをデプロイした場合は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 マネジメントコンソールクラスターを更新しますAWS CLI。

    重要

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

    • 更新する前に、マネージド および kubelet Fargate ノードの が、コントロールプレーンと同じ Kubernetes バージョンであることを確認します。また、自己管理型ノードはコントロールプレーンと同じバージョンにすることをお勧めしますが、コントロールプレーンの現在のバージョンより最大で 1 つのバージョン遅れることもできます。

    • 1.16 より前のAWS Fargateマイナーバージョンを持つkubeletポッドがある場合、1.16 から 1.17 へのクラスターの更新は失敗します。クラスターを 1.16 から 1.17 に更新する前にFargate、ポッドをリサイクルして、クラスターを 1.17 に更新する前にポッドkubeletが 1.16 になるようにする必要があります。

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

    • クラスターを新しいバージョンに更新すると、カスタム設定が上書きされる場合があります。

    eksctl

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

    eksctl version

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

    次のコマンドを使用してAmazon EKS、コントロールプレーンの Kubernetes バージョンを、現在のバージョンより 1 つ後のマイナーバージョンに更新します。置換 <my-cluster> ( を含む <>) を選択します。 

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

    更新が完了するまでに数分かかります。

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

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

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

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

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

      更新が完了するまでに数分かかります。

    AWS CLI

    1. 次の AWS CLI コマンドを使用して、クラスターを作成します。の置き換え <example-values> ( を含む <>) を選択します。 

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

      出力:

      {
    "update": {
        "id": "<b5f0ba18-9a87-4450-b5a0-825e6e84496f>",
        "status": "InProgress",
        "type": "VersionUpdate",
        "params": [
            {
                "type": "Version",
                "value": "1.19"
            },
            {
                "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.19"
            },
            {
                "type": "PlatformVersion",
                "value": "eks.1"
            }
        ],
...
        "errors": []
    }
}

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

    Kubernetes バージョン 1.19 1.18 1.17 1.16 1.15
    KubeProxy 1.19.6 1.18.8 1.17.9 1.16.13 1.15.11

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

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

      出力例

      602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/kube-proxy:v1.18.8-eksbuild.1

    2. を置き換えて推奨バージョンkube-proxyに更新する 602401143452 および us-west-2 出力の値に置き換えて 1.19.6 クラスターの推奨kube-proxyバージョンに置き換えます。より前のバージョンをデプロイする場合は1.19.6、 を置き換えます。[eksbuild.2] ( を使用eksbuild.1)。 

      kubectl set image daemonset.apps/kube-proxy \
  -n kube-system \
  kube-proxy=602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/kube-proxy:v1.19.6-eksbuild.2

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

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

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

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

    4. (オプション) クラスターが Kubernetes v1 以降で最初に作成された場合は、 kube-proxy にすでにこの が含まれているため、このステップをスキップできますAffinity Rule。当初 Kubernetes バージョン 1.13 または earilier を使用して Amazon EKS クラスターを作成し、 Fargate ノードを使用する場合はkube-proxy、ノードでNodeAffinityポッドがシャーディングされないようにkube-proxyルールを含めるようにFargateマニフェストを編集します。これは 1 回限りの編集です。Affinity Rule をマニフェストに追加したら、クラスターをアップグレードするたびに行う必要はありません。kube-proxy デーモンセットを編集します。 

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

      エディタの ファイルの Affinity Rule Daemonset spec セクションに以下を追加し、ファイルを保存します。エディタでこのテキストを含める場所の例についてはGitHub の CNI マニフェストファイルを参照してください。 

      - key: eks.amazonaws.com/compute-type
  operator: NotIn
  values:
  - fargate

  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.6.6>

    対応する Kubernetes coredns バージョンの推奨バージョンは次のとおりです。

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

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

    1. 次のコマンドを使用して configmap を開きます。

      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に更新する 602401143452, us-west-2、、および amazonaws.com 前のコマンドの出力を含む次のコマンドの 。置換 1.8.0 クラスターの Kubernetes バージョンに推奨されるバージョンを使用して、変更したコマンドを実行します。 

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

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

    kubectl edit -n kube-system deployment/coredns

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

    - 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

    • 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 を更新します。

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

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

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

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

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

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

Kubernetes 1.16 更新の前提条件

「 1.16: 必要なことはここに」のドキュメントで削除された Kubernetes 1.15 変更ログおよび非推奨の 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 を介して取得できます。

  • v1.16 では、DaemonSet、Deployment、StatefulSet、および ReplicaSet の各リソースが 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 DaemonSet から kube-proxy フラグを削除していない場合、Kubernetes 1.16 に更新するとkube-proxy、エラーが発生します。このフラグは、Kubernetes 1.16 ではサポートされなくなりました。詳細についてはkube-proxy、Kubernetes 1.16 の「廃止と削除」を参照してください。Kubernetes 1.16 にアップデートする前に、このフラグを削除する必要があります。

1.16 に更新する前に行う必要があること

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

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

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

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

  • クラスターが最初に Kubernetes 1.11 以前でデプロイされている場合は --resource-container="" DaemonSet から kube-proxy フラグを削除するか、kube-proxy 設定ファイルを使用します (推奨)。の現在のバージョンに フラグ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 アドオンを設定する

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

eksctl または eksctl を使用して を設定できますAWS マネジメントコンソール。

eksctl

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

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

    1. クラスターで使用できるAmazon EKSアドオンを決定します。

      eksctl utils describe-addon-versions --cluster <my-cluster>

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

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

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

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

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

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

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

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

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

      eksctl get addons --cluster <my-cluster>

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

      eksctl delete addon --cluster <my-cluster> --name <addon-name-from-previous-command>
AWS マネジメントコンソール

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

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

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

  3. [設定] タブを選択し、[アドオン] タブを選択します。

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

    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 OpenID Connect (OIDC) プロバイダーが必要です。OIDC プロバイダーを作成するにはクラスターの IAM OIDC プロバイダーを作成する、「」を参照してください。

    4. 現在、アドオンをクラスターにデプロイして自分で管理し、アドオンを管理する場合はAmazon EKS、クラスターでこのアドオンの [Override existing configuration for this add-on] を有効にすることができます。このオプションを有効にすると、既存のアドオンのすべての設定をAmazon EKSアドオンの設定で上書きできます。現在クラスターにアドオンをデプロイしていて、このオプションを有効にしていない場合、Amazon EKSアドオン設定のいずれかが既存の設定と競合すると、アドオンをAmazon EKSアドオンに移行できず、競合の解決に役立つエラーメッセージが表示されます。

    5. [Add (追加)] または [Update (更新)] を選択します。

既存のクラスターでエンベロープ暗号化を有効にする

シークレットの暗号化を有効にすると、選択した AWS AWS Key Management Service (KMS) カスタマーマスターキー (CMK) を使用して Kubernetes シークレットが暗号化されます。CMK は対称で、クラスターと同じリージョンで作成する必要があります。CMK が別のアカウントで作成されている場合は、ユーザーが CMK にアクセスできる必要があります。詳細については、 https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html 開発者ガイドの「他のアカウントのユーザーに CMKAWS Key Management Service の使用を許可する」を参照してください。既存のクラスターでエンベロープ暗号化を有効にすることは、Kubernetes バージョン 1.13 以降でサポートされています。

警告

エンベロープ暗号化を有効にした後で無効にすることはできません。このアクションは元に戻すことはできません。

eksctl

暗号化は、次の 2 つの方法で有効にできます。

  • 1 つのコマンドでクラスターに暗号化を追加します。

    シークレットを自動的に再暗号化するには:

    eksctl utils enable-secrets-encryption /
    --cluster <my-cluster> /
    --key-arn arn:aws:kms:<Region-code>:<account>:key/<key>

    シークレットを自動的に再暗号化することを解除するには:

    eksctl utils enable-secrets-encryption 
    --cluster <my-cluster> /
    --key-arn arn:aws:kms:<Region-code>:<account>:key/<key> /
    --encrypt-existing-secrets=false

  • .yaml ファイルを使用してクラスターに暗号化を追加します。

    # cluster.yaml

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: <my-cluster>
  region: <Region-code>
  
secretsEncryption:
  keyARN: arn:aws:kms:<Region-code>:<account>:key/<key>

    シークレットを自動的に再暗号化するには:

    eksctl utils enable-secrets-encryption -f kms-cluster.yaml

    シークレットを自動的に再暗号化することを解除するには:

    eksctl utils enable-secrets-encryption -f kms-cluster.yaml --encrypt-existing-secrets=false
AWS マネジメントコンソール

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

  2. KMS 暗号化を追加するクラスターを選択します。

  3. [設定] タブをクリックします。

  4. [Secrets encryption (シークレットの暗号化)] セクションまで下にスクロールし、[有効化] ボタンをクリックします。

  5. ドロップダウンメニューからキーを選択し、[有効化] ボタンをクリックします。キーが一覧表示されていない場合は、最初にキーを作成する必要があります。詳細については、「キーhttps://docs.aws.amazon.com/kms/latest/developerguide/create-keys.htmlの作成」を参照してください。

  6. [確認] ボタンをクリックして、選択したキーを使用します。

AWS CLI

  1. 次のコマンドを使用して、エンベロープ暗号化設定をクラスターに関連付けAWS CLIます。の置き換え <example-values> ( を含む <>) を選択します。 

    aws eks associate-encryption-config \
    --cluster-name <my-cluster> \
    --encryption-config '[{"resources":["secrets"],"provider":{"keyArn":"arn:aws:kms:<Region-code>:<account>:key/<key>"}}]'

    出力: 

    {
  "update": {
    "id": "<3141b835-8103-423a-8e68-12c2521ffa4d>",
    "status": "InProgress",
    "type": "AssociateEncryptionConfig",
    "params": [
      {
        "type": "EncryptionConfig",
        "value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws:kms:<Region-code>:<account>:key/<key>\"}}]"
      }
    ],
    "createdAt": <1613754188.734>,
    "errors": []
  }
}

  2. 次のコマンドを使用して、暗号化の更新のステータスをモニタリングできます。上記のステップcluster nameの出力update IDで返された と を使用します。ステータスが Successful となったら、更新は完了です。 

    aws eks describe-update \
    --region <Region-code> \
    --name <my-cluster> \
    --update-id <3141b835-8103-423a-8e68-12c2521ffa4d>

    出力: 

    {
  "update": {
    "id": "<3141b835-8103-423a-8e68-12c2521ffa4d>",
    "status": "Successful",
    "type": "AssociateEncryptionConfig",
    "params": [
      {
        "type": "EncryptionConfig",
        "value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws:kms:<region-code>:<account>:key/<key>\"}}]"
      }
    ],
    "createdAt": <1613754188.734>,
    "errors": []
  }
}

  3. クラスターで暗号化が有効になっていることを確認するには、 describe-cluster コマンドを実行します。レスポンスには が含まれますEncryptionConfig。 

    aws eks describe-cluster --region <Region-code> --name <my-cluster>

クラスターで暗号化を有効にしたら、既存のすべてのシークレットを新しいキーで暗号化する必要があります。

注記

eksctl ユーザーは、シークレットを自動的に再暗号化することを選択しない限り、次のコマンドを実行する必要はありません。 

kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - kms-encryption-timestamp="<time value>"
警告

既存のクラスターのエンベロープ暗号化を有効にし、使用するキーが削除されると、クラスターの復旧パスがなくなります。CMK を削除すると、クラスターは永続的にパフォーマンスが低下した状態になります。

注記

デフォルトでは、 create-key コマンドは、 アクションおよびリソースに対する アカウントのルートユーザー管理者アクセスを許可するキーポリシーを持つ対称AWS KMSキーを作成します。アクセス許可の範囲を絞り込む場合は、kms:DescribeKey API を呼び出すプリンシパルのキーポリシーで、kms:CreateGrant および create-cluster アクションが許可されていることを確認します。

Amazon EKS はキーポリシー条件 をサポートしていません。kms:GrantIsForAWSResourceこのアクションがキーポリシーステートメントにある場合、クラスターの作成は機能しません。