Amazon EKS クラスター の Windows サポートの有効化 - Amazon EKS
Windows サポートの有効化レガシー Windows サポートの削除Windows サポートを無効にするポッドのデプロイレガシー Windows サポートの有効化Windows ノードでより高い Pod 密度のサポート

Amazon EKS クラスター の Windows サポートの有効化

Windows ノードをデプロイする前に、以下の考慮事項を確認してください。

考慮事項

  • HostProcess ポッドを使用して Windows ノードでホスト ネットワークを使用できます。詳細については、Kubernetes ドキュメントの「Create a Windows HostProcessPod」を参照してください。

  • CoreDNS など、Linux でのみ動作するコアシステム Pods を実行するには、Amazon EKS クラスターに 1 つ以上の Linux ノードまたは Fargate ノードが含まれている必要があります。

  • kubelet および kube-proxy イベントログは EKS Windows Event Log にリダイレクトされ、200 MB の制限に設定されます。

  • チュートリアル: Pods のセキュリティグループ を、Windows ノードで実行する Pods で使用することはできません。

  • Windows ノードで カスタムネットワーキング を使用することはできません。

  • IPv6 を Windows ノードで使用することはできません。

  • Windows ノードは、ノードごとに 1 つの Elastic Network Interface をサポートします。デフォルトでは、Windows ノードごとに実行できる Pods の数は、ノードのインスタンスタイプの Elastic Network Interface ごとに使用できる IP アドレスの数から、1 を引いた数に等しくなります。詳細については、Amazon EC2 の Windows インスタンス用ユーザーガイドの各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス数を参照してください。

  • Amazon EKS クラスターでは、ロードバランサーを持つ単一のサービスが、最大 1024 個までのバックエンド Pods をサポートできます。各 Pod には固有の IP アドレスがあります。OS ビルド 17763.2746 で始まる Windows Server 更新プログラム以降、以前の 64 個の Pods という上限はなくなりました。

  • Windows コンテナは、Fargate の Amazon EKS Pods でサポートされていません。

  • vpc-resource-controller ポッドからはログを取得できません。コントローラーをデータプレーンにデプロイしていたときには取得できていました。

  • IPv4 アドレスが新しいポッドに割り当てられるまでにはクールダウン期間があります。これは、古い kube-proxy ルールが原因で、同じ IPv4 アドレスを持つ古いポッドにトラフィックが流れるのを防ぎます。

  • コントローラーのソースは GitHub で管理されます。コントローラーに関する投稿や、問題の登録を行うには、GitHub の プロジェクト にアクセスしてください。

  • Windows マネージド型ノードグループのカスタム AMI ID を指定するとき、AWS IAM Authenticator 設定マップに eks:kube-proxy-windows を追加します。詳細については、「AMI ID を指定する場合の制限と条件」を参照してください。

前提条件

  • 既存のクラスター。クラスターは、次の表に示す Kubernetes バージョンとプラットフォームバージョンのいずれかを実行している必要があります。一覧にあるバージョンより後の Kubernetes とプラットフォームのバージョンもサポートされます。クラスターまたはプラットフォームのバージョンが次のいずれかのバージョンより前の場合は、クラスターのデータプレーン上で レガシー Windows サポートを有効にする 必要があります。クラスターが次の Kubernetes とプラットフォームのバージョンのいずれか以降になったら、コントロールプレーン上で レガシー Windows サポートを削除 して Windows サポートの有効化 を実行できます。

    Kubernetes バージョン プラットフォームのバージョニング
    1.27 eks.1
    1.26 eks.1
    1.25 eks.1
    1.24 eks.2
    1.23 eks.1

  • CoreDNS を実行するには、クラスターに少なくとも 1 つ (推奨値は少なくとも 2 つ) の Linux ノードまたは Fargate Pod が必要です。レガシー Windows サポートを有効にする場合は、 CoreDNS の実行に Linux ノードを使用する必要があります (Fargate Pod は使用できません)。

  • 既存の Amazon EKS クラスター の IAM ロール。

Windows サポートの有効化

クラスターが、前提条件のリストにある Kubernetes およびプラットフォームのバージョンのいずれか以降ではない場合、代わりにレガシー Windows サポートを有効にする必要があります。詳細については、「レガシー Windows サポートの有効化」を参照してください。

クラスターで Windows サポートを有効にしたことがない場合は、次のステップに進みます。

前提条件 の一覧にある Kubernetes またはプラットフォームのバージョンより前のクラスターで Windows サポートを有効にした場合は、まず データプレーンから vpc-resource-controller と vpc-admission-webhook を削除 する必要があります。これらは廃止され、もう必要ありません。

クラスターに対して Windows サポートを有効にするには

  1. クラスターに Amazon Linux ノードがなく、Pods のセキュリティグループを使用する場合は、次のステップに進みます。それ以外の場合は、クラスターのロールに AmazonEKSVPCResourceController マネージドポリシーがアタッチされていることを確認します。eksClusterRole をクラスターロール名に置き換えます。

    aws iam list-attached-role-policies --role-name eksClusterRole

    出力例は次のとおりです。

    {
    "AttachedPolicies": [
        {
            "PolicyName": "AmazonEKSClusterPolicy",
            "PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
        },
        {
            "PolicyName": "AmazonEKSVPCResourceController",
            "PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSVPCResourceController"
        }
    ]
}

    前の出力のようにポリシーがアタッチされている場合は、次のステップをスキップします。

  2. Amazon EKS クラスター の IAM ロール に AmazonEKSVPCResourceController マネージドポリシーを添付します。eksClusterRole をクラスターロール名に置き換えます。

    aws iam attach-role-policy \
  --role-name eksClusterRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController

  3. 次の内容で、vpc-resource-controller-configmap.yaml という名前のファイルを作成します。

    apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  enable-windows-ipam: "true"

  4. クラスターに ConfigMap を適用します。

    kubectl apply -f vpc-resource-controller-configmap.yaml

データプレーンからのレガシー Windows サポートの削除

前提条件 の一覧にある Kubernetes またはプラットフォームのバージョンより前のクラスターで Windows サポートを有効にした場合は、まずータプレーンから vpc-resource-controller とvpc-admission-webhook を削除する必要があります。これらで提供されていた機能はコントロールプレーンで有効になったため、これらは廃止され、もう必要ありません。

  1. 次のコマンドを使用して vpc-resource-controller をアンインストールします。このコマンドは、元々インストールしたツールに関係なく使用します。region-code (/manifests/ の後のそのテキストのインスタンスのみ) を、クラスターが含まれている AWS リージョン に置き換えます。

    kubectl delete -f https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-resource-controller/latest/vpc-resource-controller.yaml

  2. インストールに使用したツールの手順を使用して、vpc-admission-webhook をアンインストールします。

    eksctl

    以下のコマンドを実行します。

    kubectl delete deployment -n kube-system vpc-admission-webhook
kubectl delete service -n kube-system vpc-admission-webhook
kubectl delete mutatingwebhookconfigurations.admissionregistration.k8s.io vpc-admission-webhook-cfg
    kubectl on macOS or Windows

    以下のコマンドを実行します。region-code (/manifests/ の後のそのテキストのインスタンスのみ) を、クラスターが含まれている AWS リージョン に置き換えます。

    kubectl delete -f https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/vpc-admission-webhook-deployment.yaml

  3. コントロールプレーン上で、クラスターに対する Windows サポートを有効 にします。

Windows サポートを無効にする

クラスターで Windows サポートを無効にするには

  1. クラスターに Amazon Linux ノードが含まれていて、Pods のセキュリティグループ をそれらとともに使用する場合は、このステップをスキップしてください。

    クラスターのロールから AmazonVPCResourceController マネージド IAM ポリシーを削除します。eksClusterRole をクラスタロールの名前と 111122223333 のアカウントIDに置き換えます。

    aws iam detach-role-policy \
    --role-name eksClusterRole \
    --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController

  2. amazon-vpc-cni ConfigMap で Windows IPAM を無効にします。

    kubectl patch configmap/amazon-vpc-cni \
                    -n kube-system \
                    --type merge \
                    -p '{"data":{"enable-windows-ipam":"false"}}'

ポッドのデプロイ

クラスターにポッドをデプロイするときに、さまざまなノードタイプを混在させて実行する場合に使用するオペレーティングシステムを指定する必要があります。

Linux Pods の場合は、マニフェストで以下のノードセレクタテキストを使用します。

nodeSelector:
        kubernetes.io/os: linux
        kubernetes.io/arch: amd64

Windows Pods の場合は、マニフェストで以下のノードセレクタテキストを使用します。

nodeSelector:
        kubernetes.io/os: windows
        kubernetes.io/arch: amd64

サンプルアプリケーションをデプロイして、使用されているノードセレクタを確認できます。

レガシー Windows サポートの有効化

クラスターが、前提条件 の一覧にある Kubernetes とプラットフォームのバージョンのいずれか以降である場合は、代わりにコントロールプレーンで Windows サポートを有効にすることをお勧めします。詳細については、「Windows サポートの有効化」を参照してください。

次のステップは、クラスターまたはプラットフォームのバージョンが 前提条件 の一覧にあるバージョンより前の場合に、Amazon EKS クラスターのデータプレーンに対してレガシー Windows サポートを有効にするのに役立ちます。クラスターとプラットフォームのバージョンが、前提条件 の一覧にあるバージョン以降になったら、レガシー Windows サポートを削除 し、コントロールプレーンに対して有効にする ことをお勧めします。

クラスターに対してレガシー Windows サポートを有効にするには、eksctl、Windows クライアント、または macOS あるいは Linux のクライアントを使用できます。

eksctl
eksctl を使用してクラスターに対してレガシー Windows サポートを有効にするには
前提条件

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

eksctl version

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

  1. 以下の eksctl コマンドを使用して、Amazon EKS クラスターで Windows サポートを有効にします。my-cluster を自分のクラスター名に置き換えます。このコマンドは、Windows ワークロードを実行するために Amazon EKS クラスターが必要とする、VPC リソースコントローラーと VPC アドミッションコントローラーのウェブフックをデプロイします。

    eksctl utils install-vpc-controllers --cluster my-cluster --approve
    重要

    VPC アドミッションコントローラーのウェブフックは、発行日から 1 年後に有効期限が切れる証明書で署名されます。ダウンタイムを回避するには、有効期限が切れる前に証明書を更新してください。詳細については、「VPC アドミッションウェブフック証明書の更新」を参照してください。

  2. Windows サポートを有効にした後、Windows ノードグループをクラスターに起動できます。詳細については、「セルフマネージド型 Windows ノードの起動」を参照してください。

Windows
Windows クライアントを使用してクラスターに対してレガシー Windows サポートを有効にするには

次のステップでは、region-code をクラスターが存在する AWS リージョン に置き換えてください。

  1. VPC リソースコントローラーをクラスターにデプロイします。

    kubectl apply -f https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-resource-controller/latest/vpc-resource-controller.yaml

  2. VPC アドミッションコントローラーウェブフックをクラスターにデプロイします。

    1. 必要なスクリプトとデプロイファイルをダウンロードします。

      curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/vpc-admission-webhook-deployment.yaml;
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/Setup-VPCAdmissionWebhook.ps1;
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/webhook-create-signed-cert.ps1;
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/webhook-patch-ca-bundle.ps1;

    2. OpenSSL と jq をインストールします。

    3. VPC アドミッションウェブフックを設定してデプロイします。

      ./Setup-VPCAdmissionWebhook.ps1 -DeploymentTemplate ".\vpc-admission-webhook-deployment.yaml"
      重要

      VPC アドミッションコントローラーのウェブフックは、発行日から 1 年後に有効期限が切れる証明書で署名されます。ダウンタイムを回避するには、有効期限が切れる前に証明書を更新してください。詳細については、「VPC アドミッションウェブフック証明書の更新」を参照してください。

  3. クラスターに必要なクラスターロールバインドがあるかどうかを確認します。

    kubectl get clusterrolebinding eks:kube-proxy-windows

    以下の出力例のような出力が返された場合、クラスターには必要なロールバインドがあります。

    NAME                      AGE
eks:kube-proxy-windows    10d

    出力に Error from server (NotFound) が含まれている場合、クラスターには必要なクラスターロールバインドがありません。eks-kube-proxy-windows-crb.yaml という名前のファイルを以下の内容で作成して、バインドを追加します。

    kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: eks:kube-proxy-windows
  labels:
    k8s-app: kube-proxy
    eks.amazonaws.com/component: kube-proxy
subjects:
  - kind: Group
    name: "eks:kube-proxy-windows"
roleRef:
  kind: ClusterRole
  name: system:node-proxier
  apiGroup: rbac.authorization.k8s.io

    設定をクラスターに適用します。

    kubectl apply -f eks-kube-proxy-windows-crb.yaml

  4. Windows サポートを有効にした後、Windows ノードグループをクラスターに起動できます。詳細については、「セルフマネージド型 Windows ノードの起動」を参照してください。

macOS and Linux
macOS または Linux クライアントでクラスターに対してレガシー Windows サポートを有効にするには

この手順では、クライアントシステムに openssl ライブラリと jq JSON プロセッサがインストールされている必要があります。

次のステップでは、region-code を、クラスターが存在する AWS リージョン に置き換えてください。

  1. VPC リソースコントローラーをクラスターにデプロイします。

    kubectl apply -f https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-resource-controller/latest/vpc-resource-controller.yaml

  2. クラスターの VPC アドミッションコントローラーウェブフックのマニフェストを作成します。

    1. 必要なスクリプトとデプロイファイルをダウンロードします。

      curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/webhook-create-signed-cert.sh
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/webhook-patch-ca-bundle.sh
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/vpc-admission-webhook-deployment.yaml

    2. シェルスクリプトに、実行に必要なアクセス許可を追加します。

      chmod +x webhook-create-signed-cert.sh webhook-patch-ca-bundle.sh

    3. セキュアな通信のためのシークレットを作成します。

      ./webhook-create-signed-cert.sh

    4. シークレットを確認します。

      kubectl get secret -n kube-system vpc-admission-webhook-certs

    5. ウェブフックを設定し、デプロイファイルを作成します。

      cat ./vpc-admission-webhook-deployment.yaml | ./webhook-patch-ca-bundle.sh > vpc-admission-webhook.yaml

  3. VPC アドミッションウェブフックをデプロイします。

    kubectl apply -f vpc-admission-webhook.yaml
    重要

    VPC アドミッションコントローラーのウェブフックは、発行日から 1 年後に有効期限が切れる証明書で署名されます。ダウンタイムを回避するには、有効期限が切れる前に証明書を更新してください。詳細については、「VPC アドミッションウェブフック証明書の更新」を参照してください。

  4. クラスターに必要なクラスターロールバインドがあるかどうかを確認します。

    kubectl get clusterrolebinding eks:kube-proxy-windows

    以下の出力例のような出力が返された場合、クラスターには必要なロールバインドがあります。

    NAME                     ROLE                              AGE
eks:kube-proxy-windows   ClusterRole/system:node-proxier   19h

    出力に Error from server (NotFound) が含まれている場合、クラスターには必要なクラスターロールバインドがありません。eks-kube-proxy-windows-crb.yaml という名前のファイルを以下の内容で作成して、バインドを追加します。

    kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: eks:kube-proxy-windows
  labels:
    k8s-app: kube-proxy
    eks.amazonaws.com/component: kube-proxy
subjects:
  - kind: Group
    name: "eks:kube-proxy-windows"
roleRef:
  kind: ClusterRole
  name: system:node-proxier
  apiGroup: rbac.authorization.k8s.io

    設定をクラスターに適用します。

    kubectl apply -f eks-kube-proxy-windows-crb.yaml

  5. Windows サポートを有効にした後、Windows ノードグループをクラスターに起動できます。詳細については、「セルフマネージド型 Windows ノードの起動」を参照してください。

VPC アドミッションウェブフック証明書の更新

VPC アドミッションウェブフックで使用される証明書は、発行後 1 年で期限切れになります。ダウンタイムを回避するには、有効期限が切れる前に証明書を更新することが重要です。現在の証明書の有効期限は、次のコマンドを使用して確認できます。

kubectl get secret \
    -n kube-system \
    vpc-admission-webhook-certs -o json | \
    jq -r '.data."cert.pem"' | \
    base64 -decode | \
    openssl x509 \
    -noout \
    -enddate | \
    cut -d= -f2

出力例は次のとおりです。

May 28 14:23:00 2022 GMT

証明書は、eksctl または Windows または Linux/macOS コンピュータを使用して更新できます。VPC アドミッションウェブフックのインストールに使用した当初のツールの指示に従ってください。たとえば、最初に eksctl で VPC アドミッションウェブフックをインストールした場合、eksctl の指示に従って証明書を更新する必要があります。

eksctl

  1. 証明書を再インストールします。my-cluster を自分のクラスター名に置き換えます。

    eksctl utils install-vpc-controllers -cluster my-cluster -approve

  2. 次のような出力が表示されます。

    2021/05/28 05:24:59 [INFO] generate received request
2021/05/28 05:24:59 [INFO] received CSR
2021/05/28 05:24:59 [INFO] generating key: rsa-2048
2021/05/28 05:24:59 [INFO] encoded CSR

  3. ウェブフックデプロイメントを再起動します。

    kubectl rollout restart deployment -n kube-system vpc-admission-webhook

  4. 更新した証明書の有効期限が切れていて、Windows Pods が Container creating 状態のままの場合は、それらの Pods を削除して再デプロイする必要があります。

Windows

  1. 新しい証明書を生成するスクリプトを取得します。

    curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/webhook-create-signed-cert.ps1;

  2. スクリプトのパラメータを準備します。

    ./webhook-create-signed-cert.ps1 -ServiceName vpc-admission-webhook-svc -SecretName vpc-admission-webhook-certs -Namespace kube-system

  3. ウェブフックデプロイメントを再起動します。

    kubectl rollout restart deployment -n kube-system vpc-admission-webhook-deployment

  4. 更新した証明書の有効期限が切れていて、Windows Pods が Container creating 状態のままの場合は、それらの Pods を削除して再デプロイする必要があります。

Linux and macOS
前提条件

コンピュータに OpenSSL と jq がインストールされている必要があります。

  1. 新しい証明書を生成するスクリプトを取得します。

    curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/webhook-create-signed-cert.sh

  2. 権限を変更します。

    chmod +x webhook-create-signed-cert.sh

  3. スクリプトを実行します。

    ./webhook-create-signed-cert.sh

  4. ウェブフックを再起動します。

    kubectl rollout restart deployment -n kube-system vpc-admission-webhook-deployment

  5. 更新した証明書の有効期限が切れていて、Windows Pods が Container creating 状態のままになっている場合は、それらの Pods を削除して再展開する必要があります。

Windows ノードでより高い Pod 密度のサポート

Amazon EKS では、各 Pod に VPC の IPv4 アドレスが割り当てられます。このため、ノード上でさらに多くの Pods を実行するのに十分なリソースがある場合でも、ノードにデプロイできる Pods の数の上限は、使用可能な IP アドレスによって制限されます。Windows ノードでサポートされる Elastic Network Interface は 1 つだけなので、デフォルトでは Windows ノードで使用できる IP アドレスの最大数は次のようになります。

Number of private IPv4 addresses for each interface on the node - 1

1 つの IP アドレスがネットワークインターフェースのプライマリ IP アドレスとして使用されるため、Pods に割り当てることはできません。

IP プレフィックスの委任を有効にすると、Windows ノードで Pod 密度をより高めることができます。この機能により、セカンダリ IPv4 アドレスを割り当てる代わりに、プライマリネットワークインターフェイスに /28IPv4 プレフィックスを割り当てることができます。IP プレフィックスを割り当てると、ノードで使用できる IPv4 アドレスの最大数が次のように増加します。

(Number of private IPv4 addresses assigned to the interface attached to the node - 1) * 16

使用可能な IP アドレス数が大幅に増加したため、使用可能な IP アドレスによってノード上の Pods の数をスケーリングできることが制限されることはありません。詳細については、「Amazon EC2 ノードで使用可能な IP アドレスの量を増やす」を参照してください。