

 **このページの改善にご協力ください** 

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。

# セルフマネージド Microsoft Windows ノードの作成
<a name="launch-windows-workers"></a>

このトピックでは、Amazon EKS クラスターに登録されている Windows ノードの Auto Scaling グループの起動方法について説明します。ノードがクラスターに参加したら、それらのノードに Kubernetes アプリケーションをデプロイ可能になります。

**重要**  
Amazon EKS ノードは標準の Amazon EC2 インスタンスであり、通常の Amazon EC2 インスタンス価格に基づいて請求されます。詳細については「[Amazon EC2 料金](https://aws.amazon.com/ec2/pricing/)」を参照してください。
AWS Outposts 上の Amazon EKS 拡張クラスターで Windows ノードを起動できますが、AWS Outposts 上のローカルクラスターでは起動できません。詳細については、「[AWS Outposts を使用して Amazon EKS をオンプレミスにデプロイする](eks-outposts.md)」を参照してください。

クラスターに対して Windows サポートを有効にします。Windows ノードグループを起動する前に、重要な考慮事項を確認することをお勧めします。詳細については、「[Windows サポートを有効にする](windows-support.md#enable-windows-support)」を参照してください。

次のいずれかを使用して、セルフマネージド型の Windows ノードを起動できます。
+  [`eksctl`](#eksctl_create_windows_nodes) 
+  [AWS マネジメントコンソール](#console_create_windows_nodes) 

## `eksctl`
<a name="eksctl_create_windows_nodes"></a>

 **`eksctl` <2> を使用して自己管理型 Windows ノードを起動します。**

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

```
eksctl version
```

`eksctl` のインストールまたはアップグレードの手順については`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。

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

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

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

   次のコマンドを使用して、ノードグループを作成します。*地域コード* を、クラスターのある AWS リージョンに置き換えます。*マイクラスター* の部分は自分のクラスター名に置き換えます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前はクラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。*ng-windows* をノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。*2019* を `2022` に置き換えて Windows Server 2022 を使用するか、もしくは `2025` に置き換えて Windows Server 2025 を使用できます。残りのサンプル値は独自の値に置き換えます。
**重要**  
ノードグループを AWS Outposts、AWS 波長、または AWS ローカルゾーン サブネットにデプロイする場合、クラスターの作成時に AWS Outposts、波長、または ローカルゾーン サブネットは渡さないでください。AWS Outposts、波長、または ローカルゾーンサブネットを指定した設定ファイルを使用して、ノードグループを作成します。詳細については`eksctl` ドキュメントの「[設定ファイルからノードグループを作成する](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file)」と「[設定ファイルのスキーマ](https://eksctl.io/usage/schema/)」を参照してください。

   ```
   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
   ```
**注記**  
ノードがクラスターに参加できない場合はトラブルシューティングガイドの「[ノードをクラスターに結合できません](troubleshooting.md#worker-node-fail)」を参照してください。
`eksctl` コマンドで使用可能なオプションを表示するには次のコマンドを入力してください。  

     ```
     eksctl command -help
     ```

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

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

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

1. 次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。
   + IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。
   + クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。

   詳細については、「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。

## AWS マネジメントコンソール
<a name="console_create_windows_nodes"></a>

 **前提条件** 
+ 既存の Amazon EKS クラスターと Linux ノードグループ。これらのリソースがない場合は[Amazon EKS の使用を開始する](getting-started.md) のガイドのいずれかに従って作成することをお勧めします。これらのガイドでは、Linux ノードで Amazon EKS クラスターを作成する方法について説明しています。
+ Amazon EKS クラスターの要件を満たす、既存の VPC およびセキュリティグループ。詳細については[VPC とサブネットの Amazon EKS ネットワーキング要件を表示する](network-reqs.md)および[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)を参照してください。[Amazon EKS の使用を開始する](getting-started.md) のガイドでは要件を満たす VPC を作成します。または「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」に従って手動で作成することもできます。
+ Amazon EKS クラスターの要件を満たす VPC およびセキュリティグループを使用している、既存の Amazon EKS クラスター。詳細については「[Amazon EKS クラスターを作成します。](create-cluster.md)」を参照してください。AWS Outposts、AWS 波長、または AWS ローカルゾーンが有効になっている AWS リージョンにサブネットがある場合はクラスターの作成時にそれらのサブネットが渡されるべきではありません。

 **ステップ 1: AWS マネジメントコンソール を使用してセルフマネージド型の Windows ノードを起動する** 

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

1. [AWS クラウドフォーメーション コンソール](https://console.aws.amazon.com/cloudformation/)を開きます 

1. **[スタックの作成]** を選択してください。

1. **[テンプレートを指定]** で、**[Amazon S3 URL]** を選択してください。

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

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

1. **[次へ]** を 2 回選択してください。

1. **[スタックのクイック作成]** ページで、必要に応じて以下のパラメータを入力してください。
   +  **スタック名**: AWS クラウドフォーメーション スタックのスタック名を選択してください。例えば、`my-cluster-nodes` という名前にすることができます。
   +  **[クラスター名]**: Amazon EKS クラスターの作成時に使用した名前を入力してください。
**重要**  
この名前は「[ステップ 1: Amazon EKS クラスターを作成する](getting-started-console.md#eks-create-cluster)」で使用した名前と完全に一致する必要があります。そうしないと、ノードはクラスターに参加できません。
   +  **クラスター制御プレーンセキュリティグループ**: [VPC](creating-a-vpc.md) を作成する際に生成した AWS クラウドフォーメーション 出力からセキュリティグループを選択してください。次のステップでは該当するグループを取得する 1 つの方法を説明します。

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

     1. クラスターの名前を選択してください。

     1. **[ネットワーキング]** タブを選択してください。

     1. **[クラスター制御プレーンセキュリティグループ]** ドロップダウンリストから選択する場合は**[追加のセキュリティグループ]** の値をリファレンスとして使用します。
   +  **[ノードグループ名]**: ノードグループの名前を入力してください。この名前はノードに対して作成される自動スケーリングノードグループを識別するために後で使用できます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。
   +  **[ノードオートスケーリンググループ最小サイズ]**: ノードの 自動スケーリング グループがスケールインできる最小ノード数を入力してください。
   +  **ノード自動スケーリンググループ希望容量**: スタック作成時にスケーリングする必要のあるノード数を入力してください。
   +  **[NodeAutoScalingGroupMaxSize]**: ノードの 自動スケーリング グループがスケールアウトできる最大ノード数を入力してください。
   +  **[ノードインスタンス型]**: ノードのインスタンスタイプを選択してください。詳細については、「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を参照してください。
**注記**  
最新バージョンの [Amazon VPC CNI plugin for Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) でサポートされているインスタンスタイプは、GitHub 上の [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) にリストされています。サポートされている最新のインスタンスタイプを利用するには、CNI のバージョンを更新することが必要になる場合があります。詳細については、「[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md)」を参照してください。
   +  **[NodeImageIdSSMParam]**: 現在推奨されている Amazon EKS 最適化 Windows Core AMI ID の Amazon EC2 Systems Manager パラメータが事前設定されています。Windows の通常版を使用する場合は、*Core* を `Full` に置き換えます。
   +  **ノードイメージId**: (オプション) (Amazon EKS 最適化 AMI の代わりに) 独自のカスタム AMI を使用している場合はAWS リージョンのノード AMI ID を入力してください。このフィールドに値を指定すると、**[ノードイメージIdSSMParam]** フィールドの値はすべて上書きされます。
   +  **[ノードボリュームサイズ]**: ノードのルートボリュームのサイズを GiB 単位で指定します。
   +  **[キー名]**: 起動後に、SSH を使用してノードに接続するときに使用できる Amazon EC2 SSH キーペアの名前を入力してください。Amazon EC2 キーペアをまだ持っていない場合はAWS マネジメントコンソール で作成できます。詳細については「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 キーペア](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html)」を参照してください。
**注記**  
ここでキーペアを指定しないと、AWS クラウドフォーメーション スタックの作成は失敗します。
   +  [**ブートストラップ引数**]: `kubelet` を使用して、`-KubeletExtraArgs` の追加引数など、ノードブートストラップスクリプトに渡すオプションの引数を指定します。
   +  **[無効IMDSv1]**: 各ノードはデフォルトでインスタンスメタデータサービスバージョン 1 (IMDSv1) および IMDSv2 をサポートします。IMDSv1 は無効にできます。今後ノードグループのノードおよび Pod が MDSv1 を使用しないようにするには、**DisableIMDSv1** を **true** に設定します。IDMS の詳細については「[インスタンスメタデータサービスの設定](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)」を参照してください。
   +  **[VpcId]**: 作成した [VPC](creating-a-vpc.md) の ID を選択します。
   +  **[NodeSecurityGroups]**: [VPC](creating-a-vpc.md) の作成時に Linux ノードグループ用に作成したセキュリティグループを選択します。Linux ノードに複数のセキュリティグループがアタッチされている場合、それらのすべてを指定します。これは、たとえば、Linux ノードグループが `eksctl` を使用して作成された場合に行います。
   +  **[Subnets]**: 作成したサブネットを選択してください。「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」で説明されている手順で VPC を作成した場合は起動するノードの VPC 内のプライベートサブネットのみを指定します。
**重要**  
いずれかのサブネットがパブリックサブネットである場合はパブリック IP アドレスの自動割り当て設定を有効にする必要があります。この設定がパブリックサブネットに対して有効になっていない場合、そのパブリックサブネットにデプロイするノードにはパブリック IP アドレスが割り当てられず、クラスターやその他の AWS のサービスと通信できなくなります。2020 年 3 月 26 日以前に、[Amazon EKS AWS クラウドフォーメーション VPC テンプレート](creating-a-vpc.md)を使用して、または `eksctl` を使用してサブネットがデプロイされた場合、パブリックサブネットではパブリック IP アドレスの自動割り当てが無効になります。サブネットのパブリック IP アドレス割り当てを有効にする方法については「[サブネットのパブリック IPv4 アドレス属性の変更](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)」を参照してください。ノードがプライベートサブネットにデプロイされている場合、NAT ゲートウェイを介してクラスターや他の AWS のサービスと通信できます。
サブネットにインターネットアクセスがない場合は「[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)」の考慮事項と追加の手順を確認してください
AWS Outposts、波長、またはローカルゾーンサブネット を選択する場合はクラスターの作成時にサブネットを渡さないようにします。

1. スタックが IAM リソースを作成する可能性があることを確認し、**[スタックの作成]** を選択してください。

1. スタックの作成が完了したら、コンソールで選択し、**[出力]** を選択してください。

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

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

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

   ```
   kubectl describe configmap -n kube-system aws-auth
   ```

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

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

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

   1. 必要に応じて新しい `mapRoles` エントリを追加します。`rolearn` 値を、前の手順で記録した **[ノードインスタンス役割]** の値に設定します。

      ```
      [...]
      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
      [...]
      ```

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

1. 「`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
      ```

   1. `aws-auth-cm-windows.yaml` ファイルで、`rolearn` 値を、前の手順で記録した該当する **[ノードインスタンス役割]** 値に設定します。これを行うにはテキストエディタを使用するか、このサンプル値を置き換えて次のコマンドを実行してください。

      ```
      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 ロールを使用しないでください。

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

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

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

   ```
   kubectl get nodes --watch
   ```

   `Ctrl`\$1`C` を入力して、シェルプロンプトに戻ります。
**注記**  
認可またはリソースタイプのエラーが発生した場合はトラブルシューティングトピックの「[許可されていないか、アクセスが拒否されました (`kubectl`)](troubleshooting.md#unauthorized)」を参照してください。

   ノードがクラスターに参加できない場合はトラブルシューティングの章にある「[ノードをクラスターに結合できません](troubleshooting.md#worker-node-fail)」を参照してください。

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

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

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

1. 次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。
   + IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。
   + クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。

   詳細については「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。