**このページの改善にご協力ください** このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。 # クラスターのマネージドノードグループを作成する このトピックでは、Amazon EKS クラスターに登録しているノードの、Amazon EKS マネージド型ノードグループを起動する方法を説明します。ノードがクラスターに参加したら、それらのノードに Kubernetes アプリケーションをデプロイ可能になります。 Amazon EKS マネージド型ノードグループを初めて起動する場合は、[Amazon EKS の使用を開始する](getting-started.md) のガイドのいずれかに従うことをお勧めします。このガイドでは、ノードを使用して Amazon EKS クラスターを作成するためのウォークスルーを説明します。 **重要** Amazon EKS ノードは、標準の Amazon EC2 インスタンスです。通常の Amazon EC2 料金に基づいて請求されます。詳細については、[Amazon EC2 の料金表](https://aws.amazon.com/ec2/pricing/)を参照してください。 AWS Outposts または AWS Wavelength が有効になっている AWS リージョンでは、マネージドノードを作成できません。ユーザーは代わりに、セルフマネージド型ノードを作成できます。詳細については[セルフマネージド Amazon Linux ノードを作成する](launch-workers.md)、[セルフマネージド Microsoft Windows ノードの作成](launch-windows-workers.md)、および[セルフマネージド Bottlerocket ノードの作成](launch-node-bottlerocket.md)を参照してください。また、Outpost に自己管理型 Amazon Linux ノードグループを作成することもできます。詳細については、「[AWS Outposts で Amazon Linux ノードを作成する](eks-outposts-self-managed-nodes.md)」を参照してください。 Amazon EKS 最適化 Linux または Bottlerocket に含まれる `bootstrap.sh` ファイル用に [AMI ID を指定](launch-templates.md#launch-template-custom-ami)しない場合、マネージドノードグループは `maxPods` の値に最大数を適用します。vCPU が 30 未満のインスタンスの場合、最大数は `110` です。30 を超える vCPU を持つインスタンスの場合、最大数は `250` に跳ね上がります。この適用は、`maxPodsExpression` を含む他の `maxPods` 設定を上書きします。`maxPods` の決定方法とカスタマイズ方法の詳細については、「[maxPods の決定方法](choosing-instance-type.md#max-pods-precedence)」を参照してください。 + 既存の Amazon EKS クラスター。デプロイするには「[Amazon EKS クラスターを作成します。](create-cluster.md)」を参照してください。 + ノードが使用する既存の 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 に関する追加の前提条件がある場合もあります。 + Windows マネージドノードグループを追加するには、まずクラスターの Windows サポートを有効にする必要があります。詳細については、「[EKS クラスターに WiWindows ノードをデプロイする](windows-support.md)」を参照してください。 マネージド型ノードグループを作成するには、以下のいずれかを使用します。 + [`eksctl`](#eksctl_create_managed_nodegroup) + [AWS マネジメントコンソール](#console_create_managed_nodegroup) ## `eksctl` **eksctl を使用してマネージド型ノードグループを作成する** この手順には、`eksctl` バージョン `0.215.0` 以降が必要です。お使いのバージョンは、以下のコマンドを使用して確認できます。 ``` eksctl version ``` `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. カスタム起動テンプレートの有無にかかわらず、マネージド型ノードグループを作成します。起動テンプレートを手動で指定すると、ノードグループをより詳細にカスタマイズできます。たとえば、カスタム AMI をデプロイしたり、Amazon EKS 最適化 AMI の `boostrap.sh` スクリプトの引数を指定したりできます。すべての使用可能なオプションとデフォルト値の一覧を表示するには、次のコマンドを入力します。 ``` eksctl create nodegroup --help ``` 次のコマンドで、*my-cluster* をクラスターの名前に置き換え、*my-mng* をノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。 **重要** マネージド型ノードグループを最初に作成する際にカスタム起動テンプレートを使用しない場合は、後でノードグループに使用しないでください。カスタム起動テンプレートを指定しなかった場合、システムにより起動テンプレートが自動生成されます。これを手動で変更することはお勧めしません。自動生成された起動テンプレートを手動で変更すると、エラーが発生する場合があります。 **起動テンプレートなし** `eksctl` は、デフォルトの Amazon EC2 起動テンプレートをアカウント内に作成し、指定したオプションに基づいて作成した起動テンプレートを使用してノードグループをデプロイします。`--node-type` の値を指定する前に「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を参照してください。 *ami-family* を許可されているキーワードに置き換えます。詳細については、「`eksctl` ドキュメント」の「[Setting the node AMI Family](https://eksctl.io/usage/custom-ami-support/#setting-the-node-ami-family)」(ノード AMI ファミリーの設定) を参照してください。*my-key* を Amazon EC2 キーペアまたはパブリックキーの名前に置き換えます。このキーは起動後のノードに SSH 接続するために使用されます。 **注記** Windows の場合、このコマンドは SSH を有効にしません。代わりに Amazon EC2 キーペアをインスタンスに関連付け、インスタンスに RDP できるようにします。 Amazon EC2 キーペアをまだ持っていない場合は、AWS マネジメントコンソール で作成できます。Linux の詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 key pairs and Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。Windows の詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 key pairs and Windows instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html)」を参照してください。 次の条件が 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)」を参照してください。 IMDS への Pod のアクセスをブロックするには、`--disable-pod-imds` オプションを次のコマンドに追加します。 ``` eksctl create nodegroup \ --cluster my-cluster \ --region region-code \ --name my-mng \ --node-ami-family ami-family \ --node-type m5.large \ --nodes 3 \ --nodes-min 2 \ --nodes-max 4 \ --ssh-access \ --ssh-public-key my-key ``` ご使用のインスタンスでは、オプションで大量の IP アドレスをポッドに割り当てることや、インスタンスではなく CIDR ブロックから Pod に IP アドレスを割り当てることができます。また、そのインスタンスはインターネットにアクセスできないクラスターにデプロイすることも可能です。詳細については、追加オプションの[プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md)、[カスタムネットワーキングを使用して代替サブネットに Pod をデプロイする](cni-custom-network.md)および [インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md) を参照して、前のコマンドに追加します。 マネージドノードグループは、インスタンスタイプに基づいて、ノードグループの各ノードで実行できる Pod の最大数に対して 1 つの値を計算して適用します。異なるインスタンスタイプを持つノードグループを作成する場合、すべてのインスタンスタイプで計算された最小値が、ノードグループ内のすべてのインスタンスタイプで実行できる Pod の最大数として適用されます。マネージドノードグループは、で参照するスクリプトを使用して値を計算します。 **起動テンプレートの使用** 起動テンプレートがすでに存在している必要があり、また、「[起動テンプレート設定の基本](launch-templates.md#launch-template-basics)」で指定されている要件を満たしている必要があります。次の条件が 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)」を参照してください。 IMDS への Pod のアクセスをブロックするには、起動テンプレートで必要な設定を行います。 1. 次のコンテンツをデバイスにコピーします。サンプル値を置き換えたら、変更したコマンドを実行して `eks-nodegroup.yaml` ファイルを作成します。起動テンプレートなしでデプロイしたときに指定したいくつかの設定は、起動テンプレートに移動されます。`version` を指定しない場合は、テンプレートのデフォルトバージョンが使用されます。 ``` cat >eks-nodegroup.yaml < **AWS マネジメントコンソール を使用してマネージド型ノードグループを作成する** 1. クラスターステータスが `ACTIVE` と表示されるまで待ちます。まだ `ACTIVE` ではないクラスターにはマネージド型ノードグループを作成できません。 1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。 1. マネージド型ノードグループを作成するクラスターの名前を選択します。 1. **[コンピューティング]** タブを選択します。 1. **[ノードグループを追加]** を選択します。 1. **[ノードグループの設定]** ページで、必要に応じてパラメータを指定し、**[次へ]** を選択します。 + **[名前]** – マネージド型ノードグループの一意の名前を入力します。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。 + **[ノード IAM ロール]** – ノードグループで使用するノードインスタンスロールを選択します。詳細については、「[Amazon EKS ノードの IAM ロール](create-node-role.md)」を参照してください。 **重要** クラスターの作成に使用したロールは使用できません。 セルフマネージド型ノードグループによって現在使用されていないロールを使用することをお勧めします。それ以外の場合は、新しいセルフマネージド型ノードグループで使用します。詳細については、「[クラスターからマネージドノードグループを削除する](delete-managed-node-group.md)」を参照してください。 + **起動テンプレートを使用する** — (オプション) 既存の起動テンプレートを使用するかどうかを選択します。**[起動テンプレート名]** を選択します。次に、**[起動テンプレートのバージョン]** を選択します。バージョンを選択しない場合、Amazon EKS はテンプレートのデフォルトのバージョンを使用します。起動テンプレートを使用すると、ノードグループを詳細にカスタマイズできます。これにより、カスタム AMI のデプロイ、ポッドへの大量の IP アドレスの割り当て、インスタンスのブロックとは異なる CIDR ブロックからのポッドに対する IP アドレスの割り当て、さらにアウトバウンドのインターネットアクセスのないクラスターに対するノードのデプロイが可能になります。詳細については[プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md)、[カスタムネットワーキングを使用して代替サブネットに Pod をデプロイする](cni-custom-network.md)、および[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)を参照してください。 起動テンプレート は、「[起動テンプレートを使用してマネージドノードをカスタマイズする](launch-templates.md)」の要件を満たしている必要があります。独自の起動テンプレートを使用しない場合、Amazon EKS API はデフォルトの Amazon EC2 起動テンプレートをアカウントに作成し、デフォルトの起動テンプレートを使用してノードグループをデプロイします。 [サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md)を実装する場合は、AWS サービスへのアクセス許可を必要とするすべての Pod に必要なアクセス許可を直接割り当て、クラスター内の Pod が、現在の AWS リージョンを取得するなどの理由で IMDS にアクセスしないようにします。また、起動テンプレートでホストネットワークを使用しないポッドの、IMDS へのアクセスを無効にすることもできます。詳細については、「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。 + [**Kubernetes ラベル**]: (オプション) マネージド型ノードグループ内のノードに Kubernetes ラベルを適用するように選択できます。 + **Kubernetes テイント** - (オプション) 管理対象ノードグループ内のノードに Kubernetes テイントを適用することを選択できます。**[効果]** メニューでの利用可能なオプションは ` NoSchedule `、` NoExecute `、および ` PreferNoSchedule ` です。詳細については、「[レシピ: 特定のノードでポッドがスケジュールされないようにする](node-taints-managed-node-groups.md)」を参照してください。 + **[タグ]** – (オプション) Amazon EKS マネージド型ノードグループにタグを付けることを選択できます。これらのタグは、Auto Scaling グループやインスタンスなど、ノードグループ内の他のリソースには伝達されません。詳細については、「[タグを使用して Amazon EKS リソースを整理する](eks-using-tags.md)」を参照してください。 1. **[コンピューティング構成とスケーリングの設定]** ページで、必要に応じてパラメータを指定し、**[次へ]** を選択します。 + **[AMI タイプ]** – AMI タイプを選択します。Arm インスタンスをデプロイする場合は、デプロイする前に「[Amazon EKS optimized Arm Amazon Linux AMIs](eks-optimized-ami.md#arm-ami)」の考慮事項を確認してください。 前のページで起動テンプレートを指定し、起動テンプレートで AMI を指定した場合は、値を選択できません。テンプレートの値が表示されます。テンプレートで指定された AMI は、「[AMI の指定](launch-templates.md#launch-template-custom-ami)」の要件を満たしている必要があります。 + **[キャパシティータイプ]** – キャパシティタイプを選択します。キャパシティータイプの選択の詳細については、「[マネージド型ノードグループのキャパシティータイプ](managed-node-groups.md#managed-node-group-capacity-types)」を参照してください。同じノードグループ内で、異なるキャパシティータイプを混在させることはできません。両方のキャパシティータイプを使用したい場合は、キャパシティータイプとインスタンスタイプをそれぞれに持つ、別々のノードグループを作成します。GPU アクセラレーテッドワーカーノードのプロビジョニングとスケーリングについては、「[マネージドノードグループの GPU を予約する](https://docs.aws.amazon.com/eks/latest/userguide/capacity-blocks-mng.html)」を参照してください。 + **[インスタンスタイプ]** – デフォルトで 1 つまたは複数のインスタンスタイプが指定されています。デフォルトのインスタンスタイプを削除するには、インスタンスタイプの右側にある `X` を選択します。マネージド型ノードグループで使用するインスタンスタイプを選択します。詳細については、「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を参照してください。 コンソールには、一般的に使用されるインスタンスタイプのセットが表示されます。表示されてないインスタンスタイプを持つマネージド型ノードグループの作成が必要な場合は、`eksctl`、AWS CLI、AWS CloudFormation、または SDK を使用して、ノードグループを作成します。前のページで起動テンプレートを指定した場合、起動テンプレートでインスタンスタイプを指定する必要があるため、値を選択できません。起動テンプレートの値が表示されます。[**キャパシティータイプ**] で [**スポット**] を選択した場合は、可用性を高めるために、複数のインスタンスタイプを指定することをお勧めします。 + **[ディスクサイズ]** – ノードのルートボリュームに使用するディスクサイズ (GiB 単位) を入力します。 前のページで起動テンプレートを指定した場合は、値を起動テンプレートで指定する必要があるため、値を選択できません。 + **[必要なサイズ]** – マネージド型ノードグループが起動時に保持する必要があるノードの現在の数を指定します。 **注記** Amazon EKS は、ノードグループを自動的にスケールインまたはスケールアウトしません。ただし、これを行うように Kubernetes Cluster Autoscaler を設定することはできます。詳細については、「[AWS の Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)」を参照してください。 + **[最小サイズ]** – マネージド型ノードグループがスケールインできるノードの最小数を指定します。 + **[最大サイズ]** – マネージド型ノードグループがスケールアウトできるノードの最大数を指定します。 + **ノードグループの更新設定** – (オプション) 並行して更新するノードの数または割合を選択できます。これらのノードは、更新中は使用できません。**[使用できない最大値]** で、次のいずれかのオプションを選択し、その **[値]** を指定します: + **[数値]** – 並行して更新できるノードグループ内のノード数を選択して指定します。 + **[パーセンテージ]** – 並行して更新できるノードグループ内のノードの割合を選択して指定します。ノードグループに多数のノードがある場合に便利です。 + **ノードの自動修復設定** – (オプション) **[ノードの自動修復を有効にする]** チェックボックスを有効にすると、Amazon EKS は検出された問題が発生したときにノードを自動的に置き換えます。詳細については、「[ノードのヘルス問題を検出し、自動ノード修復を有効にする](node-health.md)」を参照してください。 1. **[ネットワーキングを指定]** ページで、必要に応じてパラメータを指定し、**[次へ]** を選択します。 + **[サブネット]**: マネージド型ノードを起動するサブネットを選択します。 **重要** Amazon EBS ボリュームによってバックアップされ、Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) を使用する複数のアベイラビリティーゾーンにわたってステートフルアプリケーションを実行している場合、それぞれが単一のアベイラビリティーゾーンにスコープされる複数のノードグループを設定する必要があります。また、`--balance-similar-node-groups` 機能を有効にする必要があります。 **重要** パブリックサブネットを選択し、クラスターでパブリック API サーバーのエンドポイントのみが有効になっている場合は、サブネットの `MapPublicIPOnLaunch` に `true` をセットして、インスタンスがクラスターに正常に参加できるようにします。サブネットが 2020 年 3 月 26 日以降に `eksctl` または [Amazon EKS で発行された AWS CloudFormation テンプレート](creating-a-vpc.md)を使用して作成された場合は、この設定はすでに `true` に設定されています。サブネットが 2020 年 3 月 26 日より前に `eksctl` または AWS CloudFormation テンプレートを使用して作成されている場合は、設定を手動で変更する必要があります。詳細については「[サブネットの IPv4 アドレス指定属性の変更](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)」を参照してください。 起動テンプレートを使用しており、複数のネットワークインターフェイスを指定している場合には、たとえ `MapPublicIpOnLaunch` が `true` に設定されていても、Amazon EC2 はパブリック `IPv4` アドレスの自動的な割り当てを行いません。このシナリオでノードがクラスターに参加するには、クラスターのプライベート API サーバーエンドポイントを有効にするか、NAT ゲートウェイなどの別の方法によってアウトバウンドインターネットアクセスを提供する、プライベートサブネットでノードを起動する必要があります。詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 インスタンスの IP アドレス指定](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html)」を参照してください。 + **ノードへの SSH アクセスの設定** (オプション)。SSH を有効にすることにより、インスタンスに接続し、問題がある場合に診断情報を収集できます。ノードグループを作成するときは、リモートアクセスを有効にすることを強くお勧めします。ノードグループの作成後にリモートアクセスを有効にすることはできません。 起動テンプレートの使用を選択した場合、このオプションは表示されません。ノードへのリモートアクセスを有効にするには、起動テンプレートでキーペアを指定し、起動テンプレートで指定したセキュリティグループのノードに対して適切なポートが開いていることを確認します。詳細については、「[カスタムセキュリティグループを使用する](launch-templates.md#launch-template-security-groups)」を参照してください。 **注記** Windows の場合、このコマンドは SSH を有効にしません。代わりに Amazon EC2 キーペアをインスタンスに関連付け、インスタンスに RDP できるようにします。 + **[SSH キーペア]** (オプション) の場合は、使用する Amazon EC2 SSH キーを選択します。Linux の詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 key pairs and Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。Windows の詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 key pairs and Windows instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html)」を参照してください。起動テンプレートを使用することを選択した場合、選択することはできません。Bottlerocket AMI を使用するノードグループに Amazon EC2 SSH キーが提供されると、管理コンテナも有効になります。詳細については、GitHub の [Admin container](https://github.com/bottlerocket-os/bottlerocket#admin-container) を参照してください。 + **[次からの SSH リモートアクセスを許可する]** の場合、特定のインスタンスへのアクセスを制限するには、それらのインスタンスに関連付けられているセキュリティグループを選択します。特定のセキュリティグループを選択しないと、インターネット上のどの場所 (`0.0.0.0/0`) からでも SSH アクセスが許可されます。 1. **[確認と作成]** ページで、マネージド型ノードグループの設定を確認し、**[作成]** を選択してください。 ノードがクラスターに参加できない場合はトラブルシューティングの章にある「[ノードをクラスターに結合できません](troubleshooting.md#worker-node-fail)」を参照してください。 1. ノードのステータスを監視し、`Ready` ステータスになるまで待機します。 ``` kubectl get nodes --watch ``` 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 ``` ## Kubernetes アドオンをインストールする ノードが関連付けられた Amazon EKS クラスターが実行中になったところで、Kubernetes アドオンのインストールとクラスターへのアプリケーションのデプロイを開始できます。以下のトピックはクラスターの機能を拡張するのに役立ちます。 + クラスターを作成した [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)は、`kubectl` または AWS マネジメントコンソール を使用して Kubernetes API サーバーを呼び出すことができる唯一のプリンシパルです。他の IAM プリンシパルがクラスターにアクセスできるようにする場合はそれらを追加する必要があります。詳細については、「[IAM ユーザーおよびロールに Kubernetes API へのアクセスを付与する](grant-k8s-access.md)」および「[必要なアクセス許可](view-kubernetes-resources.md#view-kubernetes-resources-permissions)」を参照してください。 + 次の条件が 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)」を参照してください。 + ノードグループ内のノード数を自動的に調整するように Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) を設定します。 + [サンプルアプリケーション](sample-deployment.md)をクラスターにデプロイします。 + クラスターを管理するための重要なツールを使用して、[クラスターリソースを整理およびモニタリング](eks-managing.md)します。