この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。

EKSクラスター設定リファレンス

アカウントアクセス

IAMポリシー用に取得した情報を使って、各ドロップダウンとフィールドを入力してください。

設定 説明

地域

ドロップダウンから、クラスターを構築するリージョンを選択してください。

クラウド資格情報

IAMポリシーのために作成したクラウドクレデンシャルを選択してください。Rancherでクラウドクレデンシャルを作成する方法の詳細については、このページを参照してください。

サービスロール

サービスロールを選択してください。

サービスロール 説明

標準:Rancherが生成したサービスロール

このロールを選択すると、Rancherはクラスターで使用するためのサービスロールを自動的に追加します。

カスタム:既存のサービスロールから選択してください

このロールを選択すると、RancherはAWS内で既に作成したサービスロールから選択できるようにします。AWSでカスタムサービスロールを作成する方法の詳細については、 Amazonのドキュメントを参照してください。

シークレット暗号化

オプション:秘密を暗号化するには、 AWSキー管理サービス(KMS)で作成したキーを選択または入力してください。

APIサーバーエンドポイントアクセス

パブリック/プライベートAPIアクセスの構成は、高度なユースケースです。詳細については、EKSクラスターエンドポイントアクセス制御に関する ドキュメントを参照してください。

プライベート専用APIエンドポイント

クラスターを作成する際にプライベートを有効にし、パブリックAPIエンドポイントアクセスを無効にすると、Rancherがクラスターに正常に接続するために追加の手順が必要です。この場合、Rancherにクラスターを登録するためのコマンドが記載されたポップアップが表示されます。クラスターがプロビジョニングされると、クラスターのKubernetes APIに接続できる場所で表示されたコマンドを実行できます。

この追加の手動ステップを回避する方法は2つあります:

  • クラスター作成時に、プライベートおよびパブリックAPIエンドポイントアクセスの両方を持つクラスターを作成できます。クラスターが作成され、アクティブな状態になった後にパブリックアクセスを無効にすることができ、RancherはEKSクラスターと引き続き通信します。

  • RancherがEKSクラスターと同じサブネットを共有することを確認できます。その後、セキュリティグループを使用してRancherがクラスターのAPIエンドポイントと通信できるようにします。この場合、クラスターを登録するためのコマンドは必要なく、Rancherはクラスターと通信できるようになります。セキュリティグループの設定に関する詳細情報は、 セキュリティグループのドキュメントを参照してください。

パブリックアクセスエンドポイント

オプションで、明示的なCIDRブロックを介してパブリックエンドポイントへのアクセスを制限できます。

特定のCIDRブロックへのアクセスを制限する場合は、クラスターへのネットワーク通信を失わないようにプライベートアクセスも有効にすることをお勧めします。

プライベートアクセスを有効にするには、以下のいずれかが必要です:

  • RancherのIPは許可されたCIDRブロックの一部でなければなりません。

  • プライベートアクセスを有効にし、Rancherはクラスターと同じサブネットを共有し、クラスターへのネットワークアクセスを持つ必要があります。これはセキュリティグループで設定できます。

クラスターエンドポイントへのパブリックおよびプライベートアクセスに関する詳細情報は、 Amazon EKSのドキュメントを参照してください。

IPv6 / デュアルスタックネットワーキング

Rancherは、IPv6ネットワークルーティングを使用してAmazon EKSクラスターのプロビジョニングと管理をサポートしています。IPv6が有効になると、KubernetesポッドとサービスにIPv6アドレスが割り当てられます。ただし、基盤となるEC2ワーカーノードは*デュアルスタックモード*で動作し(IPv4およびIPv6アドレスの両方を受信します)。このデュアルスタックアーキテクチャにより、ノードはIPv4を介してAWS APIおよびKubernetesコントロールプレーンと通信し、アプリケーションワークロードはIPv6を介して通信できることが保証されます。

Rancher UIからデュアルスタッククラスターをプロビジョニングするには:

  1. クラスター作成中に、*Networking*セクションを開きます。

  2. *IP Family*の下で、*IPv6*ラジオボタンを選択します。

    IPファミリーを変更すると、フォームで行った現在のサブネット選択がクリアされます。

  3. *VPCs and Subnets*の下で、*新しいVPCとサブネットを自動的に作成する*か、*既存のサブネットから選択する*のいずれかを選択します。

    カスタムVPCに関する警告

    既存のサブネットを選択する場合、*必ず*デュアルスタックサブネットを選択する必要があります。選択したサブネットには、IPv4 CIDRブロックとIPv6 CIDRブロックの両方が必要です。IPv6専用のサブネットはサポートされていません。

  4. クラスター構成の残りの部分(ノードグループなど)を完了します。

  5. 作成]をクリックします。

IPファミリー設定は*不変*です。EKSクラスターが作成された後、IPv4クラスターをIPv6に変換することも、IPv6クラスターをIPv4に変換することもできません。

既存のIPv6クラスターのインポート

Rancherは、Rancherの外部でIPv6ネットワーキングで構成された既存のAmazon EKSクラスターの登録(インポート)を完全にサポートしています(例:TerraformやAWSコンソールを介して)。

既存のEKSクラスターを登録する際:

  1. 標準のクラスター登録プロセスに従います(クラスター管理 > クラスターの追加 > 一般)。

  2. RancherはAWS EKS APIにクエリを送信して、クラスターのアップストリーム状態を読み取ります。

  3. Rancherは、クラスターがIPv6でプロビジョニングされたかどうかを自動的に検出します。

IPv6クラスターを構成する際には、いくつかの自動化された動作と厳格な要件が適用されます:

  • *サービスCIDR:*AWSは固定IPv6範囲からサービスCIDRを自動的に割り当てます(fd00::/108)。IPv6クラスターのサービスCIDRをカスタマイズすることはできません。

  • OIDCプロバイダー(IRSA)要件:*IPv6クラスターでは、Amazon VPC CNIプラグインは、Elastic Network Interfaces(ENI)にIPv6プレフィックスを割り当てるためにIAM権限を厳格に要求します。この認証は、サービスアカウントのためのIAMロール(IRSA)を介して処理されます。したがって、IPv6クラスターをプロビジョニングする際には、*IAM OIDCプロバイダーは必須であり、Rancherによって自動的に有効化されます。それがないと、ポッドはIPアドレスを取得できません。

EKSクラスター設定の参照例(IPv6)

`eksclusterconfigs.eks.cattle.io`カスタムリソースを使用してプログラム的にEKSクラスターをデプロイする場合、`ipFamily`フィールドを`ipv6`に設定することでIPv6を有効にできます。

以下は、IPv6用に構成された最小限の`EKSClusterConfig`の例です。`ipFamily`が設定されており、AWSがIPv6モードで自動的に管理するため、`serviceCidr`のような標準IPv4フィールドは省略されていることに注意してください。

apiVersion: eks.cattle.io/v1
kind: EKSClusterConfig
metadata:
  name: my-ipv6-cluster
  namespace: cluster-fleet-default
spec:
  amazonCredentialSecret: cattle-global-data/my-aws-credentials
  displayName: my-ipv6-cluster
  region: us-west-2
  imported: false
  kubernetesVersion: "1.33"
  ipFamily: "ipv6" # Enables Dual-Stack IPv6 networking. Triggers automatic OIDC creation.
  nodeGroups:
    - nodegroupName: initial-nodegroup
      desiredSize: 2
      maxSize: 3
      minSize: 1
      instanceType: t3.medium
      diskSize: 20
      requestSpotInstances: false
      version: "1.33"
  privateAccess: false
  publicAccess: true
  secretsEncryption: false

サブネット

オプション 説明

標準:Rancherが生成したVPCとサブネット

クラスターをプロビジョニングする際、Rancherは3つのパブリックサブネットを持つ新しいVPCを生成します。

カスタム:既存のVPCとサブネットから選択してください。

クラスターをプロビジョニングする際、Rancherはあなたがすでに AWSで作成した VPCとサブネットを使用するように制御プレーンとノードを構成します。

詳細については、 クラスターVPCの考慮事項に関するAWSのドキュメントを参照してください。前のステップでの選択に基づいて、以下の指示のセットのいずれかに従ってください。

カスタムVPCに関する警告

`IPv6`をIPファミリーとして選択し、カスタムVPCを持っている場合、デュアルスタックサブネットを選択する必要があります。選択したサブネットは、IPv4 CIDRブロックとIPv6 CIDRブロックの両方を持っている必要があります。"IPv6専用"サブネットはEKSによってサポートされていません。EC2ワーカーノードは、クラスターに参加しAWSサービスと通信するために依然としてIPv4アドレスを必要とします。

ログ記録

コントロールプレーンのログをAmazon CloudWatchに送信するように設定します。クラスターからCloudWatch Logsに送信されるログに対して、標準のCloudWatch Logsデータ取り込みおよびストレージコストが請求されます。

各ログタイプはKubernetesコントロールプレーンのコンポーネントに対応しています。これらのコンポーネントについて詳しくは、Kubernetesドキュメントの Kubernetesコンポーネントを参照してください。

EKSコントロールプレーンのログに関する詳細は、公式の ドキュメントを参照してください。

管理ノードグループ

Amazon EKSの管理ノードグループは、Amazon EKS Kubernetesクラスターのノード(Amazon EC2インスタンス)のプロビジョニングとライフサイクル管理を自動化します。

ノードグループの動作と構成方法についての詳細は、 EKSドキュメントを参照してください。

ユーザー提供の起動テンプレート

ノードグループ内のEC2インスタンスを構成するために、独自の起動テンプレートIDとバージョンを提供できます。起動テンプレートを提供する場合、テンプレートの設定はRancherから構成できません。起動テンプレート内で、以下に示すすべての必須オプションを設定する必要があります。

また、起動テンプレートを提供する場合、テンプレートIDではなく、テンプレートバージョンのみを更新できます。新しいテンプレートIDを使用するには、新しい管理ノードグループを作成してください。

オプション 説明 必須/オプション

インスタンスタイプ

プロビジョニングしているインスタンスのために、 ハードウェア仕様を選択してください。

必須

イメージID

ノード用のカスタムAMIを指定してください。EKSで使用されるカスタムAMIは、 適切に構成されている必要があります

オプション

ノードボリュームサイズ

起動テンプレートは、希望するサイズのEBSボリュームを指定する必要があります。

必須

SSHキー

ノードへのSSHアクセスを提供するためにインスタンスに追加されるキーです。

オプション

ユーザデータ

MIMEマルチパート形式のクラウドinitスクリプト

オプション

インスタンスリソースタグ

ノードグループ内の各EC2インスタンスとそのボリュームにタグを付けてください。

オプション

カスタム起動テンプレートから作成されたノードグループは、新しいKubernetesバージョンに直接更新することはできません。適切なKubernetesバージョンの新しい起動テンプレートを作成し、ノードグループを新しいテンプレートに関連付ける必要があります。

Rancher管理の起動テンプレート

起動テンプレートを指定しない場合、上記のオプションをRancher UIで構成でき、作成後にすべて更新できます。これらすべてのオプションを活用するために、Rancherがあなたのために起動テンプレートを作成し管理します。Rancherの各クラスターには1つのRancher管理の起動テンプレートがあり、指定された起動テンプレートを持たない各管理ノードグループには管理起動テンプレートの1つのバージョンがあります。この起動テンプレートの名前は、"rancher-managed-lt-"というプレフィックスの後にクラスターの表示名が続きます。さらに、Rancher管理の起動テンプレートには、"rancher-managed-template"というキーと"do-not-modify-or-delete"という値がタグ付けされ、Rancher管理であることを識別するのに役立ちます。この起動テンプレートとそのバージョンは、変更、削除、または他のクラスターや管理ノードグループで使用されないことが重要です。そうすることで、ノードグループが「劣化」し、破棄して再作成する必要が生じる可能性があります。

カスタムAMI

カスタムAMIを指定する場合、起動テンプレートまたはRancherで、イメージは 適切に構成されている必要があり、ノードを 起動するためのユーザーデータを提供しなければなりません。これは高度な使用ケースと見なされ、要件を理解することが不可欠です。

カスタムAMIを含まない起動テンプレートを指定した場合、AmazonはKubernetesのバージョンと選択したリージョンに対して EKS最適化AMIを使用します。また、ワークロードに利益をもたらす GPU対応インスタンスを選択することもできます。

カスタムAMIが提供されている場合、RancherのGPU対応インスタンス設定は無視されます。

スポットインスタンス

スポットインスタンスは現在 EKSによってサポートされています。起動テンプレートが指定されている場合、Amazonはテンプレートがインスタンスタイプを提供しないことを推奨します。代わりに、Amazonは複数のインスタンスタイプを提供することを推奨します。ノードグループの「スポットインスタンスをリクエスト」チェックボックスが有効になっている場合、複数のインスタンスタイプを提供する機会があります。

インスタンスタイプのドロップダウンで行った選択はこの状況では無視され、"スポットインスタンスタイプ"セクションに少なくとも1つのインスタンスタイプを指定しなければなりません。さらに、EKSで使用される起動テンプレートはスポットインスタンスをリクエストすることはできません。スポットインスタンスのリクエストはEKSの設定の一部でなければなりません。

ノードグループ設定

以下の設定も構成可能です。これらのうち「ノードグループ名」を除くすべては、ノードグループが作成された後に編集可能です。

オプション 説明

ノードグループ名

ノードグループの名前。

希望するASGサイズ

希望するインスタンスの数。

最大ASGサイズ

最大インスタンス数。この設定は、 クラスターオートスケーラーがインストールされるまで有効になりません。

最小ASGサイズ

最小インスタンス数。この設定は、 クラスターオートスケーラーがインストールされるまで有効になりません。

ラベル

管理ノードグループ内のノードに適用されるKubernetesラベル。

タグ

これらは管理ノードグループのタグであり、関連リソースには伝播しません。

自己管理型Amazon Linuxノード

自己管理型Amazon Linuxノードを含むEKSクラスターを登録できます。このタイプのクラスターは、 自己管理型Amazon Linuxノードの起動に関する公式AWSドキュメントの指示に従って設定する必要があります。自己管理型Amazon Linuxノードを含むEKSクラスターは、通常、 Karpenterプロジェクトによって運用されます。自己管理型Amazon Linuxノードを含むEKSクラスターをプロビジョニングした後、クラスターを登録してRancherによって管理できるようにします。ただし、ノードはRancher UIには表示されません。

サービスアカウント用のIAMロール

EKSクラスター上で実行されるアプリケーションデプロイメントは、IAM権限を介してAWSサービスにリクエストを行うことができます。これらのアプリケーションは、AWS資格情報でリクエストに署名する必要があります。IAMロールは、サービスアカウントがこれらの資格情報をAWS OIDCエンドポイントを使用して管理します。AWSの資格情報をコンテナに配布したり、EC2インスタンスのロールに依存する代わりに、 IAMロールをKubernetesサービスアカウントにリンクし、Podをこのアカウントを使用するように構成できます。

EKSクラスター内のRancherポッドに対してIAMロールへのリンクはサポートされていません。

サービスアカウントのためのIAMロールを有効にするには:

リフレッシュ間隔の設定

`eks-refresh-cron`設定は廃止されました。それは`eks-refresh`設定に移行されました。これは秒を表す整数です。

デフォルト値は300秒です。

sync間隔は`kubectl edit setting eks-refresh`を実行することで変更できます。

`eks-refresh-cron`設定が以前に設定されていた場合、移行は自動的に行われます。

リフレッシュウィンドウが短いほど、レースコンディションが発生する可能性は低くなりますが、AWS APIに対して設定されているリクエスト制限に遭遇する可能性は高くなります。