**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# セルフマネージド Amazon Linux ノードを作成する
このトピックでは、Amazon EKS クラスターに登録されている Linux ノードの Auto Scaling グループを起動する方法を説明します。ノードがクラスターに参加したら、それらのノードに Kubernetes アプリケーションをデプロイ可能になります。`eksctl` または AWS マネジメントコンソールを使用して、セルフマネージド型の Amazon Linux ノードを起動することもできます。AWS アウトポスト でノードを起動する必要がある場合は「[AWS Outposts で Amazon Linux ノードを作成する](eks-outposts-self-managed-nodes.md)」を参照してください。
+ 既存の Amazon EKS クラスター。デプロイするには「[Amazon EKS クラスターを作成します。](create-cluster.md)」を参照してください。AWS アウトポスト、AWS 波長、または AWS ローカルゾーンs が有効になっている AWS リージョンにサブネットがある場合はクラスターの作成時にそれらのサブネットが渡されるべきではありません。
+ ノードが使用する既存の IAM 役割。作成する場合は「[Amazon EKS ノードの IAM ロール](create-node-role.md)」を参照してください。この役割に VPC CNI のポリシーがどちらも含まれていない場合、VPC CNI ポッドには以下の別の役割が必要です。
+ (オプションですが推奨) 必要な IAM ポリシーがアタッチされた独自の IAM ロールで構成された Amazon VPC CNI plugin for Kubernetes アドオン。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
+ 「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」に記載されている考慮事項に精通していること。選択したインスタンスタイプによってはクラスターと VPC に関する追加の前提条件がある場合もあります。
セルフマネージド Linux ノードは次のいずれかを使用して起動できます。
+ [`eksctl`](#eksctl_create_managed_amazon_linux)
+ [AWS マネジメントコンソール](#console_create_managed_amazon_linux)
## `eksctl`
**`eksctl` を使用してセルフマネージド型の Linux ノードを起動する**
1. デバイスまたは AWS クラウドシェル にインストールされている `eksctl` コマンドラインツールのバージョン `0.215.0` 以降をインストールします。`eksctl` をインストールまたはアップグレードするには`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。
1. (オプション) **[AmazonEKS\$1CNI\$1Policy]** マネージド IAM ポリシーが [Amazon EKS ノードの IAM ロール](create-node-role.md)にアタッチされている場合は、代わりに Kubernetes `aws-node` サービスアカウントに関連付けた IAM ロールに割り当てることをお勧めします。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
1. 次のコマンドは既存のクラスターにノードグループを作成します。*al-nodes* を、ノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。*マイクラスター* の部分は自分のクラスター名に置き換えます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前はクラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。残りの*サンプル値*は独自の値に置き換えます。デフォルトでは、ノードはコントロールプレーンと同じ Kubernetes バージョンで作成されます。
`--node-type` の値を選択する前に、[「最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を確認してください。
*my-key* を Amazon EC2 キーペアまたはパブリックキーの名前に置き換えます。このキーは起動後のノードに SSH 接続するために使用されます。Amazon EC2 キーペアをまだ持っていない場合はAWS マネジメントコンソール で作成できます。詳細については「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。
次のコマンドを使用して、ノードグループを作成します。
**重要**
ノードグループを AWS アウトポスト、波長、または ローカルゾーンs サブネットにデプロイする場合、追加の考慮事項があります。
クラスターを作成したときに、サブネットが渡されていない必要があります。
ノードグループはサブネットと ` [volumeType](https://eksctl.io/usage/schema/#nodeGroups-volumeType): gp2` を指定する設定ファイルを使用して作成する必要があります。詳細については「`eksctl` ドキュメント」の「[設定ファイルからノードグループを作成する](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file)」と「[設定ファイルのスキーマ](https://eksctl.io/usage/schema/)」を参照してください。
```
eksctl create nodegroup \
--cluster my-cluster \
--name al-nodes \
--node-type t3.medium \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--ssh-access \
--managed=false \
--ssh-public-key my-key
```
次のノードグループをデプロイするには
+ デフォルト設定よりもはるかに多くの IP アドレスを Pod に割り当てることができるノードグループについては、「[プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md)」を参照してください。
+ インスタンスのブロックとは異なる CIDR ブロックから `IPv4` アドレスを Pod に割り当てることができるノードグループについては、「[カスタムネットワーキングを使用して代替サブネットに Pod をデプロイする](cni-custom-network.md)」を参照してください。
+ Pod とサービスに `IPv6` アドレスを割り当てることができるノードグループについては、「[クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md)」を参照してください。
+ アウトバウンドインターネットアクセスがない場合は「[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)」を参照してください。
すべての使用可能なオプションとデフォルト値の一覧を表示するには次のコマンドを入力してください。
```
eksctl create nodegroup --help
```
ノードがクラスターに参加できない場合はトラブルシューティングの章にある「[ノードをクラスターに結合できません](troubleshooting.md#worker-node-fail)」を参照してください。
出力例は次のとおりです。ノードの作成中に、複数の行が出力されます。出力の最後の行は次のサンプル行が表示されます。
```
[✔] created 1 nodegroup(s) in cluster "my-cluster"
```
1. (オプション) [サンプルアプリケーション](sample-deployment.md)をデプロイして、クラスターと Linux ノードをテストします。
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 マネジメントコンソール
**ステップ 1: AWS マネジメントコンソール を使用してセルフマネージド型の リナックス ノードを起動する**`
1. AWS クラウドフォーメーション テンプレートの最新バージョンをダウンロードします。
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-26/amazon-eks-nodegroup.yaml
```
1. クラスターステータスが `ACTIVE` と表示されるまで待ちます。クラスターがアクティブになる前にノードを起動した場合、ノードはクラスターへの登録に失敗し、再起動する必要があります。
1. [AWS クラウドフォーメーション コンソール](https://console.aws.amazon.com/cloudformation/)を開きます。
1. **[スタックの作成]** を選択し、**[新しいリソースを使用 (標準)]** を選択してください。
1. **[テンプレートの指定]** で、**[テンプレートファイルのアップロード]** を選択し、**[ファイルを選択]** を選択してください。
1. ダウンロードした `amazon-eks-nodegroup.yaml` ファイルを選択してください。
1. **[次へ]** を選択してください。
1. **[スタックの詳細の指定]** ページで、必要に応じて次のパラメータを入力し、**[次へ]** を選択してください。
+ **スタック名**: AWS クラウドフォーメーション スタックのスタック名を選択してください。例えば、*マイクラスター-nodes* という名前にすることができます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前はクラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。
+ **[クラスター名]**: Amazon EKS クラスターの作成時に使用した名前を入力してください。この名前はクラスター名と同じにする必要があります。同じでない場合、ノードはクラスターに参加できません。
+ [**クラスター制御プレーンセキュリティグループ**]: [VPC](creating-a-vpc.md) の作成時に生成した AWS クラウドフォーメーション 出力の [**セキュリティグループs**] 値を選択してください。
次のステップでは該当するグループを取得する 1 つのオペレーションを説明します。
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. クラスターの名前を選択してください。
1. **[ネットワーキング]** タブを選択してください。
1. **[クラスター制御プレーンセキュリティグループ]** ドロップダウンリストから選択する場合は**[追加のセキュリティグループ]** の値をリファレンスとして使用します。
+ **[ApiServerEndpoint]**: EKS クラスターの API サーバーエンドポイントを入力します。これは EKS クラスターコンソールの [詳細] セクションにあります。
+ **[CertificateAuthorityData]**: base64 でエンコードされた認証機関データを入力します。これは、EKS クラスターコンソールの [詳細] セクションにもあります。
+ **[ServiceCidr]**: クラスター内の Kubernetes サービスに IP アドレスを割り当てるために使用される CIDR 範囲を入力します。これは、EKS クラスターコンソールの [ネットワーク] タブにあります。
+ **[AuthenticationMode]**: EKS クラスターコンソール内の [アクセス] タブを確認して、EKS クラスターで使用されている認証モードを選択します。
+ **[ノードグループ名]**: ノードグループの名前を入力してください。この名前はノードに対して作成される自動スケーリングノードグループを識別するために後で使用できます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。
+ **[ノードオートスケーリンググループ最小サイズ]**: ノードの 自動スケーリング グループがスケールインできる最小ノード数を入力してください。
+ **ノード自動スケーリンググループ希望容量**: スタック作成時にスケーリングする必要のあるノード数を入力してください。
+ **[NodeAutoScalingGroupMaxSize]**: ノードの 自動スケーリング グループがスケールアウトできる最大ノード数を入力してください。
+ **[ノードインスタンス型]**: ノードのインスタンスタイプを選択してください。詳細については、「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を参照してください。
+ **[NodeImageIdSSMParam]**: 最新の Amazon EKS 最適化 Amazon Linux 2023 AMI の Amazon EC2 Systems Manager のパラメータが、可変 Kubernetes バージョン用に事前設定されています。Amazon EKS でサポートされている別の Kubernetes マイナーバージョンを使用するには、*1.XX* を別の[サポートされているバージョン](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)に置き換えます。クラスターと同じ Kubernetes バージョンを指定することをお勧めします。
*アマゾンリナックス-2023* を別の AMI タイプに置き換えることもできます。詳細については、「[推奨 Amazon Linux AMI ID を取得する](retrieve-ami-id.md)」を参照してください。
**注記**
Amazon EKS ノード AMI は Amazon リナックス をベースとしています。[Amazon Linux セキュリティセンター](https://alas.aws.amazon.com/alas2023.html)で Amazon Linux 2023 のセキュリティイベントまたはプライバシーイベントを追跡するか、関連する [RSS フィード](https://alas.aws.amazon.com/AL2023/alas.rss)をサブスクライブします。セキュリティおよびプライバシーイベントには問題の概要、影響を受けるパッケージ、および問題を修正するためにインスタンスを更新する方法などがあります。
+ **ノードイメージ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/UserGuide/ec2-key-pairs.html)」を参照してください。
+ **[VpcId]**: 作成した [VPC](creating-a-vpc.md) の ID を入力してください。
+ **[Subnets]**: VPC 用に作成したサブネットを選択してください。「[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 アウトポスト、波長、または ローカルゾーンs サブネット を選択する場合はクラスターの作成時にサブネットを渡さないようにします。
1. **[スタックオプションの設定]** ページで、希望する設定を選択し、**[次へ]** を選択してください。
1. **[AWS クラウドフォーメーション が IAM リソースを作成する可能性を認識しています]** の左にあるチェックボックスを選択して、**[スタックの作成]** を選択してください。
1. スタックの作成が完了したら、コンソールで選択し、**[出力]** を選択してください。`EKS API` または `EKS API and ConfigMap` 認証モードを使用している場合は、これが最後のステップです。
1. `ConfigMap` 認証モードを使用している場合は、作成されたノードグループの **NodeInstanceRole** を記録します。
**ステップ 2: ノードを有効にしてクラスターに参加する**
**注記**
次の 2 つのステップは、EKS クラスター内で Configmap 認証モードを使用している場合にのみ必要です。さらに、アウトバウンドのインターネットアクセスのないプライベート VPC でノードを起動する場合はノードが VPC 内からクラスターに参加できるようにしてください。
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:
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
[...]
```
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.yaml
```
1. `aws-auth-cm.yaml` ファイルで、`rolearn` 値を前の手順で記録した **[ノードインスタンス役割]** 値に設定します。これを行うにはテキストエディタを使用するか、*マイノードインスタンス役割* を置き換えて次のコマンドを実行してください。
```
sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml
```
1. 設定を適用します。このコマンドが完了するまで数分かかることがあります。
```
kubectl apply -f aws-auth-cm.yaml
```
1. ノードのステータスを監視し、`Ready` ステータスになるまで待機します。
```
kubectl get nodes --watch
```
`Ctrl`\$1`C` を入力して、シェルプロンプトに戻ります。
**注記**
認可またはリソースタイプのエラーが発生した場合はトラブルシューティングトピックの「[許可されていないか、アクセスが拒否されました (`kubectl`)](troubleshooting.md#unauthorized)」を参照してください。
ノードがクラスターに参加できない場合はトラブルシューティングの章にある「[ノードをクラスターに結合できません](troubleshooting.md#worker-node-fail)」を参照してください。
1. (GPU ノードのみ) GPU インスタンスタイプと Amazon EKS 最適化アクセラレーション AMI を選択した場合はクラスター上の DaemonSet として [Kubernetes 用の NVIDIA デバイスプラグイン](https://github.com/NVIDIA/k8s-device-plugin)を適用する必要があります。次のコマンドを実行する前に、*vX.X.X* を必要となる [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin/releases) バージョンに置き換えます。
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml
```
**ステップ 3: その他のアクション**
1. (オプション) [サンプルアプリケーション](sample-deployment.md)をデプロイして、クラスターと Linux ノードをテストします。
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)」を参照してください。