マネージド型ノードグループの作成 - Amazon EKS

マネージド型ノードグループの作成

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

Amazon EKS マネージド型ノードグループを初めて起動する場合は、代わりに Amazon EKS の使用開始 ガイドに従うことをお勧めします。このガイドでは、ノードを使用して Amazon EKS クラスターを作成するためのウォークスルーを説明します。

重要

前提条件

マネージド型ノードグループを作成するには、eksctl または AWS Management Console を使用します。

eksctl

eksctl を使用してマネージド型ノードグループを作成する

この手順には、eksctl バージョン 0.84.0 以降が必要です。 のバージョンは、以下のコマンドを使用して確認できます。

eksctl version

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

  1. (オプション) AmazonEKS_CNI_Policy が管理する IAM ポリシーが Amazon EKS ノードの IAM ロール に添付されている場合は、代わりに Kubernetes aws-node サービスアカウントに関連付けた IAM ロールに割り当てることをお勧めします。詳細については、「サービスアカウントの IAM ロールを使用する Amazon VPC CNI プラグインの設定」を参照してください。

  2. カスタム起動テンプレートの有無にかかわらず、マネージド型ノードグループを作成します。起動テンプレートを手動で指定すると、ノードグループをより詳細にカスタマイズできます。たとえば、カスタム AMI をデプロイしたり、Amazon EKS 最適化 AMI の boostrap.sh スクリプトの引数を指定したりできます。すべての使用可能なオプションとデフォルト値の一覧を表示するには、次のコマンドを入力します。

    eksctl create nodegroup --help

    example-value をすべて自分の値に置き換えてください。

    重要

    マネージド型ノードグループを最初に作成する際にカスタム起動テンプレートを使用しない場合は、後でノードグループに使用しないでください。カスタム起動テンプレートを指定しなかった場合、システムにより起動テンプレートが自動生成されます。これを手動で変更することはお勧めしません。自動生成された起動テンプレートを手動で変更すると、エラーが発生する場合があります。

    • 起動テンプレートなし: eksctl は、デフォルトの Amazon EC2 起動テンプレートをアカウント内に作成し、指定したオプションに基づいて作成した起動テンプレートを使用して、ノードグループをデプロイします。--node-type の値を指定する前に「Amazon EC2 インスタンスタイプを選択する」を参照してください。

      my-keyを Amazon EC2 キーペアまたはパブリックキーの名前に置き換えます。このキーは、起動後のノードに SSH 接続するために使用されます。Amazon EC2 キーペアをまだ持っていない場合は、AWS Management Console で作成できます。詳細については、Linux インスタンス用 Amazon EC2 ユーザーガイドの「Amazon EC2 キーペア」を参照してください。

      ポッドには必要最低限のアクセス許可のみを与えるように、すべての Kubernetes サービスアカウントに IAM ロールを割当て、クラスター内のポッドが現在の AWS リージョン を取得するなどの理由から Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセス許可を必要としないようにしたい場合は、IMDS へのポッドのアクセスをブロックすることをお勧めします。詳細については、「ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する」を参照してください。IMDS へのポッドのアクセスをブロックするには、--disable-pod-imds オプションを次のコマンドに追加します。

      eksctl create nodegroup \
  --cluster my-cluster \
  --region region-code \
  --name my-mng \
  --node-type m5.large \
  --nodes 3 \
  --nodes-min 2 \
  --nodes-max 4 \
  --ssh-access \
  --ssh-public-key my-key

      ご使用のインスタンスでは、オプションで大量の IP アドレスをポッドに割り当てることや、インスタンスではなく CIDR ブロックからポッドに IP アドレスを割り当てることができます。また、そのインスタンスはインターネットにアクセスできないクラスターにデプロイすることも可能です。詳細については、追加オプションのAmazon EC2 ノードで使用可能な IP アドレスの量を増やす、CNI カスタムネットワークおよび プライベートクラスター を参照して、前のコマンドに追加します。

      マネージドノードグループは、インスタンスタイプに基づいて、ノードグループの各ノードで実行できるポッドの最大数に対して 1 つの値を計算して適用します。異なるインスタンスタイプを持つノードグループを作成する場合、すべてのインスタンスタイプで計算された最小値が、ノードグループ内のすべてのインスタンスタイプで実行できるポッドの最大数として適用されます。マネージド型ノードグループは、各 Amazon EC2 インスタンスタイプの Amazon EKS の推奨最大ポッド数 で参照されているスクリプトを使用して値を計算します。

    • 起動テンプレートの使用: 起動テンプレートがすでに存在している必要があり、また、起動テンプレート設定の基本 で指定されている要件を満たしている必要があります。ポッドには必要最低限のアクセス許可のみを与えるように、すべての Kubernetes サービスアカウントに IAM ロールを割当て、クラスター内のポッドが現在の AWS リージョン を取得するなどの理由から Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセス許可を必要としないようにしたい場合は、IMDS へのポッドのアクセスをブロックすることをお勧めします。詳細については、「ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する」を参照してください。IMDS へのポッドのアクセスをブロックするには、起動テンプレートで必要な設定を行います。

      1. 次の内容で、eks-nodegroup.yaml というファイルを作成します。起動テンプレートなしでデプロイしたときに指定したいくつかの設定は、起動テンプレートに移動されます。version を指定しない場合は、テンプレートのデフォルトバージョンが使用されます。

        apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
  region: region-code
managedNodeGroups:
- name: node-group-lt
  launchTemplate:
    id: lt-id
    version: "1"

        eksctl 設定ファイル使用の詳細については、eksctl ドキュメントの「Config file schema」を参照してください。このインスタンスのオプションでは、ポッドに対する大量の IP アドレスの割り当てや、インスタンスのポッドではなく CIDR ブロックのポッドへの IP アドレスの割り当て、containerd ランタイムの使用などが行えます。さらに、アウトバウンドのインターネットアクセスのないクラスターに対するデプロイも可能です。設定ファイルへの追加に関する他のオプションについては、「Amazon EC2 ノードで使用可能な IP アドレスの量を増やす」、「CNI カスタムネットワーク」、「containerd ランタイムブートストラップフラグを有効にする」、および「プライベートクラスター」を参照してください。

        起動テンプレートで AMI ID を指定しなかった場合、マネージドノードグループは、インスタンスタイプに基づいて、ノードグループの各ノードで実行できるポッドの最大数に対して 1 つの値を計算して適用します。異なるインスタンスタイプを持つノードグループを作成する場合、すべてのインスタンスタイプで計算された最小値が、ノードグループ内のすべてのインスタンスタイプで実行できるポッドの最大数として適用されます。マネージド型ノードグループは、各 Amazon EC2 インスタンスタイプの Amazon EKS の推奨最大ポッド数 で参照されているスクリプトを使用して値を計算します。

        起動テンプレートで AMI ID を指定した場合、カスタムネットワークを使用しているか、またはインスタンスに割り当てられている IP アドレスの数を増やす場合には、ノードグループの各ノードで実行できるポッドの最大数を指定します。詳細については、「各 Amazon EC2 インスタンスタイプの Amazon EKS の推奨最大ポッド数」を参照してください。

      2. 次のコマンドでノードグループをデプロイします。

        eksctl create nodegroup --config-file eks-nodegroup.yaml
AWS Management Console

AWS Management Console を使用してマネージド型ノードグループを作成するには

  1. クラスターステータスが ACTIVE と表示されるまで待ちます。まだ ACTIVE ではないクラスターにはマネージド型ノードグループを作成できません。

  2. Amazon EKS コンソール (https://console.aws.amazon.com/eks/home#/clusters) を開きます。

  3. マネージド型ノードグループを作成するクラスターの名前を選択します。

  4. [Configuration (設定)] タブを選択します。

  5. [設定] タブで、[コンピューティング] タブを選択し、[ノードグループを追加] を選択します。

  6. [Configure node group (ノードグループの設定)] ページで、必要に応じてパラメータを指定し、[次へ] を選択します。

    • [名前]: マネージド型ノードグループの一意の名前を入力します。

    • [ノード IAM ロール名]: ノードグループで使用するノードインスタンスロールを選択します。詳細については、「Amazon EKS ノードの IAM ロール」を参照してください。

      重要

      セルフマネージド型ノードグループによって現在使用されていないロールを使用することをお勧めします。それ以外の場合は、新しいセルフマネージド型ノードグループで使用します。詳細については、「マネージド型ノードグループの削除」を参照してください。

    • 起動テンプレートを使用する — (オプション) 既存の起動テンプレートを使用するかどうかを選択します。次に、[Launch template version] (起動テンプレートのバージョン) (オプション) を選択します。バージョンを選択しない場合、Amazon EKS はテンプレートのデフォルトのバージョンを使用します。起動テンプレートを使用すると、ノードグループを詳細にカスタマイズできます。これにより、カスタム AMI のデプロイ、ポッドへの大量の IP アドレスの割り当て、インスタンスではなく CIDR ブロックからのポッドに対する IP アドレスの割り当て、インスタンスでの containerd ランタイムの有効化、さらにアウトバウンドのインターネットアクセスのないクラスターに対するノードのデプロイが可能になります。詳細については、「Amazon EC2 ノードで使用可能な IP アドレスの量を増やす」、「CNI カスタムネットワーク」、「containerd ランタイムブートストラップフラグを有効にする」、および「プライベートクラスター」を参照してください。

      起動テンプレートは、起動テンプレートのサポート の要件を満たしている必要があります。独自の起動テンプレートを使用しない場合、Amazon EKS API はデフォルトの Amazon EC2 起動テンプレートをアカウントに作成し、デフォルトの起動テンプレートを使用してノードグループをデプロイします。

      サービスアカウントの IAM ロール を実装する場合は、AWS サービスへのアクセス許可を必要とするすべてのポッドに必要なアクセス許可を直接割り当て、クラスター内のポッドが、現在の AWS リージョン を取得するなどの理由で IMDS にアクセスしないようにします。また、起動テンプレートでホストネットワークを使用しないポッドの、IMDS へのアクセスを無効にすることもできます。詳細については、「ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する」を参照してください。

    • [Kubernetes ラベル]: (オプション) マネージド型ノードグループ内のノードに Kubernetes ラベルを適用するように選択できます。

    • [Kubernetes テイント]: (オプション) No_Schedule、Prefer_No_Schedule、またはNo_Executeの影響による Kubernetes のテイントを、マネージド型ノードグループ内のノードに適用するように選択できます。

    • [タグ]: (オプション) Amazon EKS マネージド型ノードグループにタグを付けることを選択できます。これらのタグは、Auto Scaling グループやインスタンスなど、ノードグループ内の他のリソースには伝達されません。詳細については、「Amazon EKS リソースのタグ付け」を参照してください。

    • ノードグループの更新設定 – (オプション) 並行して更新するノードの数または割合を選択できます。[数値] または [パーセンテージ]のいずれかを選択して数値を入力します。これらのノードは、更新中は使用できません。

  7. [コンピューティング構成とスケーリングの設定] ページで、必要に応じてパラメータを指定し、[次へ] を選択します。

    • AMI タイプ — Linux 非 GPU インスタンスには、Amazon Linux 2 (AL2_x86_64)、Linux GPU インスタンスには、Amazon Linux 2 GPU 対応 (AL2_x86_64_GPU)、Linux Arm インスタンスには、Amazon Linux 2 (AL2_ARM_64)、Bottlerocket Arm インスタンスには、Bottlerocket (ARM_64)、または Bottlerocket x86_64 インスタンスには、Bottlerocket (x86_64) を選択します。

      Arm インスタンスをデプロイする場合は、デプロイする前に Amazon EKS 最適化 Arm Amazon Linux AMI の考慮事項を確認してください。

      前のページで起動テンプレートを指定し、起動テンプレートで AMI を指定した場合は、値を選択できません。テンプレートの値が表示されます。テンプレートで指定された AMI は、AMI を指定する の要件を満たしている必要があります。

    • [キャパシティータイプ]: キャパシティタイプを選択します。キャパシティータイプの選択の詳細については、「マネージド型ノードグループのキャパシティータイプ」を参照してください。同じノードグループ内で、異なるキャパシティータイプを混在させることはできません。両方のキャパシティータイプを使用したい場合は、キャパシティータイプとインスタンスタイプをそれぞれに持つ、別々のノードグループを作成します。

    • [インスタンスタイプ]: デフォルトで 1 つ以上のインスタンスタイプが指定されています。デフォルトのインスタンスタイプを削除するには、インスタンスタイプの右側にある X を選択します。マネージド型ノードグループで使用するインスタンスタイプを選択します。

      コンソールには、一般的に使用されるインスタンスタイプのセットが表示されます。サポートされているインスタンスタイプのセットについては、GitHub で「eni-max-pods.txt」リストを参照してください。表示されてないインスタンスタイプを持つマネージド型ノードグループの作成が必要な場合は、eksctl、AWS CLI、AWS CloudFormation、または SDK を使用して、ノードグループを作成します。前のページで起動テンプレートを指定した場合、起動テンプレートでインスタンスタイプを指定する必要があるため、値を選択できません。起動テンプレートの値が表示されます。[キャパシティータイプ] で [スポット] を選択した場合は、可用性を高めるために、複数のインスタンスタイプを指定することをお勧めします。

    • [ディスクサイズ]: ノードのルートボリュームに使用するディスクサイズ (GiB 単位) を入力します。

      前のページで起動テンプレートを指定した場合は、値を起動テンプレートで指定する必要があるため、値を選択できません。

    • [最小サイズ]: マネージド型ノードグループがスケールインできるノードの最小数を指定します。

    • [最大サイズ]: マネージド型ノードグループがスケールアウトできるノードの最大数を指定します。

    • [必要なサイズ]: マネージド型ノードグループが起動時に保持する必要があるノードの現在の数を指定します。

      注記

      Amazon EKS は、ノードグループを自動的にスケールインまたはスケールアウトしません。ただし、これを行うように Kubernetes Cluster Autoscaler を設定することはできます。

    • [使用できない最大値] で、次のいずれかのオプションを選択し、その [値] を指定します:

      • [数値]: 並行して更新できるノードグループ内のノード数を選択して指定します。これらのノードは、更新中は使用できません。

      • [パーセンテージ]: 並行して更新できるノードグループ内のノードの割合を選択して指定します。これらのノードは、更新中は使用できません。ノードグループに多数のノードがある場合に便利です。

  8. [ネットワーキングを指定] ページで、必要に応じてパラメータを指定し、[次へ] を選択します。

    • [サブネット]: マネージド型ノードを起動するサブネットを選択します。

      重要

      Amazon EBS ボリュームによってバックアップされ、Kubernetes Cluster Autoscaler を使用する複数のアベイラビリティーゾーンにわたってステートフルアプリケーションを実行している場合、それぞれが単一のアベイラビリティーゾーンにスコープされる複数のノードグループを設定する必要があります。また、--balance-similar-node-groups 機能を有効にする必要があります。

      重要

      • パブリックサブネットを選択し、クラスターでパブリック API サーバーのエンドポイントのみが有効になっている場合は、サブネットの MapPublicIPOnLaunch に true をセットして、インスタンスがクラスターに正常に参加できるようにします。サブネットが eksctl、または 2020 年 3 月 26 日以降に Amazon EKS が販売した AWS CloudFormation テンプレートを使用して作成された場合、この設定はすでに true に設定されています。サブネットが eksctl または AWS CloudFormation テンプレートで 2020 年 3 月 26 日 より前に作成されている場合は、設定を手動で変更する必要があります。詳細については、「サブネットの IPv4 アドレス指定属性の変更」を参照してください。

      • 起動テンプレートを使用しており、複数のネットワークインターフェイスを指定している場合には、たとえ MapPublicIpOnLaunch が true に設定されていても、Amazon EC2 はパブリック IPv4 アドレスの自動的な割り当てを行いません。このシナリオでノードがクラスターに参加するには、クラスターのプライベート API サーバーエンドポイントを有効にするか、NAT ゲートウェイなどの別の方法によってアウトバウンドインターネットアクセスを提供する、プライベートサブネットでノードを起動する必要があります。詳しくは、Linux インスタンス用 Amazon EC2 ユーザーガイドの Amazon EC2 インスタンスの IP アドレス指定を参照してください｡

    • ノードへの SSH アクセスの設定 (オプション)。SSH を有効にすることにより、インスタンスに接続し、問題がある場合に診断情報を収集できます。リモートアクセスを有効にするには、以下の手順に従います。ノードグループを作成するときは、リモートアクセスを有効にすることを強くお勧めします。ノードグループの作成後にリモートアクセスを有効にすることはできません。

      起動テンプレートの使用を選択した場合、このオプションは表示されません。ノードへのリモートアクセスを有効にするには、起動テンプレートでキーペアを指定し、起動テンプレートで指定したセキュリティグループのノードに対して適切なポートが開いていることを確認します。詳細については、「カスタムセキュリティグループを使用する」を参照してください。

    • [SSH キーペア] (オプション) の場合は、使用する Amazon EC2 SSH キーを選択します。詳細については、Linux インスタンス用 Amazon EC2 ユーザーガイドの「Amazon EC2 キーペア」を参照してください。起動テンプレートを使用することを選択した場合、選択することはできません。Bottlerocket AMI を使用するノードグループに Amazon EC2 SSH キーが提供されると、管理コンテナも有効になります。詳細については、GitHub の Admin container を参照してください。

    • [次からの SSH リモートアクセスを許可する] の場合、特定のインスタンスへのアクセスを制限するには、それらのインスタンスに関連付けられているセキュリティグループを選択します。特定のセキュリティグループを選択しないと、インターネット上のどの場所 (0.0.0.0/0) からでも SSH アクセスが許可されます。

  9. [確認と作成] ページで、マネージド型ノードグループの設定を確認し、[作成] を選択します。

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

  10. ノードのステータスを監視し、Ready ステータスになるまで待機します。

    kubectl get nodes --watch

  11. (GPU ノードのみ) GPU インスタンスタイプと Amazon EKS 最適化 高速 AMI を選択した場合は、NVIDIA device plugin for Kubernetes を、次のコマンドを使ってクラスターに設定されたデーモンセットとして適用しなければなりません。

    kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.9.0/nvidia-device-plugin.yml

  12. (オプション) Linux ワーカーノードをクラスターに追加したら、「Windows サポート」の手順に従って Windows サポートをクラスターに追加し、Windows ワーカーノードを追加します。クラスターで Windows ワークロードのみを実行する場合でも、すべての Amazon EKS クラスターには 1 つ以上の Linux ワーカーノードが含まれている必要があります。

ノードが関連付けられた Amazon EKS クラスターが実行中になったところで、Kubernetes アドオンのインストールとクラスターへのアプリケーションのデプロイを開始できます。以下のトピックは、クラスターの機能を拡張するのに役立ちます。

  • クラスターを作成した IAM エンティティ (ユーザーまたはロール) は、kubectl を使用して Kubernetes API サーバーを呼び出すことができる唯一の IAM ユーザーです。他のユーザーがクラスターにアクセスできるようにする場合は、クラスターへの IAM ユーザーおよびロールアクセスを有効にするを参照してください。

  • インスタンスメタデータサービスへのアクセスを制限する – IAM ロールをすべての Kubernetes サービスアカウントに割り当てることを計画している場合、ポッドには必要な最小限のアクセス許可のみを付与します。さらに、(現在の AWS リージョン の取得など) 他の理由で、クラスター内のポッドが Amazon EC2 インスタンスメタデータサービス (IMDS) にアクセスしないようにします。このためには、ポッドによる IMDS へのアクセスをブロックすることをお勧めします。詳細については、「ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する」を参照してください。

  • Cluster Autoscaler – ノードグループ内のノード数を自動的に調整するように、Kubernetes Cluster Autoscaler を設定します。

  • サンプルアプリケーションをクラスターにデプロイします。

  • クラスターの管理 – クラスター管理のための重要なツールを使用する方法を解説します。