**このページの改善にご協力ください** このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。 # 起動テンプレートを使用してマネージドノードをカスタマイズする このページの手順に基づいて自分の起動テンプレートを使用することで、マネージド型ノードをデプロイでき、最高レベルのカスタマイズを実現できます。起動テンプレートを使用すると、ノードのデプロイ中にブートストラップ引数 (追加の [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 引数など) を指定したり、ノードに割り当てられた IP アドレスとは異なる CIDR ブロックからポッドに IP アドレスを割り当てたり、独自のカスタム AMI をノードにデプロイしたり、独自のカスタム CNI をノードにデプロイしたりできます。 最初にマネージドノードグループを作成するときに独自の起動テンプレートを指定する場合にも、後で高い柔軟性を得ることができます。自分の起動テンプレートを使用してマネージド型ノードグループをデプロイする限り、同じ起動テンプレートの異なるバージョンとして繰り返し更新できます。ノードグループを別のバージョンの起動テンプレートに更新すると、指定した起動テンプレートバージョンの新しい設定と一致するように、グループ内のすべてのノードがリサイクルされます。 マネージド型ノードグループは常に アマゾン EC2 自動スケーリング グループで使用する起動テンプレートでデプロイされます。起動テンプレートを指定しない場合、アマゾン EKS API はアカウントのデフォルト値を使用して起動テンプレートを自動的に作成します。ただし、自動生成された起動テンプレートを変更することは推奨しません。さらに、カスタム起動テンプレートを使用していない既存のノードグループは直接更新できません。代わりに、カスタム起動テンプレートを使用して、新しいノードグループを作成する必要があります。 ## 起動テンプレート設定の基本 AWS マネジメントコンソール、AWS CLI、または AWS SDK を使用して、アマゾン EC2 自動スケーリング 起動テンプレートを作成できます。詳細については*「アマゾン EC2 自動スケーリング ユーザーガイド」*の「[自動スケーリング グループの起動テンプレートを作成する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html)」を参照してください。起動テンプレートの一部の設定はマネージド型ノードで使われている設定と似ています。起動テンプレートを使用してノードグループをデプロイまたは更新する場合、一部の設定はノードグループ設定または起動テンプレートのいずれかで指定する必要があります。両方の場所で設定を指定しないでください。存在してはいけない場所に設定が存在する場合、ノードグループの作成や更新などの操作は失敗します。 次の表に、起動テンプレートで禁止されている設定を示します。また、マネージド型ノードグループの設定に必要な同様の設定がある場合はその設定も示します。リスト化されている設定はコンソールに表示される設定です。AWS CLI と SDK では類似するが異なる名前がある場合があります。 | 起動テンプレート — 禁止 | アマゾン EKS ノードグループ設定 | | --- | --- | | [**ネットワークインターフェイス**] ([**ネットワークインターフェイスを追加**]) の下の [**サブネット**] | **[Specify networking]** (ネットワーキングを指定) ページの **[Node group network configuration]** (ノードグループのネットワーク設定) の下の **[Subnets]** (サブネット) | | [**高度な詳細**] の下の [**IAM インスタンスプロファイル**] | **[Configure Node group]** (ノードグループを設定) ページの **[Node group configuration]** (ノードグループ設定) の下の **[Node IAM role]** (ノード IAM 役割) | | [**高度な詳細**] の下の [**シャットダウン動作**] および [**停止 – 休止動作**]。起動テンプレートのどちらの設定でも、[**起動テンプレート設定に含めない**] のデフォルトを保持します。 | 同等のものはありません。アマゾン EKS は自動スケーリング グループではなく、インスタンスのライフサイクルを管理する必要があります。 | 次の表に、マネージド型ノードグループ構成で禁止される設定を示します。また、起動テンプレートで必要な同様の設定がある場合はその設定も示します。リスト化されている設定はコンソールに表示される設定です。AWS CLI と SDK とで名前が似ている場合があります。 | アマゾン EKS ノードグループ設定 — 禁止 | 起動テンプレート | | --- | --- | | (起動テンプレートでカスタム AMI を指定した場合のみ) **[コンピューティングとスケーリングの設定を実行]** ページの **[ノードグループのコンピューティング設定]** の下の **[AMI タイプ]** — **[起動テンプレートで指定]** と、指定した AMI ID がコンソールに表示されます。 起動テンプレートで **[アプリ and OS Images (アマゾン Machine Image)]** (アプリケーションと OS のイメージ (アマゾン マシンイメージ)) が指定されていない場合はノードグループ設定で AMI を選択できます。 | **[Launch template contents]** (起動テンプレートのコンテンツ) での **[Application and OS Images (Amazon Machine Image)]** (アプリケーションと OS のイメージ (Amazon マシンイメージ)) - 次のいずれかの要件がある場合はID を指定する必要があります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/launch-templates.html) | | **[Set compute and scaling configuration]** (コンピューティングとスケーリングの設定を実行) ページの **[Node Group compute configuration]** (ノードグループのコンピューティング設定) の下の **[Disk size]** (ディスクサイズ) — **[Specified in launch template]** (起動テンプレートで指定) がコンソールに表示されます。 | [**ストレージ (ボリューム)**] ([**新しいボリュームの追加**]) の下の [**サイズ**]。これを起動テンプレートで指定する必要があります。 | | **[Specify Networking]** (ネットワーキングを指定) ページの **[Node group configuration]** (ノードグループ設定) の下の **[SSH key pair]** (SSH キーペア) — コンソールに起動テンプレートで指定したキーまたは **[Not specified in launch template]** (起動テンプレートで指定されていません) が表示されます。 | [**キーペア (ログイン)**] の下の [**キーペア名**]。 | | 起動テンプレートを使用する場合はリモートアクセスを許可するソースセキュリティグループを指定できません。 | インスタンスの場合、[**ネットワーク設定**] の下の [**セキュリティグループ**]、または [**ネットワークインターフェイス**] ([**ネットワークインターフェイスを追加**])の下の [**セキュリティグループ**]。両方設定することはできません。詳細については「[カスタムセキュリティグループを使用する](#launch-template-security-groups)」を参照してください。 | **注記** 起動テンプレートを使用してノードグループをデプロイする場合は起動テンプレート内の **[起動テンプレートのコンテンツ]** で 0 または 1 の **[インスタンスタイプ]** を指定します。またはコンソールの **[コンピューティングとスケーリングの構成を設定する]** ページにある **[インスタンスタイプ]** で 0 から 20 までのインスタンスタイプを指定できます。またはアマゾン EKS API を使用する他のツールを使用して行うこともできます。起動テンプレートでインスタンスタイプを指定し、その起動テンプレートを使用してノードグループをデプロイする場合、コンソールや、アマゾン EKS API を使用する他のツールを使用してインスタンスタイプを指定することはできません。起動テンプレートやコンソール、または アマゾン EKS API を使用する他のツールを使用してインスタンスタイプを指定しない場合は`t3.medium` インスタンスタイプが使用されます。ノードグループがスポットキャパシティータイプを使用している場合はコンソールを使用して複数のインスタンスタイプを指定することをお勧めします。詳細については「[マネージド型ノードグループのキャパシティータイプ](managed-node-groups.md#managed-node-group-capacity-types)」を参照してください。 ノードグループにデプロイするコンテナが、インスタンスメタデータサービスバージョン 2 を使用している場合は起動テンプレートの **[メタデータレスポンスのホップ制限]** を `2` に設定してください。詳細については*「アマゾン EC2 ユーザーガイド」*の「[Instance metadata and user data](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)」(インスタンスメタデータとユーザーデータ) を参照してください。 起動テンプレートでは、インスタンスタイプを柔軟に選択できるようにする `InstanceRequirements` 機能はサポートされていません。 ## アマゾン EC2 インスタンスへのタグ付け 起動テンプレートの `TagSpecification` パラメータを使用して、ノードグループの アマゾン EC2 インスタンスに適用するタグを指定します。`CreateNodegroup` または `UpdateNodegroupVersion` API を呼び出す IAM エンティティには`ec2:RunInstances` および `ec2:CreateTags` へのアクセス許可が必要です。また、起動テンプレートにタグが追加される必要があります。 ## カスタムセキュリティグループを使用する 起動テンプレートでカスタムの アマゾン EC2 [セキュリティグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html)を指定し、ノードグループ内のインスタンスに適用できます。これはインスタンスレベルのセキュリティグループのパラメータ内か、ネットワークインターフェイス設定のパラメータの一部として指定できます。しかし、インスタンスレベルとネットワークインタフェイス、両方のセキュリティグループを指定して、起動テンプレートを作成することはできません。マネージドノード型グループでカスタムセキュリティグループを使用する際に適用される、次の条件を考慮してください。 + AWS マネジメントコンソール を使用する場合、アマゾン EKS では単一のネットワークインターフェイス仕様の起動テンプレートのみ使用できます。 + デフォルトではAmazon EKS は[クラスターセキュリティグループ](sec-group-reqs.md)をノードグループ内のインスタンスに追加して、ノードとコントロールプレーンとの間の通信を容易にします。前述のいずれかのオプションを使用して、起動テンプレートでカスタムセキュリティグループを指定した場合、アマゾン EKS はクラスターセキュリティグループを追加しません。したがって、セキュリティグループのインバウンドルールとアウトバウンドルールで、クラスターのエンドポイントとの通信が有効になっていることを確認する必要があります。セキュリティグループのルールが正しくない場合、ワーカーノードはクラスターに参加できません。セキュリティグループルールの詳細については[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)を参照してください。 + ノードグループ内のインスタンスへの SSH アクセスが必要な場合はそのアクセスを許可するセキュリティグループを含めてください。 ## アマゾン EC2 ユーザーデータ 起動テンプレートにはカスタムユーザーデータのセクションが含まれています。このセクションでは、個々のカスタム AMI を手動で作成しなくても、ノードグループの構成設定を指定できます。Bottlerocket で使用できる設定の詳細については、GitHub で [Using user data](https://github.com/bottlerocket-os/bottlerocket#using-user-data) を参照してください。 `cloud-init` を使用すると、インスタンス起動時に起動テンプレート内の Amazon EC2 ユーザーデータを提供できます。詳細については「[cloud-init ドキュメント](https://cloudinit.readthedocs.io/en/latest/index.html)」を参照してください。ユーザーデータを使用すると、一般的な設定操作を実行できます。これには次の操作が含まれます。 + [ユーザーまたはグループを含む](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups) + [パッケージのインストール](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages) マネージド型ノードグループで使用される起動テンプレートの Amazon EC2 ユーザーデータは、Amazon Linux AMI の場合は、[MIME マルチパートアーカイブ](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive)、Bottlerocket AMI の場合は TOML の形式であることが必要です。これはユーザーデータが、ノードがクラスターに参加するために必要な Amazon EKS ユーザーデータにマージされるためです。`kubelet` を起動または変更するコマンドをユーザーデータに指定しないでください。これは アマゾン EKS によってマージされたユーザーデータの一部として実行されます。ノードへのラベル設定などの一部の `kubelet` パラメータはマネージド型ノードグループ API 経由で直接設定できます。 **注記** 手動での起動や、カスタムの設定パラメータの受け渡しなど、高度な `kubelet` のカスタマイズについては[AMI を指定する](#launch-template-custom-ami)を参照してください。起動テンプレートでカスタム AMI ID が指定されている場合、アマゾン EKS はユーザーデータをマージしません。 次の詳細はユーザーデータセクションについて説明しています。 **アマゾン リナックス 2 ユーザーデータ** 複数のユーザーデータブロックと単一の MIME マルチパートファイルを組み合わせることができます。例えば、カスタムパッケージをインストールするユーザーデータのシェルスクリプトを、Docker デーモンを設定するクラウドブートフックに組み合わせることができます。MIME マルチパートファイルには次のコンポーネントが含まれます。 + コンテンツタイプとパートバウンダリの宣言: `Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="` + MIME バージョンの宣言: `MIME-Version: 1.0` + 次のコンポーネントを含む 1 つ以上のユーザーデータブロック: + ユーザーデータブロックの始まりを示す開始境界:`--==MYBOUNDARY==` + ブロックのコンテンツの種類の宣言: `Content-Type: text/cloud-config; charset="us-ascii"`。コンテンツタイプの詳細については[cloud-init](https://cloudinit.readthedocs.io/en/latest/topics/format.html) のドキュメントを参照してください。 + ユーザーデータのコンテンツ (例えば、シェルコマンドや `cloud-init` ディレクティブのリスト)。 + MIME マルチパートファイルの終わりを示す、終了境界: `--==MYBOUNDARY==--` 自分で MIME マルチパートファイルを作成するときに使用できる例は次の通りです。 ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==MYBOUNDARY==" --==MYBOUNDARY== Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash echo "Running custom user data script" --==MYBOUNDARY==-- ``` **アマゾン リナックス 2023 ユーザーデータ** アマゾン リナックス 2023 (AL2023) ではYAML 設定スキーマを使用する新しいノード初期化プロセス `nodeadm` が導入されています。セルフマネージド型ノードグループまたは起動テンプレートを持つ AMI を使用している場合は新しいノードグループの作成時に追加のクラスターメタデータを明示的に指定する必要があります。最低限必要なパラメータの[例](https://awslabs.github.io/amazon-eks-ami/nodeadm/)を以下に示します。ここで、`apiServerEndpoint`、`certificateAuthority`、サービスの `cidr` が必要になります。 ``` --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster apiServerEndpoint: https://example.com certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk= cidr: 10.100.0.0/16 ``` 通常、この設定はユーザーデータにそのまま設定するか、MIME マルチパートドキュメントに埋め込まれます。 ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY" --BOUNDARY Content-Type: application/node.eks.aws --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: [...] --BOUNDARY-- ``` AL2 ではこれらのパラメータからのメタデータは アマゾン EKS `DescribeCluster` API コールから検出されていました。AL2023 ではノードの大規模なスケールアップ中に API コールによってスロットリングが発生するリスクがあるため、この動作が変更されました。この変更は起動テンプレートのないマネージド型ノードグループを使用している場合や、Karpenter を使用している場合には影響しません。`certificateAuthority` とサービス `cidr` の詳細については、「*Amazon EKS API リファレンス*」の「[https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html)」を参照してください。 次に、AL2023 ユーザーデータの詳しい例を示します。ノードをカスタマイズするシェルスクリプト (パッケージのインストールやコンテナイメージの事前キャッシュなど) を必要な `nodeadm` 設定と結合しています。この例では、よく使用されるカスタマイズを示しています。\$1 追加でシステムパッケージをインストールする \$1 コンテナイメージを事前キャッシュしてポッドの起動時間を改善する \$1 HTTP プロキシ設定を設定する \$1 ノードのラベル付けに関する `kubelet` フラグを設定する ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY" --BOUNDARY Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash set -o errexit set -o pipefail set -o nounset # Install additional packages yum install -y htop jq iptables-services # Pre-cache commonly used container images nohup docker pull public.ecr.aws/eks-distro/kubernetes/pause:3.2 & # Configure HTTP proxy if needed cat > /etc/profile.d/http-proxy.sh << 'EOF' export HTTP_PROXY="http://proxy.example.com:3128" export HTTPS_PROXY="http://proxy.example.com:3128" export NO_PROXY="localhost,127.0.0.1,169.254.169.254,.internal" EOF --BOUNDARY Content-Type: application/node.eks.aws apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster apiServerEndpoint: https://example.com certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk= cidr: 10.100.0.0/16 kubelet: config: clusterDNS: - 10.100.0.10 flags: - --node-labels=app=my-app,environment=production --BOUNDARY-- ``` **Bottlerocket ユーザーデータ** Bottlerocket はユーザーデータを TOML 形式で構造化しています。Amazon EKS が提供するユーザーデータとマージするユーザーデータを提供できます。たとえば、追加の `kubelet` 設定を指定できます。 ``` [settings.kubernetes.system-reserved] cpu = "10m" memory = "100Mi" ephemeral-storage= "1Gi" ``` サポートされる設定について詳しくは[Bottlerocket のドキュメント](https://github.com/bottlerocket-os/bottlerocket)を参照してください。ユーザーデータにノードラベルと[テイント](node-taints-managed-node-groups.md)を設定できます。ただし、代わりにノードグループ内にこれらを設定することをお勧めします。この場合、アマゾン EKS によりこれらの設定が適用されます。 ユーザーデータをマージしても、書式設定は保持されませんが、コンテンツは同じままです。ユーザーデータに指定した設定はアマゾン EKS によって構成された設定よりも優先されます。したがって、`settings.kubernetes.max-pods` または `settings.kubernetes.cluster-dns-ip` を設定した場合、ユーザーデータのこれらの値がノードに適用されます。 アマゾン EKS で、有効な TOML がすべてサポートされるわけではありません。以下はサポートされていない既知の形式の一覧です。 + 引用符で囲まれたキー内の引用符: `'quoted "value"' = "value"` + 値内のエスケープされた引用符: `str = "I’m a string. \"You can quote me\""` + 浮動小数点と整数の混在: `numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]` + 配列内の混合型: `contributors = ["[foo@example.com](mailto:foo@example.com)", { name = "Baz", email = "[baz@example.com](mailto:baz@example.com)" }]` + 引用符付きキーを含む括弧で囲まれたヘッダー: `[foo."bar.baz"]` **Windows ユーザーデータ** Windows ユーザーデータでは、PowerShell コマンドを使用します。マネージド型ノードグループを作成すると、カスタムユーザーデータが Amazon EKS マネージドユーザーデータと結合されます。まず PowerShell コマンドが表示され、その後にマネージドユーザーデータコマンドが続きます。そのいずれも 1 つの `` タグ内にあります。 Windows ノードグループを作成すると、Amazon EKS は Linux ベースのノードがクラスターに参加できるように `aws-auth` `ConfigMap` を更新します。このサービスは、Windows AMI に対するアクセス許可を自動的には設定しません。Windows ノードを使用している場合は、アクセスエントリ API を利用するか、`aws-auth` `ConfigMap` を直接更新することで、アクセスを管理する必要があります。詳細については、「[EKS クラスターに WiWindows ノードをデプロイする](windows-support.md)」を参照してください。 起動テンプレートに AMI ID が指定されていない場合はユーザーデータで Windows Amazon EKS ブートストラップスクリプトを使用して Amazon EKS を設定しないでください。 ユーザーデータの例は次のとおりです。 ``` Write-Host "Running custom user data script" ``` ## AMI を指定する 以下のいずれかの要件がある場合は起動テンプレートの `ImageId` フィールドで AMI ID を指定します。追加情報については要件を選択してください。 ### Amazon EKS に最適化された Linux/Bottlerocket AMI に含まれる `bootstrap.sh` ファイルに引数を渡すためのユーザーデータを提供する ブートストラップとはインスタンスの起動時に実行できるコマンドの追加を表す用語です。例えば、ブートストラップでは追加の [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 引数を使用できます。起動テンプレートを指定せずに、`eksctl` を使用して引数を `bootstrap.sh` スクリプトに渡すことができます。または起動テンプレートのユーザーデータセクションに情報を指定することでこれを行うことができます。 **起動テンプレートを指定しない eksctl** *my-nodegroup.yaml* という名前のファイルを以下の内容で作成します。各*サンプル値*は独自の値に置き換えます。`--apiserver-endpoint`、`--b64-cluster-ca`、および `--dns-cluster-ip` 引数はオプションです。しかし、これらを定義すると、`bootstrap.sh` スクリプトによる `describeCluster` 呼び出しを避けることができます。これはプライベートクラスターのセットアップや、ノードを頻繁にスケールインおよびスケールアウトするクラスターで役立ちます。`bootstrap.sh` スクリプトの詳細については、GitHub で「[bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh)」ファイルを参照してください。 + 必須となる引数はクラスター名 (*マイクラスター*) のみです。 + `ami-1234567890abcdef0 ` に最適化された AMI ID を取得するには、次のセクションを参照してください。 + [推奨 Amazon Linux AMI ID を取得する](retrieve-ami-id.md) + [推奨 Bottlerocket AMI ID を取得する](retrieve-ami-id-bottlerocket.md) + [推奨 Microsoft Windows AMI ID を取得する](retrieve-windows-ami-id.md) + クラスターの *認証機関* を取得するには次のコマンドを実行してください。 ``` aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code ``` + クラスターの *api-server-endpoint* を取得するには次のコマンドを実行してください。 ``` aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code ``` + 最終的に、`--dns-cluster-ip` の値はサービス CIDR を示す `.10` となります。クラスターの *service-cidr* を取得するには次のコマンドを実行してください。例えば、戻り値が `ipv4 10.100.0.0/16` であれば、自分の値は *10.100.0.10* です。 ``` aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code ``` + この例ではカスタムの `max-pods` 値を設定するために `kubelet` 引数を指定します。その際、Amazon EKS 最適化 AMI に含まれている `bootstrap.sh` スクリプトを使用します。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。*my-max-pods-value* を選択する方法については「」を参照してください。マネージド型ノードグループを使用する場合の `maxPods` の決定方法の詳細については、「[maxPods の決定方法](choosing-instance-type.md#max-pods-precedence)」を参照してください。 ``` --- apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-cluster region: region-code managedNodeGroups: - name: my-nodegroup ami: ami-1234567890abcdef0 instanceType: m5.large privateNetworking: true disableIMDSv1: true labels: { x86-al2-specified-mng } overrideBootstrapCommand: | #!/bin/bash /etc/eks/bootstrap.sh my-cluster \ --b64-cluster-ca certificate-authority \ --apiserver-endpoint api-server-endpoint \ --dns-cluster-ip service-cidr.10 \ --kubelet-extra-args '--max-pods=my-max-pods-value' \ --use-max-pods false ``` 利用可能な `eksctl` `config` ファイルオプションについては「`eksctl` ドキュメント」の「[Config file schema](https://eksctl.io/usage/schema/)」(Config ファイルスキーマ) を参照してください。`eksctl` ユーティリティは引き続き起動テンプレートを作成し、`config` ファイルに提供したデータを使用してユーザーデータを設定します。 次のコマンドを使用して、ノードグループを作成します。 ``` eksctl create nodegroup --config-file=my-nodegroup.yaml ``` **起動テンプレートのユーザーデータ** 起動テンプレートのユーザーデータセクションで次の情報を指定します。各*サンプル値*は独自の値に置き換えます。`--apiserver-endpoint`、`--b64-cluster-ca`、および `--dns-cluster-ip` 引数はオプションです。しかし、これらを定義すると、`bootstrap.sh` スクリプトによる `describeCluster` 呼び出しを避けることができます。これはプライベートクラスターのセットアップや、ノードを頻繁にスケールインおよびスケールアウトするクラスターで役立ちます。`bootstrap.sh` スクリプトの詳細については、GitHub で「[bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh)」ファイルを参照してください。 + 必須となる引数はクラスター名 (*マイクラスター*) のみです。 + クラスターの *認証機関* を取得するには次のコマンドを実行してください。 ``` aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code ``` + クラスターの *api-server-endpoint* を取得するには次のコマンドを実行してください。 ``` aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code ``` + 最終的に、`--dns-cluster-ip` の値はサービス CIDR を示す `.10` となります。クラスターの *service-cidr* を取得するには次のコマンドを実行してください。例えば、戻り値が `ipv4 10.100.0.0/16` であれば、自分の値は *10.100.0.10* です。 ``` aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code ``` + この例ではカスタムの `max-pods` 値を設定するために `kubelet` 引数を指定します。その際、Amazon EKS 最適化 AMI に含まれている `bootstrap.sh` スクリプトを使用します。*my-max-pods-value* を選択する方法については「」を参照してください。マネージド型ノードグループを使用する場合の `maxPods` の決定方法の詳細については、「[maxPods の決定方法](choosing-instance-type.md#max-pods-precedence)」を参照してください。 ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==MYBOUNDARY==" --==MYBOUNDARY== Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash set -ex /etc/eks/bootstrap.sh my-cluster \ --b64-cluster-ca certificate-authority \ --apiserver-endpoint api-server-endpoint \ --dns-cluster-ip service-cidr.10 \ --kubelet-extra-args '--max-pods=my-max-pods-value' \ --use-max-pods false --==MYBOUNDARY==-- ``` ### Amazon EKS に最適化された Windows AMI に含まれる `Start-EKSBootstrap.ps1` ファイルに引数を渡すためのユーザーデータを提供する ブートストラップとはインスタンスの起動時に実行できるコマンドの追加を表す用語です。起動テンプレートを指定せずに、`eksctl` を使用して引数を `Start-EKSBootstrap.ps1` スクリプトに渡すことができます。または起動テンプレートのユーザーデータセクションに情報を指定することでこれを行うことができます。 カスタム Windows AMI ID を指定する場合は、次の考慮事項に留意してください。 + 起動テンプレートを使用し、必要なブートストラップコマンドをユーザーデータセクションに入力する必要があります。目的の Windows ID を取得するには、「[最適化された Windows AMI を使用してノードを作成する](eks-optimized-windows-ami.md)」のテーブルを使用できます。 + いくつかの制限と条件があります。例えば、`eks:kube-proxy-windows` を AWS IAM 認証 設定マップに追加する必要があります。詳細については「[AMI ID を指定する場合の制限と条件](#mng-ami-id-conditions)」を参照してください。 起動テンプレートのユーザーデータセクションで次の情報を指定します。各*サンプル値*は独自の値に置き換えます。`-APIServerEndpoint`、`-Base64ClusterCA`、および `-DNSClusterIP` 引数はオプションです。しかし、これらを定義すると、`Start-EKSBootstrap.ps1` スクリプトによる `describeCluster` 呼び出しを避けることができます。 + 必須となる引数はクラスター名 (*マイクラスター*) のみです。 + クラスターの *認証機関* を取得するには次のコマンドを実行してください。 ``` aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code ``` + クラスターの *api-server-endpoint* を取得するには次のコマンドを実行してください。 ``` aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code ``` + 最終的に、`--dns-cluster-ip` の値はサービス CIDR を示す `.10` となります。クラスターの *service-cidr* を取得するには次のコマンドを実行してください。例えば、戻り値が `ipv4 10.100.0.0/16` であれば、自分の値は *10.100.0.10* です。 ``` aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code ``` + その他の引数については「[ブートストラップスクリプトの設定パラメータ](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters)」を参照してください。 **注記** カスタムサービス CIDR を使用している場合は`-ServiceCIDR` パラメータを使用して指定する必要があります。そうしないと、クラスター内の Pod の DNS 解決が失敗します。 ``` [string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1" & $EKSBootstrapScriptFile -EKSClusterName my-cluster ` -Base64ClusterCA certificate-authority ` -APIServerEndpoint api-server-endpoint ` -DNSClusterIP service-cidr.10 ``` ### 特定のセキュリティ、コンプライアンス、または社内的なポリシー要件のために、カスタム AMI を実行する 詳細については*「アマゾン EC2 ユーザーガイド」*の「[アマゾン マシンイメージ (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)」を参照してください。Amazon EKS AMI ビルド仕様にはAmazon Linux をベースにしたカスタム Amazon EKS AMI を構築するためのリソースと設定スクリプトが含まれています。詳細については、GitHubの「[Amazon EKS AMI ビルド仕様](https://github.com/awslabs/amazon-eks-ami/)」を参照してください。他のオペレーティングシステムがインストールされたカスタム AMI を作成するには、GitHubの「[Amazon EKS Sample Custom AMIs](https://github.com/aws-samples/amazon-eks-custom-amis)」を参照してください。 マネージドノードグループで使用される起動テンプレートで AMI ID に動的パラメータ参照を使用することはできません。 **重要** AMI を指定する場合、Amazon EKS はクラスターのコントロールプレーンバージョンに対して AMI に埋め込まれた Kubernetes バージョンを検証しません。ユーザーは、カスタム AMI の Kubernetes バージョンが以下の [Kubernetes バージョンスキューポリシー](https://kubernetes.io/releases/version-skew-policy)に準拠していることを確認する責任があります。 ノード上の `kubelet` バージョンはクラスターバージョンより新しいものであってはならない ノード上の `kubelet` バージョンは、お使いのクラスターバージョン (Kubernetes バージョン `1.28` およびそれ以降) から最大 マイナーバージョン 3 つ前まで、またはクラスターバージョン (Kubernetes バージョン `1.27` およびそれ以前) から最大 マイナーバージョン 2 つ前までである必要がある バージョンスキューポリシーに違反したマネージド型ノードグループを作成すると、次の結果になる可能性があります。 ノードをクラスターに結合できない 未定義の動作または API の非互換性 クラスターの不安定性またはワークロード障害 AMI を指定する際、Amazon EKS ではユーザーデータをマージしません。代わりに、ノードのクラスターへの参加に必要な `bootstrap` コマンドを、ユーザーが提供する必要があります。ノードがクラスターに参加できない場合、アマゾン EKS `CreateNodegroup` および `UpdateNodegroupVersion` アクションも失敗します。 ## AMI ID を指定する場合の制限と条件 以下に、マネージド型ノードグループで AMI ID を指定する際の制限と条件を示します。 + 起動テンプレートで AMI ID を指定する場合と、AMI ID を指定しない場合は新しいノードグループを作成して切り替える必要があります。 + 新しい AMI バージョンが利用可能になっても、コンソールでは通知を表示しません。ノードグループを新しい AMI バージョンに更新するには更新された AMI ID で新しいバージョンの起動テンプレートを作成する必要があります。次に、新しい起動テンプレートバージョンでノードグループを更新する必要があります。 + AMI ID を指定した場合はAPI の次のフィールドを設定することはできません。 + `amiType` + `releaseVersion` + `version` + AMI ID を指定する場合、API で設定されたすべての `taints` は非同期に適用されます。ノードがクラスターに参加する前にテイントを適用するには`--register-with-taints` コマンドラインフラグを使用してユーザーデータ内の `kubelet` にテイントを渡す必要があります。詳細については、Kubernetes ドキュメントの「[kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)」を参照してください。 + Windows マネージド型ノードグループのカスタム AMI ID を指定するときは、AWS IAM オーセンティケーター設定マップに `eks:kube-proxy-windows` を追加します。これはDNS が正しく機能するために必要です。 1. AWS IAM 認証 設定マップを編集用に開きます。 ``` kubectl edit -n kube-system cm aws-auth ``` 1. このエントリを、Windows ノードに関連付けられた各 `rolearn` の下にある `groups` リストに追加します。設定マップは [aws-auth-cm-windows.yaml](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml)に似ているはずです。 ``` - eks:kube-proxy-windows ``` 1. ファイルを保存し、テキストエディタを終了します。 + カスタム起動テンプレートを使用する AMI の場合、マネージドノードグループのデフォルト `HttpPutResponseHopLimit` は `2` に設定されます。