翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

VPC とサブネットに関する考慮事項

EKS クラスターを操作するには、Kubernetes ネットワークに加えて、AWS VPC ネットワークに関する知識が必要です。

VPC の設計または既存の VPC へのクラスターのデプロイを開始する前に、EKS コントロールプレーンVPCsメカニズムを理解しておくことをお勧めします。

EKS で使用する VPC とサブネットを設計するときは、クラスター VPC に関する考慮事項と Amazon EKS セキュリティグループの考慮事項を参照してください。 https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html

概要

EKS クラスターアーキテクチャ

EKS クラスターは 2 つの VPCsで構成されます。

カスタマー VPC のノードには、AWS VPC のマネージド API サーバーエンドポイントに接続する機能が必要です。これにより、ノードは Kubernetes コントロールプレーンに登録し、アプリケーションポッドを実行するリクエストを受信できます。

ノードは、(a) EKS パブリックエンドポイント、または (b) EKS によって管理されるクロスアカウント Elastic Network Interface (X-ENI) を介して EKS コントロールプレーンに接続します。クラスターを作成するときは、少なくとも 2 つの VPC サブネットを指定する必要があります。EKS は、クラスターの作成時に指定された各サブネット (クラスターサブネットとも呼ばれます) に X-ENI を配置します。Kubernetes API サーバーは、これらのクロスアカウント ENIs を使用して、カスタマーマネージドクラスター VPC サブネットにデプロイされたノードと通信します。

ノードが起動すると、EKS ブートストラップスクリプトが実行され、Kubernetes ノード設定ファイルがインストールされます。各インスタンスの起動プロセスの一環として、コンテナランタイムエージェント、kubelet、Kubernetes ノードエージェントを起動します。

ノードを登録するため、Kubelet は Kubernetes クラスターエンドポイントに連絡します。VPC の外部にあるパブリックエンドポイントまたは VPC 内のプライベートエンドポイントとの接続を確立します。Kubelet は API 指示を受け取り、ステータスの更新とハートビートを定期的にエンドポイントに提供します。

EKS コントロールプレーン通信

EKS には、クラスターエンドポイントへのアクセスを制御する 2 つの方法があります。エンドポイントアクセスコントロールを使用すると、パブリックインターネットからエンドポイントにアクセスできるか、VPC 経由でのみエンドポイントにアクセスできるかを選択できます。パブリックエンドポイント (デフォルト）、プライベートエンドポイント、またはその両方を一度にオンにできます。

クラスター API エンドポイントの設定により、ノードがコントロールプレーンと通信するためのパスが決まります。これらのエンドポイント設定は、EKS コンソールまたは API を通じていつでも変更できます。

パブリックエンドポイント

これは新しい Amazon EKS クラスターのデフォルトの動作です。クラスターのパブリックエンドポイントのみが有効になっている場合、クラスターの VPC 内 (ワーカーノードからコントロールプレーンへの通信など) から送信される Kubernetes API リクエストは VPC を離れますが、Amazon のネットワークは離れません。ノードをコントロールプレーンに接続するには、パブリック IP アドレスとインターネットゲートウェイへのルート、または NAT ゲートウェイのパブリック IP アドレスを使用できる NAT ゲートウェイへのルートが必要です。

パブリックエンドポイントとプライベートエンドポイント

パブリックエンドポイントとプライベートエンドポイントの両方が有効になっている場合、VPC 内からの Kubernetes API リクエストは、VPC 内の X-ENIs を介してコントロールプレーンと通信します。クラスター API サーバーにはインターネットからアクセスできます。

プライベートエンドポイント

プライベートエンドポイントのみが有効になっている場合、インターネットから API サーバーへのパブリックアクセスはありません。クラスター API サーバーへのすべてのトラフィックはクラスターの VPC または接続されたネットワーク内から送信する必要があります。ノードは、VPC 内の X-ENIs を介して API サーバーと通信します。クラスター管理ツールには、プライベートエンドポイントへのアクセス権が必要です。Amazon VPC の外部からプライベート Amazon EKS クラスターエンドポイントに接続する方法について説明します。

クラスターの API サーバーエンドポイントは、パブリック DNS サーバーによって VPC のプライベート IP アドレスに解決されることに注意してください。これまではエンドポイントは VPC 内からしか解決できませんでした。

VPC 設定

Amazon VPC では、IPv4 と IPv6 アドレス設定がサポートされています。Amazon EKS はデフォルトで IPv4 をサポートしています。VPC には、それに関連付けられた IPv4 CIDR ブロックがある必要があります。オプションで、複数の IPv4 クラスレスドメイン間ルーティング (CIDR) ブロックと複数の IPv6 CIDR ブロックを VPC に関連付けることができます。VPC を作成するときは、RFC 1918 で指定されたプライベート IPv4 アドレス範囲から VPC の IPv4 CIDR ブロックを指定する必要があります。 http://www.faqs.org/rfcs/rfc1918.html許可されるブロックサイズは、/16プレフィックス (65,536 IP アドレス) と/28プレフィックス (16 IP アドレス) の間です。

新しい VPC を作成するときは、単一の IPv6 CIDR ブロックをアタッチし、既存の VPC を変更するときは最大 5 つまでアタッチできます。IPv6 CIDR ブロックサイズのプレフィックスの長さは /44 ～ /60 で、IPv6 サブネットでは /44/ ～ /64 にすることができます。Amazon が管理する IPv6 アドレスのプールから IPv6 CIDR ブロックをリクエストできます。詳細については、「VPC ユーザーガイド」の「VPC CIDR ブロック」セクションを参照してください。

Amazon EKS クラスターは、IPv4 と IPv6 の両方をサポートしています。デフォルトでは、EKS クラスターは IPv4 IP を使用します。クラスターの作成時に IPv6 を指定すると、IPv6 クラスターの使用が有効になります。IPv6 クラスターには、デュアルスタック VPCs とサブネットが必要です。

Amazon EKS では、クラスターの作成時に異なるアベイラビリティーゾーンにあるサブネットを少なくとも 2 つ使用することをお勧めします。クラスターの作成時に渡すサブネットは、クラスターサブネットと呼ばれます。クラスターを作成すると、Amazon EKS は指定したサブネットに最大 4 つのクロスアカウント (x アカウントまたは x ENIs) ENIs を作成します。x-ENIs は常にデプロイされ、ログ配信、exec、プロキシなどのクラスター管理トラフィックに使用されます。VPC とサブネットの要件の詳細については、「EKS ユーザーガイド」を参照してください。

Kubernetes ワーカーノードはクラスターサブネットで実行できますが、推奨されません。クラスターのアップグレード中、Amazon EKS はクラスターサブネットに追加の ENIs をプロビジョニングします。クラスターがスケールアウトすると、ワーカーノードとポッドがクラスターサブネットで使用可能な IPs を消費する可能性があります。したがって、/28 ネットマスクで専用クラスターサブネットを使用することを検討 IPs することをお勧めします。

Kubernetes ワーカーノードは、パブリックサブネットまたはプライベートサブネットのいずれかで実行できます。サブネットがパブリックかプライベートかは、サブネット内のトラフィックがインターネットゲートウェイを介してルーティングされるかどうかを指します。パブリックサブネットには、インターネットゲートウェイを介してインターネットへのルートテーブルエントリがありますが、プライベートサブネットにはアクセスできません。

別の場所から発信され、ノードに到達するトラフィックは、イングレスと呼ばれます。ノードから発信され、ネットワークから出るトラフィックは、エグレスと呼ばれます。インターネットゲートウェイで設定されたサブネット内にパブリック IP アドレスまたは Elastic IP アドレス (EIPs) を持つノードは、VPC の外部からの進入を許可します。プライベートサブネットには通常、NAT ゲートウェイへのルーティングがあります。これにより、VPC の外部からサブネット内のノードへの進入トラフィックは許可されませんが、ノードからのトラフィックは VPC (進入) から出ることが許可されます。

IPv6 の世界では、すべてのアドレスがインターネットルーティング可能です。ノードとポッドに関連付けられた IPv6 アドレスはパブリックです。プライベートサブネットは、VPC に Egress-Only インターネットゲートウェイ (EIGW) を実装することでサポートされ、すべての着信トラフィックをブロックしながらアウトバウンドトラフィックを許可します。IPv6 サブネットを実装するためのベストプラクティスは、VPC ユーザーガイドに記載されています。

VPC とサブネットは、次の 3 つの異なる方法で設定できます。

パブリックサブネットのみを使用する

同じパブリックサブネットに、ノードとイングレスリソース (ロードバランサーなど) の両方が作成されます。パブリックサブネットに をタグ付けkubernetes.io/role/elbして、インターネットに面するロードバランサーを構築します。この設定では、クラスターエンドポイントをパブリック、プライベート、またはその両方 (パブリックとプライベート) に設定できます。

プライベートサブネットとパブリックサブネットの使用

ノードはプライベートサブネットに作成されますが、イングレスリソースはパブリックサブネットにインスタンス化されます。クラスターエンドポイントへのパブリックアクセス、プライベートアクセス、またはその両方 (パブリックおよびプライベート) アクセスを有効にできます。クラスターエンドポイントの設定に応じて、ノードトラフィックは NAT ゲートウェイまたは ENI を介して入ります。

プライベートサブネットのみを使用する

ノードとイングレスはどちらもプライベートサブネットに作成されます。kubernetes.io/role/internal-elb サブネットタグを使用して内部ロードバランサーを構築します。クラスターのエンドポイントにアクセスするには、VPN 接続が必要です。EC2 およびすべての Amazon ECR および S3 リポジトリに対して AWS PrivateLink を有効にする必要があります。クラスターのプライベートエンドポイントのみを有効にする必要があります。プライベートクラスターをプロビジョニングする前に、EKS プライベートクラスターの要件を確認することをお勧めします。

VPCs間の通信

複数の VPCs と個別の EKS クラスターをこれらの VPCs多くのシナリオがあります。

Amazon VPC Lattice を使用すると、複数の VPCs とアカウント間でサービスを一貫して安全に接続できます (VPC ピアリング、AWS PrivateLink、AWS Transit Gateway などのサービスによって追加の接続が提供される必要はありません）。詳細については、こちらを参照してください。

Amazon VPC Lattice は IPv4 と IPv6 のリンクローカルアドレス空間で動作し、重複する IPv4 アドレスを持つ可能性のあるサービス間の接続を提供します。運用効率を高めるために、EKS クラスターとノードを重複しない IP 範囲にデプロイすることを強くお勧めします。インフラストラクチャに重複する IP 範囲VPCs が含まれている場合は、それに応じてネットワークを設計する必要があります。ルーティング可能な RFC1918 IP アドレスを維持しながら、重複する CIDR の課題を解決するには、プライベート NAT ゲートウェイ、またはカスタムネットワーキングモードの VPC CNI をトランジットゲートウェイと組み合わせて EKS 上のワークロードを統合することをお勧めします。

お客様がサービスプロバイダーであり、Kubernetes サービスと進入 (ALB または NLB) を別のアカウントのカスタマー VPC と共有する場合は、エンドポイントサービスとも呼ばれる AWS PrivateLink の使用を検討してください。

複数のアカウント間で VPC を共有する

多くの企業は、AWS Organization 内の複数の AWS アカウントでネットワーク管理を合理化し、コストを削減し、セキュリティを向上させる手段として、共有 Amazon VPCs を採用しました。AWS Resource Access Manager (RAM) を使用して、サポートされている AWS リソースを個々の AWS アカウント、組織単位 (OUs。

AWS RAM を使用して、別の AWS アカウントの共有 VPC サブネットに Amazon EKS クラスター、マネージド型ノードグループ、その他のサポート対象の AWS リソース (LoadBalancers、セキュリティグループ、エンドポイントなど) をデプロイできます。次の図は、高レベルアーキテクチャの例を示しています。これにより、中央ネットワークチームは VPCs、サブネットなどのネットワーク構造を制御しながら、アプリケーションまたはプラットフォームチームはそれぞれの AWS アカウントに Amazon EKS クラスターをデプロイできます。このシナリオの完全なチュートリアルは、この github リポジトリで入手できます。

共有サブネットを使用する場合の考慮事項

セキュリティグループ

セキュリティグループは、関連付けられたリソースに到達するトラフィックおよびリソースから離れるトラフィックを制御します。Amazon EKS はセキュリティグループを使用して、コントロールプレーンとノード間の通信を管理します。クラスターを作成すると、Amazon EKS により eks-cluster-sg-my-cluster-uniqueID という名前のセキュリティグループが作成されます。EKS は、これらのセキュリティグループをマネージド ENIsとノードに関連付けます。デフォルトのルールでは、すべてのトラフィックがクラスターとノード間で自由に行き来することができます。また、任意の送信先へのすべてのアウトバウンドトラフィックが許可されています。

クラスターを作成するときに、独自のセキュリティグループを指定できます。独自のセキュリティグループを指定する場合は、セキュリティグループの推奨事項を参照してください。

レコメンデーション

マルチ AZ 配置を検討する

AWS リージョンは、低レイテンシー、高スループット、および高度に冗長なネットワークで接続された、物理的に分離された複数のアベイラビリティーゾーン (AZ) を提供します。アベイラビリティーゾーンを使用すると、中断することなくアベイラビリティーゾーン間で自動的にフェイルオーバーするアプリケーションを設計および運用できます。Amazon EKS では、EKS クラスターを複数のアベイラビリティーゾーンにデプロイすることを強くお勧めします。クラスターを作成するときは、少なくとも 2 つのアベイラビリティーゾーンでサブネットを指定することを検討してください。

ノードで実行される Kubelet は、 などのノードオブジェクトにラベルを自動的に追加しますtopology.kubernetes.io/region=us-west-2。ノードラベルを Pod トポロジーの分散制約と組み合わせて使用して、ゾーン間で Pod を分散する方法を制御することをお勧めします。これらのヒントにより、Kubernetes スケジューラは Pod を配置して、予想される可用性を向上させ、相関障害がワークロード全体に影響を与えるリスクを軽減できます。ノードセレクタと AZ スプレッド制約の例については、「Pod へのノードの割り当て」を参照してください。

ノードの作成時にサブネットまたはアベイラビリティーゾーンを定義できます。サブネットが設定されていない場合、ノードはクラスターサブネットに配置されます。マネージド型ノードグループの EKS サポートは、使用可能な容量に基づいて複数のアベイラビリティーゾーンにノードを自動的に分散します。Karpenter は、ワークロードでトポロジーのスプレッド制限が定義されている場合、ノードを指定された AZ にスケーリングすることで AZs スプレッドプレイスメントを尊重します。

AWS Elastic Load Balancer は、Kubernetes クラスターの AWS Load Balancer Controller によって管理されます。Kubernetes イングレスリソース用の Application Load Balancer (ALB) と、 Load Balancer タイプの Kubernetes サービス用の Network Load Balancer (NLB) をプロビジョニングします。Elastic Load Balancer コントローラーはタグを使用してサブネットを検出します。ELB コントローラーでは、進入リソースを正常にプロビジョニングするために、少なくとも 2 つのアベイラビリティーゾーン (AZs) が必要です。地理的冗長性の安全性と信頼性を活用するには、少なくとも 2 つの AZs にサブネットを設定することを検討してください。

プライベートサブネットにノードをデプロイする

プライベートサブネットとパブリックサブネットの両方を含む VPC は、Kubernetes ワークロードを EKS にデプロイするのに最適な方法です。2 つの異なるアベイラビリティーゾーンに 2 つ以上のパブリックサブネットと 2 つのプライベートサブネットを設定することを検討してください。パブリックサブネットの関連ルートテーブルには、インターネットゲートウェイ へのルートが含まれています。ポッドは NAT ゲートウェイを介してインターネットとやり取りできます。プライベートサブネットは、IPv6 環境 (EIGW) の Egress-Only インターネットゲートウェイでサポートされています。

プライベートサブネット内のノードをインスタンス化することで、ノードへのトラフィックを最大限制御でき、ほとんどの Kubernetes アプリケーションに効果的です。イングレスリソース (ロードバランサーなど) はパブリックサブネットでインスタンス化され、プライベートサブネットで動作している Pod にトラフィックをルーティングします。

厳格なセキュリティとネットワークの分離が必要な場合は、プライベート専用モードを検討してください。この設定では、AWS リージョンの VPC 内の個別のアベイラビリティーゾーンに 3 つのプライベートサブネットがデプロイされます。サブネットにデプロイされたリソースは、インターネットにアクセスすることも、サブネット内のリソースにもアクセスすることもできません。Kubernetes アプリケーションが他の AWS のサービスにアクセスするには、PrivateLink インターフェイスやゲートウェイエンドポイントを設定する必要があります。AWS Load Balancer Controller を使用してトラフィックを Pod にリダイレクトするように内部Load Balancerを設定できます。ロードバランサーをプロビジョニングするには、コントローラーにプライベートサブネットにタグ (kubernetes.io/role/internal-elb: 1) を付ける必要があります。ノードをクラスターに登録するには、クラスターエンドポイントをプライベートモードに設定する必要があります。要件と考慮事項の詳細については、プライベートクラスターガイドを参照してください。

クラスターエンドポイントのパブリックモードとプライベートモードを検討する

Amazon EKS には、パブリック専用、public-and-privateのクラスターエンドポイントモードが用意されています。デフォルトモードはパブリック専用ですが、クラスターエンドポイントをパブリックモードとプライベートモードで設定することをお勧めします。このオプションを使用すると、クラスターの VPC 内の Kubernetes API コール (node-to-control-plane通信など) がプライベート VPC エンドポイントとトラフィックを利用してクラスターの VPC 内に留まることができます。一方、クラスター API サーバーにはインターネットからアクセスできます。ただし、パブリックエンドポイントを使用できる CIDR ブロックを制限することを強くお勧めします。CIDR ブロックの制限など、パブリックエンドポイントとプライベートエンドポイントのアクセスを設定する方法について説明します。

セキュリティとネットワークの分離が必要な場合は、プライベート専用のエンドポイントをお勧めします。EKS ユーザーガイドに記載されているオプションのいずれかを使用して、API サーバーにプライベートに接続することをお勧めします。

セキュリティグループを慎重に設定する

Amazon EKS は、カスタムセキュリティグループの使用をサポートしています。カスタムセキュリティグループでは、ノードと Kubernetes コントロールプレーン間の通信を許可する必要があります。組織がオープンな通信を許可していない場合は、ポートの要件を確認し、ルールを手動で設定してください。

EKS は、クラスターの作成時に指定したカスタムセキュリティグループをマネージドインターフェイス (X-ENIs。ただし、ノードにすぐに関連付けられるわけではありません。ノードグループを作成するときは、カスタムセキュリティグループを手動で関連付けることを強くお勧めします。securityGroupSelectorTerms を有効にして、ノードの自動スケーリング中にカスタムセキュリティグループの Karpenter ノードテンプレート検出を有効にすることを検討してください。

すべてのノード間通信トラフィックを許可するセキュリティグループを作成することを強くお勧めします。ブートストラッププロセス中、ノードはクラスターエンドポイントにアクセスするためにアウトバウンドインターネット接続を必要とします。オンプレミス接続やコンテナレジストリアクセスなどの外部アクセス要件を評価し、ルールを適切に設定します。本番環境に変更を加える前に、開発環境で接続を慎重に確認することを強くお勧めします。

各アベイラビリティーゾーンに NAT ゲートウェイをデプロイする

プライベートサブネット (IPv4 および IPv6) にノードをデプロイする場合は、各アベイラビリティーゾーン (AZ) に NAT ゲートウェイを作成して、ゾーンに依存しないアーキテクチャを確保し、AZ 間の支出を削減することを検討してください。AZ 内の各 NAT ゲートウェイは冗長性を持って実装されます。

Cloud9 を使用してプライベートクラスターにアクセスする

AWS Cloud9 は、AWS Systems Manager を使用して、イングレスアクセスなしでプライベートサブネットで安全に実行できるウェブベースの IDE です。Cloud9 インスタンスで Egress を無効にすることもできます。Cloud9 を使用してプライベートクラスターとサブネットにアクセスする方法について説明します。