セルフマネージド Microsoft Windows ノードを作成する

eksctl を使用してセルフマネージド型の Windows ノードを起動する

この手順では、eksctl をインストール済みで、お使いの eksctl バージョンが 0.191.0 以上であることが必要です。お使いのバージョンは、以下のコマンドを使用して確認できます。

eksctl version

eksctl のインストールまたはアップグレードの手順については、eksctl ドキュメントの「インストール」を参照してください。

1. (オプション) [AmazonEKS_CNI_Policy] マネージド IAM ポリシー (IPv4 クラスターがある場合)、または (IPv6 クラスターがある場合に、ユーザー自身が作成した) AmazonEKS_CNI_IPv6_Policy が Amazon EKS ノードの IAM ロール に添付されている場合、代わりに Kubernetes aws-node サービスアカウントに関連付けている IAM ロールに割り当てることをお勧めします。詳細については、「IRSA を使用するように Amazon VPC CNI プラグインを設定する」を参照してください。

2. この手順では、既存のクラスターがあることを前提としています。Windows ノードグループを追加する先の Amazon EKS クラスターと Linux ノードグループがまだない場合は、ガイド「Amazon EKS – eksctl の使用を開始する」に従うことをお勧めします。このガイドは、Amazon Linux ノードで Amazon EKS クラスターを作成する方法についての完全なチュートリアルを提供します。

   次のコマンドを使用して、ノードグループを作成します。region-code をクラスターのある AWS リージョン に置き換えます。my-cluster をクラスター名に置き換えます。この名前には、英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前は、クラスターを作成する AWS リージョン および AWS アカウント 内で一意である必要があります。ng-windows をノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。Kubernetes バージョン 1.24 以降の場合は、2019 Server 2022 で使用する場合、2022 を Windows に置き換えることができます。残りの example values を、独自の値に置き換えます。

   重要

   ノードグループを AWS Outposts、AWS Wavelength、または AWS Local Zones サブネットにデプロイする場合、クラスターの作成時に AWS Outposts、Wavelength、または Local Zones サブネットは渡さないでください。AWS Outposts、Wavelength、または Local Zones サブネットを指定した設定ファイルを使用して、ノードグループを作成します。詳細については、eksctl ドキュメントの「設定ファイルからノードグループを作成する」と「設定ファイルのスキーマ」を参照してください。

   eksctl create nodegroup \
       --region region-code \
       --cluster my-cluster \
       --name ng-windows \
       --node-type t2.large \
       --nodes 3 \
       --nodes-min 1 \
       --nodes-max 4 \
       --managed=false \
       --node-ami-family WindowsServer2019FullContainer
   

   注記

   • ノードがクラスターに参加できない場合は、トラブルシューティングガイドの「ノードをクラスターに結合できません」を参照してください。

   • eksctl コマンドで使用可能なオプションを表示するには、次のコマンドを入力します。

     eksctl command -help
     

   出力例は次のとおりです。ノードの作成中に、複数の行が出力されます。出力の最後の行は、次のサンプル行が表示されます。

   [✔]  created 1 nodegroup(s) in cluster "my-cluster"

3. (オプション) サンプルアプリケーション をデプロイして、クラスターと Windows ノードをテストします。

4. 次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。

   • すべての Kubernetes サービスアカウントに IAM ロールを割り当てて、Pods が必要最小限のアクセス許可のみを持つように計画しています。

   • クラスター内の Pods が、現在の AWS リージョン の取得といったその他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていません。

   詳細については、「ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する」を参照してください。

ステップ 1: AWS Management Console を使用してセルフマネージド型の Windows ノードを起動する

1. クラスターステータスが ACTIVE と表示されるまで待ちます。クラスターがアクティブになる前にノードを起動した場合、ノードはクラスターへの登録に失敗し、再起動が必要になります。

2. https://console.aws.amazon.com/cloudformation で AWS CloudFormation コンソール を開きます。

3. [スタックの作成] を選択します。

4. [テンプレートを指定] で、[Amazon S3 URL] を選択します。

5. 次の URL をコピーして、[Amazon S3 URL] に貼り付けます。

   https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-02-09/amazon-eks-windows-nodegroup.yaml
   

6. [次へ] を 2 回選択します。

7. [スタックのクイック作成] ページで、必要に応じて以下のパラメータを入力します。

   • [スタック名]: AWS CloudFormation スタックのスタック名を選択します。例えば、my-cluster-nodes という名前にすることができます。

   • [ClusterName]: Amazon EKS クラスターの作成時に使用した名前を入力します。

     重要

     この名前は、ステップ 1: Amazon EKS クラスターを作成する で使用した名前と正確に一致する必要があります。そうしないと、ノードはクラスターに参加できません。

   • ClusterControlPlaneSecurityGroup: VPC を作成する際に生成した AWS CloudFormation 出力からセキュリティグループを選択します。

     次のステップでは、該当するグループを取得する 1 つの方法を説明します。

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

     2. クラスターの名前を選択します。

     3. [ネットワーキング] タブを選択します。

     4. [ClusterControlPlaneSecurityGroup] ドロップダウンリストから選択する場合は、[追加のセキュリティグループ] の値をリファレンスとして使用します。

   • [NodeGroupName]: ノードグループの名前を入力します。この名前は、ノードに対して作成される Auto Scaling ノードグループを識別するために後で使用できます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。

   • [NodeAutoScalingGroupMinSize]: ノードの Auto Scaling グループがスケールインできる最小ノード数を入力します。

   • NodeAutoScalingGroupDesiredCapacity: スタック作成時にスケーリングする必要のあるノード数を入力します。

   • [NodeAutoScalingGroupMaxSize]: ノードの Auto Scaling グループがスケールアウトできる最大ノード数を入力します。

   • [NodeInstanceType]: ノードのインスタンスタイプを選択します。詳細については、「最適な Amazon EC2 ノードインスタンスタイプを選択する」を参照してください。

     注記

     Amazon VPC CNI plugin for Kubernetes の最新バージョン用のサポートされているインスタンスタイプは、GitHub の vpc_ip_resource_limit.go にリストされています。サポートされている最新のインスタンスタイプを利用するには、CNI のバージョンを更新することが必要になる場合があります。詳細については、「Amazon VPC CNI を使用してPodsに IP を割り当てる」を参照してください。

   • [NodeImageIdSSMParam]: 現在推奨されている Amazon EKS 最適化 Windows Core AMI ID の Amazon EC2 Systems Manager パラメータが事前設定されています。Windows のフルバージョンを使用する場合、Core は Full に置き換えます。

   • [NodeImageId]: (オプション) (Amazon EKS 最適化 AMI の代わりに) 独自のカスタム AMI を使用している場合は、AWS リージョン のノード AMI ID を入力します。このフィールドに値を指定すると、[NodeImageIdSSMParam] フィールドの値はすべて上書きされます。

   • [NodeVolumeSize]: ノードのルートボリュームのサイズを GiB 単位で指定します。

   • [KeyName]: 起動後に、SSH を使用してノードに接続するときに使用できる Amazon EC2 SSH キーペアの名前を入力します。Amazon EC2 キーペアをまだ持っていない場合は、AWS Management Console で作成できます。詳細については、「Amazon EC2 ユーザーガイド」の「Amazon EC2 キーペア」を参照してください。

     注記

     ここでキーペアを指定しないと、AWS CloudFormation スタックの作成は失敗します。

   • [BootstrapArguments]: kubelet を使用して、-KubeletExtraArgs の追加引数など、ノードブートストラップスクリプトに渡すオプションの引数を指定します。

   • [DisableIMDSv1]: 各ノードは、デフォルトでインスタンスメタデータサービスバージョン 1 (IMDSv1) および IMDSv2 をサポートします。IMDSv1 は無効にできます。以後、ノードグループのノードおよび Pods が MDSv1 を使用しないようにするには、DisableIMDsv1 を true に設定します。IDMS の詳細については、「インスタンスメタデータサービスの設定」を参照してください。

   • [VpcId]: 作成した VPC の ID を選択します。

   • [NodeSecurityGroups]: VPC の作成時に Linux ノードグループ用に作成したセキュリティグループを選択します。Linux ノードに複数のセキュリティグループが添付されている場合、それらのすべてを指定します。これは、例えば、Linux ノードグループが eksctl を使用して作成された場合に行います。

   • [Subnets]: 作成したサブネットを選択します。Amazon EKS クラスターの Amazon VPC を作成する で説明されている手順で VPC を作成した場合は、起動するノードの VPC 内のプライベートサブネットのみを指定します。

     重要

     • いずれかのサブネットがパブリックサブネットである場合は、パブリック IP アドレスの自動割り当て設定を有効にする必要があります。この設定がパブリックサブネットに対して有効になっていない場合、そのパブリックサブネットにデプロイするノードにはパブリック IP アドレスが割り当てられず、クラスターやその他の AWS のサービスと通信できなくなります。2020 年 3 月 26 日以前に、Amazon EKS AWS CloudFormation VPC テンプレートを使用して、または eksctl を使用してサブネットがデプロイされた場合、パブリックサブネットではパブリック IP アドレスの自動割り当てが無効になります。サブネットのパブリック IP アドレスの割り当てを有効にする方法については、「サブネットのパブリック IPv4 アドレス属性の変更」を参照してください。ノードがプライベートサブネットにデプロイされている場合、NAT ゲートウェイを介してクラスターや他の AWS のサービスと通信できます。

     • サブネットにインターネットアクセスがない場合は、インターネットアクセスが制限されたプライベートクラスターをデプロイするの考慮事項と追加の手順を確認してください

     • AWS Outposts、Wavelength、または Local Zones サブネット を選択する場合は、クラスターの作成時にサブネットを渡さないようにします。

8. スタックが IAM リソースを作成する可能性があることを確認し、[スタックの作成] を選択します。

9. スタックの作成が完了したら、コンソールで選択し、[出力] を選択します。

10. 作成されたノードグループの [NodeInstanceRole] を記録します。これは、Amazon EKS Windows ノードを設定する際、必要になります。

ステップ 2: ノードを有効にしてクラスターに参加させるには

1. aws-auth ConfigMap がすでにあるかどうかを確認します。

   kubectl describe configmap -n kube-system aws-auth
   

2. aws-auth ConfigMap が表示されている場合は、必要に応じて更新してください。

   1. 編集する ConfigMap を開きます。

      kubectl edit -n kube-system configmap/aws-auth
      

   2. 必要に応じて新しい mapRoles エントリを追加します。rolearn 値を、前の手順で記録した [NodeInstanceRole] の値に設定します。

      [...]
      data:
        mapRoles: |
      - rolearn: <ARN of linux instance role (not instance profile)>
            username: system:node:{{EC2PrivateDNSName}}
            groups:
              - system:bootstrappers
              - system:nodes
          - rolearn: <ARN of windows instance role (not instance profile)>
            username: system:node:{{EC2PrivateDNSName}}
            groups:
              - system:bootstrappers
              - system:nodes
              - eks:kube-proxy-windows
      [...]

   3. ファイルを保存し、テキストエディタを終了します。

3. 「Error from server (NotFound): configmaps "aws-auth" not found」というエラーが表示されたら、ストック ConfigMap を適用してください。

   1. 設定マップをダウンロードします。

      curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml
      

   2. aws-auth-cm-windows.yaml ファイルで、rolearn 値を、前の手順で記録した該当する [NodeInstanceRole] 値に設定します。これを行うには、テキストエディタを使用するか、この example values を置き換えて次のコマンドを実行します。

      sed -i.bak -e 's|<ARN of linux instance role (not instance profile)>|my-node-linux-instance-role|' \
          -e 's|<ARN of windows instance role (not instance profile)>|my-node-windows-instance-role|' aws-auth-cm-windows.yaml
      

      重要

      • このファイルの他の行は変更しないでください。

      • Windows ノードと Linux ノードの両方に同じ IAM ロールを使用しないでください。

   3. 設定を適用します。このコマンドが完了するまで数分かかることがあります。

      kubectl apply -f aws-auth-cm-windows.yaml
      

4. ノードのステータスを監視し、Ready ステータスになるまで待機します。

   kubectl get nodes --watch
   

   Ctrl+C を入力して、シェルプロンプトに戻ります。

   注記

   認可またはリソースタイプのエラーが発生した場合は、トラブルシューティングトピックの「許可されていないか、アクセスが拒否されました (kubectl)」を参照してください。

   ノードがクラスターに参加できない場合は、トラブルシューティングの章にある「ノードをクラスターに結合できません」を参照してください。

ステップ 3: その他のアクション

1. (オプション) サンプルアプリケーションをデプロイして、クラスターと Windows ノードをテストします。

2. (オプション) AmazonEKS_CNI_Policy マネージド IAM ポリシー (IPv4 クラスターがある場合)、または(IPv6 クラスターがある場合に、ユーザー自身が作成した) AmazonEKS_CNI_IPv6_Policy が Amazon EKS ノードの IAM ロール に添付されている場合、代わりに Kubernetes aws-node サービスアカウントに関連付けている IAM ロールに割り当てることをお勧めします。詳細については、「IRSA を使用するように Amazon VPC CNI プラグインを設定する」を参照してください。

3. 次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。

   • すべての Kubernetes サービスアカウントに IAM ロールを割り当てて、Pods が必要最小限のアクセス許可のみを持つように計画しています。

   • クラスター内の Pods が、現在の AWS リージョン の取得といったその他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていません。

   詳細については、「ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する」を参照してください。