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

セルフマネージド Microsoft 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 サポートを有効にする」を参照してください。

次のいずれかを使用して、セルフマネージド型の Windows ノードを起動できます。

eksctl

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

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

eksctl version

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

注記

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

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

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

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

    重要

    ノードグループを AWS Outposts、AWS Wavelength、または AWS Local Zone サブネットにデプロイする場合、クラスターの作成時に AWS Outposts、Wavelength、または Local Zone サブネットは渡さないでください。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) へのアクセスを必要としていません。

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

AWS Management Console

前提条件

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

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

  2. 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 スタックのスタック名を選択します。例えば、cluster-name-nodes という名前にすることができます。

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

      重要

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

    • ClusterControlPlaneSecurityGroup: VPC を作成する際に生成した AWS CloudFormation 出力からセキュリティグループを選択します。次のステップでは、該当するグループを取得する 1 つの方法を説明します。

      1. Amazon EKS コンソールを開きます。

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

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

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

    • [NodeGroupName]: ノードグループの名前を入力します。この名前は、ノードに対して作成される自動スケーリングノードグループを識別するために後で使用できます。ノードグループ名は 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」を参照してください。

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

    • 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 を使用しないようにするには、DisableIMDsv1true に設定します。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] 値に設定します。これを行うには、テキストエディタを使用するか、このサンプル値を置き換えて次のコマンドを実行します。

      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 クラスターがある場合) または AmazonEKS_CNI_IPv6_Policy (IPv6 クラスターがある場合、ユーザー自身が作成したもの) が Amazon EKS ノードの IAM ロールにアタッチされている場合、代わりに Kubernetes aws-node サービスアカウントに関連付けている IAM ロールに割り当てることをお勧めします。詳細については、「IRSA を使用するように Amazon VPC CNI プラグインを設定する」を参照してください。

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

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

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

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