セルフマネージド型 Windows ノードの起動

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

重要

Amazon EKS ノードは標準の Amazon EC2 インスタンスであり、通常の Amazon EC2 インスタンス価格に基づいて請求されます。詳細については、「Amazon EC2 料金」を参照してください。
AWS Outposts 上の Amazon EKS 拡張クラスターで Windows ノードを起動できますが、AWS Outposts 上のローカルクラスターでは起動できません。詳細については、「AWS Outposts における Amazon EKS」を参照してください。

クラスターの Windows サポートを有効にします。Windows ノードグループを起動する前に、重要な考慮事項を確認することをお勧めします。詳細については、「Windows サポートの有効化」を参照してください。

eksctl または AWS Management Console を使用して、セルフマネージド型の Windows ノードを起動できます。

eksctl

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

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


eksctl version

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

注記

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

(オプション) [AmazonEKS_CNI_Policy] マネージド IAM ポリシー (IPv4 クラスターがある場合)、または (IPv6 クラスターがある場合に、ユーザー自身が作成した) AmazonEKS_CNI_IPv6_Policy が Amazon EKS ノードの IAM ロールに添付されている場合、代わりに Kubernetes aws-node サービスアカウントに関連付けている IAM ロールに割り当てることをお勧めします。詳細については、「サービスアカウントの IAM ロールを使用する Amazon VPC CNI plugin for Kubernetes の設定」を参照してください。
この手順では、既存のクラスターがあることを前提としています。Windows ノードグループを追加する先の Amazon EKS クラスターと Linux 2 ノードグループがまだない場合は、「Amazon EKS の開始方法 – eksctl ガイド」に従うことをお勧めします。このガイドは、Amazon Linux ノードで Amazon EKS クラスターを作成する方法についての完全なチュートリアルを提供します。

次のコマンドを使用して、ノードグループを作成します。region-code をクラスターのある AWS リージョンに置き換えます。my-cluster をクラスター名に置き換えます。この名前には、英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字はアルファベット文字である必要があります。また、100 文字より長くすることはできません。ng-windows をノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。Kubernetes バージョン 1.23 以降の場合は、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 ドキュメント」の「設定ファイルからノードグループを作成する」と「設定ファイルのスキーマ」を参照してください。

注記
Amazon EKS 最適化 Windows AMI は、ランタイムとして containerd を使用するように設定できます。Windows ノードの起動に eksctl を使用する場合は、ノードグループ設定で containerd として containerRuntime を指定します。詳細については、このユーザーガイドの「containerd ランタイムブートストラップフラグを有効にする」または「eksctlドキュメント」の「Define container runtime」(コンテナランタイムの定義) を参照してください。
```
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"
```
(オプション) サンプルアプリケーションをデプロイして、クラスターと Windows ノードをテストします。
次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。
- すべての Kubernetes サービスアカウントに IAM ロールを割り当てて、Pods が必要最小限のアクセス許可のみを持つように計画しています。
- クラスター内の Pods が、現在の AWS リージョンの取得といったその他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていません。
詳細については、「ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する」を参照してください。

AWS Management Console

前提条件

既存の Amazon EKS クラスターと Linux ノードグループ。これらのリソースがない場合は、Amazon EKS の使用開始ガイドのいずれかに従って作成することをお勧めします。このガイドでは、Linux ノードで Amazon EKS クラスターを作成する方法について説明します。
Amazon EKS クラスターの要件を満たす、既存の VPC およびセキュリティグループ。詳細については、Amazon EKS VPC およびサブネットの要件と考慮事項および Amazon EKS セキュリティグループの要件および考慮事項を参照してください。Amazon EKS の使用開始ガイドでは、要件を満たす VPC を作成します。または、Amazon EKS クラスター VPC の作成に従って手動で作成することもできます。
Amazon EKS クラスターの要件を満たす VPC およびセキュリティグループを使用している、既存の Amazon EKS クラスター。詳細については、「Amazon EKS クラスターの作成」を参照してください。AWS Outposts、AWS Wavelength、または AWS Local Zones が有効になっている AWS リージョンにサブネットがある場合は、クラスターの作成時にそれらのサブネットが渡されるべきではありません。

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

クラスターステータスが ACTIVE と表示されるまで待ちます。クラスターがアクティブになる前にノードを起動した場合、ノードはクラスターへの登録に失敗し、再起動が必要になります。
https://console.aws.amazon.com/cloudformation で AWS CloudFormation コンソールを開きます。
[スタックの作成] を選択します。
[Specify template (テンプレートを指定)] で、[Amazon S3 URL] を選択します。

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


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

[Next] (次へ) を 2 回選択します。
[Quick create stack] ページで、必要に応じて以下のパラメータを入力します。
- [Stack name] (スタック名): AWS CloudFormation スタックのスタック名を選択します。例えば、my-cluster-nodes という名前にすることができます。
- [ClusterName]: Amazon EKS クラスターの作成時に使用した名前を入力します。
  
  重要
  この名前は、ステップ 1: Amazon EKS クラスターを作成するで使用した名前と正確に一致する必要があります。そうしないと、ノードはクラスターに参加できません。
- ClusterControlPlaneSecurityGroup: VPC を作成する際に生成した AWS CloudFormation 出力からセキュリティグループを選択します。
  
  次のステップでは、該当するグループを取得する 1 つの方法を説明します。
  1. https://console.aws.amazon.com/eks/home#/clusters で Amazon EKS コンソールを開きます。
  2. クラスターの名前を選択します。
  3. [Networking] (ネットワーキング) タブを選択します。
  4. [ClusterControlPlaneSecurityGroup] ドロップダウンリストから選択する場合は、[Additional Security Group] (追加のセキュリティグループ) の値をリファレンスとして使用します。
- [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 plugin for Kubernetes Amazon EKS アドオンの使用」を参照してください。
- [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 で作成できます。詳細については、Windows インスタンス用 Amazon EC2 ユーザーガイドの「Amazon EC2 キーペア」を参照してください。
  
  注記
  ここでキーペアを指定しないと、AWS CloudFormation スタックの作成は失敗します。
- [BootstrapArguments]: kubelet を使用して、-KubeletExtraArgs の追加引数など、ノードブートストラップスクリプトに渡すオプションの引数を指定します。
  
  注記
  ランタイムとして containerd を使用するように、Amazon EKS 最適化 Windows AMI を設定できます。Windows ノードの作成に AWS CloudFormation テンプレートを使用する場合、ブートストラップ引数で -ContainerRuntime containerd を指定して、containerd ランタイムを有効にします。詳細については、「containerd ランタイムブートストラップフラグを有効にする」を参照してください。
- [DisableIMDSv1]: 各ノードは、デフォルトでインスタンスメタデータサービスバージョン 1 (IMDSv1) および IMDSv2 をサポートします。IMDSv1 は無効にできます。以後、ノードグループのノードおよび Pods が MDSv1 を使用しないようにするには、DisableIMDsv1 を true に設定します。IDMS の詳細については、「インスタンスメタデータサービスの設定」を参照してください。
- [VpcId]: 作成した VPC の ID を選択します。
- [NodeSecurityGroups]: VPC の作成時に Linux ノードグループ用に作成したセキュリティグループを選択します。Linux ノードに複数のセキュリティグループが添付されている場合、それらのすべてを指定します。これは、例えば、Linux ノードグループが eksctl を使用して作成された場合に行います。
- [Subnets]: 作成したサブネットを選択します。Amazon EKS クラスター VPC の作成で説明されている手順で VPC を作成した場合は、起動するノードの VPC 内のプライベートサブネットのみを指定します。
  重要
  いずれかのサブネットがパブリックサブネットである場合は、パブリック IP アドレスの自動割り当て設定を有効にする必要があります。この設定がパブリックサブネットに対して有効になっていない場合、そのパブリックサブネットにデプロイするノードにはパブリック IP アドレスが割り当てられず、クラスターやその他の AWS のサービスと通信できなくなります。2020 年 3 月 26 日以前に、Amazon EKS AWS CloudFormation VPC テンプレートを使用して、または eksctl を使用してサブネットがデプロイされた場合、パブリックサブネットではパブリック IP アドレスの自動割り当てが無効になります。サブネットのパブリック IP アドレスの割り当てを有効にする方法については、「Modifying the public IPv4 addressing attribute for your subnet」(サブネットのパブリック IPv4 アドレス属性の変更) を参照してください。ノードがプライベートサブネットにデプロイされている場合、NAT ゲートウェイを介してクラスターや他の AWS のサービスと通信できます。
  
  サブネットにインターネットアクセスがない場合は、プライベートクラスターの要件の考慮事項と追加の手順を確認してください
  
  AWS Outposts、Wavelength、または Local Zones サブネットを選択する場合は、クラスターの作成時にサブネットを渡さないようにします。
スタックが IAM リソースを作成する可能性があることを確認し、[スタックの作成] を選択します。
スタックの作成が完了したら、コンソールで選択し、[Outputs] (出力) を選択します。
作成されたノードグループの [NodeInstanceRole] を記録します。これは、Amazon EKS Windows ノードを設定する際、必要になります。

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

aws-auth ConfigMap がすでにあるかどうかを確認します。
```
kubectl describe configmap -n kube-system aws-auth
```

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

編集する ConfigMap を開きます。


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

必要に応じて新しい 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
[...]

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

「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
```
ノードのステータスを監視し、Ready ステータスになるまで待機します。
```
kubectl get nodes --watch
```
Ctrl+C を入力して、シェルプロンプトに戻ります。

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

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

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

(オプション) サンプルアプリケーションをデプロイして、クラスターと Windows ノードをテストします。
(オプション) AmazonEKS_CNI_Policy マネージド IAM ポリシー (IPv4 クラスターがある場合)、または(IPv6 クラスターがある場合に、ユーザー自身が作成した) AmazonEKS_CNI_IPv6_Policy が Amazon EKS ノードの IAM ロールに添付されている場合、代わりに Kubernetes aws-node サービスアカウントに関連付けている IAM ロールに割り当てることをお勧めします。詳細については、「サービスアカウントの IAM ロールを使用する Amazon VPC CNI plugin for Kubernetes の設定」を参照してください。
次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。
- すべての Kubernetes サービスアカウントに IAM ロールを割り当てて、Pods が必要最小限のアクセス許可のみを持つように計画しています。
- クラスター内の Pods が、現在の AWS リージョンの取得といったその他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていません。
詳細については、「ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する」を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

Bottlerocket

更新