**このページの改善にご協力ください** このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。 # Amazon EKS Hybrid Nodes の概要 *Amazon EKS Hybrid Nodes* では、オンプレミスおよびエッジインフラストラクチャを Amazon EKS クラスターのノードとして使用できます。AWS は、Amazon EKS クラスターの AWS ホスト型 Kubernetes コントロールプレーンを管理し、オンプレミス環境またはエッジ環境で実行されるハイブリッドノードを管理します。これにより、Kubernetes 管理が環境全体で統合され、Kubernetes コントロールプレーン管理がオンプレミスおよびエッジアプリケーションの AWS にオフロードされます。 Amazon EKS Hybrid Nodes は、オンプレミスのハードウェアまたは仮想マシンと連携し、アプリケーションを実行する必要がある場所に Amazon EKS の効率、スケーラビリティ、可用性をもたらします。Amazon EKS Hybrid Nodes では、Amazon EKS アドオン、Amazon EKS Pod Identity、クラスターアクセスエントリ、クラスターインサイト、Kubernetes バージョンの延長サポートといったさまざまな Amazon EKS 機能を使用できます。Amazon EKS Hybrid Nodes は AWS Systems Manager、AWS IAM Roles Anywhere、Amazon Managed Service for Prometheus、Amazon CloudWatch などの AWS サービスとネイティブに統合し、一元化したモニタリング、ログ記録、ID 管理を実現します。 Amazon EKS Hybrid Nodes では、前払いの義務や最低料金はなく、ハイブリッドノードの vCPU リソースが Amazon EKS クラスターにアタッチされると、1 時間ごとに課金されます。料金の詳細については、「[Amazon EKS の料金表](https://aws.amazon.com/eks/pricing/)」を参照してください。 [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/tFn9IdlddBw?rel=0/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/tFn9IdlddBw?rel=0) ## 機能 EKS Hybrid Nodes には、次の高度な機能があります。 + **マネージド型 Kubernetes のコントロールプレーン**: AWS がホストする、EKS クラスターの Kubernetes コントロールプレーンは AWS が管理し、オンプレミス環境またはエッジ環境で実行されるハイブリッドノードはユーザーが管理します。これにより、Kubernetes 管理が環境全体で統合され、Kubernetes コントロールプレーン管理がオンプレミスおよびエッジアプリケーションの AWS にオフロードされます。Kubernetes コントロールプレーンを AWS に移動させることで、ユーザーはアプリケーションのオンプレミス容量を節約し、ワークロードのスケーリングは Kubernetes コントロールプレーンに任せることができます。 + **一貫性のある EKS エクスペリエンス**: ほとんどの EKS 機能は EKS Hybrid Nodes でサポートされており、EKS アドオン、EKS Pod Identity、クラスターアクセスエントリ、クラスターインサイト、Kubernetes バージョンの拡張サポートその他の、オンプレミス環境とクラウド環境を横断する、一貫性のある EKS エクスペリエンスを実現しています。EKS Hybrid Nodes でサポートされている EKS アドオンの詳細については、「[ハイブリッドノードのアドオンを構成する](hybrid-nodes-add-ons.md)」を参照してください。 + **オブザーバビリティと ID 管理を一元化**: EKS Hybrid Nodes は、AWS Systems Manager、AWS IAM Roles Anywhere、Amazon Managed Service for Prometheus、Amazon CloudWatch などの AWS サービスとネイティブに統合されており、モニタリング、ログ記録、ID 管理を一元的に行えます。 + **Burst-to-cloud またはオンプレミス容量の追加**: EKS クラスターを 1 つ使うことで、AWS リージョン、AWS Local Zones、AWS Outposts のいずれかでハイブリッドノードおよびノードを実行し、EKS クラスターに Burst-to-cloud する、またはオンプレミス容量を追加することができます。詳細については、「[Considerations for mixed mode clusters](hybrid-nodes-webhooks.md#hybrid-nodes-considerations-mixed-mode)」を参照してください。 + **柔軟なインフラストラクチャ**: EKS Hybrid Nodes は *Bring Your Own Infrastructure* のアプローチに従い、ユーザーがハイブリッドノードに使用しているインフラストラクチャに依存しません。ハイブリッドノードを物理マシンまたは仮想マシン、および x86 と ARM のアーキテクチャで実行できるため、ハイブリッドノードで実行されているオンプレミスワークロードを、さまざまなインフラストラクチャタイプに移行することができます。 + **柔軟なネットワーキング**: EKS Hybrid Nodes を使用すると、EKS コントロールプレーンとハイブリッドノード間の通信は、クラスターの作成時にユーザーが渡す VPC とサブネットを介してルーティングされます。これは、コントロールプレーンからノードへのネットワーキング向けに[既存のメカニズム](https://docs.aws.amazon.com/eks/latest/best-practices/subnets.html)の上に構築されます。これにより、ユーザーが希望する、オンプレミスネットワークを AWS の VPC に接続する方法に、柔軟に対応できます。AWS Site-to-Site VPN、AWS Direct Connect、あるいはユーザー独自の VPN ソリューションなど、[文書化されたオプション](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html)を複数利用でき、ユースケースに最適な方法を選択できます。 ## 制限 + クラスターごとにリモートノードネットワークには最大 15 CIDR がサポートされ、リモートポッドネットワークには最大 15 CIDR がサポートされています。 ## 考慮事項 + EKS Hybrid Nodes は、新規の EKS クラスターでも既存の EKS クラスターでも使用できます。 + EKS Hybrid Nodes は、AWS GovCloud (米国) リージョンと AWS 中国リージョンを除くすべての AWS リージョンで使用できます。 + EKS Hybrid Nodes には、オンプレミス環境と AWS の間に信頼性の高い接続が必要です。EKS Hybrid Nodes は、切断された環境、中断しているまたは一時的に停止している環境、制限 (DDIL) されている環境には適していません。DDIL 環境で実行している場合は、[Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/) を検討してください。ネットワーク切断シナリオでハイブリッドノードの動作に関する詳細については、「[EKS Hybrid Nodes のベストプラクティス](https://docs.aws.amazon.com/eks/latest/best-practices/hybrid-nodes-network-disconnections.html)」を参照してください。 + EKS Hybrid Nodes をクラウドインフラストラクチャ (AWS リージョン、AWS Local Zones、AWS Outposts) やその他のクラウドで実行することは、サポートされていません。Amazon EC2 インスタンスでハイブリッドノードを実行すると、ハイブリッドノード料金が課金されます。 + ハイブリッドノードの請求は、ノードが EKS クラスターに追加されたとに開始し、ノードがクラスターから削除されたときに停止します。ハイブリッドノードを使用しないときは、必ず EKS クラスターからこれを削除してください。 ## 追加リソース + [https://www.eksworkshop.com/docs/networking/eks-hybrid-nodes/](https://www.eksworkshop.com/docs/networking/eks-hybrid-nodes/): EKS Hybrid Nodes をデモ環境にデプロイするためのステップバイステップ手順。 + [https://www.youtube.com/watch?v=ZxC7SkemxvU](https://www.youtube.com/watch?v=ZxC7SkemxvU): EKS Hybrid Nodes の顧客環境でのローンチを紹介し、顧客が独自の環境で EKS Hybrid Nodes どのように使用しているかを示す AWS re:Invent セッション。 + [https://repost.aws/articles/ARL44xuau6TG2t-JoJ3mJ5Mw/unpacking-the-cluster-networking-for-amazon-eks-hybrid-nodes](https://repost.aws/articles/ARL44xuau6TG2t-JoJ3mJ5Mw/unpacking-the-cluster-networking-for-amazon-eks-hybrid-nodes): EKS Hybrid Nodes のネットワークを設定するためのさまざまな方法について説明する記事。 + [https://aws.amazon.com/blogs/containers/run-genai-inference-across-environments-with-amazon-eks-hybrid-nodes/](https://aws.amazon.com/blogs/containers/run-genai-inference-across-environments-with-amazon-eks-hybrid-nodes/): EKS Hybrid Nodes を使用した複数環境間で生成 AI 推論を実行する方法について示すブログ投稿。 # ハイブリッドノードの前提条件のセットアップ Amazon EKS Hybrid Nodes を使用するには、オンプレミス環境と AWS 間のプライベート接続、サポートされているオペレーティングシステムを持つベアメタルサーバーまたは仮想マシン、AWS IAM Roles Anywhere または AWS Systems Manager (SSM) ハイブリッドアクティベーションを設定する必要があります。ハイブリッドノードのライフサイクル全体を通じてこれらの前提条件を管理するのはお客様の責任となります。 + オンプレミス環境と AWS 間のハイブリッドネットワーク接続　 + 物理マシンまたは仮想マシンの形式のインフラストラクチャ + ハイブリッドノードと互換性のあるオペレーティングシステム + オンプレミスの IAM 認証情報プロバイダーが設定されました ![\[ハイブリッドノードのネットワーク接続。\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/hybrid-prereq-diagram.png) ## ハイブリッドネットワーク接続 Amazon EKS コントロールプレーンとハイブリッドノード間の通信は、クラスターの作成時に渡される VPC とサブネットを介してルーティングされます。これは、コントロールプレーンからノードへのネットワーク形成のために Amazon EKS の[既存のメカニズム](https://aws.github.io/aws-eks-best-practices/networking/subnets/)上に構築されます。オンプレミス環境と VPC の接続には、AWS Site-to-Site VPN、AWS Direct Connect、独自の VPN 接続など、[文書化されたオプション](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html)がいくつか利用可能です。ハイブリッドネットワーク接続にこれらのソリューションを使用する方法の詳細については、「[AWS Site-to-Site VPN ユーザーガイド](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)」および「[AWS Direct Connect ユーザーガイド](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)」を参照してください。 最適なエクスペリエンスを実現するには、ハイブリッドノードから AWS リージョンへの接続には、100 Mbps 以上の通信速度と 200 ミリ秒以下のラウンドトリップレイテンシーを持つ、信頼性の高いネットワーク接続が推奨されます。これはほとんどのユースケースに対応する一般的なガイダンスですが、厳格な要件ではありません。帯域幅とレイテンシーの要件は、アプリケーションのイメージサイズ、アプリケーションの伸縮性、モニタリングとログ記録の設定、他の AWS サービスに保存されているデータへのアクセスに関するアプリケーションの依存関係など、ハイブリッドノードの数とワークロードの特性によって異なります。本番環境にデプロイする前に、独自のアプリケーションと環境でテストして、ネットワーク設定がワークロードの要件を満たしているか確認することをお勧めします。 ## オンプレミスのネットワーク設定 Amazon EKS コントロールプレーンからオンプレミス環境へのインバウンドネットワークアクセスを有効にして、Amazon EKS コントロールプレーンが、ハイブリッドノードで実行されている `kubelet` と通信できるようにし、オプションでハイブリッドノードで実行されているウェブフックと通信できるようにする必要があります。さらに、Amazon EKS コントロールプレーンと通信するには、ハイブリッドノードとハイブリッドノードで実行されているコンポーネントのアウトバウンドネットワークアクセスを有効にする必要があります。この通信は、AWS Direct Connect、AWS Site-to-Site VPN、または独自の VPN 接続に対して完全にプライベートなままになるように設定できます。 オンプレミスノードおよびポッドネットワークに使用する Classless Inter-Domain Routing (CIDR) 範囲では、IPv4 RFC1918 アドレスまたは CGNAT アドレスの範囲を使用する必要があります。オンプレミスルーターは、オンプレミスノードとオプションでポッドへのルートで設定する必要があります。ファイアウォールおよびオンプレミス環境で有効にする必要があるポートおよびプロトコルの完全なリストなど、オンプレミスのネットワーク要件の詳細については、「[オンプレミスネットワーク設定](hybrid-nodes-networking.md#hybrid-nodes-networking-on-prem)」を参照してください。 ## EKS クラスター設定 レイテンシーを最小限に抑えるには、オンプレミス環境またはエッジ環境に最も近い AWS リージョンで Amazon EKS クラスターを作成することが推奨されます。Amazon EKS クラスターの作成時に、2 つの API フィールド、`RemoteNodeNetwork` および `RemotePodNetwork` を介してオンプレミスのノードとポッドの CIDR を渡します。オンプレミスのノードとポッドの CIDR を特定するために、オンプレミスのネットワークチームに相談する必要がある場合があります。ノード CIDR はオンプレミスネットワークから割り当てられ、ポッド CIDR は、CNI のオーバーレイネットワークを使用している場合に使用する Container Network Interface (CNI) から割り当てられます。Cilium および Calico はデフォルトでオーバーレイネットワークを使用します。 `RemoteNodeNetwork` および `RemotePodNetwork` フィールドを介して設定するオンプレミスノードおよびポッド CIDR は、VPC 経由でハイブリッドノードで実行されている `kubelet` およびポッドにトラフィックをルーティングするように Amazon EKS コントロールプレーンを設定するために使用されます。クラスター作成時に渡す VPC CIDR、または Amazon EKS クラスターのサービス IPv4 構成と互いに重複することはできません。また、オンプレミスのルーターがトラフィックをルーティングできるように、ポッド CIDR を各 EKS クラスターに対して一意にする必要があります。 Amazon EKS Kubernetes API サーバーエンドポイントには、パブリックエンドポイントまたはプライベートエンドポイントのいずれかのアクセスを使用することが推奨されます。「Public and Private (パブリックとプライベート)」を選択した場合、Amazon EKS Kubernetes API サーバーエンドポイントは、常に VPC の外部で稼働しているハイブリッドノードのパブリック IP に解決されるため、ハイブリッドノードがクラスターに参加できなくなる可能性があります。パブリックエンドポイントアクセスを使用すると、Kubernetes API サーバーエンドポイントはパブリック IP に解決され、ハイブリッドノードから Amazon EKS コントロールプレーンへの通信はインターネット経由でルーティングされます。プライベートエンドポイントアクセスを選択すると、Kubernetes API サーバーエンドポイントはプライベート IP に解決され、ハイブリッドノードから Amazon EKS コントロールプレーンへの通信は、プライベート接続リンク (ほとんどの場合 AWS Direct Connect または AWS Site-to-Site VPN) を介してルーティングされます。 ## VPC の構成 Amazon EKS クラスター作成時に渡す VPC のルーティングテーブルに、オンプレミスノード用のルートを設定し、オプションで仮想プライベートゲートウェイ (VGW) またはトランジットゲートウェイ (TGW) をターゲットとするポッドネットワークを設定する必要があります。次に例を示します。`REMOTE_NODE_CIDR` と `REMOTE_POD_CIDR` をオンプレミスのネットワークの値に置き換えます。 | ルーティング先 | ターゲット | 説明 | | --- | --- | --- | | 10.226.0.0/16 | ローカル | VPC 内の VPC ルートへのローカルトラフィック | | REMOTE\$1NODE\$1CIDR | tgw-abcdef123456 | オンプレミスノード CIDR、トラフィックを TGW にルーティングする | | REMODE\$1POD\$1CIDR | tgw-abcdef123456 | オンプレミスポッド CIDR、トラフィックを TGW にルーティングする | ## セキュリティグループの構成 クラスターを作成すると、Amazon EKS により `eks-cluster-sg--` という名前のセキュリティグループが作成されます。このクラスターセキュリティグループのインバウンドルールは変更できませんが、アウトバウンドルールは制限できます。クラスターに追加のセキュリティグループを追加して、kubelet と、オプションでハイブリッドノードで実行されているウェブフックが Amazon EKS コントロールプレーンに接続できるようにする必要があります。この追加のセキュリティグループに必要なインバウンドルールを以下に示します。`REMOTE_NODE_CIDR` と `REMOTE_POD_CIDR` をオンプレミスのネットワークの値に置き換えます。 | 名前 | セキュリティグループのルール ID | IP バージョン | タイプ | プロトコル | ポート範囲 | ソース | | --- | --- | --- | --- | --- | --- | --- | | オンプレミスノードのインバウンド | sgr-abcdef123456 | IPv4 | HTTPS | TCP | 443 | REMOTE\$1NODE\$1CIDR | | オンプレミスポッドのインバウンド | sgr-abcdef654321 | IPv4 | HTTPS | TCP | 443 | REMOTE\$1POD\$1CIDR | ## インフラストラクチャ ハイブリッドノードとして使用するには、ベアメタルサーバーまたは仮想マシンが必要です。ハイブリッドノードは基盤となるインフラストラクチャに依存せず、x86 および ARM アーキテクチャに対応しています。Amazon EKS Hybrid Nodes は「独自のインフラストラクチャを導入する」アプローチに従います。ここでは、ハイブリッドノードに使用するベアメタルサーバーまたは仮想マシンのプロビジョニングと管理はお客様の責任となります。厳格な最小リソースの要件はありませんが、ハイブリッドノードには少なくとも 1 vCPU および 1GiB RAM のホストを使用することが推奨されます。 ## オペレーティングシステム Bottlerocket、Amazon Linux 2023 (AL2023)、Ubuntu、RHEL は、ハイブリッドノードのノードオペレーティングシステムとして使用されるために継続的に検証されます。Bottlerocket は、VMware vSphere 環境でのみ AWS でサポートされています。AL2023 は、Amazon EC2 の外部で実行される場合、AWS サポートプランの対象外です。AL2023 はオンプレミスの仮想化環境でのみ使用できます。詳細については、「[Amazon Linux 2023 ユーザーガイド](https://docs.aws.amazon.com/linux/al2023/ug/outside-ec2.html)」を参照してください。AWS は Ubuntu および RHEL オペレーティングシステムとのハイブリッドノード統合をサポートしていますが、オペレーティングシステム自体はサポートしていません。 オペレーティングシステムのプロビジョニングと管理はお客様の責任となります。ハイブリッドノードを初めてテストする場合、プロビジョニング済みのホストで Amazon EKS Hybrid Nodes CLI (`nodeadm`) を実行するのが最も簡単です。本稼働のデプロイでは、ホスト起動時にホストを Amazon EKS クラスターに自動的に参加させる systemd サービスとして実行されるように設定された `nodeadm` を、オペレーティングシステムのゴールデンイメージに含めることが推奨されます。 ## オンプレミスの IAM 認証情報プロバイダー Amazon EKS Hybrid Nodes は、AWS SSM ハイブリッドアクティベーションまたは AWS IAM Roles Anywhere によってプロビジョニングされた一時的な IAM 認証情報を使用して、Amazon EKS クラスターで認証します。Amazon EKS Hybrid Nodes CLI (`nodeadm`) を用いて、AWS SSM ハイブリッドアクティベーションまたは AWS IAM Roles Anywhere を使用する必要があります。認証局 (CA) およびオンプレミス環境の証明書を持つ既存の公開鍵基盤 (PKI) がない場合、AWS SSM ハイブリッドアクティベーションを使用することをお勧めします。既存の PKI と証明書がオンプレミスにある場合は、AWS IAM Roles Anywhere を使用します。 Amazon EC2 で実行されているノードの [Amazon EKS ノードの IAM ロール](create-node-role.md) と同様に、ハイブリッドノードを Amazon EKS クラスターに結合するために必要なアクセス許可を持つハイブリッドノード IAM ロールを作成します。AWS IAM Roles Anywhere を使用している場合は、AWS IAM Roles Anywhere が Hybrid Nodes IAM Role を引き受けることを許可する信頼ポリシーを設定し、ハイブリッドノード IAM ロールを引き受け可能なロールとして AWS IAM Roles Anywhere プロファイルを設定します。AWS SSM を使用している場合は、AWS SSM がハイブリッドノード IAM ロールを引き受け、ハイブリッドノード IAM ロールを使用してハイブリッドアクティベーションを作成できるようにする信頼ポリシーを設定します。必要なアクセス許可を持つハイブリッドノード IAM ロールを作成する方法については、「[ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md)」を参照してください。 # ハイブリッドノード用のネットワークを準備する このトピックでは、Amazon EKS クラスターを作成してハイブリッドノードをアタッチする前に設定する必要があるネットワーク設定の概要を説明します。このガイドでは、[AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html)、[AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)、または独自の VPN ソリューションを使用したハイブリッドネットワーク接続の前提条件の要件を満たしていることを前提としています。 ![\[ハイブリッドノードのネットワーク接続。\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/hybrid-prereq-diagram.png) ## オンプレミスネットワーク設定 ### 最小ネットワーク要件 最適なエクスペリエンスを実現するには、ハイブリッドノードから AWS リージョンへの接続には、100 Mbps 以上の通信速度と 200 ミリ秒以下のラウンドトリップレイテンシーを持つ、信頼性の高いネットワーク接続が推奨されます。これはほとんどのユースケースに対応する一般的なガイダンスですが、厳格な要件ではありません。帯域幅とレイテンシーの要件は、アプリケーションのイメージサイズ、アプリケーションの伸縮性、モニタリングとログ記録の設定、他の AWS サービスに保存されているデータへのアクセスに関するアプリケーションの依存関係など、ハイブリッドノードの数とワークロードの特性によって異なります。本番環境にデプロイする前に、独自のアプリケーションと環境でテストして、ネットワーク設定がワークロードの要件を満たしているか確認することをお勧めします。 ### オンプレミスノードとポッド CIDR ハイブリッドノードに使用するノードとポッドの CIDR と、それらで実行されているワークロードを特定します。CNI にオーバーレイネットワークを使用している場合、ノード CIDR はオンプレミスネットワークから割り当てられ、ポッド CIDR は Container Network Interface (CNI) から割り当てられます。`RemoteNodeNetwork` および `RemotePodNetwork` フィールドで EKS クラスターを作成する際、オンプレミスノード CIDR およびポッド CIDR を入力として渡します。オンプレミスノード CIDR は、オンプレミスネットワークでルーティング可能である必要があります。オンプレミスポッド CIDR のルーティング可能性の詳細については、次のセクションを参照してください。 オンプレミスノードとポッド CIDR ブロックは、以下の要件を満たしている必要があります。 1. `IPv4` RFC-1918 のいずれかの範囲内にある (`10.0.0.0/8`、`172.16.0.0/12`、または `192.168.0.0/16`) か、RFC 6598 で定義される CGNAT 範囲内にある (`100.64.0.0/10`) こと。 1. EKS クラスターの VPC CIDR や Kubernetes サービスの `IPv4` CIDR と相互に重複しないこと。 ### オンプレミスポッドのネットワークルーティング EKS Hybrid Node を使用する際、クラウド環境とオンプレミス環境間で完全なクラスター通信および機能を有効にするため、オンプレミスネットワークでオンプレミスポッド CIDR をルーティング可能にすることが一般的に推奨されています。 **ルーティング可能なポッドネットワーク** オンプレミスネットワークでポッドネットワークをルーティング可能にできる場合、以下のガイダンスに従ってください。 1. オンプレミスポッド CIDR で EKS クラスターの `RemotePodNetwork` フィールドを設定し、オンプレミスポッド CIDR で VPC ルートテーブルを設定し、オンプレミスポッド CIDR で EKS クラスターセキュリティグループを設定します。 1. オンプレミスネットワークでオンプレミスポッド CIDR をルーティング可能にするために使用できる手法がいくつかあります。具体的には、ボーダーゲートウェイプロトコル (BGP)、静的ルート、その他のカスタムルーティングソリューションなどです。BGP はカスタムまたは手動でルート設定する必要がある代替ソリューションよりもスケーラブルで管理しやすいため、推奨されるソリューションです。AWS は、ポッド CIDR をアドバタイズするための Cilium と Calico の BGP 機能をサポートしています。詳細については、「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」および「[ルーティング可能なリモートポッド CIDR](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs)」を参照してください。 1. EKS コントロールプレーンはウェブフックに割り当てられたポッド IP アドレスと通信できるため、ウェブフックはハイブリッドノードで実行できます。 1. クラウドノードで実行されているワークロードは、同じ EKS クラスター内のハイブリッドノードで実行されているワークロードと直接通信することができます。 1. 他の AWS サービス (AWS Application Load Balancer や Amazon Managed Service for Prometheus など) はハイブリッドノードで実行されているワークロードと通信し、ネットワークトラフィックのバランスを取ってポッドメトリクスをスクレイピングすることができます。 **ルーティング不可能なポッドネットワーク** オンプレミスネットワークでポッドネットワークをルーティング*できない*場合、以下のガイダンスに従ってください。 1. ウェブフックは EKS コントロールプレーンからウェブフックに割り当てられたポッド IP アドレスへの接続が必要なため、ウェブフックはハイブリッドノードで実行することはできません。この場合、ハイブリッドノードと同じ EKS クラスター内のクラウドノードでウェブフックを実行することが推奨されます。詳細については、「[ハイブリッドノード用のウェブフックを設定する](hybrid-nodes-webhooks.md)」を参照してください。 1. クラウドノードで実行されているワークロードは、クラウドノードに VPC CNI を使用する際、またはハイブリッドノードに Cilium または Calico を使用する際、ハイブリッドノードで実行されているワークロードと直接通信することはできません。 1. サービストラフィック分散を使用し、トラフィックを発信元のゾーン内に留めます。サービストラフィック分散の詳細については、「[サービストラフィック分散の設定](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-service-traffic-distribution)」を参照してください。 1. ポッドトラフィックがオンプレミスホストから出る際、出力マスカレードまたはネットワークアドレス変換 (NAT) を使用するように CNI を設定します。Cilium ではデフォルトで有効になっています。Calico では `natOutgoing` を `true` に設定する必要があります。 1. AWS Application Load Balancer や Amazon Managed Service for Prometheus などの他の AWS サービスは、ハイブリッドノードで実行されているワークロードと通信できません。 ### ハイブリッドノードのインストールとアップグレードに必要なアクセス ホストにハイブリッドノードの依存関係をインストールするインストールプロセス中は、以下のドメインにアクセスできる必要があります。このプロセスは、オペレーティングシステムイメージを構築するときに 1 回実行することも、ランタイム時に各ホストで実行することもできます。これには、初期インストールと、ハイブリッドノードの Kubernetes バージョンをアップグレードするときが含まれます。 パッケージの中には、OS のデフォルトパッケージマネージャーを使用してインストールされるものがあります。AL2023 および RHEL の場合、`yum` コマンドを使用して `containerd`、`ca-certificates`、`iptables`、`amazon-ssm-agent` をインストールします。Ubuntu の場合、`apt` を使用して `containerd`、`ca-certificates`、`iptables` をインストールし、`snap` を使用して `amazon-ssm-agent` をインストールします。 | コンポーネント | [URL] | プロトコル | ポート | | --- | --- | --- | --- | | EKS ノードアーティファクト (S3) | https://hybrid-assets.eks.amazonaws.com | HTTPS | 443 | | [VPC サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/eks.html) | https://eks.*region*.amazonaws.com | HTTPS | 443 | | [ECR サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/ecr.html) | https://api.ecr.*region*.amazonaws.com | HTTPS | 443 | | EKS ECR エンドポイント | リージョンのエンドポイントについては、「[Amazon EKS アドオンの Amazon コンテナイメージレジストリを表示する](add-ons-images.md)」を参照してください。 | HTTPS | 443 | | SSM バイナリエンドポイント 1 | https://amazon-ssm-*region*.s3.*region*.amazonaws.com | HTTPS | 443 | | [SSM サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/ssm.html) 1 | https://ssm.*region*.amazonaws.com | HTTPS | 443 | | IAM Anywhere バイナリエンドポイント 2 | https://rolesanywhere.amazonaws.com | HTTPS | 443 | | [IAM Anywhere サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rolesanywhere.html) 2 | https://rolesanywhere.*region*.amazonaws.com | HTTPS | 443 | | オペレーティングシステムパッケージマネージャーのエンドポイント | パッケージリポジトリのエンドポイントは OS に固有であり、地理的リージョンによって異なる場合があります。 | HTTPS | 443 | **注記** 1 AWS SSM エンドポイントへのアクセスは、オンプレミスの IAM 認証情報プロバイダーに AWS SSM ハイブリッドアクティベーションを使用している場合のみ必要です。 2 AWS IAM エンドポイントへのアクセスは、オンプレミスの IAM 認証情報プロバイダーに AWS IAM Roles Anywhere を使用している場合のみ必要です。 ### 継続的なクラスター運用に必要なアクセス クラスターの継続的な運用には、オンプレミスのファイアウォールに以下のネットワークアクセスが必要です。 **重要** CNI の選択に応じて、CNI ポートに追加のネットワークアクセスルールを設定する必要があります。詳細については、「[Cilium のドキュメント](https://docs.cilium.io/en/stable/operations/system_requirements/#firewall-rules)」および「[Calico のドキュメント](https://docs.tigera.io/calico/latest/getting-started/kubernetes/requirements#network-requirements)」を参照してください。 | タイプ | プロトコル | 方向 | ポート | 送信元 | 目的地 | 使用方法 | | --- | --- | --- | --- | --- | --- | --- | | HTTPS | TCP | アウトバウンド | 443 | リモートノード CIDR | EKS クラスター IP 1 | Kubelet から Kubernetes API サーバーへ | | HTTPS | TCP | アウトバウンド | 443 | リモートポッド CIDR | EKS クラスター IP 1 | Pod から Kubernetes API サーバーへ | | HTTPS | TCP | アウトバウンド | 443 | リモートノード CIDR | [SSM サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/ssm.html) | SSM ハイブリッドアクティベーション認証情報の更新と 5 分ごとの SSM ハートビート | | HTTPS | TCP | アウトバウンド | 443 | リモートノード CIDR | [IAM Anywhere サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rolesanywhere.html) | IAM Roles Anywhere 認証情報の更新 | | HTTPS | TCP | アウトバウンド | 443 | リモートポッド CIDR | [STS リージョナルエンドポイント](https://docs.aws.amazon.com/general/latest/gr/sts.html) | Pod から STS エンドポイントへ、IRSA のみ必要 | | HTTPS | TCP | アウトバウンド | 443 | リモートノード CIDR | [Amazon EKS Auth サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/eks.html) | Amazon EKS Pod Identity のみに必要な Amazon EKS 認証エンドポイントへのノード | | HTTPS | TCP | インバウンド | 10250 | EKS クラスター IP 1 | リモートノード CIDR | Kubernetes API サーバーから kubelet へ | | HTTPS | TCP | インバウンド | ウェブフックポート | EKS クラスター IP 1 | リモートポッド CIDR | Kubernetes API サーバーからウェブフックへ | | HTTPS | TCP、UDP | インバウンド、アウトバウンド | 53 | リモートポッド CIDR | リモートポッド CIDR | Pod から CoreDNS へ。クラウドで CoreDNS のレプリカを少なくとも 1 つ実行する場合は、CoreDNS が実行されている VPC への DNS トラフィックを許可する必要があります。 | | ユーザー定義 | ユーザー定義 | インバウンド、アウトバウンド | アプリポート | リモートポッド CIDR | リモートポッド CIDR | Pod から Pod へ | **注記** 1 EKS クラスターの IP。Amazon EKS Elastic Network Interface については、次のセクションを参照してください。 ### Amazon EKS ネットワークインターフェイス Amazon EKS は、クラスターの作成時に渡す VPC 内のサブネットにネットワークインターフェイスをアタッチして、EKS コントロールプレーンと VPC 間の通信を有効にします。Amazon EKS が作成するネットワークインターフェイスは、クラスターの作成後に、Amazon EC2 コンソールまたは AWS CLI で確認できます。Kubernetes バージョンのアップグレードなど、EKS クラスターに変更が適用されると、元のネットワークインターフェイスが削除され、新しいネットワークインターフェイスが作成されます。クラスターの作成時に渡すサブネットに制約付きサブネットサイズを使用することで、Amazon EKS ネットワークインターフェイスの IP 範囲を制限できます。これにより、この既知の制約付き IP セットへのインバウンド/アウトバウンド接続を許可するようにオンプレミスファイアウォールを設定することが容易になります。ネットワークインターフェイスが作成されるサブネットを制御するためには、クラスター作成時に指定するサブネットの数を制限するか、クラスター作成後にサブネットを更新することができます。 Amazon EKS によってプロビジョニングされるネットワークインターフェイスには、`Amazon EKS your-cluster-name ` の形式の説明が付けられています。Amazon EKS がプロビジョニングするネットワークインターフェイスの IP アドレスを見つけるために使用できる AWS CLI コマンドについては、以下の例を参照してください。`VPC_ID` を、クラスターの作成時に渡す VPC の ID に置き換えます。 ``` aws ec2 describe-network-interfaces \ --query 'NetworkInterfaces[?(VpcId == VPC_ID && contains(Description,Amazon EKS))].PrivateIpAddress' ``` ## AWS VPC とサブネットの設定 ハイブリッドノードを持つクラスターには、Amazon EKS の既存の [VPC とサブネットの要件](network-reqs.md)が適用されます。さらに、VPC CIDR はオンプレミスノードおよびポッド CIDR と重複することはできません。オンプレミスノードの VPC ルートテーブルにルートを設定し、オプションでポッド CIDR を設定する必要があります。これらのルートは、ハイブリッドネットワーク接続に使用しているゲートウェイにトラフィックをルーティングするように設定する必要があります。通常、これは仮想プライベートゲートウェイ (VGW) またはトランジットゲートウェイ (TGW) です。TGW または VGW を使用して VPC をオンプレミス環境に接続する場合は、VPC の TGW または VGW アタッチメントを作成する必要があります。VPC は、DNS ホスト名と DNS 解決がサポートされている必要があります。 AWS CLI を使用する手順は以下のとおりです。これらのリソースは AWS マネジメントコンソール で、または AWS CloudFormation、AWS CDK、Terraform などの他のインターフェイスでも作成することができます。 ### ステップ 1: VPC を作成する 1. 次のコマンドを実行して VPC を作成します。VPC\$1CIDR を、RFC 1918 (プライベート)、CGNAT (RFC 6598)、または非 RFC 1918/非 CGNAT (パブリック) のいずれかの IPv4 CIDR 範囲に置き換えます (例えば、10.0.0.0/16 など)。注: EKS の要件である DNS 解決は、VPC に対しデフォルトで有効になっています。 ``` aws ec2 create-vpc --cidr-block VPC_CIDR ``` 1. VPC の DNS ホスト名を有効にします。DNS 解決は、VPC に対しデフォルトで有効になっています。`VPC_ID` を、前のステップで作成した VPC の ID に置き換えます。 ``` aws ec2 modify-vpc-attribute --vpc-id VPC_ID --enable-dns-hostnames ``` ### ステップ 2: サブネットを作成する 少なくとも 2 つのサブネットを作成します。Amazon EKS は、これらのサブネットをクラスターのネットワークインターフェイスに使用します。詳細については、「[サブネットの要件と考慮事項](network-reqs.md#network-requirements-subnets)」を参照してください。 1. AWS リージョンのアベイラビリティーゾーンは、以下のコマンドで確認できます。`us-west-2` を実際のリージョンに置き換えます。 ``` aws ec2 describe-availability-zones \ --query 'AvailabilityZones[?(RegionName == us-west-2)].ZoneName' ``` 1. サブネットを作成します。`VPC_ID` を VPC の ID に置き換えます。`SUBNET_CIDR` を、サブネットの CIDR ブロック (10.0.1.0/24 など) に置き換えます。`AZ` を、サブネットが作成されるアベイラビリティーゾーン (us-west-2a など) に置き換えます。作成するサブネットは、少なくとも 2 つの異なるアベイラビリティーゾーンに存在している必要があります。 ``` aws ec2 create-subnet \ --vpc-id VPC_ID \ --cidr-block SUBNET_CIDR \ --availability-zone AZ ``` ### (オプション) ステップ 3: Amazon VPC Transit Gateway (TGW) または AWS Direct Connect 仮想プライベートゲートウェイ (VGW) を使用して VPC をアタッチする TGW または VGW を使用している場合は、VPC を TGW または VGW にアタッチします。詳細については、「[Amazon VPC attachments in Amazon VPC Transit Gateways](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html)」または「[AWS Direct Connect virtual private gateway associations](https://docs.aws.amazon.com/vpn/latest/s2svpn/how_it_works.html#VPNGateway)」を参照してください。 **Transit Gateway** 以下のコマンドを実行して、トランジットゲートウェイをアタッチします。`VPC_ID` を VPC の ID に置き換えます。`SUBNET_ID1` と `SUBNET_ID2` を、前のステップで作成したサブネットの ID に置き換えます。`TGW_ID` を TGW の ID に置き換えます。 ``` aws ec2 create-transit-gateway-vpc-attachment \ --vpc-id VPC_ID \ --subnet-ids SUBNET_ID1 SUBNET_ID2 \ --transit-gateway-id TGW_ID ``` **仮想プライベートゲートウェイ** 以下のコマンドを実行して、トランジットゲートウェイをアタッチします。`VPN_ID` をVGW の ID に置き換えます。`VPC_ID` を VPC の ID に置き換えます。 ``` aws ec2 attach-vpn-gateway \ --vpn-gateway-id VPN_ID \ --vpc-id VPC_ID ``` ### (オプション) ステップ 4: ルートテーブルを作成する VPC のメインルートテーブルを変更するか、カスタムルートテーブルを作成できます。以下の手順では、オンプレミスノードとポッド CIDR へのルートを含むカスタムルートテーブルを作成します。詳細については、「[サブネットルートテーブル](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-route-tables.html)」を参照してください。`VPC_ID` を VPC の ID に置き換えます。 ``` aws ec2 create-route-table --vpc-id VPC_ID ``` ### ステップ 5: オンプレミスノードとポッドのルートを作成する オンプレミスの各リモートノードのルートテーブルにルートを作成します。VPC のメインルートテーブルを変更するか、前のステップで作成したカスタムルートテーブルを使用できます。 以下の例は、オンプレミスノードとポッド CIDR のルートを作成する方法を示します。この例では、トランジットゲートウェイ (TGW) を使用して VPC をオンプレミス環境に接続します。複数のオンプレミスノードとポッド CIDR がある場合は、CIDR ごとにステップを繰り返します。 + インターネットゲートウェイまたは仮想プライベートゲートウェイ (VGW) を使用している場合は、`--transit-gateway-id` を `--gateway-id` に置き換えます。 + `RT_ID` を、前のステップで作成したルートテーブルの ID に置き換えます。 + `REMOTE_NODE_CIDR` を、ハイブリッドノードに使用する CIDR 範囲に置き換えます。 + `REMOTE_POD_CIDR` を、ハイブリッドノードで稼働しているポッドに使用する CIDR 範囲に置き換えます。ポッド CIDR 範囲は、オンプレミスのオーバーレイネットワークを最も一般的に使用するコンテナネットワークインターフェイス (CNI) 設定に対応しています。詳細については、「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」を参照してください。 + `TGW_ID` を TGW の ID に置き換えます。 **リモートノードネットワーク** ``` aws ec2 create-route \ --route-table-id RT_ID \ --destination-cidr-block REMOTE_NODE_CIDR \ --transit-gateway-id TGW_ID ``` **リモートポッドネットワーク** ``` aws ec2 create-route \ --route-table-id RT_ID \ --destination-cidr-block REMOTE_POD_CIDR \ --transit-gateway-id TGW_ID ``` ### (オプション) ステップ 6: サブネットをルートテーブルに関連付ける 前のステップでカスタムルートテーブルを作成した場合は、前のステップで作成した各サブネットをカスタムルートテーブルに関連付けます。VPC メインルートテーブルを変更する場合、サブネットは VPC のメインルートテーブルに自動的に関連付けられるため、このステップをスキップできます。 前のステップで作成したサブネットごとに、以下のコマンドを実行します。`RT_ID` を、前のステップで作成したルートテーブルに置き換えます。`SUBNET_ID` をサブネットの ID に置き換えます。 ``` aws ec2 associate-route-table --route-table-id RT_ID --subnet-id SUBNET_ID ``` ## クラスターセキュリティグループの設定 クラスターの継続的な運用には、EKS クラスターセキュリティグループの以下のアクセスが必要です。Amazon EKS は、リモートノードとポッドネットワークが設定されたクラスターを作成または更新するときに、ハイブリッドノードに必要な**インバウンド**セキュリティグループルールを自動的に作成します。セキュリティグループがデフォルトですべての**アウトバウンド**トラフィックを許可するため、Amazon EKS はハイブリッドノードのクラスターセキュリティグループの**アウトバウンド**ルールを自動的には変更しません。クラスターセキュリティグループをカスタマイズする場合は、以下の表に示したルールにトラフィックを制限できます。 | タイプ | プロトコル | 方向 | ポート | 送信元 | 目的地 | 使用方法 | | --- | --- | --- | --- | --- | --- | --- | | HTTPS | TCP | インバウンド | 443 | リモートノード CIDR | 該当なし | Kubelet から Kubernetes API サーバーへ | | HTTPS | TCP | インバウンド | 443 | リモートポッド CIDR | 該当なし | CNI がポッドトラフィックに NAT を使用していない場合で、ポッドが K8s API サーバーへのアクセスを必要とする場合。 | | HTTPS | TCP | アウトバウンド | 10250 | 該当なし | リモートノード CIDR | Kubernetes API サーバーから Kubelet へ | | HTTPS | TCP | アウトバウンド | ウェブフックポート | 該当なし | リモートポッド CIDR | Kubernetes API サーバーからウェブフックへ (ハイブリッドノードでウェブフックを実行している場合) | **重要** **セキュリティグループルールの制限**: Amazon EC2 セキュリティグループに保持できるインバウンドルールはデフォルトで最大 60 個です。クラスターセキュリティグループがこの制限に近づいた場合、セキュリティグループのインバウンドルールが適用されないことがあります。この場合、欠落しているインバウンドルールを手動で追加しなければならないことがあります。 **CIDR クリーンアップの責任**: EKS クラスターからリモートノードまたはポッドネットワークを削除した場合、EKS は対応するセキュリティグループルールを自動的に削除しません。セキュリティグループルールから未使用のリモートノードまたはポッドネットワークを手動で削除する責任はお客様にあります。 Amazon EKS が作成するクラスターセキュリティグループの詳細については「[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)」を参照してください。 ### (オプション) セキュリティグループの手動設定 追加のセキュリティグループを作成したり、自動的に作成されたルールを変更したりする必要がある場合は、次のコマンドを参照として使用できます。デフォルトでは、以下のコマンドは、すべてのアウトバウンドアクセスを許可するセキュリティグループを作成します。アウトバウンドアクセスを上記のルールのみに制限することができます。アウトバウンドルールの制限を検討している場合、変更したルールを本番稼働用のクラスターに適用する前に、すべてのアプリケーションとポッドの接続を徹底的にテストすることをお勧めします。 + 最初のコマンドで、`SG_NAME` をセキュリティグループの名前に置き換えます + 最初のコマンドで、`VPC_ID` を前のステップで作成した VPC の ID に置き換えます + 2 番目のコマンドで、`SG_ID` を最初のコマンドで作成したセキュリティグループの ID に置き換えます + 2 番目のコマンドで、`REMOTE_NODE_CIDR` と `REMOTE_POD_CIDR` をハイブリッドノードとオンプレミスネットワークの値にそれぞれ置き換えます。 ``` aws ec2 create-security-group \ --group-name SG_NAME \ --description "security group for hybrid nodes" \ --vpc-id VPC_ID ``` ``` aws ec2 authorize-security-group-ingress \ --group-id SG_ID \ --ip-permissions '[{"IpProtocol": "tcp", "FromPort": 443, "ToPort": 443, "IpRanges": [{"CidrIp": "REMOTE_NODE_CIDR"}, {"CidrIp": "REMOTE_POD_CIDR"}]}]' ``` # ハイブリッドノード用のオペレーティングシステムを準備する Bottlerocket、Amazon Linux 2023 (AL2023)、Ubuntu、RHEL は、ハイブリッドノードのノードオペレーティングシステムとして使用されるために継続的に検証されます。Bottlerocket は、VMware vSphere 環境でのみ AWS でサポートされています。AL2023 は、Amazon EC2 の外部で実行される場合、AWS サポートプランの対象外です。AL2023 はオンプレミスの仮想化環境でのみ使用できます。詳細については、「[Amazon Linux 2023 ユーザーガイド](https://docs.aws.amazon.com/linux/al2023/ug/outside-ec2.html)」を参照してください。AWS は Ubuntu および RHEL オペレーティングシステムとのハイブリッドノード統合をサポートしていますが、オペレーティングシステム自体はサポートしていません。 オペレーティングシステムのプロビジョニングと管理はお客様の責任となります。ハイブリッドノードを初めてテストする場合、プロビジョニング済みのホストで Amazon EKS Hybrid Nodes CLI (`nodeadm`) を実行するのが最も簡単です。本稼働デプロイでは、ホスト起動時にホストを Amazon EKS クラスターに自動的に結合する systemd サービスとして実行するように設定された `nodeadm` を、オペレーティングシステムイメージに含めることが推奨されます。Bottlerocket を vSphere のノードオペレーティングシステムとして使用している場合は `nodeadm` を使用する必要はありません。Bottlerocket にはハイブリッドノードに必要な依存関係が既に含まれ、ホストのスタートアップ時に設定するクラスターに自動的に接続されるからです。 ## バージョン互換性 以下の表は、ハイブリッドノードのノードオペレーティングシステムとしての使用に互換性があり、検証済みとなっているオペレーティングシステムのバージョンを示しています。オペレーティングシステムのこの表に記載されていないバリアントやバージョンを使用している場合、そのオペレーティングシステムのバリアントまたはバージョンとのハイブリッドノードの互換性は、AWS サポートの対象外となります。ハイブリッドノードは基盤となるインフラストラクチャに依存せず、x86 および ARM アーキテクチャに対応しています。 | オペレーティングシステム | バージョン | | --- | --- | | Amazon Linux | Amazon Linux 2023 (AL2023) | | Bottlerocket | v1.37.0 以降、Kubernetes v1.28 以降を実行している VMware のバリアント | | Ubuntu | Ubuntu 20.04、Ubuntu 22.04、Ubuntu 24.04 | | Red Hat Enterprise Linux | RHEL 8、RHEL 9 | ## オペレーティングシステムに関する考慮事項 ### General + Amazon EKS Hybrid Nodes CLI (`nodeadm`) を使用すると、ハイブリッドノードのコンポーネントおよび依存関係のインストールと設定を簡素化できます。`nodeadm install` プロセスは、オペレーティングシステムイメージのビルドパイプライン中、または各オンプレミスホストの実行時に実行できます。`nodeadm` がインストールするコンポーネントの詳細については、「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。 + オンプレミス環境でプロキシを使用してインターネットにアクセスしている場合、インストールおよびアップグレードのプロセスでパッケージマネージャーがプロキシを使用するよう設定するために、追加のオペレーティングシステム設定が必要です。手順については「[ハイブリッドノードのプロキシを設定する](hybrid-nodes-proxy.md)」を参照してください。 ### Bottlerocket + Bottlerocket ノードを接続するときのステップとツールは他のオペレーティングシステムのステップとは異なるため、「[ハイブリッドノードを接続する](hybrid-nodes-join.md)」の手順ではなく「[Bottlerocket を実行しているハイブリッドノードの接続](hybrid-nodes-bottlerocket.md)」に記載しています。 + Bottlerocket のステップでは、ハイブリッドノード CLI のツールである `nodeadm` は使用しません。 + EKS Hybrid Nodes でサポートされているのは、Bottlerocket のバージョンが v1.37.0 以降である VMware のバリアントのみです。Bottlerocket の VMware のバリアントは、Kubernetes のバージョン v1.28 以降で使用できます。[その他の Bottlerocket のバリアント](https://bottlerocket.dev/en/os/1.36.x/concepts/variants)は、ハイブリッドノードのオペレーティングシステムとしてサポートされていません。注: Bottlerocket の VMware のバリアントを使用できるのは、x86\$164 のアーキテクチャのみです。 ### Containerd + Containerd は標準の Kubernetes コンテナランタイムであり、ハイブリッドノードのみならず、あらゆるコンピューティングタイプの Amazon EKS ノードの依存関係の 1 つです。Amazon EKS Hybrid Nodes CLI (`nodeadm`) は、`nodeadm install` プロセス中に containerd のインストールを試みます。`--containerd-source` コマンドラインオプションを使用して、`nodeadm install` の実行時に containerd のインストールを設定できます。有効なオプションは、`none`、`distro`、`docker` です。RHEL を使用している場合、`distro` は有効なオプションではなく、Docker のリポジトリから containerd ビルドをインストールするよう `nodeadm` を設定するか、containerd を手動でインストールできます。AL2023 または Ubuntu を使用する場合、`nodeadm` はオペレーティングシステムのディストリビューションから containerd をインストールするのがデフォルトになります。nodeadm で containerd をインストールしない場合は、`--containerd-source none` オプションを使用します。 ### Ubuntu + Ubuntu 24.04 を使用している場合、ポッドを適切に終了させるための修正を適用するために、containerd のバージョンを更新するか、AppArmor の設定を変更する必要がある場合があります。「[Ubuntu \$12065423](https://bugs.launchpad.net/ubuntu/+source/containerd-app/\+bug/2065423)」を参照してください。AppArmor プロファイルに変更を適用するには、再起動が必要です。Ubuntu 24.04 の最新バージョンには、修正が含まれた更新版の containerd バージョン (containerd バージョン 1.7.19 以降) がパッケージマネージャーに含まれています。 ### ARM + ARM ハードウェアを使用している場合、EKS kube-proxy アドオンのバージョン 1.31 以降を実行するためには、Cryptography Extension (ARMv8.2\$1crypto) を搭載した ARMv8.2 準拠のプロセッサが必要です。Cortex-A72 ベースのプロセッサのほか、Raspberry Pi 5 より前のすべての Raspberry Pi システムもこの要件を満たしていません。回避策として、2026 年 7 月に延長サポートが終了するまで、EKS kube-proxy アドオンのバージョン 1.30 をこれまで通り使用できます。「[Kubernetes release calendar](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)」を参照するか、アップストリームからカスタム kube-proxy イメージを使用してください。 + kube-proxy ログに以下のエラーメッセージが記録されていれば、この非互換性が生じていることになります。 ``` Fatal glibc error: This version of Amazon Linux requires a newer ARM64 processor compliant with at least ARM architecture 8.2-a with Cryptographic extensions. On EC2 this is Graviton 2 or later. ``` ## オペレーティングシステムイメージの構築 Amazon EKS は、`nodeadm` を含み、ホスト起動時に実行するように設定されたオペレーティングシステムイメージを作成するために使用できる [Packer テンプレートの例](https://github.com/aws/eks-hybrid/tree/main/example/packer)を提供しています。このプロセスは、各ホストでハイブリッドノードの依存関係を個別にプルすることを避け、ハイブリッドノードのブートストラッププロセスを自動化するために推奨されています。Packer テンプレートの例は、Ubuntu 22.04、Ubuntu 24.04、RHEL 8、または RHEL 9 ISO イメージで使用でき、イメージの出力は OVA、Qcow2、または raw の形式で行えます。 ### 前提条件 Packer テンプレートの例を使用する前に、Packer を実行しているマシンに以下がインストールされている必要があります。 + Packer バージョン 1.11.0 以降。Packer のインストール手順については、「Packer documentation」の「[nstall Packer](https://developer.hashicorp.com/packer/tutorials/docker-get-started/get-started-install-cli)」を参照してください。 + OVA を構築する場合、VMware vSphere プラグイン 1.4.0 以降 + `Qcow2` または raw イメージを構築する場合、QEMU プラグインバージョン 1.x ### 環境変数の設定 Packer ビルドを実行する前に、Packer を実行しているマシンで次の環境変数を設定します。 **General** いずれのオペレーティングシステムおよび出力形式においても、イメージを構築する際には、以下の環境変数を設定する必要があります。 | 環境変数 | タイプ | 説明 | | --- | --- | --- | | PKR\$1SSH\$1PASSWORD | String | Packer は、プロビジョニング時に作成されたマシンに SSH 接続する際は、`ssh_username` および `ssh_password` 変数を使用します。これは、各 OS のキックスタートファイルまたは user-data ファイル内に初期ユーザーを作成する際に使用されるパスワードと一致する必要があります。デフォルトは、OS に応じて「builder」または「ubuntu」に設定されます。パスワードを設定する際は、必ず対応する `ks.cfg` または `user-data` ファイル内のパスワードも一致するように変更してください。 | | ISO\$1URL | String | 使用する ISO の URL。サーバーからダウンロードするウェブリンクでも、ローカルファイルへの絶対パスでもかまいません | | ISO\$1CHECKSUM | String | 指定された ISO に関連するチェックサム。 | | CREDENTIAL\$1PROVIDER | String | ハイブリッドノードの認証情報プロバイダー。有効な値は `ssm` (SSM ハイブリッドアクティベーション用、デフォルト) と `iam` (IAM Roles Anywhere 用) です | | K8S\$1VERSION | String | ハイブリッドノードの Kubernetes バージョン (`1.31` など)。サポートされている Kubernetes のバージョンについては、「[Amazon EKS supported versions](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)」を参照してください。 | | NODEADM\$1ARCH | String | `nodeadm install` 用アーキテクチャ。`amd` または `arm` を選択します。 | ** (RHEL**) RHEL を使用している場合は、以下の環境変数を設定する必要があります。 | 環境変数 | タイプ | 説明 | | --- | --- | --- | | RH\$1USERNAME | String | RHEL サブスクリプションマネージャーのユーザー名 | | RH\$1PASSWORD | String | RHEL サブスクリプションマネージャーのパスワード | | RHEL\$1VERSION | String | 使用する RHEL の ISO のバージョン。有効な値は `8` または `9` です。 | **Ubuntu** - Ubuntu 固有の環境変数は必要ありません。 **vSphere** VMware vSphere OVA を構築する場合は、以下の環境変数を設定する必要があります。 | 環境変数 | タイプ | 説明 | | --- | --- | --- | | VSPHERE\$1SERVER | String | vSphere のサーバーアドレス | | VSPHERE\$1USER | String | vSphere のユーザー名 | | VSPHERE\$1PASSWORD | String | vSphere のパスワード | | VSPHERE\$1DATACENTER | String | vSphere のデータセンター名 | | VSPHERE\$1CLUSTER | String | vSphere のクラスター名 | | VSPHERE\$1DATASTORE | String | vSphere のデータストア名 | | VSPHERE\$1NETWORK | String | vSphere のネットワーク名 | | VSPHERE\$1OUTPUT\$1FOLDER | String | テンプレート用の vSphere の出力フォルダ | **QEMU** | 環境変数 | タイプ | 説明 | | --- | --- | --- | | PACKER\$1OUTPUT\$1FORMAT | String | QEMU ビルダーの出力形式。有効な値は、`qcow2` および `raw` です。 | **テンプレートを検証する** 環境変数を設定した後は、ビルドを実行する前に以下のコマンドでテンプレートを検証します。テンプレートに異なる名前を使用している場合は、`template.pkr.hcl` を置き換えてください。 ``` packer validate template.pkr.hcl ``` ### イメージを構築する 以下のコマンドを使用してイメージを構築し、`-only` フラグを使用してイメージのターゲットとオペレーティングシステムを指定します。テンプレートに異なる名前を使用している場合は、`template.pkr.hcl` を置き換えてください。 **vSphere OVA** **注記** vSphere で RHEL を使用している場合は、キックスタートファイルを OEMDRV イメージに変換し、起動元の ISO として渡す必要があります。詳細については、EKS ハイブリッドノードの GitHub リポジトリにある「[Packer Readme](https://github.com/aws/eks-hybrid/tree/main/example/packer#utilizing-rhel-with-vsphere)」を参照してください。 **Ubuntu 22.04 OVA** ``` packer build -only=general-build.vsphere-iso.ubuntu22 template.pkr.hcl ``` **Ubuntu 24.04 OVA** ``` packer build -only=general-build.vsphere-iso.ubuntu24 template.pkr.hcl ``` **RHEL 8 OVA** ``` packer build -only=general-build.vsphere-iso.rhel8 template.pkr.hcl ``` **RHEL 9 OVA** ``` packer build -only=general-build.vsphere-iso.rhel9 template.pkr.hcl ``` **QEMU** **注記** ビルダーのホストと一致しない特定のホストの CPU 用にイメージを構築する場合は、ホストの CPU に対応する名前を「[QEMU](https://www.qemu.org/docs/master/system/qemu-cpu-models.html)」のドキュメントで確認し、以下のコマンドを実行する際にホストの CPU 名を指定した `-cpu` フラグを使用します。 **Ubuntu 22.04 Qcow2/Raw** ``` packer build -only=general-build.qemu.ubuntu22 template.pkr.hcl ``` **Ubuntu 24.04 Qcow2/Raw** ``` packer build -only=general-build.qemu.ubuntu24 template.pkr.hcl ``` **RHEL 8 Qcow2/Raw** ``` packer build -only=general-build.qemu.rhel8 template.pkr.hcl ``` **RHEL 9 Qcow2/Raw** ``` packer build -only=general-build.qemu.rhel9 template.pkr.hcl ``` ### nodeadm 設定を user-data を通して渡す cloud-init を介して `nodeadm` の設定を user-data で渡すことで、ホストの起動時にハイブリッドノードを設定し、自動的に EKS クラスターに接続することができます。以下は、ハイブリッドノードのインフラストラクチャとして VMware vSphere を使用する場合の実装例です。 1. GitHub の [govc readme](https://github.com/vmware/govmomi/blob/main/govc/README.md) の手順に従って `govc` CLI をインストールします。 1. 前のセクションで Packer ビルドを実行してテンプレートをプロビジョニングした後は、以下を使用してテンプレートをクローンし、複数の異なるノードを作成することができます。ハイブリッドノードに使用する新規 VM を作成するたびに、テンプレートをクローンする必要があります。以下のコマンド内の変数は、お使いの環境に応じた値に置き換えます。以下のコマンドの `VM_NAME` は、`metadata.yaml` ファイルを介して VM の名前を注入する際に `NODE_NAME` として使用されます。 ``` govc vm.clone -vm "/PATH/TO/TEMPLATE" -ds="YOUR_DATASTORE" \ -on=false -template=false -folder=/FOLDER/TO/SAVE/VM "VM_NAME" ``` 1. 各新規 VM のテンプレートをクローンした後は、VM の `metadata.yaml` と `userdata.yaml` を作成します。VM は同じ `userdata.yaml` と `metadata.yaml` を共有でき、以下のステップで VM ごとにこれらを入力していきます。`nodeadm` の設定は、`userdata.yaml` の `write_files` セクションで作成および定義されます。以下の例では、ハイブリッドノードのオンプレミス認証情報プロバイダーとして AWS SSM ハイブリッドアクティベーションを使用しています。`nodeadm` 設定の詳細については、「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。 **userdata.yaml:** ``` #cloud-config users: - name: # username for login. Use 'builder' for RHEL or 'ubuntu' for Ubuntu. passwd: # password to login. Default is 'builder' for RHEL. groups: [adm, cdrom, dip, plugdev, lxd, sudo] lock-passwd: false sudo: ALL=(ALL) NOPASSWD:ALL shell: /bin/bash write_files: - path: /usr/local/bin/nodeConfig.yaml permissions: '0644' content: | apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: # Cluster Name region: # AWS region hybrid: ssm: activationCode: # Your ssm activation code activationId: # Your ssm activation id runcmd: - /usr/local/bin/nodeadm init -c file:///usr/local/bin/nodeConfig.yaml >> /var/log/nodeadm-init.log 2>&1 ``` **metadata.yaml:** お使いの環境に応じた `metadata.yaml` を作成します。`"$NODE_NAME"` 変数の形式は、後続のステップで値が入力されるため、ファイル内にそのまま保持してください。 ``` instance-id: "$NODE_NAME" local-hostname: "$NODE_NAME" network: version: 2 ethernets: nics: match: name: ens* dhcp4: yes ``` 1. 以下のコマンドを使用して、`userdata.yaml` および `metadata.yaml` ファイルを `gzip+base64` 文字列として追加します。以下のコマンドは、作成する VM ごとに実行する必要があります。`VM_NAME` は、更新する VM の名前に置き換えてください。 ``` export NODE_NAME="VM_NAME" export USER_DATA=$(gzip -c9 metadata.yaml.tmp export METADATA=$(gzip -c9 Amazon EKS Hybrid Nodes は、AWS SSM ハイブリッドアクティベーションまたは AWS IAM Roles Anywhere によってプロビジョニングされた一時的な IAM 認証情報を使用して、Amazon EKS クラスターで認証します。Amazon EKS Hybrid Nodes CLI (`nodeadm`) を用いて、AWS SSM ハイブリッドアクティベーションまたは AWS IAM Roles Anywhere を使用する必要があります。AWS SSM ハイブリッドアクティベーションと AWS IAM Roles Anywhere の両方を使用しないでください。認証局 (CA) およびオンプレミス環境の証明書を持つ既存の公開鍵基盤 (PKI) がない場合、AWS SSM ハイブリッドアクティベーションを使用することをお勧めします。既存の PKI と証明書がオンプレミスにある場合は、AWS IAM Roles Anywhere を使用します。 ## ハイブリッドノードの IAM ロール ハイブリッドノードを Amazon EKS クラスターに接続する前に、SSM ハイブリッドアクティベーションで使用する AWS IAM ロールまたはハイブリッドノードの認証情報用の AWS IAM Roles Anywhere を作成する必要があります。クラスターの作成後、Amazon EKS アクセスエントリまたは `aws-auth` ConfigMap エントリでこのロールを使用して、IAM ロールを Kubernetes ロールベースのアクセスコントロール (RBAC) にマッピングします。ハイブリッドノードの IAM ロールと Kubernetes RBAC の関連付けの詳細については、「[ハイブリッドノードのクラスターアクセスを準備する](hybrid-nodes-cluster-prep.md)」を参照してください。 ハイブリッドノードの IAM ロールには、以下のアクセス許可が必要です。 + ハイブリッドノードを接続するクラスターに関する情報を収集するための `eks:DescribeCluster` アクションを、`nodeadm` が使用するためのアクセス許可。`eks:DescribeCluster` アクションを有効にしない場合は、`nodeadm init` コマンドに渡すノード設定で、Kubernetes API エンドポイント、クラスター CA バンドル、およびサービス IPv4 CIDR を渡す必要があります。 + ハイブリッドノードを接続するクラスターのアクセスエントリを一覧表示するための `eks:ListAccessEntries` アクションを、`nodeadm` が使用するためのアクセス許可。`eks:ListAccessEntries` アクションを有効にしない場合は、`nodeadm init` コマンドの実行時に `--skip cluster-access-validation` フラグを渡す必要があります。 + kubelet が「[AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ContainerRegistryPullOnly.html)」 ポリシーで定義されているように、 Amazon Elastic Container Registry (Amazon ECR) のコンテナイメージを使用するためのアクセス許可。 + AWS SSM を使用している場合、[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html) ポリシーで定義されている AWS SSM ハイブリッドアクティベーションを使用するための `nodeadm init` のアクセス許可。 + AWS SSM を使用している場合、`nodeadm uninstall` がインスタンスを登録解除するために `ssm:DeregisterManagedInstance` アクションと `ssm:DescribeInstanceInformation` アクションを使用するためのアクセス許可。 + (オプション) Amazon EKS Pod Identity エージェントが `eks-auth:AssumeRoleForPodIdentity` アクションを使用してポッドの認証情報を取得するためのアクセス許可。 ## AWS SSM ハイブリッドアクティベーションのセットアップ AWS SSM ハイブリッドアクティベーションを設定する前に、ハイブリッドノードの IAM ロールを作成して設定する必要があります。詳細については、「[ハイブリッドノードの IAM ロールを作成する](#hybrid-nodes-create-role)」を参照してください。「AWS Systems Manager ユーザーガイド」の「[Systems Manager にハイブリッドノードを登録するためのハイブリッドアクティベーションの作成](https://docs.aws.amazon.com/systems-manager/latest/userguide/hybrid-activation-managed-nodes.html)」の指示に従って、ハイブリッドノード用の AWS SSM ハイブリッドアクティベーションを作成します。受け取ったアクティベーションコードと ID は、ホストを Amazon EKS クラスターのハイブリッドノードとして登録する際に、`nodeadm` で使用されます。ハイブリッドノード用の Amazon EKS クラスターを作成し準備した後は、このステップに戻ることができます。 **重要** アクティベーションの作成方法に応じて、Systems Manager はすぐにアクティベーションコードと ID をコンソールまたはコマンドウィンドウに返します。この情報をコピーして、安全な場所に保管します。コンソールから離れたり、コマンドウィンドウを閉じたりすると、この情報は失われる可能性があります。紛失した場合は、新しいアクティベーションを作成する必要があります。 デフォルトでは、AWS SSM ハイブリッドアクティベーションは 24 時間アクティブになります。または、ハイブリッドアクティベーションを作成する際に、`2024-08-01T00:00:00` のようなタイムスタンプ形式で `--expiration-date` を指定することもできます。認証情報プロバイダーとして AWS SSM を使用する場合、ハイブリッドノードのノード名は設定できず、AWS SSM によって自動生成されます。AWS SSM マネージドインスタンスは、Fleet Manager の AWS Systems Manager コンソールで表示および管理できます。追加コストなしで、アカウントにつき AWS リージョンごとに最大 1,000 のスタンダード[ハイブリッドアクティベーションノード](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html)を登録できます。ただし、1,000 を超えるハイブリッドノードを登録するには、アドバンストインスタンス層のアクティブ化が必要です。これには、[Amazon EKS Hybrid Nodes の料金](https://aws.amazon.com/eks/pricing/)に含まれていない、アドバンストインスタンス層の利用料金が発生します。詳細については、「[AWS Systems Manager の料金](https://aws.amazon.com/systems-manager/pricing/)」を参照してください。 ハイブリッドノードの IAM ロールを使用して AWS SSM ハイブリッドアクティベーションを作成する方法については、以下の例を参照してください。ハイブリッドノードの認証情報に AWS SSM ハイブリッドアクティベーションを使用する場合、ハイブリッドノードの名前は `mi-012345678abcdefgh` 形式になり、AWS SSM によってプロビジョニングされた一時的な認証情報は 1 時間有効です。AWS SSM を認証情報プロバイダーとして使用する場合、ノード名または認証情報の期間を変更することはできません。一時的な認証情報は AWS SSM によって自動的にローテーションされ、ローテーションはノードやアプリケーションのステータスには影響しません。 ハイブリッドノードの IAM ロールの AWS SSM の `ssm:DeregisterManagedInstance` アクセス許可の範囲を、お使いの AWS SSM ハイブリッドアクティベーションに関連付けられたインスタンスしか登録解除できないよう制限するために、EKS クラスターごとに 1 つの AWS SSM ハイブリッドアクティベーションを使用することをお勧めします。このページの例では、EKS クラスター ARN を含むタグが使用され、AWS SSM ハイブリッドアクティベーションを EKS クラスターにマッピングするために使用できます。または、任意のタグと方法を使用して、アクセス許可の境界と要件に基づいて AWS SSM アクセス許可の範囲を絞り込むこともできます。以下のコマンドの `REGISTRATION_LIMIT` オプションは、AWS SSM ハイブリッドアクティベーションを使用できるマシンの数を制限するために使用される整数です (`10` など)。 ``` aws ssm create-activation \ --region AWS_REGION \ --default-instance-name eks-hybrid-nodes \ --description "Activation for EKS hybrid nodes" \ --iam-role AmazonEKSHybridNodesRole \ --tags Key=EKSClusterARN,Value=arn:aws:eks:AWS_REGION:AWS_ACCOUNT_ID:cluster/CLUSTER_NAME \ --registration-limit REGISTRATION_LIMIT ``` AWS SSM ハイブリッドアクティベーションで使用可能な構成設定の詳細については、「[ハイブリッドアクティベーションを作成して Systems Manager にノードを登録する](https://docs.aws.amazon.com/systems-manager/latest/userguide/hybrid-activation-managed-nodes.html)」の手順を確認してください。 ## AWS IAM Roles Anywhere の設定 「IAM Roles Anywhere ユーザーガイド」の「[IAM Roles Anywhere の開始方法](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/getting-started.html)」の手順に従って、ハイブリッドノードの IAM ロールの一時的な IAM 認証情報に使用するトラストアンカーとプロファイルを設定します。プロファイルを作成する際は、ロールを追加せずにプロファイルを作成できます。プロファイルを作成してから、ハイブリッドノードの IAM ロールを作成するステップに戻り、作成したプロファイルにロールを追加することもできます。または、このページの後半にある AWS CloudFormation ステップを使用して、ハイブリッドノードの IAM Roles Anywhere セットアップを完了することもできます。 ハイブリッドノードの IAM ロールをプロファイルに追加するときは、AWS IAM Roles Anywhere コンソールの **[プロファイルの編集]** ページの下部にある **[カスタムロール]** セッション名パネルで **[カスタムロールセッション名を受け入れる]** を選択します。これは `CreateProfile` API の [acceptRoleSessionName](https://docs.aws.amazon.com/rolesanywhere/latest/APIReference/API_CreateProfile.html#rolesanywhere-CreateProfile-request-acceptRoleSessionName) フィールドに対応します。これにより、ブートストラッププロセス中に `nodeadm` に渡す設定内で、ハイブリッドノードのカスタムノード名を指定できます。`nodeadm init` プロセス中にカスタムノード名を渡す必要があります。プロファイルの作成後、カスタムロールセッション名を受け入れるようにプロファイルを更新できます。 AWS IAM Roles Anywhere では、AWS IAM Roles Anywhere プロファイルの [durationSeconds](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/authentication-create-session#credentials-object) フィールドを通して認証情報の有効期間を設定できます。デフォルトの期間は 1 時間で、最大は 12 時間です。ハイブリッドノードの IAM ロールでの `MaxSessionDuration` 設定は、AWS IAM Roles Anywhere プロファイルの `durationSeconds` 設定よりも大きくする必要があります。`MaxSessionDuration` の詳細については、「[UpdateRole API documentation](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateRole.html)」を参照してください。 認証機関 (CA) から生成するマシンごとの証明書とキーは、ファイル名を証明書は `server.pem`、キーは `server.key` として、各ハイブリッドノードの `/etc/iam/pki` ディレクトリに配置する必要があります。 ## ハイブリッドノードの IAM ロールを作成する このセクションのステップを実行するには、AWS コンソールまたは AWS CLI を使用する IAM プリンシパルに以下のアクセス許可が必要です。 + `iam:CreatePolicy` + `iam:CreateRole` + `iam:AttachRolePolicy` + AWS IAM Roles Anywhere を使用している場合 + `rolesanywhere:CreateTrustAnchor` + `rolesanywhere:CreateProfile` + `iam:PassRole` ### AWS CloudFormation まだである場合は、AWS CLI をインストールして設定します。「[AWS CLI の最新バージョンのインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。 **AWS SSM ハイブリッドアクティベーションのステップ** CloudFormation スタックは、上記のアクセス許可を持つハイブリッドノードの IAM ロールを作成します。CloudFormation テンプレートは、AWS SSM ハイブリッドアクティベーションを作成しません。 1. ハイブリッドノード用の AWS SSM CloudFormation テンプレートをダウンロードします。 ``` curl -OL 'https://raw.githubusercontent.com/aws/eks-hybrid/refs/heads/main/example/hybrid-ssm-cfn.yaml' ``` 1. 以下のオプションを使用して `cfn-ssm-parameters.json` を作成します。 1. `ROLE_NAME` をハイブリッドノードの IAM ロールの名前に置き換えます。デフォルトでは、名前を指定しない場合、CloudFormation テンプレートは作成するロールの名前として `AmazonEKSHybridNodesRole` を使用します。 1. `TAG_KEY` を、AWS SSM ハイブリッドアクティベーションの作成時に使用した AWS SSM リソースのタグキーに置き換えます。タグキーとタグ値の組み合わせは、`ssm:DeregisterManagedInstance` の条件で使用されます。これにより、ハイブリッドノードの IAM ロールは、ユーザーの AWS SSM ハイブリッドアクティベーションに関連付けられている AWS SSM マネージドインスタンスの登録解除のみ許可されるようになります。CloudFormation テンプレートでは、`TAG_KEY` はデフォルトで `EKSClusterARN` になります。 1. `TAG_VALUE` を、AWS SSM ハイブリッドアクティベーションの作成時に使用した SSM AWS リソースタグ値に置き換えます。タグキーとタグ値の組み合わせは、`ssm:DeregisterManagedInstance` の条件で使用されます。これにより、ハイブリッドノードの IAM ロールは、ユーザーの AWS SSM ハイブリッドアクティベーションに関連付けられている AWS SSM マネージドインスタンスの登録解除のみ許可されるようになります。`EKSClusterARN` のデフォルトの `TAG_KEY` を使用している場合は、EKS クラスター ARN を `TAG_VALUE` として渡します。EKS クラスター ARN の形式は ` arn:aws:eks:AWS_REGION:AWS_ACCOUNT_ID:cluster/CLUSTER_NAME` になります。 ``` { "Parameters": { "RoleName": "ROLE_NAME", "SSMDeregisterConditionTagKey": "TAG_KEY", "SSMDeregisterConditionTagValue": "TAG_VALUE" } } ``` 1. CloudFormation スタックをデプロイします。`STACK_NAME` は、その CloudFormation スタックに付けた任意の名前に置き換えてください。 ``` aws cloudformation deploy \ --stack-name STACK_NAME \ --template-file hybrid-ssm-cfn.yaml \ --parameter-overrides file://cfn-ssm-parameters.json \ --capabilities CAPABILITY_NAMED_IAM ``` **AWS IAM Roles Anywhere のステップ** CloudFormation スタックは、設定した認証機関 (CA) を使用して AWS IAM Roles Anywhere のトラストアンカーを作成し、AWS IAM Roles Anywhere プロファイルを作成し、前述のアクセス許可を使用して、ハイブリッドノードの IAM ロールを作成します。 1. 認証機関 (CA) のセットアップ 1. AWS Private CA リソースを使用するには、[AWS Private Certificate Authority コンソール](https://console.aws.amazon.com/acm-pca/home)を開きます。[「AWS Private CA ユーザーガイド](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html)」の指示に従ってください。 1. 外部 CA を使用するには、CA が提供する手順に従ってください。証明書本文は後のステップで提出します。 1. パブリック CA から発行された証明書をトラストアンカーとして使用することはできません。 1. ハイブリッドノード用の AWS IAM Roles Anywhere CloudFormation テンプレートをダウンロードします ``` curl -OL 'https://raw.githubusercontent.com/aws/eks-hybrid/refs/heads/main/example/hybrid-ira-cfn.yaml' ``` 1. 以下のオプションを使用して `cfn-iamra-parameters.json` を作成します。 1. `ROLE_NAME` をハイブリッドノードの IAM ロールの名前に置き換えます。デフォルトでは、名前を指定しない場合、CloudFormation テンプレートは作成するロールの名前として `AmazonEKSHybridNodesRole` を使用します。 1. `CERT_ATTRIBUTE` を、ホストを一意に識別するマシンごとの証明書属性に置き換えます。使用する証明書属性は、ハイブリッドノードをクラスターに接続するときに `nodeadm` 設定に使用する nodeName と一致する必要があります。詳細については、「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。デフォルトでは、CloudFormation テンプレートは `${aws:PrincipalTag/x509Subject/CN}` を `CERT_ATTRIBUTE` として使用します。これは、マシンごとの証明書の CN フィールドに対応します。または、`$(aws:PrincipalTag/x509SAN/Name/CN}` を `CERT_ATTRIBUTE` として渡すこともできます。 1. `CA_CERT_BODY` を、CA の証明書本文から改行を取り除いたものに置き換えます。`CA_CERT_BODY` は、プライバシー強化メール (PEM) 形式である必要がありす。PEM 形式の CA 証明書がある場合は、CA 証明書本文を `cfn-iamra-parameters.json` ファイルに配置する前に、改行と BEGIN CERTIFICATE 行と END CERTIFICATE 行を削除します。 ``` { "Parameters": { "RoleName": "ROLE_NAME", "CertAttributeTrustPolicy": "CERT_ATTRIBUTE", "CABundleCert": "CA_CERT_BODY" } } ``` 1. CloudFormation テンプレートをデプロイする。`STACK_NAME` は、その CloudFormation スタックに付けた任意の名前に置き換えてください。 ``` aws cloudformation deploy \ --stack-name STACK_NAME \ --template-file hybrid-ira-cfn.yaml \ --parameter-overrides file://cfn-iamra-parameters.json --capabilities CAPABILITY_NAMED_IAM ``` ### AWS CLI まだである場合は、AWS CLI をインストールして設定します。「[AWS CLI の最新バージョンのインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。 **EKS DescribeCluster ポリシーを作成する** 1. 次の内容で、`eks-describe-cluster-policy.json` という名前のファイルを作成します。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:DescribeCluster" ], "Resource": "*" } ] } ``` 1. 次のコマンドを使用してポリシーを作成します。 ``` aws iam create-policy \ --policy-name EKSDescribeClusterPolicy \ --policy-document file://eks-describe-cluster-policy.json ``` **AWS SSM ハイブリッドアクティベーションのステップ** 1. 次の内容で、`eks-hybrid-ssm-policy.json` という名前のファイルを作成します。このポリシーは、`ssm:DescribeInstanceInformation` と `ssm:DeregisterManagedInstance` の 2 つのアクションのアクセス許可を付与します。このポリシーは、`ssm:DeregisterManagedInstance` へのアクセス許可の範囲を、信頼ポリシーで指定したリソースタグに基づき、AWS SSM ハイブリッドアクティベーションに関連付けられた AWS SSM マネージドインスタンスに制限します。 1. `AWS_REGION` を、AWS SSM ハイブリッドアクティベーションの AWS リージョンに置き換えます。 1. `AWS_ACCOUNT_ID` を AWS アカウント ID に置き換えます。 1. `TAG_KEY` を、AWS SSM ハイブリッドアクティベーションの作成時に使用した AWS SSM リソースのタグキーに置き換えます。タグキーとタグ値の組み合わせは、`ssm:DeregisterManagedInstance` の条件で使用されます。これにより、ハイブリッドノードの IAM ロールは、ユーザーの AWS SSM ハイブリッドアクティベーションに関連付けられている AWS SSM マネージドインスタンスの登録解除のみ許可されるようになります。CloudFormation テンプレートでは、`TAG_KEY` はデフォルトで `EKSClusterARN` になります。 1. `TAG_VALUE` を、AWS SSM ハイブリッドアクティベーションの作成時に使用した SSM AWS リソースタグ値に置き換えます。タグキーとタグ値の組み合わせは、`ssm:DeregisterManagedInstance` の条件で使用されます。これにより、ハイブリッドノードの IAM ロールは、ユーザーの AWS SSM ハイブリッドアクティベーションに関連付けられている AWS SSM マネージドインスタンスの登録解除のみ許可されるようになります。`EKSClusterARN` のデフォルトの `TAG_KEY` を使用している場合は、EKS クラスター ARN を `TAG_VALUE` として渡します。EKS クラスター ARN の形式は ` arn:aws:eks:AWS_REGION:AWS_ACCOUNT_ID:cluster/CLUSTER_NAME` になります。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ssm:DescribeInstanceInformation", "Resource": "*" }, { "Effect": "Allow", "Action": "ssm:DeregisterManagedInstance", "Resource": "arn:aws:ssm:us-east-1:123456789012:managed-instance/*", "Condition": { "StringEquals": { "ssm:resourceTag/TAG_KEY": "TAG_VALUE" } } } ] } ``` 1. 次のコマンドを使用してポリシーを作成します。 ``` aws iam create-policy \ --policy-name EKSHybridSSMPolicy \ --policy-document file://eks-hybrid-ssm-policy.json ``` 1. `eks-hybrid-ssm-trust.json` という名前のファイルを作成します。`AWS_REGION` を AWS SSM ハイブリッドアクティベーションの AWS リージョンに、`AWS_ACCOUNT_ID` をお使いの AWS アカウント ID に置き換えます。 ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"", "Effect":"Allow", "Principal":{ "Service":"ssm.amazonaws.com" }, "Action":"sts:AssumeRole", "Condition":{ "StringEquals":{ "aws:SourceAccount":"123456789012" }, "ArnEquals":{ "aws:SourceArn":"arn:aws:ssm:us-east-1:123456789012:*" } } } ] } ``` 1. 次のコマンドを使用してロールを作成します。 ``` aws iam create-role \ --role-name AmazonEKSHybridNodesRole \ --assume-role-policy-document file://eks-hybrid-ssm-trust.json ``` 1. 前のステップで作成した `EKSDescribeClusterPolicy` と `EKSHybridSSMPolicy` をアタッチします。`AWS_ACCOUNT_ID` を AWS アカウント ID に置き換えます。 ``` aws iam attach-role-policy \ --role-name AmazonEKSHybridNodesRole \ --policy-arn arn:aws:iam::AWS_ACCOUNT_ID:policy/EKSDescribeClusterPolicy ``` ``` aws iam attach-role-policy \ --role-name AmazonEKSHybridNodesRole \ --policy-arn arn:aws:iam::AWS_ACCOUNT_ID:policy/EKSHybridSSMPolicy ``` 1. `AmazonEC2ContainerRegistryPullOnly` と `AmazonSSMManagedInstanceCore` AWS マネージドポリシーをアタッチします。 ``` aws iam attach-role-policy \ --role-name AmazonEKSHybridNodesRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly ``` ``` aws iam attach-role-policy \ --role-name AmazonEKSHybridNodesRole \ --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore ``` **AWS IAM Roles Anywhere のステップ** AWS IAM Roles Anywhere を使用するには、ハイブリッドノードの IAM ロールを作成する前に、AWS IAM Roles Anywhere のトラストアンカーを設定する必要があります。手順については「[AWS IAM Roles Anywhere の設定](#hybrid-nodes-iam-roles-anywhere)」を参照してください。 1. `eks-hybrid-iamra-trust.json` という名前のファイルを作成します。`TRUST_ANCHOR ARN` を、[AWS IAM Roles Anywhere の設定](#hybrid-nodes-iam-roles-anywhere) のステップで作成したトラストアンカーの ARN に置き換えます。この信頼ポリシーの条件は、AWS IAM Roles Anywhere がハイブリッドノードの IAM ロールを引き受けて一時的な IAM 認証情報を交換する機能を、ロールセッション名がハイブリッドノードにインストールされている x509 証明書の CN と一致する場合のみに制限します。別の方法として、他の証明書属性を使用してノードを一意に識別することもできます。信頼ポリシーで使用する証明書属性は、`nodeadm` 設定で設定した `nodeName` に対応している必要があります。詳細については、「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "rolesanywhere.amazonaws.com" }, "Action": [ "sts:TagSession", "sts:SetSourceIdentity" ], "Condition": { "StringEquals": { "aws:PrincipalTag/x509Subject/CN": "${aws:PrincipalTag/x509Subject/CN}" }, "ArnEquals": { "aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/TA_ID" } } }, { "Effect": "Allow", "Principal": { "Service": "rolesanywhere.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}", "aws:PrincipalTag/x509Subject/CN": "${aws:PrincipalTag/x509Subject/CN}" }, "ArnEquals": { "aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/TA_ID" } } } ] } ``` 1. 次のコマンドを使用してロールを作成します。 ``` aws iam create-role \ --role-name AmazonEKSHybridNodesRole \ --assume-role-policy-document file://eks-hybrid-iamra-trust.json ``` 1. 前のステップで作成した `EKSDescribeClusterPolicy` をアタッチします。`AWS_ACCOUNT_ID` を AWS アカウント ID に置き換えます。 ``` aws iam attach-role-policy \ --role-name AmazonEKSHybridNodesRole \ --policy-arn arn:aws:iam::AWS_ACCOUNT_ID:policy/EKSDescribeClusterPolicy ``` 1. `AmazonEC2ContainerRegistryPullOnly` AWS マネージドポリシーをアタッチします。 ``` aws iam attach-role-policy \ --role-name AmazonEKSHybridNodesRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly ``` ### AWS マネジメントコンソール **EKS DescribeCluster ポリシーを作成する** 1. [Amazon IAM コンソール](https://console.aws.amazon.com/iam/home)を開きます。 1. 左のナビゲーションペインの [**ポリシー**] を選択します。 1. **[ポリシー]** ページで、**[ポリシーの作成]** を選択します。 1. [アクセス許可を指定] ページの [サービスの選択] パネルで、[EKS] を選択します。 1. **DescribeCluster** でアクションをフィルタリングし、**DescribeCluster** の Read アクションを選択します。 1. [**次へ**] を選択します。 1. **[確認と作成]** ページで以下を行います。 1. ポリシーの**ポリシー名**を、たとえば `EKSDescribeClusterPolicy` のように入力します。 1. [**Create policy**] (ポリシーの作成) を選択します。 **AWS SSM ハイブリッドアクティベーションのステップ** 1. [Amazon IAM コンソール](https://console.aws.amazon.com/iam/home)を開きます。 1. 左のナビゲーションペインの [**ポリシー**] を選択します。 1. **[ポリシー]** ページで、**[ポリシーの作成]** を選択します。 1. **[アクセス許可を指定]** ページの **[ポリシーエディタ]** の右上のナビゲーションで、**[JSON]** を選択します。以下のスニペットを貼り付けます。`AWS_REGION` を AWS SSM ハイブリッドアクティベーションの AWS リージョンに置き換え、`AWS_ACCOUNT_ID` をお使いの AWS アカウント ID に置き換えます。`TAG_KEY` と `TAG_VALUE` を、AWS SSM ハイブリッドアクティベーションの作成時に使用した AWS SSM リソースのタグキーに置き換えます。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ssm:DescribeInstanceInformation", "Resource": "*" }, { "Effect": "Allow", "Action": "ssm:DeregisterManagedInstance", "Resource": "arn:aws:ssm:us-east-1:123456789012:managed-instance/*", "Condition": { "StringEquals": { "ssm:resourceTag/TAG_KEY": "TAG_VALUE" } } } ] } ``` 1. [**次へ**] を選択します。 1. **[確認と作成]** ページで以下を行います。 1. ポリシーの**ポリシー**名を、たとえば `EKSHybridSSMPolicy` のように入力します。 1. **[ポリシーの作成]** を選択します。 1. 左のナビゲーションペインで、**[ロール]** を選択してください。 1. **[ロール]** ページで、**[ロールの作成]** を選択してください。 1. **[信頼されたエンティティを選択]** ページで、以下の操作を実行してください： 1. **[信頼されたエンティティのタイプ]** セクションで **[カスタム信頼ポリシー]** を選択します。以下をカスタム信頼ポリシーエディタに貼り付けます。`AWS_REGION` を AWS SSM ハイブリッドアクティベーションの AWS リージョンに、`AWS_ACCOUNT_ID` をお使いの AWS アカウント ID に置き換えます。 ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"", "Effect":"Allow", "Principal":{ "Service":"ssm.amazonaws.com" }, "Action":"sts:AssumeRole", "Condition":{ "StringEquals":{ "aws:SourceAccount":"123456789012" }, "ArnEquals":{ "aws:SourceArn":"arn:aws:ssm:us-east-1:123456789012:*" } } } ] } ``` 1. [次へ] を選択します。 1. **[アクセス許可を追加]** ページで、カスタムポリシーをアタッチするか、以下の操作を行います。 1. **[フィルターポリシー]** ボックスに、`EKSDescribeClusterPolicy` または上記で作成したポリシーの名前を入力します。検索結果でポリシー名の左にあるチェックボックスを選択します。 1. **[フィルターポリシー]** ボックスに、`EKSHybridSSMPolicy` または上記で作成したポリシーの名前を入力します。検索結果でポリシー名の左にあるチェックボックスを選択します。 1. **[フィルタポリシー]** ボックスに `AmazonEC2ContainerRegistryPullOnly` と入力します。検索結果の `AmazonEC2ContainerRegistryPullOnly` の左にあるチェックボックスを選択します。 1. **[フィルタポリシー]** ボックスに `AmazonSSMManagedInstanceCore` と入力します。検索結果の `AmazonSSMManagedInstanceCore` の左にあるチェックボックスを選択します。 1. [**次へ**] を選択します。 1. **[名前を付けて、レビューし、作成する]** ページで、以下の操作を実行します。 1. **[ロール名]** に、`AmazonEKSHybridNodesRole` などのロールの一意の名前を入力します。 1. **[Description]** (説明) では、現在のテキストを「`Amazon EKS - Hybrid Nodes role`」などの説明文に置き換えます。 1. [**ロールの作成**] を選択してください。 **AWS IAM Roles Anywhere のステップ** AWS IAM Roles Anywhere を使用するには、ハイブリッドノードの IAM ロールを作成する前に、AWS IAM Roles Anywhere のトラストアンカーを設定する必要があります。手順については「[AWS IAM Roles Anywhere の設定](#hybrid-nodes-iam-roles-anywhere)」を参照してください。 1. [Amazon IAM コンソール](https://console.aws.amazon.com/iam/home)を開きます。 1. 左のナビゲーションペインで、**[ロール]** を選択してください。 1. **[ロール]** ページで、**[ロールの作成]** を選択してください。 1. **[信頼されたエンティティを選択]** ページで、以下の操作を実行してください： 1. **[信頼されたエンティティのタイプ]** セクションで **[カスタム信頼ポリシー]** を選択します。以下をカスタム信頼ポリシーエディタに貼り付けます。`TRUST_ANCHOR ARN` を、[AWS IAM Roles Anywhere の設定](#hybrid-nodes-iam-roles-anywhere) のステップで作成したトラストアンカーの ARN に置き換えます。この信頼ポリシーの条件は、AWS IAM Roles Anywhere がハイブリッドノードの IAM ロールを引き受けて一時的な IAM 認証情報を交換する機能を、ロールセッション名がハイブリッドノードにインストールされている x509 証明書の CN と一致する場合のみに制限します。別の方法として、他の証明書属性を使用してノードを一意に識別することもできます。信頼ポリシーで使用する証明書属性は、nodeadm 設定で設定した nodeName に対応している必要があります。詳細については、「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "rolesanywhere.amazonaws.com" }, "Action": [ "sts:TagSession", "sts:SetSourceIdentity" ], "Condition": { "StringEquals": { "aws:PrincipalTag/x509Subject/CN": "${aws:PrincipalTag/x509Subject/CN}" }, "ArnEquals": { "aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/TA_ID" } } }, { "Effect": "Allow", "Principal": { "Service": "rolesanywhere.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}", "aws:PrincipalTag/x509Subject/CN": "${aws:PrincipalTag/x509Subject/CN}" }, "ArnEquals": { "aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/TA_ID" } } } ] } ``` 1. [次へ] を選択します。 1. **[アクセス許可を追加]** ページで、カスタムポリシーをアタッチするか、以下の操作を行います。 1. **[フィルターポリシー]** ボックスに、`EKSDescribeClusterPolicy` または上記で作成したポリシーの名前を入力します。検索結果でポリシー名の左にあるチェックボックスを選択します。 1. **[フィルタポリシー]** ボックスに `AmazonEC2ContainerRegistryPullOnly` と入力します。検索結果の `AmazonEC2ContainerRegistryPullOnly` の左にあるチェックボックスを選択します。 1. [**次へ**] を選択します。 1. **[名前を付けて、レビューし、作成する]** ページで、以下の操作を実行します。 1. **[ロール名]** に、`AmazonEKSHybridNodesRole` などのロールの一意の名前を入力します。 1. **[Description]** (説明) では、現在のテキストを「`Amazon EKS - Hybrid Nodes role`」などの説明文に置き換えます。 1. [**ロールの作成**] を選択してください。 # ハイブリッドノードを使用して Amazon EKS クラスターを作成する このトピックでは、使用可能なオプションの概要と、ハイブリッドノード対応の Amazon EKS クラスターの作成時に考慮すべき点を説明します。EKS Hybrid Nodes には、クラウドノードを使用する Amazon EKS クラスターと同じ [Kubernetes バージョンのサポート](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)があります (標準サポートや拡張サポートなど)。 EKS Hybrid Nodes を使用する予定がない場合は、「[Amazon EKS クラスターを作成します。](create-cluster.md)」にある Amazon EKS でのクラスター作成に関する基本ドキュメントを参照してください。 ## 前提条件 + [ハイブリッドノードの前提条件のセットアップ](hybrid-nodes-prereqs.md) が完了していること。ハイブリッドノード対応クラスターを作成する前に、オンプレミスノードとオプションでポッド CIDR を特定し、EKS の要件とハイブリッドノードの要件に従って VPC とサブネットを作成し、オンプレミスおよびオプションでポッド CIDR のインバウンドルールを持つセキュリティグループを指定する必要があります。前提条件の詳細については、[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md) を参照してください。 + AWS コマンドラインインターフェイス (AWS CLI) の最新バージョンがデバイスにインストールおよび設定されていること。現在のバージョンを確認するには「`aws --version`」を参照してください。yum、apt-get、macOS 用の Homebrew などのパッケージマネージャーは、多くの場合 AWS CLI の最新バージョンより数バージョン古くなっています。最新バージョンをインストールするには、「AWS コマンドラインインターフェイスユーザーガイド」の「[AWS CLI の最新バージョンのインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」および「[AWS CLI の設定の構成](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。 + IAM ロールを作成してポリシーをアタッチし、EKS クラスターを作成および記述するアクセス許可を持つ [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles#iam-term-principal)があること ## 考慮事項 + クラスターは、クラスター認証モードに `API` または `API_AND_CONFIG_MAP` を使用する必要があります。 + クラスターは IPv4 アドレスファミリーを使用する必要があります。 + クラスターは、パブリッククラスターエンドポイント接続またはプライベートクラスターエンドポイント接続を使用する必要があります。ハイブリッドノードが VPC 外で実行される場合、Amazon EKS Kubernetes API サーバーエンドポイントがパブリック IP に解決されるため、クラスターは「パブリックおよびプライベート」のクラスターエンドポイント接続を使用できません。 + OIDC 認証は、ハイブリッドノードが有効な EKS クラスターでサポートされています。 + 既存のクラスターのハイブリッドノード設定を追加、変更、削除できます。詳細については、「[既存の Amazon EKS クラスターでハイブリッドノードを有効にするか、設定を変更する](hybrid-nodes-cluster-update.md)」を参照してください。 ## ステップ 1: クラスター IAM ロールを作成する 既にクラスター IAM ロールがある場合や、`eksctl` または AWS CloudFormation を使用してクラスターを作成する場合は、このステップはスキップできます。デフォルトでは、`eksctl` および AWS CloudFormation テンプレートによってクラスター IAM ロールが作成されます。 1. IAM 信頼ポリシー用の JSON ファイルを作成するには次のコマンドを実行してください。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 1. Amazon EKS クラスターの IAM ロールを作成します。必要であれば、前のステップでファイルを書き込んだコンピュータ上のパスを eks-cluster-role-trust-policy.json の前につけます。このコマンドは前のステップで作成した信頼ポリシーをロールに関連付けます。IAM ロールを作成するにはロールを作成する [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles#iam-term-principal)に `iam:CreateRole` アクション (許可) を割り当てる必要があります。 ``` aws iam create-role \ --role-name myAmazonEKSClusterRole \ --assume-role-policy-document file://"eks-cluster-role-trust-policy.json" ``` 1. Amazon EKS 管理のポリシーを割り当てるか、独自のカスタムポリシーを作成できます。カスタムポリシーで使用する必要がある最小限の許可については、「[Amazon EKS ノードの IAM ロール](create-node-role.md)」を参照してください。このロールに、Amazon EKS 管理の IAM ポリシー (`AmazonEKSClusterPolicy`) をアタッチします。IAM ポリシーを [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles#iam-term-principal)にアタッチするには、ポリシーのアタッチを行っているプリンシパルに、次のいずれかの IAM アクション (許可) を割り当てる必要があります: `iam:AttachUserPolicy` または `iam:AttachRolePolicy`。 ``` aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy \ --role-name myAmazonEKSClusterRole ``` ## ステップ 2: ハイブリッドノード対応クラスターを作成する 以下を使用してクラスターを作成できます： + [eksctl](#hybrid-nodes-cluster-create-eksctl) + [AWS CloudFormation](#hybrid-nodes-cluster-create-cfn) + [AWS CLI](#hybrid-nodes-cluster-create-cli) + [AWS マネジメントコンソール](#hybrid-nodes-cluster-create-console) ### ハイブリッドノード対応クラスターの作成 - eksctl `eksctl` コマンドラインツールの最新バージョンをインストールする必要があります。`eksctl` をインストールまたはアップグレードするには`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。 1. `cluster-config.yaml` を作成して、ハイブリッドノード対応の Amazon EKS IPv4 クラスターを定義します。`cluster-config.yaml` で以下の置換を実行します。設定の完全なリストについては、「[eksctl documentation](https://eksctl.io/getting-started/)」を参照してください。 1. `CLUSTER_NAME` をクラスターの名前に置き換えます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前はクラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。 1. `AWS_REGION` を、クラスターを作成する AWS リージョンに置き換えます。 1. `K8S_VERSION` を [Amazon EKS がサポートする任意のバージョン](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)に置き換えます。 1. [ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md) のステップで設定した認証情報プロバイダーに基づいて、`CREDS_PROVIDER` を `ssm` または `ira` に置き換えます。 1. 認証情報プロバイダーが `ira` に設定されている場合 (AWS IAM Roles Anywhere を認証情報プロバイダーとして使用)、`CA_BUNDLE_CERT` を置き換えます。CA\$1BUNDLE\$1CERT は認証機関 (CA) 証明書本文であり、CA の選択によって異なります。証明書はプライバシー強化メール (PEM) 形式である必要があります。 1. `GATEWAY_ID` を、VPC にアタッチする仮想プライベートゲートウェイまたはトランジットゲートウェイの ID に置き換えます。 1. `REMOTE_NODE_CIDRS` を、ハイブリッドノードのオンプレミスノード CIDR に置き換えます。 1. `REMOTE_POD_CIDRS` をハイブリッドノードで実行されているワークロードのオンプレミスポッド CIDR に置き換えるか、ハイブリッドノードでウェブフックを実行していない場合は設定から行を削除します。CNI がネットワークアドレス変換 (NAT) を使用しない場合や、ポッドトラフィックがオンプレミスホストから出るときにポッド IP アドレスをマスクする場合は、`REMOTE_POD_CIDRS` を設定する必要があります。ハイブリッドノードでウェブフックを実行している場合は、`REMOTE_POD_CIDRS` を設定する必要があります。詳細については、「[ハイブリッドノード用のウェブフックを設定する](hybrid-nodes-webhooks.md)」を参照してください。 1. オンプレミスノードとポッド CIDR ブロックは、以下の要件を満たしている必要があります。 1. IPv4 RFC-1918 のいずれかの範囲内にある (`10.0.0.0/8`、`172.16.0.0/12`、または `192.168.0.0/16`) か、RFC 6598 で定義される CGNAT 範囲内にある (`100.64.0.0/10`) こと。 1. 相互に、クラスターの `VPC CIDR`、または Kubernetes サービスの IPv4 CIDR と重複しないこと ``` apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: CLUSTER_NAME region: AWS_REGION version: "K8S_VERSION" remoteNetworkConfig: iam: provider: CREDS_PROVIDER # default SSM, can also be set to IRA # caBundleCert: CA_BUNDLE_CERT vpcGatewayID: GATEWAY_ID remoteNodeNetworks: - cidrs: ["REMOTE_NODE_CIDRS"] remotePodNetworks: - cidrs: ["REMOTE_POD_CIDRS"] ``` 1. 次のコマンドを実行してください： ``` eksctl create cluster -f cluster-config.yaml ``` クラスターのプロビジョニングには数分かかります。クラスターの作成中は数行の出力が表示されます。出力の最後の行は次のサンプル行のようになります。 ``` [✓] EKS cluster "CLUSTER_NAME" in "REGION" region is ready ``` 1. 「[ステップ 3: kubeconfig を更新する](#hybrid-nodes-cluster-create-kubeconfig)」に進みます。 ### ハイブリッドノード対応クラスターの作成 - AWS CloudFormation CloudFormation スタックは、指定した `RemotePodNetwork` と `RemoteNodeNetwork` を使用して、EKS クラスター IAM ロールと EKS クラスターを作成します。CloudFormation テンプレートで公開されていない EKS クラスターの設定をカスタマイズする必要がある場合は、CloudFormation テンプレートを変更します。 1. CloudFormation テンプレートをダウンロードします。 ``` curl -OL 'https://raw.githubusercontent.com/aws/eks-hybrid/refs/heads/main/example/hybrid-eks-cfn.yaml' ``` 1. `cfn-eks-parameters.json` を作成し、各値の設定を指定します。 1. `CLUSTER_NAME`: 作成する EKS クラスターの名前。 1. `CLUSTER_ROLE_NAME`: 作成する EKS クラスター IAM ロールの名前。テンプレートのデフォルトは「EKSClusterRole」です。 1. `SUBNET1_ID`: 前提条件のステップで作成した最初のサブネットの ID 1. `SUBNET2_ID`: 前提条件のステップで作成した 2 番目のサブネットの ID 1. `SG_ID`: 前提条件のステップで作成したセキュリティグループの ID 1. `REMOTE_NODE_CIDRS`: ハイブリッドノードのオンプレミスノード CIDR 1. `REMOTE_POD_CIDRS`: ハイブリッドノードで実行されているワークロードのオンプレミスポッド CIDR CNI がネットワークアドレス変換 (NAT) を使用しない場合や、ポッドトラフィックがオンプレミスホストから出るときにポッド IP アドレスをマスクする場合は、`REMOTE_POD_CIDRS` を設定する必要があります。ハイブリッドノードでウェブフックを実行している場合は、`REMOTE_POD_CIDRS` を設定する必要があります。詳細については、「[ハイブリッドノード用のウェブフックを設定する](hybrid-nodes-webhooks.md)」を参照してください。 1. オンプレミスノードとポッド CIDR ブロックは、以下の要件を満たしている必要があります。 1. IPv4 RFC-1918 のいずれかの範囲内にある (`10.0.0.0/8`、`172.16.0.0/12`、または `192.168.0.0/16`) か、RFC 6598 で定義される CGNAT 範囲内にある (`100.64.0.0/10`) こと。 1. 相互に、クラスターの `VPC CIDR`、または Kubernetes サービスの IPv4 CIDR と重複しないこと。 1. `CLUSTER_AUTH`: クラスターのクラスター認証モード。有効な値は、`API` および `API_AND_CONFIG_MAP` です。テンプレートのデフォルトは `API_AND_CONFIG_MAP` です。 1. `CLUSTER_ENDPOINT`: クラスターのクラスターエンドポイント接続。有効な値は「Public」および「Private」です。テンプレートのデフォルトは Private です。つまり、Kubernetes API エンドポイントには VPC 内からしか接続できません。 1. `K8S_VERSION`: クラスターに使用する Kubernetes のバージョン。「[サポートされている Amazon EKS バージョン](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)」を参照してください。 ``` { "Parameters": { "ClusterName": "CLUSTER_NAME", "ClusterRoleName": "CLUSTER_ROLE_NAME", "SubnetId1": "SUBNET1_ID", "SubnetId2": "SUBNET2_ID", "SecurityGroupId" "SG_ID", "RemoteNodeCIDR": "REMOTE_NODE_CIDRS", "RemotePodCIDR": "REMOTE_POD_CIDRS", "ClusterAuthMode": "CLUSTER_AUTH", "ClusterEndpointConnectivity": "CLUSTER_ENDPOINT", "K8sVersion": "K8S_VERSION" } } ``` 1. CloudFormation スタックをデプロイします。`STACK_NAME` を CloudFormation スタックの名前に置き換え、`AWS_REGION` をクラスターを作成する AWS リージョンに置き換えます。 ``` aws cloudformation deploy \ --stack-name STACK_NAME \ --region AWS_REGION \ --template-file hybrid-eks-cfn.yaml \ --parameter-overrides file://cfn-eks-parameters.json \ --capabilities CAPABILITY_NAMED_IAM ``` クラスターのプロビジョニングには数分かかります。以下のコマンドを使用してスタックの状態を確認できます。`STACK_NAME` を CloudFormation スタックの名前に置き換え、`AWS_REGION` をクラスターを作成する AWS リージョンに置き換えます。 ``` aws cloudformation describe-stacks \ --stack-name STACK_NAME \ --region AWS_REGION \ --query 'Stacks[].StackStatus' ``` 1. 「[ステップ 3: kubeconfig を更新する](#hybrid-nodes-cluster-create-kubeconfig)」に進みます。 ### ハイブリッドノード対応クラスターの作成 - AWS CLI 1. 以下のコマンドを実行して、ハイブリッドノード対応の EKS クラスターを作成します。コマンドを実行する前に、以下を自分の設定に置き換えます。設定の完全なリストについては、[Amazon EKS クラスターを作成します。](create-cluster.md) のドキュメントを参照してください。 1. `CLUSTER_NAME`: 作成する EKS クラスターの名前。 1. `AWS_REGION`: クラスターを作成する AWS リージョン。 1. `K8S_VERSION`: クラスターに使用する Kubernetes のバージョン。「サポートされている Amazon EKS バージョン」を参照してください。 1. `ROLE_ARN`: クラスター用に設定した Amazon EKS クラスターロール。詳細については、「Amazon EKS クラスターの IAM ロール」を参照してください。 1. `SUBNET1_ID`: 前提条件のステップで作成した最初のサブネットの ID 1. `SUBNET2_ID`: 前提条件のステップで作成した 2 番目のサブネットの ID 1. `SG_ID`: 前提条件のステップで作成したセキュリティグループの ID 1. クラスターアクセス認証モードには `API`と `API_AND_CONFIG_MAP` を使用できます。以下のコマンドでは、クラスターアクセス認証モードは `API_AND_CONFIG_MAP` に設定されています。 1. `endpointPrivateAccess` パラメータ と `endpointPublicAccess` パラメータを使用して、クラスターの Kubernetes API サーバーエンドポイントへのパブリックとプライベートアクセスを有効または無効にすることができます。以下のコマンドでは、`endpointPublicAccess` は false に設定され、`endpointPrivateAccess` は true に設定されています。 1. `REMOTE_NODE_CIDRS`: ハイブリッドノードのオンプレミスノード CIDR。 1. `REMOTE_POD_CIDRS` (オプション): ハイブリッドノードで実行されているワークロードのオンプレミスポッド CIDR 1. オンプレミスノードとポッド CIDR ブロックは、以下の要件を満たしている必要があります。 1. IPv4 RFC-1918 のいずれかの範囲内にある (`10.0.0.0/8`、`172.16.0.0/12`、または `192.168.0.0/16`) か、RFC 6598 で定義される CGNAT 範囲内にある (`100.64.0.0/10`) こと。 1. 相互に、Amazon EKS クラスターの `VPC CIDR`、または Kubernetes サービスの IPv4 CIDR と重複しないこと。 ``` aws eks create-cluster \ --name CLUSTER_NAME \ --region AWS_REGION \ --kubernetes-version K8S_VERSION \ --role-arn ROLE_ARN \ --resources-vpc-config subnetIds=SUBNET1_ID,SUBNET2_ID,securityGroupIds=SG_ID,endpointPrivateAccess=true,endpointPublicAccess=false \ --access-config authenticationMode=API_AND_CONFIG_MAP \ --remote-network-config '{"remoteNodeNetworks":[{"cidrs":["REMOTE_NODE_CIDRS"]}],"remotePodNetworks":[{"cidrs":["REMOTE_POD_CIDRS"]}]}' ``` 1. クラスターがプロビジョニングされるまでに数分かかります。クラスターのステータスのクエリを実行するには次のコマンドを使用します。`CLUSTER_NAME` を、作成しているクラスターの名前に置き換え、`AWS_REGION` を、クラスターを作成している AWS リージョンに置き換えます。出力が「`ACTIVE`」を返すまで、次のステップに進まないでください。 ``` aws eks describe-cluster \ --name CLUSTER_NAME \ --region AWS_REGION \ --query "cluster.status" ``` 1. 「[ステップ 3: kubeconfig を更新する](#hybrid-nodes-cluster-create-kubeconfig)」に進みます。 ### ハイブリッドノード対応クラスターの作成 - AWS マネジメントコンソール 1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)で Amazon EKS コンソールを開きます。 1. [クラスターを追加]、[作成] の順にクリックします。 1. [クラスターの設定] ページで、次のフィールドに入力します。 1. **[名前]** - クラスターの名前。この名前には英数字 (大文字と小文字が区別されます)、ハイフン、下線のみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前はクラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。 1. **[クラスター IAM ロール]** – ユーザーに代わって AWS リソースを管理することを Kubernetes コントロールプレーンに許可するために作成した Amazon EKS クラスター IAM ロールを選択します。 1. **[Kubernetes バージョン]** – クラスターで使用する Kubernetes のバージョン。以前のバージョンが必要でない限り、最新バージョンを選択することをお勧めします。 1. **[アップグレードポリシー]** — 拡張または標準を選択します。 1. **拡張:** このオプションは、リリース日から 26 か月間 Kubernetes バージョンをサポートします。延長サポート期間には、標準サポート期間終了後に開始される追加の時間単位のコストがかかります。延長サポートが終了すると、クラスターは次のバージョンに自動的にアップグレードされます。 1. **標準:** このオプションは、リリース日から 14 か月間 Kubernetes バージョンをサポートします。追加コストはかかりません。標準サポートが終了すると、クラスターは次のバージョンに自動的にアップグレードされます。 1. **クラスターアクセス** - クラスター管理者アクセスを許可または禁止し、認証モードを選択します。ハイブリッドノードが有効なクラスターでは、以下の認証モードがサポートされます。 1. **EKS API**: クラスターは、認証された IAM プリンシパルを EKS アクセスエントリ API からのみ取得します。 1. **EKS API と ConfigMap**: クラスターは、EKS アクセスエントリ API と `aws-auth` ConfigMap の両方から認証された IAM プリンシパルを取得します。 1. **[Secret encryption]** (シークレット暗号化) – (オプション) KMS キーを使用して Kubernetes シークレットのシークレット暗号化を有効にするよう選択します。クラスターを作成した後で、これを有効にすることもできます。この機能を有効にする前に、[既存のクラスターで KMS を使用して Kubernetes シークレットを暗号化する](enable-kms.md) の情報をよく理解していることを確認してください。 1. **ARC ゾーンシフト** - 有効にすると、EKS はクラスターを ARC ゾーンシフトに登録し、ゾーンシフトを使用してアプリケーショントラフィックを AZ から遠ざけることができるようになります。 1. **[タグ]** - (オプション) クラスターに任意のタグを追加します。詳細については、「[タグを使用して Amazon EKS リソースを整理する](eks-using-tags.md)」を参照してください。 1. このページを読み終えたら、**[次へ]** を選択してください。 1. **[ネットワーキングの指定]** ページで、次のフィールドの値を選択してください： 1. **VPC** – [VPC とサブネットの Amazon EKS ネットワーキング要件を表示する](network-reqs.md) および [Amazon EKS Hybrid Nodes](hybrid-nodes-prereqs.md) の要件を満たす既存の VPC を選択します。VPC を選択する前に、「VPC、サブネット、ハイブリッドノードの Amazon EKS ネットワーキング要件を表示する」の要件と考慮事項をすべて理解しておくことをお勧めします。クラスターの作成後は使用する VPC を変更できません。VPC が表示されていない場合はまず作成する必要があります。詳細については、「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」および「[Amazon EKS Hybrid Nodes のネットワーク要件](hybrid-nodes-prereqs.md)」を参照してください。 1. **[サブネット]** - デフォルトで、前のフィールドで指定した VPC 内の利用可能なすべてのサブネットがあらかじめ選択されています。少なくとも 2 つ選択する必要があります。 1. **[セキュリティグループ]** - (オプション Amazon EKS が作成するネットワークインターフェイスに関連付ける 1 つまたは複数のセキュリティグループを指定します。指定するセキュリティグループの少なくとも 1 つには、オンプレミスのノードとオプションで ポッド CIDR に対するインバウンドルールが必要です。詳細については、「[Amazon EKS Hybrid Nodes のネットワーク要件](hybrid-nodes-networking.md)」を参照してください。セキュリティグループを選択するかどうかにかかわらず、Amazon EKS はクラスターと VPC 間の通信を可能にするセキュリティグループを作成します。Amazon EKS はこのセキュリティグループおよびユーザーが選択したセキュリティグループを、作成するネットワークインターフェイスに関連付けます。Amazon EKS が作成するクラスターセキュリティグループの詳細については、「[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)」を参照してください。Amazon EKS が作成するクラスターセキュリティグループのルールは変更できます。 1. **クラスター IP アドレスファミリーの選択** — ハイブリッドノード対応クラスターには IPv4 を選択する必要があります。 1. (オプション) **[Kubernetes サービス IP アドレスの範囲を設定する]** を選択し、**[サービスの IPv4 範囲]** を指定します。 1. **[リモートネットワークを設定してハイブリッドノードを有効にする]** を選択し、ハイブリッドノードのオンプレミスノードとポッド CIDR を指定します。 1. ポッドトラフィックがオンプレミスホストを離れる際、CNI がポッド IP アドレスに対してネットワークアドレス変換 (NAT) またはマスカレードを使用しない場合は、リモートポッド CIDR を設定する必要があります。ハイブリッドノードでウェブフックを実行している場合は、リモートポッド CIDR を設定する必要があります。 1. オンプレミスノードとポッド CIDR ブロックは、以下の要件を満たしている必要があります。 1. IPv4 RFC-1918 のいずれかの範囲内にある (`10.0.0.0/8`、`172.16.0.0/12`、または `192.168.0.0/16`) か、RFC 6598 で定義される CGNAT 範囲内にある (`100.64.0.0/10`) こと。 1. 相互に、クラスターの `VPC CIDR`、または Kubernetes サービスの IPv4 CIDR と重複しないこと 1. **[クラスターエンドポイントのアクセス]** で、オプションを選択してください。クラスターを作成した後で、このオプションを変更できます。ハイブリッドノードが有効なクラスターの場合は、パブリックまたはプライベートのいずれかを選択する必要があります。デフォルト以外のオプションを選択する前に、オプションとその意味を理解しておいてください。詳細については「[クラスター API サーバーエンドポイント](cluster-endpoint.md)」を参照してください。 1. このページを読み終えたら、**[次へ]** を選択してください。 1. (オプション) **[オブザーバビリティの設定]** ページで、有効にする [メトリクス] と [コントロールプレーンのロギング] オプションを選択します。デフォルトではそれぞれのログタイプは無効化されています。 1. Prometheus メトリクスの詳細については、「[Prometheus を使用してクラスターのメトリクスをモニタリングする](prometheus.md)」を参照してください。 1. EKS コントロールのログ記録のオプションの詳細については、「[コントロールプレーンログを CloudWatch Logs に送信する](control-plane-logs.md)」を参照してください。 1. このページを読み終えたら、**[次へ]** を選択してください。 1. **[アドオンの選択]** ページで、クラスターに追加するアドオンを選択してください。 1. **[Amazon EKS アドオン]** と **[AWS マーケットプレイス アドオン]** は必要な数だけ選択できます。ハイブリッドノードと互換性のない Amazon EKS アドオンは「ハイブリッドノードと互換性がない」とマークされ、これらのアドオンには、ハイブリッドノードで実行されないようにするためのアンチアフィニティルールが設定されます。詳細については、「ハイブリッドノードのアドオンの設定」を参照してください。インストールする **[AWS Marketplace アドオン]** が一覧にない場合は、検索ボックスにテキストを入力して、利用可能な **[AWS Marketplace アドオン]** を検索できます。**[カテゴリ]**、**[ベンダー]**、または **[価格モデル]** で検索し、検索結果からアドオンを選択することもできます。 1. CoreDNS や kube-proxy などの一部のアドオンは、デフォルトでインストールされます。デフォルトのアドオンのいずれかを無効にすると、Kubernetes アプリケーションを実行する機能に影響する場合があります。 1. このページを読み終えたら、[`Next`] を選択してください。 1. **[選択したアドオン設定の構成]** ページで、インストールするバージョンを選択し、[次へ] を選択してください。 1. クラスターを作成した後はいつでも新しいバージョンに更新できます。クラスターの作成後に、各アドオンの設定を更新できます。アドオンの設定の詳細については「[Amazon EKS アドオンを更新する](updating-an-add-on.md)」を参照してください。ハイブリッドノードと互換性のあるアドオンのバージョンについては、「[ハイブリッドノードのアドオンを構成する](hybrid-nodes-add-ons.md)」を参照してください。 1. このページを読み終えたら、[次へ] を選択してください。 1. **[確認と作成]** ページで、前のページで入力または選択した情報を確認します。変更する必要がある場合は**[編集]** を選択してください。そのままでよければ、**[作成]** を選択してください。クラスターがプロビジョニングされている間、**[ステータス]** フィールドに **[作成中]** と表示されます。クラスターのプロビジョニングには数分かかります。 1. 「[ステップ 3: kubeconfig を更新する](#hybrid-nodes-cluster-create-kubeconfig)」に進みます。 ## ステップ 3: kubeconfig を更新する `eksctl` を使用してクラスターを作成した場合、このステップはスキップできます。`eksctl` によってこのステップは既に完了しているからです。新しいコンテキストを `kubectl` 設定ファイルに追加して、`kubectl` がクラスターと通信できるようにします。ファイルを作成および更新する方法の詳細については「[kubeconfig ファイルを作成して kubectl を EKS クラスターに接続する](create-kubeconfig.md)」を参照してください。 ``` aws eks update-kubeconfig --name CLUSTER_NAME --region AWS_REGION ``` 出力例は次のとおりです。 ``` Added new context arn:aws:eks:AWS_REGION:111122223333:cluster/CLUSTER_NAME to /home/username/.kube/config ``` 次のコマンドを実行して、クラスターとの通信を確認します。 ``` kubectl get svc ``` 出力例は次のとおりです。 ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.100.0.1 443/TCP 28h ``` ## ステップ 4: クラスターのセットアップ 次のステップとして、ハイブリッドノードをクラスターに参加させるためにアクセスを有効にする手順は、「[ハイブリッドノードのクラスターアクセスを準備する](hybrid-nodes-cluster-prep.md)」を参照してください。 # 既存の Amazon EKS クラスターでハイブリッドノードを有効にするか、設定を変更する このトピックでは、使用可能なオプションの概要と、Amazon EKS クラスターのハイブリッドノード設定を追加、変更、削除する際の考慮事項について説明します。 Amazon EKS クラスターでハイブリッドノードを使用できるようにするには、オンプレミスノードとポッドネットワーク (オプション) の IP アドレス CIDR 範囲を `RemoteNetworkConfig` 設定に追加します。EKS では、この CIDR リストを使用して、クラスターとオンプレミスネットワーク間の接続を有効にします。クラスター設定を更新する際のオプションについては、「*Amazon EKS API リファレンス*」の「[UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html)」でリスト全体を確認できます。 クラスター内にある EKS Hybrid Nodes のネットワーク設定では、次のいずれかのアクションを実行できます。 + [リモートネットワーク設定を追加して、既存のクラスターで EKS Hybrid Nodes を有効にする。](#hybrid-nodes-cluster-enable-existing) + [既存のクラスター内のリモートノードネットワークまたはリモートポッドネットワークを追加、変更、削除する。](#hybrid-nodes-cluster-update-config) + [すべてのリモートノードネットワーク CIDR 範囲を削除して、既存のクラスターの EKS Hybrid Nodes を無効にする。](#hybrid-nodes-cluster-disable) ## 前提条件 + ハイブリッドノードの Amazon EKS クラスターを有効にする前に、環境が次の要件を満たしていることを確認してください: 「[ハイブリッドノードの前提条件のセットアップ](hybrid-nodes-prereqs.md)」で概説されている要件に加え、「[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md)」、「[ハイブリッドノード用のオペレーティングシステムを準備する](hybrid-nodes-os.md)」、「[ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md)」で詳述されている要件 + クラスターは IPv4 アドレスファミリーを使用する必要があります。 + クラスターは、クラスター認証モードに `API` または `API_AND_CONFIG_MAP` を使用する必要があります。クラスター認証モードを変更するプロセスについては、「[アクセスエントリを使用するように認証モードを変更する](setting-up-access-entries.md)」を参照してください。 + Amazon EKS Kubernetes API サーバーエンドポイントには、パブリックまたはプライベートいずれか (両方ではなく) のエンドポイントアクセスを使用することが推奨されます。「Public and Private (パブリックとプライベート)」を選択した場合、Amazon EKS Kubernetes API サーバーエンドポイントは、常に VPC の外部で稼働しているハイブリッドノードのパブリック IP に解決されるため、ハイブリッドノードがクラスターに参加できなくなる可能性があります。クラスターへのネットワークアクセスを変更するプロセスについては、「[クラスター API サーバーエンドポイント](cluster-endpoint.md)」を参照してください。 + AWS コマンドラインインターフェイス (AWS CLI) の最新バージョンがデバイスにインストールおよび設定されていること。現在のバージョンを確認するには「`aws --version`」を参照してください。yum、apt-get、macOS 用の Homebrew などのパッケージマネージャーは、多くの場合 AWS CLI の最新バージョンより数バージョン古くなっています。最新バージョンをインストールするには、「AWS Command Line Interface ユーザーガイド」の「[AWS CLI の最新バージョンのインストールまたは更新](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」および「[AWS CLI の設定を構成する](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。 + Amazon EKS クラスターで [UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html) を呼び出す権限を持つ [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles#iam-term-principal)。 + ハイブリッドノードと互換性のあるバージョンにアドオンを更新します。ハイブリッドノードと互換性のあるアドオンのバージョンについては、「[ハイブリッドノードのアドオンを構成する](hybrid-nodes-add-ons.md)」を参照してください。 + ハイブリッドノードと互換性のないアドオンを実行している場合は、ハイブリッドノードへのデプロイを防ぐために、アドオンの [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) または [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) に、次のアフィニティルールが設定されていることを確認します。次のアフィニティルールが存在しない場合は追加してください。 ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` ## 考慮事項 `remoteNetworkConfig` JSON オブジェクトは、更新中に次のように動作します。 + 指定していない既存の設定部分は変更されません。`remoteNodeNetworks` または `remotePodNetworks` のいずれかを指定していない場合、該当箇所への変更は行われません。 + `remoteNodeNetworks` または `remotePodNetworks` の CIDR リストを変更する場合は、最終設定に必要な CIDR の完全なリストを指定しなければなりません。`remoteNodeNetworks` または `remotePodNetworks` の CIDR リストのいずれかに変更を指定すると、更新中に元のリストが置き換えられます。 + オンプレミスノードとポッド CIDR ブロックは、以下の要件を満たしている必要があります。 1. IPv4 RFC-1918 のいずれかの範囲内にある (10.0.0.0/8、172.16.0.0/12、または 192.168.0.0/16) か、RFC 6598 で定義される CGNAT 範囲内にある (`100.64.0.0/10`) こと。 1. Amazon EKS クラスターの VPC の全 CIDR、または Kubernetes サービスの IPv4 CIDR と相互に重複していないこと。 ## 既存のクラスターでハイブリッドノードを有効にする 既存のクラスターで EKS Hybrid Nodes を有効にするには、以下を使用します。 + [AWS CloudFormation](#hybrid-nodes-cluster-enable-cfn) + [AWS CLI](#hybrid-nodes-cluster-enable-cli) + [AWS マネジメントコンソール](#hybrid-nodes-cluster-enable-console) ### 既存のクラスターで EKS Hybrid Nodes を有効にする - AWS CloudFormation 1. クラスターで EKS Hybrid Nodes を有効にするには、`RemoteNodeNetwork` と `RemotePodNetwork` (オプション) を CloudFormation テンプレートに追加して、スタックを更新します。`RemoteNodeNetwork` は最大 1 つの `Cidrs` 項目が含まれるリストであり、`Cidrs` は複数の IP CIDR 範囲が含まれるリストであることに注意してください。 ``` RemoteNetworkConfig: RemoteNodeNetworks: - Cidrs: [RemoteNodeCIDR] RemotePodNetworks: - Cidrs: [RemotePodCIDR] ``` 1. 「[ハイブリッドノードのクラスターアクセスを準備する](hybrid-nodes-cluster-prep.md)」に進みます。 ### 既存のクラスターで EKS Hybrid Nodes を有効にする - AWS CLI 1. EKS クラスターの EKS Hybrid Nodes に使用する `RemoteNetworkConfig` を有効にするには、以下のコマンドを実行します。コマンドを実行する前に、以下を自分の設定に置き換えます。全設定のリストについては、「*Amazon EKS API リファレンス*」の「[UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html)」を参照してください。 1. `CLUSTER_NAME`: 更新する EKS クラスターの名前。 1. `AWS_REGION`: EKS クラスターが実行されている AWS リージョン。 1. `REMOTE_NODE_CIDRS`: ハイブリッドノードのオンプレミスノード CIDR。 1. `REMOTE_POD_CIDRS` (オプション): ハイブリッドノードで実行されているワークロードのオンプレミスポッド CIDR ``` aws eks update-cluster-config \ --name CLUSTER_NAME \ --region AWS_REGION \ --remote-network-config '{"remoteNodeNetworks":[{"cidrs":["REMOTE_NODE_CIDRS"]}],"remotePodNetworks":[{"cidrs":["REMOTE_POD_CIDRS"]}]}' ``` 1. クラスターの更新には数分かかります。クラスターのステータスのクエリを実行するには次のコマンドを使用します。`CLUSTER_NAME` は変更するクラスターの名前に、`AWS_REGION` はクラスターが稼働している AWS リージョンに置き換えてください。出力が「`ACTIVE`」を返すまで、次のステップに進まないでください。 ``` aws eks describe-cluster \ --name CLUSTER_NAME \ --region AWS_REGION \ --query "cluster.status" ``` 1. 「[ハイブリッドノードのクラスターアクセスを準備する](hybrid-nodes-cluster-prep.md)」に進みます。 ### 既存のクラスターで EKS Hybrid Nodes を有効にする - AWS マネジメントコンソール 1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)で Amazon EKS コンソールを開きます。 1. クラスター名を選択すると、そのクラスターの情報を表示されます。 1. **[ネットワーキング]** タブを開き、**[管理]** 選択します。 1. ドロップダウンで、**[リモートネットワーク]** を選択します。 1. **[リモートネットワークを設定してハイブリッドノードを有効にする]** を選択し、ハイブリッドノードのオンプレミスノードとポッド CIDR を指定します。 1. [**変更を保存**] を選択して終了します。クラスターのステータスが **[アクティブ]** に戻るまで待ちます。 1. 「[ハイブリッドノードのクラスターアクセスを準備する](hybrid-nodes-cluster-prep.md)」に進みます。 ## 既存のクラスターでハイブリッドノード設定を更新する 既存のハイブリッドクラスターで `remoteNetworkConfig` を変更するには、以下のいずれかを使用します。 + [AWS CloudFormation](#hybrid-nodes-cluster-update-cfn) + [AWS CLI](#hybrid-nodes-cluster-update-cli) + [AWS マネジメントコンソール](#hybrid-nodes-cluster-update-console) ### 既存のクラスターでハイブリッド設定を更新する - AWS CloudFormation 1. CloudFormation テンプレートを新しいネットワーク CIDR 値で更新します。 ``` RemoteNetworkConfig: RemoteNodeNetworks: - Cidrs: [NEW_REMOTE_NODE_CIDRS] RemotePodNetworks: - Cidrs: [NEW_REMOTE_POD_CIDRS] ``` **注記** `RemoteNodeNetworks` または `RemotePodNetworks` の CIDR リストを更新するときは、すべての CIDR (新規と既存) を含めます。更新中には、リスト全体が置き換えられます。更新リクエストでこれらのフィールドを省略すると、既存の設定が保持されます。 1. 変更したテンプレートで CloudFormation スタックを更新し、スタックの更新が完了するまで待ちます。 ### 既存のクラスターでハイブリッド設定を更新する - AWS CLI 1. リモートネットワークの CIDR を変更するには、次のコマンドを実行します。値をご自身の設定に置き換えます。 ``` aws eks update-cluster-config --name CLUSTER_NAME --region AWS_REGION --remote-network-config '{"remoteNodeNetworks":[{"cidrs":["NEW_REMOTE_NODE_CIDRS"]}],"remotePodNetworks":[{"cidrs":["NEW_REMOTE_POD_CIDRS"]}]}' ``` **注記** `remoteNodeNetworks` または `remotePodNetworks` の CIDR リストを更新するときは、すべての CIDR (新規と既存) を含めます。更新中には、リスト全体が置き換えられます。更新リクエストでこれらのフィールドを省略すると、既存の設定が保持されます。 1. クラスターのステータスが [アクティブ] に戻るまで待ち、次に進みます。 ### 既存のクラスターでハイブリッド設定を更新する - AWS マネジメントコンソール 1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)で Amazon EKS コンソールを開きます。 1. クラスター名を選択すると、そのクラスターの情報を表示されます。 1. **[ネットワーキング]** タブを開き、**[管理]** 選択します。 1. ドロップダウンで、**[リモートネットワーク]** を選択します。 1. 必要に応じて、`Remote node networks` と `Remote pod networks - Optional` の CIDR を更新します。 1. **[変更の保存]** を選択し、クラスターのステータスが **[アクティブ]** に戻るのを待ちます。 ## 既存のクラスターで Hybrid Nodes を無効にする 既存のクラスターで EKS Hybrid Nodes を無効にするには、以下を使用します。 + [AWS CloudFormation](#hybrid-nodes-cluster-disable-cfn) + [AWS CLI](#hybrid-nodes-cluster-disable-cli) + [AWS マネジメントコンソール](#hybrid-nodes-cluster-disable-console) ### 既存のクラスターで EKS Hybrid Nodes を無効にする - AWS CloudFormation 1. クラスターで EKS Hybrid Nodes を無効にするには、`RemoteNodeNetworks` と `RemotePodNetworks` を CloudFormation テンプレートの空の配列に設定して、スタックを更新します。 ``` RemoteNetworkConfig: RemoteNodeNetworks: [] RemotePodNetworks: [] ``` ### 既存のクラスターで EKS Hybrid Nodes を無効にする - AWS CLI 1. クラスターから `RemoteNetworkConfig` を削除するには、以下のコマンドを実行します。コマンドを実行する前に、以下を自分の設定に置き換えます。全設定のリストについては、「*Amazon EKS API リファレンス*」の「[UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html)」を参照してください。 1. `CLUSTER_NAME`: 更新する EKS クラスターの名前。 1. `AWS_REGION`: EKS クラスターが実行されている AWS リージョン。 ``` aws eks update-cluster-config \ --name CLUSTER_NAME \ --region AWS_REGION \ --remote-network-config '{"remoteNodeNetworks":[],"remotePodNetworks":[]}' ``` 1. クラスターの更新には数分かかります。クラスターのステータスのクエリを実行するには次のコマンドを使用します。`CLUSTER_NAME` は変更するクラスターの名前に、`AWS_REGION` はクラスターが稼働している AWS リージョンに置き換えてください。出力が「`ACTIVE`」を返すまで、次のステップに進まないでください。 ``` aws eks describe-cluster \ --name CLUSTER_NAME \ --region AWS_REGION \ --query "cluster.status" ``` ### 既存のクラスターで EKS Hybrid Nodes を無効にする - AWS マネジメントコンソール 1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)で Amazon EKS コンソールを開きます。 1. クラスター名を選択すると、そのクラスターの情報を表示されます。 1. **[ネットワーキング]** タブを開き、**[管理]** 選択します。 1. ドロップダウンで、**[リモートネットワーク]** を選択します。 1. **[リモートネットワークを設定してハイブリッドノードを有効にする]** を選択して、`Remote node networks` と `Remote pod networks - Optional` のすべての CIDR を削除します。 1. [**変更を保存**] を選択して終了します。クラスターのステータスが **[アクティブ]** に戻るまで待ちます。 # ハイブリッドノードのクラスターアクセスを準備する ハイブリッドノードを Amazon EKS クラスターに接続するには、クラスターに参加するために Kubernetes のアクセス許可を持つハイブリッドノードの IAM ロールを有効にする必要があります。ハイブリッドノードの IAM ロールの作成方法については、「[ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md)」を参照してください。Amazon EKS は、IAM プリンシパルを Kubernetes ロールベースアクセスコントロール (RBAC) に関連付ける方法として、Amazon EKS アクセスエントリと `aws-auth` ConfigMap の 2 つをサポートしています。Amazon EKS アクセス管理の詳細については、「[IAM ユーザーおよびロールに Kubernetes API へのアクセスを付与する](grant-k8s-access.md)」を参照してください。 以下の手順を使用して、ハイブリッドノードの IAM ロールを Kubernetes のアクセス許可に関連付けます。Amazon EKS のアクセスエントリを使用するには、クラスターが `API` または `API_AND_CONFIG_MAP` 認証モードで作成されている必要があります。`aws-auth` ConfigMap を使用するには、クラスターが `API_AND_CONFIG_MAP` 認証モードで作成されている必要があります。`CONFIG_MAP` のみの認証モードは、ハイブリッドノードが有効な Amazon EKS クラスターではサポートされていません。 ## ハイブリッドノードの IAM ロールに Amazon EKS のアクセスエントリを使用する IAM ロールと組み合わせて使用できる、HYBRID\$1LINUX というハイブリッドノード用 Amazon EKS アクセスエントリタイプがあります。このアクセスエントリタイプでは、ユーザー名は自動的に system:node:\$1\$1SessionName\$1\$1 に設定されます。アクセスエントリの作成の詳細については、「[アクセスエントリを作成する](creating-access-entries.md)」を参照してください。 ### AWS CLI 1. デバイスに最新バージョンの AWS CLI をインストールし、設定しておく必要があります。現在のバージョンを確認するには「`aws --version`」を参照してください。yum、apt-get、macOS 用の Homebrew などのパッケージマネージャーは、多くの場合 AWS CLI の最新バージョンより数バージョン古くなっています。最新バージョンをインストールするには、「AWS コマンドラインインターフェイスユーザーガイド」の「インストール」および「aws configure を使用したクイック設定」を参照してください。 1. 以下のコマンドを使用してアクセスエントリーを作成します。CLUSTER\$1NAME をお使いのクラスターの名前に、HYBRID\$1NODES\$1ROLE\$1ARN を [ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md) のステップで作成したロールの ARN に置き換えます。 ``` aws eks create-access-entry --cluster-name CLUSTER_NAME \ --principal-arn HYBRID_NODES_ROLE_ARN \ --type HYBRID_LINUX ``` ### AWS マネジメントコンソール 1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)で Amazon EKS コンソールを開きます。 1. ハイブリッドノードが有効なクラスターの名前を選択します。 1. **[リモートアクセス]** タブを選択してください。 1. **[アクセスエントリの作成]** を選択してください。 1. **[IAM プリンシパル]** には、「[ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md)」のステップで作成したハイブリッドノードの IAM ロールを選択します。 1. **[タイプ]** には **Hybrid Linux** を選択します。 1. (オプション) **[タグ]** ではアクセスエントリにラベルを割り当てます。例えば、同じタグを持つすべてのリソースを検索しやすくするためです。 1. **[レビューと作成にスキップ]** を選択します。Hybrid Linux のアクセスエントリにポリシーを追加することや、アクセス範囲を変更することはできません。 1. アクセスエントリの設定を確認してください。何かが正しくないと思われる場合は**[戻る]** を選択してステップに戻り、エラーを修正します。設定が正しければ、**[作成]** を選択してください。 ## ハイブリッドノードの IAM ロールに aws-auth ConfigMap を使用する 以下のステップでは、[ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md) のステップで作成したハイブリッドノード IAM ロールの ARN を使用して、`aws-auth` ConfigMap を作成または更新します。 1. クラスターに既存の `aws-auth` ConfigMap があるかどうかを確認します。特定の `kubeconfig` ファイルを使用している場合は、`--kubeconfig` フラグを使用してください。 ``` kubectl describe configmap -n kube-system aws-auth ``` 1. `aws-auth` ConfigMap が表示されている場合は、必要に応じて更新してください。 1. ConfigMap を編集用に開きます。 ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. 必要に応じて新しい `mapRoles` エントリを追加します。`HYBRID_NODES_ROLE_ARN` をハイブリッドノード IAM ロールの ARN に置き換えます。なお、`{{SessionName}}` は ConfigMap に保存するための正しいテンプレート形式です。他の値には置き換えないでください。 ``` data: mapRoles: | - groups: - system:bootstrappers - system:nodes rolearn: HYBRID_NODES_ROLE_ARN username: system:node:{{SessionName}} ``` 1. ファイルを保存し、テキストエディタを終了します。 1. クラスターに既存の `aws-auth` ConfigMap がない場合は、以下のコマンドを使用して作成します。`HYBRID_NODES_ROLE_ARN` をハイブリッドノード IAM ロールの ARN に置き換えます。なお、`{{SessionName}}` は ConfigMap に保存するための正しいテンプレート形式です。他の値には置き換えないでください。 ``` kubectl apply -f=/dev/stdin <<-EOF apiVersion: v1 kind: ConfigMap metadata: name: aws-auth namespace: kube-system data: mapRoles: | - groups: - system:bootstrappers - system:nodes rolearn: HYBRID_NODES_ROLE_ARN username: system:node:{{SessionName}} EOF ``` # ハイブリッドノードでオンプレミスのワークロードを実行する ハイブリッドノードが有効になっている EKS クラスターではAWS クラウドで使用するのと同じ Amazon EKS クラスター、機能、ツールを使用して、独自のインフラストラクチャでオンプレミスおよびエッジアプリケーションを実行できます。 以下のセクションではハイブリッドノードを使用するためのステップバイステップの手順について説明します。 **Topics** + [ハイブリッドノードを接続する](hybrid-nodes-join.md) + [Bottlerocket を実行しているハイブリッドノードの接続](hybrid-nodes-bottlerocket.md) + [ハイブリッドノードをアップグレードする](hybrid-nodes-upgrade.md) + [ハイブリッドノードへのパッチの適用](hybrid-nodes-security.md) + [ハイブリッドノードを削除する](hybrid-nodes-remove.md) # ハイブリッドノードを接続する **注記** 次の手順は、互換性のあるオペレーティングシステム (Bottlerocket を除く) を実行しているハイブリッドノードに適用されます。Bottlerocket を実行するハイブリッドノードを接続する手順については、「[Bottlerocket を実行しているハイブリッドノードの接続](hybrid-nodes-bottlerocket.md)」を参照してください。 このトピックでは、ハイブリッドノードを Amazon EKS クラスターに接続する方法について説明します。ハイブリッドノードがクラスターに参加すると、Amazon EKS コンソールと kubectl などの Kubernetes 互換ツールに準備中ステータスが表示されます。このページのステップを完了したら、「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」に進み、ハイブリッドノードでアプリケーションを実行する準備をします。 ## 前提条件 ハイブリッドノードを Amazon EKS クラスターに接続する前に、前提条件の手順が完了していることを確認してください。 + オンプレミス環境から Amazon EKS クラスターをホストする AWS リージョンへのネットワーク接続があること。詳細については「[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md)」を参照してください。 + ハイブリッドノード用の互換性のあるオペレーティングシステムがオンプレミスホストにインストールされていること。詳細については「[ハイブリッドノード用のオペレーティングシステムを準備する](hybrid-nodes-os.md)」を参照してください。 + ハイブリッドノードの IAM ロールを作成し、オンプレミス認証情報プロバイダー (AWS Systems Manager ハイブリッドアクティベーションまたは AWS IAM Roles Anywhere) をセットアップしていること。詳細については「[ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md)」を参照してください。 + ハイブリッドノード対応の Amazon EKS クラスターを作成していること。詳細については「[ハイブリッドノードを使用して Amazon EKS クラスターを作成する](hybrid-nodes-cluster-create.md)」を参照してください。 + ハイブリッドノードの IAM ロールを、Kubernetes ロールベースのアクセスコントロール (RBAC) のアクセス許可に関連付けていること。詳細については「[ハイブリッドノードのクラスターアクセスを準備する](hybrid-nodes-cluster-prep.md)」を参照してください。 ## ステップ 1: ハイブリッドノード CLI (`nodeadm`) を各オンプレミスホストにインストールする 構築済みのオペレーティングシステムイメージに Amazon EKS Hybrid Nodes CLI (`nodeadm`) を含める場合は、このステップをスキップできます。`nodeadm` のハイブリッドノード版の詳細については、「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。 `nodeadm` のハイブリッドノード版は、Amazon CloudFront をフロントに置いた Amazon S3 でホストされます。各オンプレミスホストに `nodeadm` をインストールするにはオンプレミスホストから以下のコマンドを実行してください。 **x86\$164 ホストの場合:** ``` curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/amd64/nodeadm' ``` **ARM ホストの場合** ``` curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/arm64/nodeadm' ``` 各ホストでダウンロードしたバイナリに実行可能ファイルのアクセス許可を追加します。 ``` chmod +x nodeadm ``` ## ステップ 2: `nodeadm` を使用してハイブリッドノードの依存関係をインストールする 構築済みのオペレーティングシステムイメージにハイブリッドノードの依存関係をインストールする場合は、このステップをスキップできます。`nodeadm install` コマンドを使用して、ハイブリッドノードに必要なすべての依存関係をインストールできます。ハイブリッドノードの依存関係には、containerd、kubelet、kubectl、AWS SSM または AWS IAM Roles Anywhere コンポーネントが含まれます。`nodeadm install` によってインストールされるコンポーネントとファイルの場所の詳細については、「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。オンプレミスファイアウォールで `nodeadm install` プロセスのために許可する必要があるドメインの詳細については、「[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md)」を参照してください。 以下のコマンドを実行して、ハイブリッドノードの依存関係をオンプレミスホストにインストールします。以下のコマンドは、ホストで sudo/root アクセスを持つユーザーで実行する必要があります。 **重要** ハイブリッドノードの CLI (`nodeadm`) は、ホストで sudo/root アクセスを持つユーザーで実行する必要があります。 + `K8S_VERSION` を、`1.31` などの Amazon EKS クラスターの Kubernetes マイナーバージョンに置き換えます。サポートされている Kubernetes のバージョンのリストについては、「[Amazon EKS supported versions](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)」を参照してください。 + `CREDS_PROVIDER` を、使用しているオンプレミスの認証情報プロバイダーに置き換えます。有効な値は、AWS SSM の場合は `ssm`、AWS IAM Roles Anywhere の場合は `iam-ra` です。 ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER ``` ## ステップ 3: ハイブリッドノードをクラスターに接続する ハイブリッドノードをクラスターに接続する前に、Amazon EKS コントロールプレーンとハイブリッドノード間の通信のために、オンプレミスファイアウォールとクラスターのセキュリティグループで必要なアクセスを許可していることを確認してください。このステップのほとんどの問題は、ファイアウォール設定、セキュリティグループ設定、またはハイブリッドノードの IAM ロール設定に関連しています。 **重要** ハイブリッドノードの CLI (`nodeadm`) は、ホストで sudo/root アクセスを持つユーザーで実行する必要があります。 1. デプロイの値を使用して、各ホストに `nodeConfig.yaml` ファイルを作成します。使用可能な構成設定の詳細については、「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。ハイブリッドノードの IAM ロールに `eks:DescribeCluster` アクションのアクセス許可がない場合は、`nodeConfig.yaml` のクラスターセクションで Kubernetes API エンドポイント、クラスター CA バンドル、および Kubernetes サービス IPv4 CIDR を渡す必要があります。 1. オンプレミス認証情報プロバイダーに AWS SSM ハイブリッドアクティベーションを使用している場合は、以下の `nodeConfig.yaml` の例を使用します。 1. `CLUSTER_NAME` を自分のクラスター名に置き換えます。 1. `AWS_REGION` を、クラスターがホストされている AWS リージョンに置き換えます。例えば、`us-west-2`。 1. `ACTIVATION_CODE` を、AWS SSM ハイブリッドアクティベーションの作成時に受け取ったアクティベーションコードに置き換えます。詳細については「[ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md)」を参照してください。 1. `ACTIVATION_ID` を、AWS SSM ハイブリッドアクティベーションの作成時に受け取ったアクティベーション ID に置き換えます。この情報は、AWS Systems Manager コンソールまたは AWS CLI `aws ssm describe-activations` コマンドから取得できます。 ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: CLUSTER_NAME region: AWS_REGION hybrid: ssm: activationCode: ACTIVATION_CODE activationId: ACTIVATION_ID ``` 1. オンプレミス認証情報プロバイダーに AWS IAM Roles Anywhere を使用している場合は、以下の `nodeConfig.yaml` の例を使用します。 1. `CLUSTER_NAME` を自分のクラスター名に置き換えます。 1. `AWS_REGION` を、クラスターがホストされている AWS リージョンに置き換えます。例えば、`us-west-2`。 1. `NODE_NAME` をノードの名前に置き換えます。ハイブリッドノードの IAM ロールの信頼ポリシーを `"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}"` リソース条件で設定した場合、ノード名はホスト上の証明書の CN と一致する必要があります。使用する `nodeName` は 64 文字以下にする必要があります。 1. `TRUST_ANCHOR_ARN` を、ハイブリッドノードの認証情報を準備する手順で設定したトラストアンカーの ARN に置き換えます。 1. `PROFILE_ARN` を、[ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md) のステップで設定したトラストアンカーの ARN に置き換えます。 1. `ROLE_ARN` をハイブリッドノード IAM ロールの ARN に置き換えます。 1. `CERTIFICATE_PATH` をノード証明書へのディスク内のパスに置き換えます。指定しなかった場合、デフォルトは `/etc/iam/pki/server.pem` です。 1. `KEY_PATH` を、証明書のプライベートキーへのディスク内のパスに置き換えます。指定しなかった場合、デフォルトは `/etc/iam/pki/server.key` です。 ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: CLUSTER_NAME region: AWS_REGION hybrid: iamRolesAnywhere: nodeName: NODE_NAME trustAnchorArn: TRUST_ANCHOR_ARN profileArn: PROFILE_ARN roleArn: ROLE_ARN certificatePath: CERTIFICATE_PATH privateKeyPath: KEY_PATH ``` 1. `nodeConfig.yaml` で `nodeadm init` コマンドを実行して、ハイブリッドノードを Amazon EKS クラスターに接続します。 ``` nodeadm init -c file://nodeConfig.yaml ``` 上記のコマンドが正常に完了すれば、ハイブリッドノードは Amazon EKS クラスターに参加したことになります。これは、Amazon EKS コンソールでクラスターの [コンピューティング] タブに移動する ([IAM プリンシパルに表示権限があることを確認してください](view-kubernetes-resources.md#view-kubernetes-resources-permissions)) か、または `kubectl get nodes` を使用して確認できます。 **重要** ノードのステータスは `Not Ready` になります。これは、ハイブリッドノードで実行されている CNI がないことが原因であり、予想通りのことです。ノードがクラスターに参加しなかった場合は、「[ハイブリッドノードのトラブルシューティング](hybrid-nodes-troubleshooting.md)」を参照してください。 ## ステップ 4: ハイブリッドノードの CNI を設定する ハイブリッドノードでアプリケーションを実行する準備を整えるには、「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」の手順に進みます。 # Bottlerocket を実行しているハイブリッドノードの接続 このトピックでは、Bottlerocket を実行しているハイブリッドノードを Amazon EKS クラスターに接続する方法について解説します。[Bottlerocket](https://aws.amazon.com/bottlerocket/) は、AWS が支援およびサポートしているオープンソースの Linux ディストリビューションです。Bottlerocket は、コンテナワークロードをホストするために専用に構築されています。Bottlerocket を使用すると、コンテナインフラストラクチャの更新を自動化することで、コンテナ化されたデプロイの可用性を向上させ、運用コストを削減できます。Bottlerocket には、コンテナの実行に不可欠なソフトウェアのみが含まれており、リソース使用率の向上、セキュリティ上の脅威の軽減、管理オーバーヘッドの軽減が実現されます。 EKS Hybrid Nodes でサポートされているのは、Bottlerocket のバージョンが v1.37.0 以降である VMware のバリアントのみです。Bottlerocket の VMware のバリアントは、Kubernetes のバージョン v1.28 以降で使用できます。これらのバリアント OS イメージには、kubelet、containerd、aws-iam-authenticator、ならびに EKS Hybrid Nodes のその他のソフトウェアの前提条件、が含まれています。これらのコンポーネントは、Bottlerocket のブートストラップと管理コンテナ向けの、base64 でエンコードされたユーザーデータを含む、Bottlerocket の[設定](https://github.com/bottlerocket-os/bottlerocket#settings)ファイルを使用して設定できます。これらを設定することで、Bottlerocket は、ハイブリッドノードの認証情報プロバイダーを使用して、クラスターのハイブリッドノードを認証できるようになります。ハイブリッドノードをクラスターに追加すると、Amazon EKS コンソールや Kubernetes 互換ツール (`kubectl` など) にそれらのステータスが `Not Ready` と表示されます。このページのステップを完了したら、「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」に進み、ハイブリッドノードでアプリケーションを実行する準備をします。 ## 前提条件 ハイブリッドノードを Amazon EKS クラスターに接続する前に、前提条件の手順が完了していることを確認してください。 + オンプレミス環境から Amazon EKS クラスターをホストする AWS リージョンへのネットワーク接続があること。詳細については「[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md)」を参照してください。 + ハイブリッドノードの IAM ロールを作成し、オンプレミス認証情報プロバイダー (AWS Systems Manager ハイブリッドアクティベーションまたは AWS IAM Roles Anywhere) をセットアップしていること。詳細については「[ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md)」を参照してください。 + ハイブリッドノード対応の Amazon EKS クラスターを作成していること。詳細については「[ハイブリッドノードを使用して Amazon EKS クラスターを作成する](hybrid-nodes-cluster-create.md)」を参照してください。 + ハイブリッドノードの IAM ロールを、Kubernetes ロールベースのアクセスコントロール (RBAC) のアクセス許可に関連付けていること。詳細については「[ハイブリッドノードのクラスターアクセスを準備する](hybrid-nodes-cluster-prep.md)」を参照してください。 ## ステップ 1: Bottlerocket 設定の TOML ファイルを作成する ハイブリッドノード用に Bottlerocket を設定するには、`settings.toml` ファイルを必要とする設定で作成する必要があります。TOML ファイルのコンテンツは、使用している認証情報プロバイダー (SSM または IAM Roles Anywhere) に応じて異なります。このファイルは、Bottlerocket インスタンスをプロビジョニングするときに、ユーザーデータとして渡されます。 **注記** 以下に示す TOML ファイルは、Bottlerocket VMWare マシンを EKS クラスターのノードとして初期化するために必要な最小設定のみを示しています。Bottlerocket にはさまざまなユースケースに対応する幅広い設定が用意されているため、ハイブリッドノードの初期化以外の設定オプションについては、使用している Bottlerocket バージョンに関して文書化されているすべての設定の包括的なリストが記載されている [Bottlerocket ドキュメント](https://bottlerocket.dev/en)を参照してください (例: Bottlerocket 1.51.x で使用できるすべての設定は[次のとおりです](https://bottlerocket.dev/en/os/1.51.x/api/settings-index))。 ### SSM AWS Systems Manager を認証情報プロバイダーとして使用している場合は、コンテンツを次のようにして `settings.toml` ファイルを作成します。 ``` [settings.kubernetes] cluster-name = "" api-server = "" cluster-certificate = "" hostname-override = "" provider-id = "eks-hybrid://///" authentication-mode = "aws" cloud-provider = "" server-tls-bootstrap = true [settings.network] hostname = "" [settings.aws] region = "" [settings.kubernetes.credential-providers.ecr-credential-provider] enabled = true cache-duration = "12h" image-patterns = [ "*.dkr.ecr.*.amazonaws.com", "*.dkr.ecr.*.amazonaws.com.rproxy.govskope.ca.cn", "*.dkr.ecr.*.amazonaws.eu", "*.dkr.ecr-fips.*.amazonaws.com", "*.dkr.ecr-fips.*.amazonaws.eu", "public.ecr.aws" ] [settings.kubernetes.node-labels] "eks.amazonaws.com/compute-type" = "hybrid" "eks.amazonaws.com/hybrid-credential-provider" = "ssm" [settings.host-containers.admin] enabled = true user-data = "" [settings.bootstrap-containers.eks-hybrid-setup] mode = "always" user-data = "" [settings.host-containers.control] enabled = true ``` プレースホルダを次の値に置き換えます。 + ``: Amazon EKS クラスターの名前 + ``: クラスターの API サーバーエンドポイント + ``: クラスターの base64 エンコードされた CA バンドル + ``: クラスターをホストしている AWS リージョン。例: "us-east-1" + ``: Bottlerocket インスタンスのホスト名。これはノード名としても設定されます。こちらは任意の一意の値にすることができますが、[Kubernetes オブジェクトの命名規則](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)に従う必要があります。さらに、使用するホスト名は 64 文字以下にする必要があります。注: SSM プロバイダーを使用する場合、このホスト名とノード名は、インスタンスが SSM に登録された後、マネージドインスタンス ID (`mi-*` ID など) に置き換えられます。 + ``: Bottlerocket 管理コンテナの設定の、base64 でエンコードされたコンテンツ。管理コンテナを有効にすると、SSH を使用して Bottlerocket インスタンスに接続し、システムの探索やデバッグを行えるようになります。これは必須の設定ではありませんが、トラブルシューティングを容易にするため有効にしておくことが推奨されます。管理コンテナを使用した認証の詳細については [Bottlerocket 管理コンテナのドキュメント](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container)を参照してください。管理者コンテナは、以下の例に示すように、SSH ユーザーとキーの入力を JSON 形式で受け取ります。 ``` { "user": "", "ssh": { "authorized-keys": [ "" ] } } ``` + ``: Bottlerocket ブートストラップコンテナの設定の、base64 でエンコードされたコンテンツ。設定の詳細については [Bottlerocket ブートストラップコンテナのドキュメント](https://github.com/bottlerocket-os/bottlerocket-bootstrap-container)を参照してください。ブートストラップコンテナは、インスタンスを AWS SSM マネージドインスタンスとして登録し、これを Amazon EKS クラスターの Kubernetes ノードとして結合する役割を果たします。ブートストラップコンテナに渡されるユーザーデータは、以前に作成した SSM ハイブリッドアクティベーションコードと ID を入力として受け入れる、コマンド呼び出しの形式をとります。 ``` eks-hybrid-ssm-setup --activation-id= --activation-code= --region= ``` ### IAM Roles Anywhere AWS IAM Roles Anywhere を認証情報プロバイダーとして使用している場合は、コンテンツを次のようにして `settings.toml` ファイルを作成します。 ``` [settings.kubernetes] cluster-name = "" api-server = "" cluster-certificate = "" hostname-override = "" provider-id = "eks-hybrid://///" authentication-mode = "aws" cloud-provider = "" server-tls-bootstrap = true [settings.network] hostname = "" [settings.aws] region = "" config = "" [settings.kubernetes.credential-providers.ecr-credential-provider] enabled = true cache-duration = "12h" image-patterns = [ "*.dkr.ecr.*.amazonaws.com", "*.dkr.ecr.*.amazonaws.com.rproxy.govskope.ca.cn", "*.dkr.ecr.*.amazonaws.eu", "*.dkr.ecr-fips.*.amazonaws.com", "*.dkr.ecr-fips.*.amazonaws.eu", "public.ecr.aws" ] [settings.kubernetes.node-labels] "eks.amazonaws.com/compute-type" = "hybrid" "eks.amazonaws.com/hybrid-credential-provider" = "iam-ra" [settings.host-containers.admin] enabled = true user-data = "" [settings.bootstrap-containers.eks-hybrid-setup] mode = "always" user-data = "" ``` プレースホルダを次の値に置き換えます。 + ``: Amazon EKS クラスターの名前 + ``: クラスターの API サーバーエンドポイント + ``: クラスターの base64 エンコードされた CA バンドル + ``: クラスターをホストしている AWS リージョン。例: "us-east-1" + ``: Bottlerocket インスタンスのホスト名。これはノード名としても設定されます。こちらは任意の一意の値にすることができますが、[Kubernetes オブジェクトの命名規則](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names)に従う必要があります。さらに、使用するホスト名は 64 文字以下にする必要があります。注: IAM-RA プロバイダーを使用しているときは、ノード名は、ハイブリッドノードの IAM ロールの信頼ポリシーを `"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}"` リソース条件で設定した場合にホストの証明書の CN と一致している必要があります。 + ``: AWS 設定ファイルの base64 でエンコードされたコンテンツ。ファイルのコンテンツは以下のようになるはずです。 ``` [default] credential_process = aws_signing_helper credential-process --certificate /root/.aws/node.crt --private-key /root/.aws/node.key --profile-arn --role-arn --trust-anchor-arn --role-session-name ``` + ``: Bottlerocket 管理コンテナの設定の、base64 でエンコードされたコンテンツ。管理コンテナを有効にすると、SSH を使用して Bottlerocket インスタンスに接続し、システムの探索やデバッグを行えるようになります。これは必須の設定ではありませんが、トラブルシューティングを容易にするため有効にしておくことが推奨されます。管理コンテナを使用した認証の詳細については [Bottlerocket 管理コンテナのドキュメント](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container)を参照してください。管理者コンテナは、以下の例に示すように、SSH ユーザーとキーの入力を JSON 形式で受け取ります。 ``` { "user": "", "ssh": { "authorized-keys": [ "" ] } } ``` + ``: Bottlerocket ブートストラップコンテナの設定の、base64 でエンコードされたコンテンツ。設定の詳細については [Bottlerocket ブートストラップコンテナのドキュメント](https://github.com/bottlerocket-os/bottlerocket-bootstrap-container)を参照してください。ブートストラップコンテナは、インスタンスに IAM Roles Anywhere ホスト証明書と証明書プライベートキーファイルを作成する役割を果たします。これらはその後、Amazon EKS クラスターで認証を行うときに、一時的な認証情報を取得するために `aws_signing_helper` が使用します。ブートストラップコンテナに渡されるユーザーデータは、以前に作成した証明書とプライベートキーのコンテンツを入力として受け入れる、コマンド呼び出しの形式をとります。 ``` eks-hybrid-iam-ra-setup --certificate= --key= ``` ## ステップ 2: ユーザーデータを使用して Bottlerocket vSphere VM をプロビジョニングする TOML ファイルを作成したら、vSphere VM の作成時にこれをユーザーデータとして渡します。ユーザーデータは VM の電源を初めて入れる前に設定しておく必要があることを忘れないでください。そのため、インスタンスの作成時にこれを指定しておく必要があります。または、VM を事前に作成する場合は、ユーザーデータを設定するまで VM のステータスを poweredOff にしておく必要があります。`govc` CLI を使用する場合の例を以下に示します。 ### VM を初めて作成する ``` govc vm.create \ -on=true \ -c=2 \ -m=4096 \ -net.adapter= \ -net= \ -e guestinfo.userdata.encoding="base64" \ -e guestinfo.userdata="$(base64 -w0 settings.toml)" \ -template= \ ``` ### 既存の VM のユーザーデータを更新する ``` govc vm.create \ -on=false \ -c=2 \ -m=4096 \ -net.adapter= \ -net= \ -template= \ govc vm.change -vm \ -e guestinfo.userdata="$(base64 -w0 settings.toml)" \ -e guestinfo.userdata.encoding="base64" govc vm.power -on ``` 上記のセクションでは、`-e guestinfo.userdata.encoding="base64"` オプションでユーザーデータが base64 でエンコードされていることを指定します。`-e guestinfo.userdata` オプションは、`settings.toml` ファイルの base64 でエンコードされたコンテンツを、ユーザーデータとして Bottlerocket インスタンスに渡します。プレースホルダーを Bottlerocket OVA テンプレートやネットワークの詳細など特定の値に置き換えます。 ## ステップ 3: ハイブリッドノードの接続を検証する Bottlerocket インスタンスは、起動すると、Amazon EKS クラスターに結合しようとします。Amazon EKS コンソールでこの接続を検証するには、クラスターの [コンピューティング] タブに移動するか、次のコマンドを実行します。 ``` kubectl get nodes ``` **重要** ノードのステータスは `Not Ready` になります。これは、ハイブリッドノードで実行されている CNI がないことが原因であり、予想通りのことです。ノードがクラスターに参加しなかった場合は、「[ハイブリッドノードのトラブルシューティング](hybrid-nodes-troubleshooting.md)」を参照してください。 ## ステップ 4: ハイブリッドノードの CNI を設定する ハイブリッドノードでアプリケーションを実行する準備を整えるには、「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」の手順に進みます。 # クラスターのハイブリッドノードをアップグレードする ハイブリッドノードのアップグレードに関するガイダンスは、Amazon EC2 で実行されるセルフマネージド Amazon EKS ノードと類似しています。ターゲットの Kubernetes バージョンで新しいハイブリッドノードを作成し、既存のアプリケーションを新しい Kubernetes バージョンのハイブリッドノードに円滑に移行し、古い Kubernetes バージョンのハイブリッドノードをクラスターから削除することが推奨されます。アップグレードを開始する前に、アップグレードに関する「[Amazon EKS ベストプラクティス](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)」を確認してください。Amazon EKS Hybrid Nodes には、標準サポートや拡張サポートなどの、クラウドノードを持つ Amazon EKS クラスターに対して同じ [Kubernetes バージョン](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)のサポートがあります。 Amazon EKS Hybrid Nodes は、アップストリーム Kubernetes と同じノードの[バージョンスキューポリシー](https://kubernetes.io/releases/version-skew-policy/#supported-version-skew)に従います。Amazon EKS Hybrid Nodes は、Amazon EKS コントロールプレーンよりも新しいバージョンにすることはできません。また、ハイブリッドノードは、Amazon EKS のコントロールプレーンのマイナーバージョンより、最大 3 つ前まで古い Kubernetes のマイナーバージョンである可能性があります。 カットオーバー移行のアップグレード戦略のためにターゲットの Kubernetes バージョンに新しいハイブリッドノードを作成する空き容量がない場合は、代わりに Amazon EKS Hybrid Nodes CLI (`nodeadm`) を使用してハイブリッドノードの Kubernetes バージョンをインプレースでアップグレードできます。 **重要** `nodeadm` を使用してインプレースでハイブリッドノードをアップグレードしている場合、古いバージョンの Kubernetes コンポーネントがシャットダウンされ、新しい Kubernetes バージョンコンポーネントがインストールされて起動されるプロセス中に、ノードのダウンタイムが発生します。 ## 前提条件 アップグレードする前に、以下の前提条件を満たしていることを確認してください。 + ハイブリッドノードのアップグレードのターゲット Kubernetes バージョンは、Amazon EKS コントロールプレーンのバージョン以下である必要があります。 + カットオーバー移行のアップグレード戦略に従う場合、ターゲット Kubernetes バージョンにインストールする新しいハイブリッドノードは、[ハイブリッドノードの前提条件のセットアップ](hybrid-nodes-prereqs.md) 要件を満たしている必要があります。この要件には、Amazon EKS クラスターの作成時に渡した Remote Node Network CIDR 内に IP アドレスがあることが含まれます。 + カットオーバー移行とインプレースアップグレードの両方について、ハイブリッドノードは、ハイブリッドノードの依存関係の新しいバージョンを取得するために[必要なドメイン](hybrid-nodes-networking.md#hybrid-nodes-networking-on-prem)にアクセスできる必要があります。 + Amazon EKS Kubernetes API エンドポイントとのやり取りに使用するローカルマシンまたはインスタンスに kubectl をインストールしてる必要があります。 + CNI のバージョンは、アップグレード先の Kubernetes バージョンをサポートしている必要があります。そうでない場合は、ハイブリッドノードをアップグレードする前に CNI バージョンをアップグレードします。詳細については「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」を参照してください。 ## カットオーバー移行 (Blue/Green) アップグレード *カットオーバー移行のアップグレード*とは、ターゲット Kubernetes バージョンを使用して新しいホストに新しいハイブリッドノードを作成し、既存のアプリケーションをターゲット Kubernetes バージョンの新しいハイブリッドノードに円滑に移行し、クラスターから古い Kubernetes のバージョンのハイブリッドノードを削除するプロセスを指します。この戦略は Blue/Green 移行とも呼ばれます。 1. [ハイブリッドノードを接続する](hybrid-nodes-join.md) 手順に従って、新しいホストをハイブリッドノードとして接続します。`nodeadm install` コマンドを実行するときは、ターゲット Kubernetes バージョンを使用します。 1. ターゲット Kubernetes バージョンの新しいハイブリッドノードと古い Kubernetes バージョンのハイブリッドノード間の通信を有効にします。この設定により、ターゲット Kubernetes バージョンのハイブリッドノードにワークロードを移行している間に、ポッドが相互に通信できるようになります。 1. ターゲット Kubernetes バージョンのハイブリッドノードがクラスターに正常に参加しており、ステータスが Ready (準備完了) であることを確認します。 1. 以下のコマンドを使用して、削除する各ノードをスケジュール不可としてマークします。これは、置き換えるノード上で新しいポッドがスケジュールまたは再スケジュールされないようにするためです。詳細については、Kubernetes のドキュメントの「[kubectl cordon](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/)」を参照してください。`NODE_NAME` を古い Kubernetes バージョンのハイブリッドノードの名前に置き換えます。 ``` kubectl cordon NODE_NAME ``` 次のコードスニペットを使用して、特定の Kubernetes バージョン (この場合は `1.28`) のすべてのノードを識別して隔離できます。 ``` K8S_VERSION=1.28 for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name') do echo "Cordoning $node" kubectl cordon $node done ``` 1. 現在のデプロイメントで、ハイブリッドノードで実行している CoreDNS レプリカが 2 つ未満の場合は、そのデプロイメントを少なくとも 2 つのレプリカにスケールアウトします。通常のオペレーションでは、回復力を高めるためにハイブリッドノードで少なくとも 2 つの CoreDNS レプリカを実行することが推奨されます。 ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. 次のコマンドを使用して、クラスターから削除する古い Kubernetes バージョンのハイブリッドノードをそれぞれドレインします。ノードドレインのドレイン処理に関する詳細については、Kubernetes ドキュメントの「[Safely Drain a Node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/)」を参照してください。`NODE_NAME` を古い Kubernetes バージョンのハイブリッドノードの名前に置き換えます。 ``` kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data ``` 以下のコードスニペットを使用して、特定の Kubernetes バージョン (この場合は `1.28`) のすべてのノードを識別してドレインすることができます。 ``` K8S_VERSION=1.28 for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name') do echo "Draining $node" kubectl drain $node --ignore-daemonsets --delete-emptydir-data done ``` 1. `nodeadm` を使用して、ホストからハイブリッドノードアーティファクトを停止および削除できます。root/sudo 権限を持つユーザーで `nodeadm` を実行する必要があります。デフォルトでは、ノードにポッドが残っている場合、`nodeadm uninstall` は続行されません。詳細については、「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。 ``` nodeadm uninstall ``` 1. ハイブリッドノードのアーティファクトを停止およびアンインストールしたら、クラスターからノードリソースを削除します。 ``` kubectl delete node node-name ``` 次のコードスニペットを使用して、特定の Kubernetes バージョン (この場合は `1.28`) のすべてのノードを識別および削除できます。 ``` K8S_VERSION=1.28 for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name') do echo "Deleting $node" kubectl delete node $node done ``` 1. CNI の選択によっては、上記のステップを実行した後にハイブリッドノードにアーティファクトが残っている場合があります。詳細については「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」を参照してください。 ## インプレースアップグレード インプレースアップグレードプロセスとは、`nodeadm upgrade` を使用して、新しい物理ホストまたは仮想ホストやカットオーバー移行戦略を使用せずに、ハイブリッドノードの Kubernetes バージョンをアップグレードすることを指します。この `nodeadm upgrade` プロセスでは、ハイブリッドノードで実行されている既存の古い Kubernetes コンポーネントのシャットダウン、既存の古い Kubernetes コンポーネントのアンインストール、新しいターゲット Kubernetes コンポーネントのインストールを行い、新しいターゲット Kubernetes コンポーネントを起動します。ハイブリッドノードで実行されているアプリケーションへの影響を最小限に抑えるために、一度にアップグレードするノードは 1 つにすることを強くお勧めします。このプロセスの期間は、ネットワーク帯域幅とレイテンシーによって異なります。 1. アップグレードするノードをスケジュール不可としてマークするには、次のコマンドを使用します。これは、アップグレードするノード上で新しいポッドがスケジュールまたは再スケジュールされないようにするためです。詳細については、Kubernetes のドキュメントの「[kubectl cordon](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/)」を参照してください。`NODE_NAME` をアップグレードするハイブリッドノードの名前に置き換える ``` kubectl cordon NODE_NAME ``` 1. 次のコマンドを使用して、アップグレードするノードをドレインします。ノードドレインのドレイン処理に関する詳細については、Kubernetes ドキュメントの「[Safely Drain a Node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/)」を参照してください。`NODE_NAME` をアップグレードするハイブリッドノードの名前に置き換えます。 ``` kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data ``` 1. アップグレードするハイブリッドノードで `nodeadm upgrade` を実行します。root/sudo 権限を持つユーザーで `nodeadm` を実行する必要があります。ノードの名前は、AWS SSM と AWS IAM Roles Anywhere の両方の認証情報プロバイダーのアップグレードによって保持されます。アップグレードプロセス中に認証情報プロバイダーを変更することはできません。`nodeConfig.yaml` の設定値については、「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。`K8S_VERSION` を、アップグレード先のターゲット Kubernetes バージョンに置き換えます。 ``` nodeadm upgrade K8S_VERSION -c file://nodeConfig.yaml ``` 1. アップグレード後にノード上で Pod をスケジュールできるように、以下を入力します。`NODE_NAME` をノードの名前に置き換えます。 ``` kubectl uncordon NODE_NAME ``` 1. ハイブリッドノードのステータスを監視し、ノードがシャットダウンするのを待ち、Ready (準備完了) ステータスになったら新しい Kubernetes バージョンで再起動します。 ``` kubectl get nodes -o wide -w ``` # ハイブリッドノード用のセキュリティ更新プログラムにパッチを適用する このトピックでは、ハイブリッドノードで実行されている特定のパッケージと依存関係を対象としたセキュリティ更新プログラムにインプレースでパッチを適用する手順について説明します。ベストプラクティスとして、ハイブリッドノードを定期的に更新して CVE とセキュリティパッチを受け取ることをお勧めします。 Kubernetes バージョンをアップグレードする手順については、「[クラスターのハイブリッドノードをアップグレードする](hybrid-nodes-upgrade.md)」を参照してください。 セキュリティパッチの適用が必要になるソフトウェアの一例が `containerd` です。 ## `Containerd` `containerd` は、標準の Kubernetes コンテナランタイムであり、EKS ハイブリッドノードとはコアな依存関係にあります。その用途は、イメージのプルやコンテナ実行の管理などコンテナのライフサイクルを管理することです。ハイブリッドノードでは、[nodeadm CLI](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-nodeadm.html) を利用するか手動で `containerd` をインストールできます。ノードのオペレーティングシステムに応じて、`nodeadm` は OS 配布のパッケージまたは Docker パッケージから `containerd` をインストールします。 `containerd` の CVE が公開されたら、以下のオプションを利用して、ハイブリッドノードで `containerd` をパッチ適用済みのバージョンにアップグレードできます。 ## ステップ 1: パッチがパッケージマネージャーに公開されているかどうかを確認する `containerd` CVE パッチがそれぞれの OS パッケージマネージャーに公開されているかどうか、対応するセキュリティ速報を参照することで確認できます。 + [Amazon Linux 2023](https://alas.aws.amazon.com/alas2023.html) + [RHEL](https://access.redhat.com/security/security-updates/security-advisories) + [Ubuntu 20.04](https://ubuntu.com/security/notices?order=newest&release=focal) + [Ubuntu 22.04](https://ubuntu.com/security/notices?order=newest&release=jammy) + [Ubuntu 24.04](https://ubuntu.com/security/notices?order=newest&release=noble) Docker リポジトリを `containerd` のソースとして使用している場合は、[Docker セキュリティのお知らせ](https://docs.docker.com/security/security-announcements/)をチェックして、Docker リポジトリからパッチ適用済みのバージョンを入手できるかどうかを確認できます。 ## ステップ 2: パッチのインストール方法を選択する ノードにインプレースでパッチを適用し、セキュリティアップグレードをインストールする方法が 3 つあります。どの方法を使用できるかは、パッチをパッケージマネージャーでオペレーティングシステムから入手できるかどうかによって異なります。 1. `nodeadm upgrade` を使用してパッケージマネージャーに公開されているパッチをインストールします。「[ステップ 2 a](#hybrid-nodes-security-nodeadm)」を参照してください。 1. パッケージマネージャーで直接パッチをインストールします。「[ステップ 2 b](#hybrid-nodes-security-package)」を参照してください。 1. パッケージマネージャーに公開されていないカスタムパッチをインストールします。`containerd` に対するカスタムパッチについては特別な考慮事項があるので注意してください。「[ステップ 2 c](#hybrid-nodes-security-manual)」を参照してください。 ## ステップ 2 a: `nodeadm upgrade` でパッチを適用する `containerd` CVE パッチが OS や Docker リポジトリ (Apt または RPM) に公開されたことを確認したら、`nodeadm upgrade` コマンドを使用して `containerd` を最新バージョンにアップグレードできます。これは Kubernetes バージョンのアップグレードではないため、現在の Kubernetes バージョンを `nodeadm` アップグレードコマンドに渡す必要があります。 ``` nodeadm upgrade K8S_VERSION --config-source file:///root/nodeConfig.yaml ``` ## ステップ 2 b: オペレーティングシステムのパッケージマネージャーでパッチを適用する あるいは、それぞれのパッケージマネージャーから更新することも可能であり、それを使用して以下のように `containerd` パッケージをアップグレードできます。 **Amazon Linux 2023** ``` sudo yum update -y sudo yum install -y containerd ``` **RHEL** ``` sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo sudo yum update -y sudo yum install -y containerd ``` **Ubuntu** ``` sudo mkdir -p /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update -y sudo apt install -y --only-upgrade containerd.io ``` ## ステップ 2 c: `Containerd` CVE パッチがパッケージマネージャーに公開されていない場合の対応 パッチ適用済みの `containerd` バージョンがパッケージマネージャー以外の手段でのみ使用できる場合、例えば GitHub リリースのみであれば GitHub の公式サイトから `containerd` をインストールできます。 1. マシンがハイブリッドノードとしてクラスターに既に参加している場合は、`nodeadm uninstall` コマンドを実行する必要があります。 1. `containerd` の公式のバイナリをインストールします。GitHub の[公式のインストール手順](https://github.com/containerd/containerd/blob/main/docs/getting-started.md#option-1-from-the-official-binaries)を使用できます。 1. `--containerd-source` 引数を `none` に設定して `nodeadm install` コマンドを実行します。`nodeadm` から `containerd` をインストールする操作がスキップされます。ノードでどのオペレーティングシステムが実行されていても、`containerd` ソースで `none` の値を使用できます。 ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --containerd-source none ``` # ハイブリッドノードを削除する このトピックではAmazon EKS クラスターからハイブリッドノードを削除する方法について説明します。[kubectl](https://kubernetes.io/docs/reference/kubectl/) などの Kubernetes 互換ツールを選択して、ハイブリッドノードを削除する必要があります。ハイブリッドノードの課金はノードオブジェクトが Amazon EKS クラスターから削除されると停止します。ハイブリッドノードの料金の詳細については「[Amazon EKS 料金表](https://aws.amazon.com/eks/pricing/)」を参照してください。 **重要** ノードを削除すると、ノードで実行されているワークロードが中断されます。ハイブリッドノードを削除する前に、まずノードをドレインしてポッドを別のアクティブノードに移動することが推奨されます。ノードドレインのドレイン処理に関する詳細についてはKubernetes ドキュメントの「[ノードの安全な排水](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/)」を参照してください。 Amazon EKS クラスターの Kubernetes API エンドポイントとのやり取りに使用するローカルマシンまたはインスタンスから、以下の kubectl ステップを実行してください。特定の `kubeconfig` ファイルを使用している場合は`--kubeconfig` フラグを使用します。 ## ステップ 1: ノードを一覧表示する ``` kubectl get nodes ``` ## ステップ 2: ノードをドレインする `kubectl drain` コマンドの詳細についてはKubernetes ドキュメントの「[kubectl drain](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_drain/)」を参照してください。 ``` kubectl drain --ignore-daemonsets ``` ## ステップ 3: ハイブリッドノードアーティファクトを停止およびアンインストールする Amazon EKS Hybrid Nodes CLI (`nodeadm`) を使用して、ホストからハイブリッドノードアーティファクトを停止および削除できます。root/sudo 権限を持つユーザーで `nodeadm` を実行する必要があります。デフォルトではノードにポッドが残っている場合、`nodeadm uninstall` は続行されません。AWS システム・マネージャー (SSM) を認証情報プロバイダーとして使用している場合、`nodeadm uninstall` コマンドはホストの AWS SSM マネージドインスタンスとしての登録を解除します。詳細については「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。 ``` nodeadm uninstall ``` ## ステップ 4: クラスターからノードを削除する ハイブリッドノードのアーティファクトを停止およびアンインストールしたら、クラスターからノードリソースを削除します。 ``` kubectl delete node ``` ## ステップ 5: 残りのアーティファクトを確認する CNI の選択によっては上記のステップを実行した後にハイブリッドノードにアーティファクトが残っている場合があります。詳細については「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」を参照してください。 # ハイブリッドノードのアプリケーションネットワーキング、アドオン、ウェブフックを設定する ハイブリッドノード用に EKS クラスターを作成したら、アプリケーションネットワーキングに関する追加の機能 (CNI、BGP、Ingress、Load Balancing、Network Policies)、アドオン、ウェブフック、プロキシを設定します。ハイブリッドノードと互換性のある EKS およびコミュニティアドオンの完全なリストは、「[ハイブリッドノードのアドオンを構成する](hybrid-nodes-add-ons.md)」を参照してください。 **EKS クラスターインサイト** EKS には、クラスターまたはワークロードの機能を損なう可能性のあるハイブリッドノードの設定ミスに関するインサイトチェックが含まれています。クラスターインサイトの詳細については、「[Kubernetes バージョンアップグレードの準備およびクラスターインサイトでの設定ミスのトラブルシューティング](cluster-insights.md)」を参照してください。 以下に、ハイブリッドノードでよく使用される機能とアドオンを示します。 + **Container Networking Interface (CNI)**: AWS は、ハイブリッドノード向けの CNI として [Cilium](https://docs.cilium.io/en/stable/index.html) をサポートしています。詳細については、「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」を参照してください。AWS VPC CNI はハイブリッドノードでは使用できないことに注意してください。 + **CoreDNS と `kube-proxy`**: ハイブリッドノードが EKS クラスターと結合したときは、CoreDNS と `kube-proxy` が自動的にインストールされます。これらのアドオンは、クラスターの作成後、EKS アドオンとして管理できます。 + **Ingress と Load Balancing**: ハイブリッドノード上で実行されているワークロードのターゲットタイプが `ip` の場合、AWS Load Balancer Controller を Application Load Balancer (ALB) または Network Load Balancer (NLB) と共に使用できます。AWS は、ハイブリッドノード上で実行されているワークロード向けに Cilium に組み込みの Ingress、Gateway、Kubernetes Service のロードバランシング機能をサポートしています。詳細については、「[ハイブリッドノード用に Kubernetes Ingress を設定する](hybrid-nodes-ingress.md)」および「[ハイブリッドノード用にタイプ LoadBalancer の Service を設定する](hybrid-nodes-load-balancing.md)」を参照してください。 + **メトリクス**: Amazon Managed Service for Prometheus (AMP) エージェントレススクレイパー、AWS Distro for Open Telemetry (ADOT)、Amazon CloudWatch Observability Agent は、ハイブリッドノードで使用できます。ポッドメトリクス用の AMP エージェントレススクレイパーをハイブリッドノードで使用する場合は、Amazon EKS クラスターに使用する VPC からポッドにアクセスできる必要があります。 + **ログ**: ハイブリッドノードが有効になっているクラスターに対して、EKS コントロールプレーンのログ記録を有効にすることができます。ADOT EKS アドオンと Amazon CloudWatch Observability Agent EKS アドオンを、ハイブリッドノードとポッドのログ記録に使用できます。 + **Pod Identity と IRSA**: EKS Pod Identity と IAM Roles for Service Accounts (IRSA) を、ハイブリッドノードで実行中のアプリケーションで使用すると、ハイブリッドノードで実行中の Pod に、他の AWS サービスを使ってきめ細かくアクセスすることが可能になります。 + **ウェブフック**: ウェブフックを実行している場合は、オンプレミスのポッドネットワークをルーティングできない場合に、クラウドノードでウェブフックを選択的に実行する際の考慮事項と手順について「[ハイブリッドノード用のウェブフックを設定する](hybrid-nodes-webhooks.md)」を参照してください。 + **Proxy**: データセンターまたはエッジ環境から送信されるトラフィックに、オンプレミス環境にあるプロキシサーバーを使用している場合は、そのプロキシサーバーを使用するようにノードとクラスターを設定することができます。詳細については、「[ハイブリッドノードのプロキシを設定する](hybrid-nodes-proxy.md)」を参照してください。 **Topics** + [ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md) + [ハイブリッドノードのアドオンを構成する](hybrid-nodes-add-ons.md) + [ハイブリッドノード用のウェブフックを設定する](hybrid-nodes-webhooks.md) + [ハイブリッドノードのプロキシを設定する](hybrid-nodes-proxy.md) + [ハイブリッドノード向けに Cilium BGP を設定する](hybrid-nodes-cilium-bgp.md) + [ハイブリッドノード用に Kubernetes Ingress を設定する](hybrid-nodes-ingress.md) + [ハイブリッドノード用にタイプ LoadBalancer の Service を設定する](hybrid-nodes-load-balancing.md) + [ハイブリッドノード用に Kubernetes ネットワークポリシーを設定する](hybrid-nodes-network-policies.md) # ハイブリッドノードの CNI を設定する Cilium は、Amazon EKS Hybrid Nodes 向けに AWS でサポートされるコンテナネットワークインターフェイス (CNI) です。ハイブリッドノードがワークロードを処理できるようにするにはCNI をインストールする必要があります。CNI が稼働するまではハイブリッドノードは `Not Ready` のステータスで表示されます。CNI は、Helm など任意のツールで管理できます。このページでは、Cilium ライフサイクル管理 (インストール、アップグレード、削除) の手順を説明します。Cilium をイングレス、ロードバランシング、ネットワークポリシー用に設定する方法については、「[Cilium Ingress および Cilium Gateway の概要](hybrid-nodes-ingress.md#hybrid-nodes-ingress-cilium)」、「[サービスタイプ LoadBalancer](hybrid-nodes-ingress.md#hybrid-nodes-ingress-cilium-loadbalancer)」、「[ハイブリッドノード用に Kubernetes ネットワークポリシーを設定する](hybrid-nodes-network-policies.md)」を参照してください。 AWS では、AWS Cloud 内のノードで Cilium を実行する操作はサポートされていません。Amazon VPC CNI はハイブリッドノードと互換性がなく、VPC CNI は `eks.amazonaws.com/compute-type: hybrid` ラベルに対しアンチアフィニティで設定されています。 このページにこれまで記載されていた Calico ドキュメントは、[EKS ハイブリッドサンプルリポジトリ](https://github.com/aws-samples/eks-hybrid-examples)に移動しました。 ## バージョン互換性 Cilium バージョン `v1.17.x` および `v1.18.x` は、Amazon EKS でサポートされているすべての Kubernetes バージョンの EKS ハイブリッドノードでサポートされています。 **注記** **Cilium v1.18.3 カーネル要件**: カーネル要件 (Linux カーネル >= 5.10) により、Cilium v1.18.3 は以下ではサポートされていません。 + Ubuntu 20.04 + Red Hat Enterprise Linux (RHEL) 8 システム要件については、「[Cilium システム要件](https://docs.cilium.io/en/stable/operations/system_requirements/)」を参照してください。 Amazon EKS でサポートされている Kubernetes のバージョンについては、「[Kubernetes version support](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)」を参照してください。EKS Hybrid Nodes には、クラウドノードを使用する Amazon EKS クラスターと同じ Kubernetes バージョンのサポートがあります。 ## サポートされる機能 AWS は、オープンソース [Cilium プロジェクト](https://github.com/cilium/cilium) に基づく Cilium for EKS Hybrid Nodes のビルドを維持します。AWS から Cilium のサポートを受けるには、AWS が維持する Cilium ビルドとサポート対象の Cilium バージョンを使用している必要があります。 AWS は、EKS ハイブリッドノードで使用する Cilium の以下の機能のデフォルト設定についてテクニカルサポートを提供しています。AWS のサポート範囲外の機能を使用する場合は、Cilium の代替商用サポートを受けるか、社内のエキスパートがトラブルシューティングして解決策を Cilium プロジェクトに提供することをお勧めします。 | Cilium 機能 | AWS によりサポート | | --- | --- | | Kubernetes ネットワーク適合性 | はい | | コアクラスターの接続 | はい | | IP ファミリー | IPv4 | | ライフサイクル管理 | Helm | | ネットワークモード | VXLAN カプセル化 | | IP アドレス管理 (IPAM) | Cilium IPAM クラスタースコープ | | ネットワークポリシー | Kubernetes ネットワークポリシー | | ボーダーゲートウェイプロトコル (BGP) | Cilium BGP コントロールプレーン | | Kubernetes Ingress | Cilium Ingress、Cilium Gateway | | Service LoadBalancer IP 割り当て | Cilium Load Balancer IPAM | | Service LoadBalancer の IP アドレスのアドバタイズ | Cilium BGP コントロールプレーン | | kube-proxy replacement | はい | ## Cilium に関する考慮事項 + **Helm リポジトリ** - AWS は、Amazon Elastic Container Registry Public (Amazon ECR Public) の [Amazon EKS Cilium/Cilium](https://gallery.ecr.aws/eks/cilium/cilium) で Cilium Helm チャートをホストします。使用可能なバージョンは次のとおりです。 + Cilium v1.17.9: `oci://public.ecr.aws/eks/cilium/cilium:1.17.9-0` + Cilium v1.18.3: `oci://public.ecr.aws/eks/cilium/cilium:1.18.3-0` このトピックで示したコマンドでは、このリポジトリを使用しています。`helm repo` コマンドの中に Amazon ECR Public の Helm リポジトリに対して有効でないものがあるため、ローカルの Helm リポジトリ名からこのリポジトリを参照できません。代わりに、ほとんどのコマンドで URI を完全な形で使用してください。 + デフォルトでは、Cilium は VXLAN を[カプセル化方法](https://docs.cilium.io/en/stable/network/concepts/routing/#encapsulation)とするオーバーレイ/トンネルモードで動作するように設定されています。このモードでは、基盤となる物理ネットワークに関する要件が最も少なくなります。 + デフォルトでは、Cilium はクラスターから出ていくすべてのポッドトラフィックの送信元 IP アドレスをノードの IP アドレスに[マスカレード](https://docs.cilium.io/en/stable/network/concepts/masquerading/)します。マスカレードを無効にする場合は、ポッド CIDR がオンプレミスネットワークでルーティング可能である必要があります。 + ハイブリッドノードでウェブフックを実行している場合は、オンプレミスネットワークでポッド CIDR をルーティング可能である必要があります。オンプレミスネットワークでポッド CIDR をルーティングできない場合は、同じクラスター内のクラウドノードでウェブフックを実行することをお勧めします。詳細については、「[ハイブリッドノード用のウェブフックを設定する](hybrid-nodes-webhooks.md)」と「[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md)」を参照してください。 + AWS では、Cilium に組み込みの BGP 機能を使用して、オンプレミスネットワークでポッド CIDR をルーティング可能にすることをお勧めします。ハイブリッドノードで Cilium BGP を設定する方法の詳細については、「[ハイブリッドノード向けに Cilium BGP を設定する](hybrid-nodes-cilium-bgp.md)」を参照してください。 + Cilium のデフォルトの IP Address Manager (IPAM) は[クラスタースコープ](https://docs.cilium.io/en/stable/network/concepts/ipam/cluster-pool/)と呼ばれ、Cilium オペレーターがユーザー設定のポッド CIDR に基づいてノードごとに IP アドレスを割り当てます。 ## ハイブリッドノードに Cilium をインストールする ### 手順 1. `cilium-values.yaml` という名前の YAML ファイルを作成します。次の例では、Cilium のエージェントとオペレーターの `eks.amazonaws.com/compute-type: hybrid` ラベルにアフィニティを設定することで、ハイブリッドノードでのみ動作するように Cilium を設定しています。 + EKS クラスターの*リモートポッドネットワーク*の場合と同じポッド CIDR で `clusterPoolIpv4PodCIDRList` を設定してください。例えば、`10.100.0.0/24`。Cilium オペレーターは、設定された `clusterPoolIpv4PodCIDRList` IP スペース内から IP アドレススライスを割り当てます。ポッド CIDR は、オンプレミスノード CIDR、VPC CIDR、Kubernetes サービス CIDR と重複してはいけません。 + ノードあたりに必要なポッドに基づいて `clusterPoolIpv4MaskSize` を設定します。例えば、ノードあたり 128 個のポッドが必要で、そのサイズが /25 セグメントの場合は `25` とします。 + クラスターに Cilium をデプロイした後で `clusterPoolIpv4PodCIDRList` または `clusterPoolIpv4MaskSize` を変更しないでください。詳細については、「[Expanding the cluster pool](https://docs.cilium.io/en/stable/network/concepts/ipam/cluster-pool/#expanding-the-cluster-pool)」を参照してください。 + kube-proxy 置き換えモードで Cilium を実行している場合は、Helm 値に `kubeProxyReplacement: "true"` を設定し、Cilium と同じノードで既存の kube-proxy デプロイが実行されていないことを確認します。 + 以下の例では、Cilium が L7 ネットワークポリシーとイングレスに使用する Envoy Layer 7 (L7) プロキシを無効にしています。詳細については、「[ハイブリッドノード用に Kubernetes ネットワークポリシーを設定する](hybrid-nodes-network-policies.md)」および「[Cilium Ingress および Cilium Gateway の概要](hybrid-nodes-ingress.md#hybrid-nodes-ingress-cilium)」を参照してください。 + 以下の例では、サービストラフィック分散がお使いのサービス用に設定した場合に正しく機能するように、`loadBalancer.serviceTopology`: `true` を設定しています。詳細については、「[サービストラフィック分散の設定](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-service-traffic-distribution)」を参照してください。 + Cilium の Helm 値の完全なリストについては、Cilium ドキュメントの「[Helm reference](https://docs.cilium.io/en/stable/helm-reference/)」を参照してください。 ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid ipam: mode: cluster-pool operator: clusterPoolIPv4MaskSize: 25 clusterPoolIPv4PodCIDRList: - POD_CIDR loadBalancer: serviceTopology: true operator: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid unmanagedPodWatcher: restart: false loadBalancer: serviceTopology: true envoy: enabled: false kubeProxyReplacement: "false" ``` 1. クラスターに Cilium をインストールします。 + `CILIUM_VERSION` を Cilium バージョン (`1.17.9-0` または `1.18.3-0` など) に置き換えます。Cilium のマイナーバージョンに最新のパッチバージョンを使用することをお勧めします。 + ノードが、選択したバージョンのカーネル要件を満たしていることを確認します。Cilium v1.18.3 には Linux カーネル >= 5.10 が必要です。 + 特定の kubeconfig ファイルを使用している場合はHelm install コマンドで `--kubeconfig` フラグを使用します。 ``` helm install cilium oci://public.ecr.aws/eks/cilium/cilium \ --version CILIUM_VERSION \ --namespace kube-system \ --values cilium-values.yaml ``` 1. 以下のコマンドを使用して、Cilium のインストールが成功したことを確認します。`cilium-operator` デプロイと、各ハイブリッドノードで実行されている `cilium-agent` が確認できるはずです。また、ハイブリッドノードのステータスは `Ready` になっているはずです。ポッド CIDR をオンプレミスネットワークにアドバタイズするように Cilium BGP を設定する方法については、「[ハイブリッドノード向けに Cilium BGP を設定する](hybrid-nodes-cilium-bgp.md)」に進んでください。 ``` kubectl get pods -n kube-system ``` ``` NAME READY STATUS RESTARTS AGE cilium-jjjn8 1/1 Running 0 11m cilium-operator-d4f4d7fcb-sc5xn 1/1 Running 0 11m ``` ``` kubectl get nodes ``` ``` NAME STATUS ROLES AGE VERSION mi-04a2cf999b7112233 Ready 19m v1.31.0-eks-a737599 ``` ## ハイブリッドノードで Cilium をアップグレードする Cilium デプロイをアップグレードする前に、[Cilium アップグレードのドキュメント](https://docs.cilium.io/en/v1.17/operations/upgrade/)とアップグレードに関する注意事項をよく確認し、対象となる Cilium バージョンの変更について理解してください。 1. コマンドライン環境に `helm` CLI がインストールされていることを確認します。インストール手順については「[Helm のドキュメント](https://helm.sh/docs/intro/quickstart/)」を参照してください。 1. Cilium アップグレードのプリフライトチェックを実行してください。`CILIUM_VERSION` を対象となる Cilium バージョンに置き換えます。Cilium のマイナーバージョンに対して、最新のパッチバージョンを実行することをお勧めします。特定の Cilium マイナーリリースの最新のパッチリリースはCilium ドキュメントの「[安定リリースのセクション](https://github.com/cilium/cilium#stable-releases)」で確認できます。 ``` helm install cilium-preflight oci://public.ecr.aws/eks/cilium/cilium --version CILIUM_VERSION \ --namespace=kube-system \ --set preflight.enabled=true \ --set agent=false \ --set operator.enabled=false ``` 1. `cilium-preflight.yaml` の適用後は `READY` Pod の数が実行中の Cilium Pod の数と同じであることを確認します。 ``` kubectl get ds -n kube-system | sed -n '1p;/cilium/p' ``` ``` NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE cilium 2 2 2 2 2 1h20m cilium-pre-flight-check 2 2 2 2 2 7m15s ``` 1. READY ポッドの数が同じになったら、Cilium プリフライトデプロイも READY 1/1 とマークされていることを確認してください。READY 0/1 と表示された場合はアップグレードを続行する前に、「[CNP の検証](https://docs.cilium.io/en/v1.17/operations/upgrade/#cnp-validation)」セクションを参照しながらデプロイの問題を解決してください。 ``` kubectl get deployment -n kube-system cilium-pre-flight-check -w ``` ``` NAME READY UP-TO-DATE AVAILABLE AGE cilium-pre-flight-check 1/1 1 0 12s ``` 1. プリフライトを削除する ``` helm uninstall cilium-preflight --namespace kube-system ``` 1. `helm upgrade` コマンドを実行する場合は、事前にデプロイの値を `existing-cilium-values.yaml` に保存します。あるいは、そのアップグレードコマンドを実行する際に、お使いの設定に対して `--set` コマンドラインオプションを使用します。アップグレード操作は Cilium ConfigMap を上書きするため、アップグレード時に設定値を渡すことが極めて重要です。 ``` helm get values cilium --namespace kube-system -o yaml > existing-cilium-values.yaml ``` 1. 通常のクラスターオペレーションではすべての Cilium コンポーネントが同じバージョンを実行している必要があります。以下のステップではある安定版リリースからより新しい安定版リリースへと、すべてのコンポーネントをアップグレードする方法について説明します。あるマイナーリリースから別のマイナーリリースにアップグレードする場合はまず既存の Cilium マイナーバージョンの最新のパッチリリースにアップグレードすることをお勧めします。中断を最小限に抑えるには `upgradeCompatibility` オプションを、このクラスターに最初にインストールされた Cilium のバージョンに設定します。 ``` helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium --version CILIUM_VERSION \ --namespace kube-system \ --set upgradeCompatibility=1.X \ -f existing-cilium-values.yaml ``` 1. (オプション) 問題があってアップグレードをロールバックする必要がある場合は次のコマンドを実行してください。 ``` helm history cilium --namespace kube-system helm rollback cilium [REVISION] --namespace kube-system ``` ## ハイブリッドノードから Cilium を削除する 1. 以下のコマンドを実行して、クラスターからすべての Cilium コンポーネントをアンインストールします。なお、CNI をアンインストールすると、ノードと Pod の正常性に影響する可能性があるため、本番稼働用クラスターでは実行しないでください。 ``` helm uninstall cilium --namespace kube-system ``` CNI がクラスターから削除されても、Cilium によって設定されたインターフェイスとルートはデフォルトでは削除されません。詳細については「[GitHub の問題](https://github.com/cilium/cilium/issues/34289)」を参照してください。 1. ディスク上の設定ファイルとリソースをクリーンアップするには標準的な設定ディレクトリを使用している場合はGitHub の Cilium リポジトリの [`cni-uninstall.sh` スクリプト](https://github.com/cilium/cilium/blob/main/plugins/cilium-cni/cni-uninstall.sh)に示されているようにファイルを削除できます。 1. Cilium カスタムリソース定義 (CRD クラスターから削除するには以下のコマンドを実行してください。 ``` kubectl get crds -oname | grep "cilium" | xargs kubectl delete ``` # ハイブリッドノードのアドオンを構成する このページでは、Amazon EKS Hybrid Nodes で AWS アドオンとコミュニティアドオンを実行する際の考慮事項について説明します。Amazon EKS アドオンと、クラスターからアドオンを作成、アップグレード、削除するプロセスの詳細については、「[Amazon EKS アドオン](eks-add-ons.md)」を参照してください。このページに特に明記されていない限り、Amazon EKS アドオンを作成、アップグレード、削除するプロセスは、ハイブリッドノードを備える Amazon EKS クラスターでも、AWS クラウドでノードが実行される Amazon EKS クラスターでも同じです。このページに記載のアドオンについてのみ、Amazon EKS Hybrid Nodes との互換性が検証されています。 以下の AWS アドオンは、Amazon EKS Hybrid Nodes と互換性があります。 | AWS アドオン | 互換性のあるアドオンバージョン | | --- | --- | | kube-proxy | v1.25.14-eksbuild.2 以降 | | CoreDNS | v1.9.3-eksbuild.7 以降 | | AWS オープンテレメトリー用ディストリビューター (ADOT) | v0.102.1-eksbuild.2 以降 | | CloudWatch Observability エージェント | v2.2.1-eksbuild.1 以降 | | EKS Pod Identity エージェント | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/hybrid-nodes-add-ons.html) | | ノードモニタリングエージェント | v1.2.0-eksbuild.1 以降 | | CSI スナップショットコントローラー | v8.1.0-eksbuild.1 以降 | | AWS プライベート CA の Connector for Kubernetes | v1.6.0-eksbuild.1 以降 | | Amazon FSx CSI ドライバー | v1.7.0-eksbuild.1 以降 | | AWS Secrets Store CSI Driver プロバイダー | v2.1.1-eksbuild.1 以降 | 以下のコミュニティアドオンは、Amazon EKS Hybrid Nodes と互換性があります。コミュニティアドオンの詳細については、「[コミュニティアドオン](community-addons.md)」を参照してください。 | コミュニティアドオン | 互換性のあるアドオンバージョン | | --- | --- | | Kubernetes メトリクスサーバー | v0.7.2-eksbuild.1 以降 | | cert-manager | v1.17.2-eksbuild.1 以降 | | Prometheus Node Exporter | v1.9.1-eksbuild.2 以降 | | kube-state-metrics | v2.15.0-eksbuild.4 以降 | | 外部 DNS | v0.19.0-eksbuild.1 以降 | 上記の表の Amazon EKS アドオンに加えて、[Amazon Managed Service for Prometheus コレクター](prometheus.md)、および[アプリケーションイングレス](alb-ingress.md) (HTTP) および[ロードバランシング](network-load-balancing.md) (TCP/UDP) 用の [AWS ロードバランサーコントローラー](aws-load-balancer-controller.md)はハイブリッドノードと互換性があります。 AWS アドオンとコミュニティアドオンには、Amazon EKS Hybrid Nodes と互換性のないものがあります。こうしたアドオンの最新バージョンには、デフォルトの `eks.amazonaws.com/compute-type: hybrid` ラベルをハイブリッドノードに適用するにあたってアンチアフィニティルールがあります。これにより、クラスターにデプロイされたときにハイブリッドノードで実行されるのが防止されます。ハイブリッドノードと AWS クラウドで実行されているノードの両方を備えたクラスターがある場合、クラスター内のこれらのアドオンを AWS クラウドで実行されているノードにデプロイできます。Amazon VPC CNI はハイブリッドノードと互換性がなく、Cilium と Calico は Amazon EKS Hybrid Nodes のコンテナネットワークインターフェイス (CNI としてサポートされています。詳細については「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」を参照してください。 ## AWSアドオン 以降のセクションでは、ハイブリッドノード上の互換性のある AWS アドオンを実行する場合と、他の Amazon EKS コンピューティングタイプで同じアドオンを実行する場合の違いについて説明します。 ## kube-proxy と CoreDNS AWS CLI によるものも含め AWS API と AWS SDK で EKS クラスターを作成すると、EKS はデフォルトで kube-proxy と CoreDNS をセルフマネージドアドオンとしてインストールします。こうしたアドオンは、クラスターの作成後に Amazon EKS アドオンで上書きできます。[Amazon EKS クラスターで `kube-proxy` を管理する](managing-kube-proxy.md) および [Amazon EKS クラスターで DNS の CoreDNS を管理する](managing-coredns.md) の詳細についてはEKS ドキュメントを参照してください。ハイブリッドノードと AWS クラウド内のノードの両方がある混合モードのクラスターを実行している場合、AWS ではハイブリッドノードに少なくとも 1 つの CoreDNS レプリカがあり、AWS クラウド内のノードに少なくとも 1 つの CoreDNS レプリカがあるようにすることをお勧めします。設定手順については、「[CoreDNS レプリカを設定する](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-coredns)」を参照してください。 ## CloudWatch Observability エージェント CloudWatch Observability エージェントオペレーターは、[ウェブフック](https://kubernetes.io/docs/reference/access-authn-authz/webhook/)を使用します。ハイブリッドノードでオペレーターを実行する場合は、オンプレミスネットワークでオンプレミスポッド CIDR をルーティングし、リモートポッドネットワークで EKS クラスターを設定する必要があります。詳細については、「[Configure webhooks for hybrid nodes](hybrid-nodes-webhooks.md)」を参照してください。 ノードレベルのメトリクスは[クラウドコンテナインサイトを見る](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) がノードレベルのメトリクスに関して[インスタンスメタデータサービス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) (IMDS の可用性に依存するため、ハイブリッドノードでは利用できません。クラスター、ワークロード、ポッド、コンテナレベルのメトリクスはハイブリッドノードで利用できます。 「[Amazon CloudWatch オベサビリティ を使用して Amazon CloudWatch エージェントをインストールする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html)」で説明されているステップに従ってアドオンをインストールした後、エージェントがハイブリッドノードで正常に実行できるようにするにはアドオンマニフェストを更新する必要があります。以下に示すように、クラスターの `amazoncloudwatchagents` リソースを編集して `RUN_WITH_IRSA` 環境変数を追加します。 ``` kubectl edit amazoncloudwatchagents -n amazon-cloudwatch cloudwatch-agent ``` ``` apiVersion: v1 items: - apiVersion: cloudwatch.aws.amazon.com/v1alpha1 kind: AmazonCloudWatchAgent metadata: ... name: cloudwatch-agent namespace: amazon-cloudwatch ... spec: ... env: - name: RUN_WITH_IRSA # <-- Add this value: "True" # <-- Add this - name: K8S_NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName ... ``` ## Amazon Managed Prometheus ハイブリッドノード用マネージドコレクター Amazon Managed Service for Prometheus (AMP) マネージドコレクターは Amazon EKS クラスター内のリソースからメトリクスを検出して収集するスクレイパーで構成されています。AMP はスクレイパーを自動的に管理するため、インスタンス、エージェント、スクレイパーをユーザーが管理する必要はありません。 AMP マネージドコレクターはハイブリッドノードに固有の追加設定を行わなくても使用できます。ただし、VPC からリモートポッドネットワーク CIDR へのルートや、オンプレミスファイアウォールで開いているポートなど、ハイブリッドノード上のアプリケーションのメトリクスエンドポイントが VPC から到達可能である必要があります。さらに、クラスターには[プライベートクラスターエンドポイントアクセス](cluster-endpoint.md)が必要です。 「Amazon Managed Service for Prometheus ユーザーガイド」の「[AWS マネージドコレクターの使用](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html)」のステップに従います。 ## AWS オープンテレメトリー用ディストリビューター (ADOT) AWS Distro for OpenTelemetry (ADOT) アドオンを使用して、ハイブリッドノードで実行されているアプリケーションからメトリクス、ログ、トレースデータを収集できます。ADOT は、Collector Custom Resource リクエストの変更と検証にアドミッション[ウェブフック](https://kubernetes.io/docs/reference/access-authn-authz/webhook/)を使用します。ハイブリッドノードで ADOT オペレーターを実行する場合は、オンプレミスネットワークでオンプレミスポッド CIDR をルーティングし、リモートポッドネットワークで EKS クラスターを設定する必要があります。詳細については、「[Configure webhooks for hybrid nodes](hybrid-nodes-webhooks.md)」を参照してください。 *AWS オープンテレメトリー用ディストリビューター* ドキュメントの「[EKS アドオンを使用した AWSオープンテレメトリー用ディストリビューター の開始方法](https://aws-otel.github.io/docs/getting-started/adot-eks-add-on)」のステップに従ってください。 ## AWS ロードバランサーコントローラー ハイブリッドノード上のワークロードのターゲットタイプが `ip` の場合、[AWS Load Balancer Controller](aws-load-balancer-controller.md) を Application Load Balancer (ALB) や Network Load Balancer (NLB) と共に使用できます。ALB または NLB で使用される IP ターゲットは、AWS からルーティング可能である必要があります。AWS Load Balancer Controller も、[ウェブフック](https://kubernetes.io/docs/reference/access-authn-authz/webhook/)を使用します。ハイブリッドノードで AWS Load Balancer Controller オペレーターを実行する場合は、オンプレミスネットワークでオンプレミスポッド CIDR をルーティングし、リモートポッドネットワークで EKS クラスターを設定する必要があります。詳細については、「[Configure webhooks for hybrid nodes](hybrid-nodes-webhooks.md)」を参照してください。 AWS ロードバランサーコントローラー をインストールするには「[AWS Application Load Balancer](hybrid-nodes-ingress.md#hybrid-nodes-ingress-alb)」または「[AWS Network Load Balancer](hybrid-nodes-load-balancing.md#hybrid-nodes-service-lb-nlb)」のステップに従います。 ALB でイングレスを使用する場合は以下の注釈を指定する必要があります。詳細については「[Application Load Balancer を使用してアプリケーションと HTTP トラフィックをルーティングする](alb-ingress.md)」を参照してください。 ``` alb.ingress.kubernetes.io/target-type: ip ``` NLB で負荷分散を使用する場合は以下の注釈を指定する必要があります。詳細については「[Network Load Balancer を使用して TCP および UDP トラフィックをルーティングする](network-load-balancing.md)」を参照してください。 ``` service.beta.kubernetes.io/aws-load-balancer-type: "external" service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip" ``` ## EKS Pod Identity エージェント **注記** Bottlerocket を実行しているハイブリッドノードに EKS Pod Identity Agent アドオンを正常にデプロイするには、Bottlerocket のバージョンが v1.39.0 以上であることを確認します。Pod Identity エージェントのハイブリッドノード環境では、以前の Bottlerocket バージョンがサポートされていません。 元の Amazon EKS Pod Identity エージェント DaemonSet は必要な AWS 認証情報を取得するために、ノードの EC2 IMDS を利用します。IMDS はハイブリッドノードでは使用できないため、バージョン 1.3.3-eksbuild.1 以降では必要に応じて Pod Identity Agent アドオンに必要な認証情報をマウントする DaemonSet がデプロイされます。Bottlerocket を実行するハイブリッドノードでは、認証情報をマウントするために別の方法が必要です。バージョン 1.3.7-eksbuild.2 以降では、必要に応じて Pod Identity Agent アドオンに Bottlerocket ハイブリッドノードを対象とする専用の DaemonSet がデプロイされます。以下のセクションでは、オプションの DaemonSet を有効にするプロセスについて説明します。 ### Ubuntu/RHEL/AL2023 1. Ubuntu/RHEL/Al2023 ハイブリッドノードで Pod Identity エージェントを使用するには、以下に示すように `nodeadm` 設定のハイブリッドセクションで `enableCredentialsFile: true` を設定します。 ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: hybrid: enableCredentialsFile: true # <-- Add this ``` これにより、`eks-pod-identity-agent` ポッドで使用される認証情報ファイルをノード上の `/eks-hybrid/.aws/credentials` に作成するように `nodeadm` が設定されます。この認証情報ファイルには定期的に更新される一時的な AWS 認証情報が含まれます。 1. *各*ノードの `nodeadm` 設定を更新したら、`nodeConfig.yaml` で以下の `nodeadm init` コマンドを実行して、ハイブリッドノードを Amazon EKS クラスターに結合します。ノードが以前にクラスターに参加していた場合でも、`nodeadm init` コマンドを再度実行してください。 ``` nodeadm init -c file://nodeConfig.yaml ``` 1. AWS CLI または AWS マネジメントコンソール のいずれかを使用し、ハイブリッドノードのサポートを有効にして `eks-pod-identity-agent` をインストールします。 1. AWS CLI: クラスターの管理に使用しているマシンから以下のコマンドを実行して、ハイブリッドノードのサポートを有効にして `eks-pod-identity-agent` をインストールします。`my-cluster` を自分のクラスター名に置き換えます。 ``` aws eks create-addon \ --cluster-name my-cluster \ --addon-name eks-pod-identity-agent \ --configuration-values '{"daemonsets":{"hybrid":{"create": true}}}' ``` 1. AWS マネジメントコンソール: AWS コンソールから Pod Identity Agent アドオンをインストールする場合は、オプションの設定に以下を追加して、ハイブリッドノードを対象とする DaemonSet をデプロイします。 ``` {"daemonsets":{"hybrid":{"create": true}}} ``` ### Bottlerocket 1. Bottlerocket ハイブリッドノードで Pod Identity エージェントを使用するには、「[Bottlerocket を実行しているハイブリッドノードの接続](hybrid-nodes-bottlerocket.md)」で説明されているように、Bottlerocket ブートストラップコンテナのユーザーデータに使用されるコマンドに `--enable-credentials-file=true` フラグを追加します。 1. SSM 認証情報プロバイダーを使用している場合、コマンドは次のようになります。 ``` eks-hybrid-ssm-setup --activation-id= --activation-code= --region= --enable-credentials-file=true ``` 1. IAM Roles Anywhere 認証情報プロバイダーを使用している場合、コマンドは次のようになります。 ``` eks-hybrid-iam-ra-setup --certificate= --key= --enable-credentials-file=true ``` これによりブートストラップスクリプトが設定され、`/var/eks-hybrid/.aws/credentials` で `eks-pod-identity-agent` ポッドで使用される認証情報ファイルがノード上に作成されます。この認証情報ファイルには定期的に更新される一時的な AWS 認証情報が含まれます。 1. AWS CLI または AWS マネジメントコンソール のいずれかを使用し、Bottlerocket ハイブリッドノードのサポートを有効にして `eks-pod-identity-agent` をインストールします。 1. AWS CLI: クラスターの管理に使用しているマシンから、以下のコマンドを実行して `eks-pod-identity-agent` をインストールし、Bottlerocket ハイブリッドノードのサポートを有効にします。`my-cluster` を自分のクラスター名に置き換えます。 ``` aws eks create-addon \ --cluster-name my-cluster \ --addon-name eks-pod-identity-agent \ --configuration-values '{"daemonsets":{"hybrid-bottlerocket":{"create": true}}}' ``` 1. AWS マネジメントコンソール: AWS コンソールから Pod Identity Agent アドオンをインストールする場合は、オプションの設定に以下を追加して、Bottlerocket ハイブリッドノードを対象とする DaemonSet をデプロイします。 ``` {"daemonsets":{"hybrid-bottlerocket":{"create": true}}} ``` ## CSI スナップショットコントローラー バージョン `v8.1.0-eksbuild.2` 以降、[CSI スナップショットコントローラーアドオン](csi-snapshot-controller.md)はハイブリッドノードにソフトアンチアフィニティルールを適用し、コントローラーの `deployment` を Amazon EKS コントロールプレーンと同じ AWS リージョンの EC2 で実行することを優先します。`deployment` を Amazon EKS コントロールプレーンと同じ AWS リージョンに配置することで、レイテンシーが改善されます。 ## コミュニティアドオン 以降のセクションでは、ハイブリッドノード上の互換性のあるコミュニティアドオンを実行する場合と、他の Amazon EKS コンピューティングタイプで同じアドオンを実行する場合の違いについて説明します。 ## Kubernetes メトリクスサーバー コントロールプレーンは、Metrics Server のポッド IP (あるいは hostNetwork が有効になっている場合にはノード IP) に到達しなければなりません。このため、hostNetwork モードで Metrics Server を実行しない限り、Amazon EKS クラスターを作成するときにリモートポッドネットワークを設定し、ポッド IP アドレスをルーティング可能にする必要があります。ポッド IP アドレスをルーティング可能にする場合によく使用される方法の 1 つに、CNI でボーダーゲートウェイプロトコル (BGP) を実装することがあります。 ## cert-manager `cert-manager` は[ウェブフック](https://kubernetes.io/docs/reference/access-authn-authz/webhook/)を使用します。ハイブリッドノードで `cert-manager` を実行する場合は、オンプレミスネットワークでオンプレミスポッド CIDR をルーティングし、リモートポッドネットワークで EKS クラスターを設定する必要があります。詳細については、「[Configure webhooks for hybrid nodes](hybrid-nodes-webhooks.md)」を参照してください。 # ハイブリッドノード用のウェブフックを設定する このページでは、ハイブリッドノードでウェブフックを実行する場合の考慮事項について詳しく説明します。ウェブフックは、AWS Load Balancer Controller や CloudWatch Observability エージェントといった Kubernetes アプリケーションとオープンソースプロジェクトで実行時にミューテーション機能と検証機能を利用する目的で使用されます。 **ルーティング可能なポッドネットワーク** オンプレミスネットワークでオンプレミスポッド CIDR をルーティング可能にできる場合、ハイブリッドノードでウェブフックを実行できます。オンプレミスネットワークでオンプレミスポッド CIDR をルーティング可能にするために使用できる手法がいくつかあります。具体的には、ボーダーゲートウェイプロトコル (BGP)、静的ルート、その他のカスタムルーティングソリューションなどです。BGP はカスタムまたは手動でルート設定する必要がある代替ソリューションよりもスケーラブルで管理しやすいため、推奨されるソリューションです。AWS は、ポッド CIDR をアドバタイズするための Cilium と Calico の BGP 機能をサポートしています。詳細については、「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」および「[ルーティング可能なリモートポッド CIDR](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs)」を参照してください。 **ルーティング不可能なポッドネットワーク** オンプレミスポッド CIDR をオンプレミスネットワークでルーティング可能にすることが*できず*、ウェブフックを実行する必要がある場合、すべてのウェブフックをハイブリッドノードと同じ EKS クラスターのクラウドノードで実行することが推奨されます。 ## 混合モードクラスターの考慮事項 *混合モードクラスター*は、ハイブリッドノードと AWS クラウドで実行中のノードの両方を備えた EKS クラスターであると定義されています。混合モードクラスターを実行する場合は、以下の推奨事項を検討してください。 + AWS Cloud 内のノードでは VPC CNI を実行し、ハイブリッドノードでは Cilium または Calico を実行します。AWS では、AWS Cloud 内のノードで Cilium と Calico を実行する操作はサポートされていません。 + AWS Cloud 内のノードで動作するようにウェブフックを設定します。AWS およびコミュニティアドオンのウェブフックを設定する方法については、「[アドオン用のウェブフックを設定する](#hybrid-nodes-webhooks-add-ons)」を参照してください。 + アプリケーションの要件により AWS Cloud 内のノードで実行中のポッドがハイブリッドノードで実行中のポッドと直接通信 (「東西通信」) しなければならず、かつ AWS Cloud 内のノードでは VPC CNI が使用され、ハイブリッドノードでは Cilium または Calico が使用されている場合は、オンプレミスネットワークでオンプレミスポッド CIDR がルーティング可能である必要があります。 + AWS クラウドのノードで少なくとも 1 つの CoreDNS レプリカを実行し、ハイブリッドノードで少なくとも 1 つの CoreDNS レプリカを実行してください。 + サービストラフィック分散を設定し、Service トラフィックを発信元のゾーン内に留めます。サービストラフィック分散の詳細については、「[サービストラフィック分散の設定](#hybrid-nodes-mixed-service-traffic-distribution)」を参照してください。 + ハイブリッドノードで実行されているワークロードトラフィックに AWS Application Load Balancer (ALB) または Network Load Balancer (NLB) を使用している場合、ALB または NLB と使用されている IP ターゲットを AWS からルーティング可能である必要があります。 + Metrics Server アドオンでは、EKS コントロールプレーンから Metrics Server ポッド IP アドレスへの接続が必要になります。ハイブリッドノードで Metrics Server アドオンを実行している場合は、オンプレミスネットワークでオンプレミスポッド CIDR をルーティングできる必要があります。 + Amazon Managed Service for Prometheus (AMP) マネージドコレクターを使用してハイブリッドノードに関するメトリクスを収集するには、オンプレミスネットワークでオンプレミスポッド CIDR をルーティングできる必要があります。または、EKS コントロールプレーンメトリクスおよび AWS クラウドで実行されているリソースに AMP マネージドコレクターを使用し、AWS Distro for OpenTelemetry (ADOT) アドオンを使用してハイブリッドノードのメトリクスを収集することもできます。 ## 混合モードクラスターの設定 クラスターで実行中のミューテーション用と検証用のウェブフックを表示するには、クラスターの EKS コンソールの **[リソース]** パネルで **[拡張機能]** リソースタイプを表示するか、以下のコマンドを使用します。EKS は、クラスターオブザーバビリティダッシュボードにウェブフックメトリクスもレポートします。詳細については、「[オブザーバビリティダッシュボードを使用してクラスターをモニタリングする](observability-dashboard.md)」を参照してください。 ``` kubectl get mutatingwebhookconfigurations ``` ``` kubectl get validatingwebhookconfigurations ``` ### サービストラフィック分散の設定 混合モードクラスターを実行する際、[https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution](https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution)を使用してサービストラフィックを発信元のゾーン内に留めることが推奨されます。サービストラフィック分散 (EKS では Kubernetes バージョン 1.31 以降で利用可能) は、[Topology Aware Routing](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/) よりも予測性に優れているため、推奨されるソリューションです。サービストラフィック分散を使用すると、ゾーン内の正常なエンドポイントはそのゾーンのすべてのトラフィックが受信されます。Topology Aware Routing を使用すると、カスタムルーティングを適用するために各サービスはそのゾーンの複数の条件を満たす必要があります。そうでない場合、トラフィックはすべてのエンドポイントに均等にルーティングされます。 Cilium を CNI として使用している場合は、`enable-service-topology` を `true` に設定して CNI を実行し、Service Traffic Distribution を有効にする必要があります。この設定は Helm インストールフラグ `--set loadBalancer.serviceTopology=true` で渡すことができます。あるいは、Cilium CLI コマンド `cilium config set enable-service-topology true` を使用して既存のインストールを更新することもできます。既存のインストールの設定を更新した場合は、その後に各ノードで実行されている Cilium エージェントを再起動する必要があります。 CoreDNS サービスにサービストラフィック分散を設定する方法の例は、次のセクションで示されています。意図しない環境間トラフィックを回避するには、クラスター内のすべてのサービスに同じ設定を有効にすることが推奨されます。 ### CoreDNS レプリカを設定する ハイブリッドノードと AWS クラウド内のノードの両方を備える混合モードのクラスターを実行している場合は、ハイブリッドノードと AWS クラウド内のノードのそれぞれに CoreDNS レプリカを 1 つ以上作成しておくことが推奨されます。混合モードクラスターの設定でレイテンシーとネットワークの問題を回避するには、[Service Traffic Distribution](https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution) を使って最も近くにある CoreDNS レプリカを優先するように CoreDNS サービスを設定します。 *Service Traffic Distribution* (EKS で Kubernetes バージョン 1.31 以降で使用可能) は、[Topology Aware Routing](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/) よりも予測性に優れているため、推奨される方法です。Service Traffic Distribution では、ゾーン内の正常なエンドポイントは、そのゾーンのすべてのトラフィックを受信します。Topology Aware Routing の場合、カスタムルーティングを適用するには各サービスがそのゾーンの複数の条件を満たしている必要があります。満たしていない場合、トラフィックはすべてのエンドポイントに均等にルーティングされます。以下のステップで、Service Traffic Distribution を設定していきます。 Cilium を CNI として使用している場合は、`enable-service-topology` を `true` に設定して CNI を実行し、Service Traffic Distribution を有効にする必要があります。この設定は Helm インストールフラグ `--set loadBalancer.serviceTopology=true` で渡すことができます。あるいは、Cilium CLI コマンド `cilium config set enable-service-topology true` を使用して既存のインストールを更新することもできます。既存のインストールの設定を更新した場合は、その後に各ノードで実行されている Cilium エージェントを再起動する必要があります。 1. ハイブリッドノードごとにトポロジゾーンラベルを追加します。例えば、`topology.kubernetes.io/zone: onprem` とします。または、`nodeadm` 設定でラベルを指定することで、`nodeadm init` フェーズのラベルを設定できます。「[kubelet をカスタマイズするためのノード設定 (オプション)](hybrid-nodes-nodeadm.md#hybrid-nodes-nodeadm-kubelet)」を参照してください。なお、AWS Cloud で実行されているノードは、自身のアベイラビリティーゾーン (AZ) に対応するトポロジゾーンラベルを自動的に適用します。 ``` kubectl label node hybrid-node-name topology.kubernetes.io/zone=zone ``` 1. トポロジゾーンキーを使用して `podAntiAffinity` を CoreDNS デプロイに追加します。または、EKS アドオンを使用してインストール時に CoreDNS デプロイを設定することもできます。 ``` kubectl edit deployment coredns -n kube-system ``` ``` spec: template: spec: affinity: ... podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: labelSelector: matchExpressions: - key: k8s-app operator: In values: - kube-dns topologyKey: kubernetes.io/hostname weight: 100 - podAffinityTerm: labelSelector: matchExpressions: - key: k8s-app operator: In values: - kube-dns topologyKey: topology.kubernetes.io/zone weight: 50 ... ``` 1. `trafficDistribution: PreferClose` 設定を `kube-dns` サービス設定に追加し、サービストラフィック分散を有効にします。 ``` kubectl patch svc kube-dns -n kube-system --type=merge -p '{ "spec": { "trafficDistribution": "PreferClose" } }' ``` 1. `kube-dns` サービスのエンドポイントスライスを表示することで、Service Traffic Distribution が有効になっていることを確認できます。エンドポイントスライスにはトポロジーゾーンのラベルの `hints` が表示されているはずです。これで、Service Traffic Distribution が有効になっていることが確認できます。各エンドポイントアドレスの `hints` が表示されなければ、Service Traffic Distribution は有効になっていません。 ``` kubectl get endpointslice -A | grep "kube-dns" ``` ``` kubectl get endpointslice [.replaceable]`kube-dns-` -n kube-system -o yaml ``` ``` addressType: IPv4 apiVersion: discovery.k8s.io/v1 endpoints: - addresses: - hints: forZones: - name: onprem nodeName: zone: onprem - addresses: - hints: forZones: - name: us-west-2a nodeName: zone: us-west-2a ``` ### アドオン用のウェブフックを設定する 以下のアドオンは、ウェブフックを使用しており、ハイブリッドノードでの使用がサポートされています。 + AWS ロードバランサーコントローラー + Amazon CloudWatch オベサビリティ エージェント + AWS オープンテレメトリー用ディストリビューター (ADOT) + `cert-manager` これらのアドオンで使用されるウェブフックを AWS クラウド内のノードで実行するように設定する方法については、以下のセクションを参照してください。 #### AWS ロードバランサーコントローラー AWS Load Balancer Controller を混合モードクラスターの設定で使用するには、このコントローラーを AWS クラウドのノードで実行する必要があります。それには、Helm 値の設定に以下を追加するか、EKS アドオン設定を使用して値を指定します。 ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` #### Amazon CloudWatch オベサビリティ エージェント CloudWatch Observability Agent アドオンには、ウェブフックを使用する Kubernetes Operator があります。混合モードクラスター設定の AWS Cloud 内のノードでオペレーターを実行するには、CloudWatch Observability エージェントオペレーター設定を編集します。インストール時に Helm と EKS アドオンを使用してオペレーターアフィニティを設定することはできません (「[containers-roadmap issue \$12431](https://github.com/aws/containers-roadmap/issues/2431)」を参照のこと)。 ``` kubectl edit -n amazon-cloudwatch deployment amazon-cloudwatch-observability-controller-manager ``` ``` spec: ... template: ... spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` #### AWS オープンテレメトリー用ディストリビューター (ADOT) AWS Distro for OpenTelemetry (ADOT) アドオンには、ウェブフックを使用する Kubernetes Operator があります。混合モードクラスター設定の AWS クラウド内のノードでオペレーターを実行するには、Helm 値設定に以下を追加するか、EKS アドオン設定を使用して値を指定します。 ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` ポッド CIDR をオンプレミスネットワークでルーティングできない場合は、ADOT コレクターをハイブリッドノードで実行して、ハイブリッドノードとそこで実行されているワークロードからメトリクスをスクレイピングする必要があります。これを行うには、カスタムリソース定義 (CRD) を編集します。 ``` kubectl -n opentelemetry-operator-system edit opentelemetrycollectors.opentelemetry.io adot-col-prom-metrics ``` ``` spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid ``` ADOT コレクター CRD 設定で各 `scrape_configs` に以下の `relabel_configs` を追加することで、ハイブリッドノードとそこで実行されているリソースからのみメトリクスをスクレイピングするように ADOT コレクターを設定できます。 ``` relabel_configs: - action: keep regex: hybrid source_labels: - __meta_kubernetes_node_label_eks_amazonaws_com_compute_type ``` ADOT アドオンには、ADOT オペレーターウェブフックで使用される TLS 証明書に `cert-manager` をインストールするための前提条件があります。`cert-manager` はウェブフックも実行し、次の Helm 値設定を使用して AWS クラウドのノードで実行するように設定することができます。 ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid webhook: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid cainjector: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid startupapicheck: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` #### `cert-manager` `cert-manager` アドオンは、ウェブフックを実行し、以下の Helm 値設定を使用して AWS クラウド内のノードで実行するように設定することができます。 ``` affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid webhook: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid cainjector: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid startupapicheck: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: NotIn values: - hybrid ``` # ハイブリッドノードのプロキシを設定する オンプレミス環境でデータセンターまたはエッジ環境から出ていくトラフィックにプロキシサーバーを使用している場合は、プロキシサーバーを使用するように個別にノードとクラスターを設定する必要があります。 クラスター クラスターでは、プロキシサーバーを使用するように `kube-proxy` を設定する必要があります。Amazon EKS クラスターの作成後に `kube-proxy` を設定する必要があります。 ノード ノードでは、プロキシサーバーを使用するようにオペレーティングシステム、`containerd`、`kubelet`、Amazon SSM エージェントを設定する必要があります。こうした変更は、オペレーティングシステムイメージのビルドプロセス中に加えることも、各ハイブリッドノードで `nodeadm init` を実行する前に加えることもできます。 ## ノードレベルの設定 以下の設定は、オペレーティングシステムイメージに適用するか、各ハイブリッドノードで `nodeadm init` を実行する前に適用する必要があります。 ### `containerd` プロキシ設定 `containerd` は、Kubernetes のデフォルトのコンテナ管理ランタイムです。インターネットアクセスにプロキシを使用している場合は、Kubernetes と Amazon EKS に必要なコンテナイメージをプルできるように `containerd` を設定する必要があります。 次の内容で、各ハイブリッドノード上の `/etc/systemd/system/containerd.service.d` ディレクトリに「`http-proxy.conf`」という名前のファイルを作成します。`proxy-domain` および `port` を環境の値で置き換えます。 ``` [Service] Environment="HTTP_PROXY=http://proxy-domain:port" Environment="HTTPS_PROXY=http://proxy-domain:port" Environment="NO_PROXY=localhost" ``` #### ユーザーデータからの `containerd` 設定 このファイル用に `containerd.service.d` ディレクトリを作成する必要があります。systemd を再ロードして設定ファイルを選択すると、再起動しなくても済むようになります。AL2023 では、スクリプトを実行した時点で既にサービスが実行されている可能性があります。その場合は再起動も必要です。 ``` mkdir -p /etc/systemd/system/containerd.service.d echo '[Service]' > /etc/systemd/system/containerd.service.d/http-proxy.conf echo 'Environment="HTTP_PROXY=http://proxy-domain:port"' >> /etc/systemd/system/containerd.service.d/http-proxy.conf echo 'Environment="HTTPS_PROXY=http://proxy-domain:port"' >> /etc/systemd/system/containerd.service.d/http-proxy.conf echo 'Environment="NO_PROXY=localhost"' >> /etc/systemd/system/containerd.service.d/http-proxy.conf systemctl daemon-reload systemctl restart containerd ``` ### `kubelet` プロキシ設定 `kubelet` は、各 Kubernetes ノードで実行される Kubernetes ノードエージェントであり、そのノードで実行されているノードとポッドの管理を担当します。オンプレミス環境でプロキシを使用している場合は、Amazon EKS クラスターのパブリックエンドポイントまたはプライベートエンドポイントと通信できるように `kubelet` を設定する必要があります。 次の内容で、各ハイブリッドノードの `/etc/systemd/system/kubelet.service.d/` ディレクトリに「`http-proxy.conf`」という名前のファイルを作成します。`proxy-domain` および `port` を環境の値で置き換えます。 ``` [Service] Environment="HTTP_PROXY=http://proxy-domain:port" Environment="HTTPS_PROXY=http://proxy-domain:port" Environment="NO_PROXY=localhost" ``` #### ユーザーデータからの `kubelet` 設定 このファイル用に `kubelet.service.d` ディレクトリを作成する必要があります。systemd を再ロードして設定ファイルを選択すると、再起動しなくても済むようになります。AL2023 では、スクリプトを実行した時点で既にサービスが実行されている可能性があります。その場合は再起動も必要です。 ``` mkdir -p /etc/systemd/system/kubelet.service.d echo '[Service]' > /etc/systemd/system/kubelet.service.d/http-proxy.conf echo 'Environment="HTTP_PROXY=http://proxy-domain:port"' >> /etc/systemd/system/kubelet.service.d/http-proxy.conf echo 'Environment="HTTPS_PROXY=http://proxy-domain:port"' >> /etc/systemd/system/kubelet.service.d/http-proxy.conf echo 'Environment="NO_PROXY=localhost"' >> /etc/systemd/system/kubelet.service.d/http-proxy.conf systemctl daemon-reload systemctl restart kubelet ``` ### `ssm` プロキシ設定 `ssm` は認証情報プロバイダーの 1 つであり、これを使用するとハイブリッドノードを初期化できます。`ssm` は、AWS での認証を実施し、`kubelet` によって使用される一時的な認証情報を生成します。オンプレミス環境でプロキシを使用し、ノードで `ssm` を認証情報プロバイダーとして使用している場合は、Amazon SSM サービスエンドポイントと通信できるように `ssm` を設定する必要があります。 オペレーティングシステムに応じて、各ハイブリッドノードに `http-proxy.conf` という名前でファイルを以下のパスに作成します。 + Ubuntu - `/etc/systemd/system/snap.amazon-ssm-agent.amazon-ssm-agent.service.d/http-proxy.conf` + Amazon Linux 2023 および Red Hat Enterprise Linux - `/etc/systemd/system/amazon-ssm-agent.service.d/http-proxy.conf` ファイルには次の内容を入力します。`proxy-domain` および `port` を環境の値で置き換えます。 ``` [Service] Environment="HTTP_PROXY=http://proxy-domain:port" Environment="HTTPS_PROXY=http://proxy-domain:port" Environment="NO_PROXY=localhost" ``` #### ユーザーデータからの `ssm` 設定 このファイル用に `ssm` システムサービスファイルディレクトリを作成する必要があります。ディレクトリパスは、ノードで使用されているオペレーティングシステムによって異なります。 + Ubuntu - `/etc/systemd/system/snap.amazon-ssm-agent.amazon-ssm-agent.service.d` + Amazon Linux 2023 および Red Hat Enterprise Linux - `/etc/systemd/system/amazon-ssm-agent.service.d` ノードで使用されているオペレーティングシステムに応じて、以下の restart コマンドの systemd サービス名を置き換えます。 + Ubuntu - `snap.amazon-ssm-agent.amazon-ssm-agent` + Amazon Linux 2023 および Red Hat Enterprise Linux - `amazon-ssm-agent` ``` mkdir -p systemd-service-file-directory echo '[Service]' > [.replaceable]#systemd-service-file-directory/http-proxy.conf echo 'Environment="HTTP_PROXY=http://[.replaceable]#proxy-domain:port"' >> systemd-service-file-directory/http-proxy.conf echo 'Environment="HTTPS_PROXY=http://[.replaceable]#proxy-domain:port"' >> [.replaceable]#systemd-service-file-directory/http-proxy.conf echo 'Environment="NO_PROXY=localhost"' >> [.replaceable]#systemd-service-file-directory/http-proxy.conf systemctl daemon-reload systemctl restart [.replaceable]#systemd-service-name ``` ### オペレーティングシステムのプロキシ設定 インターネットアクセスにプロキシを使用している場合は、オペレーティングシステムのパッケージマネージャーからハイブリッドノードの依存関係をプルできるようにオペレーティングシステムを設定する必要があります。 **Ubuntu** 1. 次のコマンドでプロキシを使用するように `snap` を設定します。 ``` sudo snap set system proxy.https=http://proxy-domain:port sudo snap set system proxy.http=http://proxy-domain:port ``` 1. `apt` のプロキシを有効にするには、`/etc/apt/` ディレクトリに `apt.conf` という名前のファイルを作成します。proxy-domain と port を環境の値に置き換えます。 ``` Acquire::http::Proxy "http://proxy-domain:port"; Acquire::https::Proxy "http://proxy-domain:port"; ``` **Amazon Linux 2023** 1. プロキシを使用するように `dnf` を設定します。環境のプロキシドメイン値とポート値を使用してファイル `/etc/dnf/dnf.conf` を作成します。 ``` proxy=http://proxy-domain:port ``` **Red Hat Enterprise Linux** 1. プロキシを使用するように `yum` を設定します。環境のプロキシドメイン値とポート値を使用してファイル `/etc/yum.conf` を作成します。 ``` proxy=http://proxy-domain:port ``` ### IAM Roles Anywhere のプロキシ設定 IAM Roles Anywhere 認証情報プロバイダーサービスは、`enableCredentialsFile` フラグと共に IAM Roles Anywhere と使用する際に認証情報を更新する役割があります ([EKS Pod Identity エージェント](hybrid-nodes-add-ons.md#hybrid-nodes-add-ons-pod-id) を参照)。オンプレミス環境でプロキシを使用している場合は、IAM Roles Anywhere エンドポイントと通信できるようにサービスを設定する必要があります。 次の内容で、`/etc/systemd/system/aws_signing_helper_update.service.d/` ディレクトリに「`http-proxy.conf`」という名前のファイルを作成します。`proxy-domain` および `port` を環境の値で置き換えます。 ``` [Service] Environment="HTTP_PROXY=http://proxy-domain:port" Environment="HTTPS_PROXY=http://proxy-domain:port" Environment="NO_PROXY=localhost" ``` ## クラスター全体の設定 このセクションの設定は、Amazon EKS クラスターを作成した後、および各ハイブリッドノードで `nodeadm init` を実行する前に適用する必要があります。 ### kube-proxy のプロキシ設定 Amazon EKS は、ハイブリッドノードがクラスターに参加すると、各ハイブリッドノードに DaemonSet として自動的に `kube-proxy` をインストールします。`kube-proxy` は、Amazon EKS クラスターのポッドによってバックアップされるサービス間のルーティングを有効にします。各ホストを設定するために、`kube-proxy` には Amazon EKS クラスターエンドポイントの DNS 解決が必要です。 1. 次のコマンドを使用して `kube-proxy` DaemonSet を編集する ``` kubectl -n kube-system edit ds kube-proxy ``` これにより、設定されたエディタで `kube-proxy` DaemonSet 定義が開きます。 1. `HTTP_PROXY` および `HTTPS_PROXY` の環境変数を追加します。`NODE_NAME` 環境変数は設定に既に存在している必要があります。`proxy-domain` と `port` を環境の値に置き換えます。 ``` containers: - command: - kube-proxy - --v=2 - --config=/var/lib/kube-proxy-config/config - --hostname-override=$(NODE_NAME) env: - name: HTTP_PROXY value: http://proxy-domain:port - name: HTTPS_PROXY value: http://proxy-domain:port - name: NODE_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: spec.nodeName ``` # ハイブリッドノード向けに Cilium BGP を設定する このトピックでは、Amazon EKS Hybrid Nodes の Cilium ボーダーゲートウェイプロトコル (BGP) を設定する方法について説明します。Cilium の BGP は [Cilium BGP コントロールプレーン](https://docs.cilium.io/en/stable/network/bgp-control-plane/bgp-control-plane/)と呼ばれる機能で、この機能を使用すると、ポッドアドレスとサービスアドレスをオンプレミスネットワークにアドバタイズできます。これ以外にオンプレミスネットワークでポッド CIDR をルーティング可能にする方法については、「[ルーティング可能なリモートポッド CIDR](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs)」を参照してください。 ## Cilium BGP を設定する ### 前提条件 + 「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」の手順に従って Cilium がインストールされていること。 ### 手順 1. Cilium で BGP を使用してオンプレミスネットワークでポッドアドレスまたはサービスアドレスをアドバタイズするには、`bgpControlPlane.enabled: true` を使用して Cilium をインストールしている必要があります。既存の Cilium のデプロイで BGP を有効にする場合は、Cilium 演算子を再起動して BGP 設定を適用する必要があります (BGP が以前に有効になっていない場合)。Helm のインストール/アップグレードプロセスの一環として Cilium 演算子を再起動するには、Helm 値の `operator.rollOutPods` を `true` に設定します。 ``` helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \ --namespace kube-system \ --reuse-values \ --set operator.rollOutPods=true \ --set bgpControlPlane.enabled=true ``` 1. Cilium オペレーターとエージェントが再起動されて実行中であることを確認します。 ``` kubectl -n kube-system get pods --selector=app.kubernetes.io/part-of=cilium ``` ``` NAME READY STATUS RESTARTS AGE cilium-grwlc 1/1 Running 0 4m12s cilium-operator-68f7766967-5nnbl 1/1 Running 0 4m20s cilium-operator-68f7766967-7spfz 1/1 Running 0 4m20s cilium-pnxcv 1/1 Running 0 6m29s cilium-r7qkj 1/1 Running 0 4m12s cilium-wxhfn 1/1 Running 0 4m1s cilium-z7hlb 1/1 Running 0 6m30s ``` 1. `CiliumBGPClusterConfig` を定義したファイルを `cilium-bgp-cluster.yaml` という名前で作成します。ネットワーク管理者から次の情報を取得する必要が生じる場合があります。 + Cilium を実行しているノードの ASN を使用して、`localASN` を設定します。 + オンプレミスルーターの ASN を使用して、`peerASN` を設定します。 + Cilium を実行している各ノードがピアリングするオンプレミスルーター IP を使用して、`peerAddress` を設定します。 ``` apiVersion: cilium.io/v2alpha1 kind: CiliumBGPClusterConfig metadata: name: cilium-bgp spec: nodeSelector: matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid bgpInstances: - name: "rack0" localASN: NODES_ASN peers: - name: "onprem-router" peerASN: ONPREM_ROUTER_ASN peerAddress: ONPREM_ROUTER_IP peerConfigRef: name: "cilium-peer" ``` 1. Cilium BGP クラスター設定をクラスターに適用します。 ``` kubectl apply -f cilium-bgp-cluster.yaml ``` 1. `CiliumBGPPeerConfig` リソースを使用して BGP ピア設定を定義するファイルを `cilium-bgp-peer.yaml` という名前で作成します。複数のピアが同じ設定を共有し、共通の `CiliumBGPPeerConfig` リソースを参照することができます。設定オプションの完全なリストについては、Cilium のドキュメントの「[BGP Peer configuration](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane-v2/#bgp-peer-configuration)」を参照してください。 次の Cilium ピア設定の値は、ピアリング先のオンプレミスルーターの値と一致する必要があります。 + `holdTimeSeconds` では、BGP ピアがキープアライブメッセージまたは更新メッセージを待機する時間を設定します。この時間を過ぎると、セッションのダウンが宣言されます。デフォルト値は 90 秒です。 + `keepAliveTimeSeconds` では、BGP ピアが引き続き到達可能で、BGP セッションがアクティブかどうかを設定します。デフォルト値は 30 秒です。 + `restartTimeSeconds` では、Cilium の BGP コントロールプレーンが再起動後に BGP セッションを再確立するまでにかかると見込まれる時間を設定します。デフォルト値は 120 秒です。 ``` apiVersion: cilium.io/v2alpha1 kind: CiliumBGPPeerConfig metadata: name: cilium-peer spec: timers: holdTimeSeconds: 90 keepAliveTimeSeconds: 30 gracefulRestart: enabled: true restartTimeSeconds: 120 families: - afi: ipv4 safi: unicast advertisements: matchLabels: advertise: "bgp" ``` 1. Cilium BGP ピア設定をクラスターに適用します。 ``` kubectl apply -f cilium-bgp-peer.yaml ``` 1. `CiliumBGPAdvertisement` リソースを使用してポッド CIDR をオンプレミスネットワークにアドバタイズするファイルを `cilium-bgp-advertisement-pods.yaml` という名前で作成します。 + `CiliumBGPAdvertisement` リソースは、関連付けられるアドバタイズタイプと属性を定義するために使用されます。以下の例では、ポッド CIDR のみをアドバタイズするように Cilium を設定しています。サービスアドレスをアドバタイズするように Cilium を設定する方法の詳細については、「[サービスタイプ LoadBalancer](hybrid-nodes-ingress.md#hybrid-nodes-ingress-cilium-loadbalancer)」と「[Cilium クラスター内ロードバランシング](hybrid-nodes-load-balancing.md#hybrid-nodes-service-lb-cilium)」の例を参照してください。 + Cilium エージェントを実行している各ハイブリッドノードは、アップストリーム BGP 対応ルーターとピアリングします。以下の例のように、Cilium の `advertisementType` が `PodCIDR` に設定されていると、各ノードは所有するポッド CIDR 範囲をアドバタイズします。詳細については、Cilium のドキュメントの「[BGP Advertisements configuration](https://docs.cilium.io/en/stable/network/bgp-control-plane/bgp-control-plane-v2/#bgp-advertisements)」を参照してください。 ``` apiVersion: cilium.io/v2alpha1 kind: CiliumBGPAdvertisement metadata: name: bgp-advertisement-pods labels: advertise: bgp spec: advertisements: - advertisementType: "PodCIDR" ``` 1. Cilium BGP アドバタイズ設定をクラスターに適用します。 ``` kubectl apply -f cilium-bgp-advertisement-pods.yaml ``` 1. `cilium bgp peers` コマンドを使用して、BGP ピアリングが [Cilium CLI](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-the-cilium-cli) で機能していることを確認できます。出力には環境に応じた正しい値が表示され、セッションの状態が `established` と表示されているはずです。トラブルシューティングの詳細については「Cilium 資料」の「[トラブルシューティングおよび操作ガイド](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane/#troubleshooting-and-operation-guide)」を参照してください。 以下の例では、Cilium エージェントを実行しているハイブリッドノードが 5 つあり、各ノードが所有するポッド CIDR 範囲をアドバタイズしています。 ``` cilium bgp peers ``` ``` Node Local AS Peer AS Peer Address Session State Uptime Family Received Advertised mi-026d6a261e355fba7 NODES_ASN ONPREM_ROUTER_ASN ONPREM_ROUTER_IP established 1h18m58s ipv4/unicast 1 2 mi-082f73826a163626e NODES_ASN ONPREM_ROUTER_ASN ONPREM_ROUTER_IP established 1h19m12s ipv4/unicast 1 2 mi-09183e8a3d755abf6 NODES_ASN ONPREM_ROUTER_ASN ONPREM_ROUTER_IP established 1h18m47s ipv4/unicast 1 2 mi-0d78d815980ed202d NODES_ASN ONPREM_ROUTER_ASN ONPREM_ROUTER_IP established 1h19m12s ipv4/unicast 1 2 mi-0daa253999fe92daa NODES_ASN ONPREM_ROUTER_ASN ONPREM_ROUTER_IP established 1h18m58s ipv4/unicast 1 2 ``` ``` cilium bgp routes ``` ``` Node VRouter Prefix NextHop Age Attrs mi-026d6a261e355fba7 NODES_ASN 10.86.2.0/26 0.0.0.0 1h16m46s [{Origin: i} {Nexthop: 0.0.0.0}] mi-082f73826a163626e NODES_ASN 10.86.2.192/26 0.0.0.0 1h16m46s [{Origin: i} {Nexthop: 0.0.0.0}] mi-09183e8a3d755abf6 NODES_ASN 10.86.2.64/26 0.0.0.0 1h16m46s [{Origin: i} {Nexthop: 0.0.0.0}] mi-0d78d815980ed202d NODES_ASN 10.86.2.128/26 0.0.0.0 1h16m46s [{Origin: i} {Nexthop: 0.0.0.0}] mi-0daa253999fe92daa NODES_ASN 10.86.3.0/26 0.0.0.0 1h16m46s [{Origin: i} {Nexthop: 0.0.0.0}] ``` # ハイブリッドノード用に Kubernetes Ingress を設定する このトピックでは、Amazon EKS Hybrid Nodes で実行されているワークロード用に Kubernetes Ingress を設定する方法について説明します。[Kubernetes Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) は、クラスターの外部からクラスター内のサービスに至るまでの HTTP ルートと HTTPS ルートを公開します。Ingress リソースを利用するには、ネットワークトラフィックを処理するネットワークインフラストラクチャとネットワークコンポーネントをセットアップするために Kubernetes Ingress コントローラーが必要です。 AWS は、EKS Hybrid Nodes で実行されているワークロード向けに AWS Application Load Balancer (ALB) と Cilium for Kubernetes Ingress をサポートしています。Ingress に ALB を使用するか Cilium を使用するかは、アプリケーショントラフィックのソースに基づきます。アプリケーショントラフィックの発信元が AWS リージョンである場合、AWS では AWS ALB と AWS Load Balancer Controller の使用を推奨しています。アプリケーショントラフィックの発信元がローカルのオンプレミス環境またはエッジ環境である場合、AWS では Cilium に組み込みの Ingress 機能の使用を推奨しています。この機能は、お使いの環境にロードバランサーインフラストラクチャを搭載しているかどうかにかかわらず使用できます。 ![\[EKS Hybrid Nodes の Ingress\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/hybrid-nodes-ingress.png) ## AWS Application Load Balancer ハイブリッドノード上で実行されているワークロードのターゲットタイプが `ip` の場合、[AWS Load Balancer](aws-load-balancer-controller.md) と Application Load Balancer (ALB) を使用できます。ターゲットタイプ `ip` を使用している場合、ALB はトラフィックをポッドに直接転送して、Service レイヤーネットワークパスをバイパスします。ALB がハイブリッドノード上のポッド IP ターゲットに到達するためには、オンプレミスネットワークでオンプレミスポッド CIDR をルーティング可能である必要があります。また、AWS Load Balancer Controller はウェブフックを使用し、EKS コントロールプレーンからの直接通信が必要です。詳細については、「[ハイブリッドノード用のウェブフックを設定する](hybrid-nodes-webhooks.md)」を参照してください。 ### 考慮事項 + AWS Application Load Balancer と AWS Load Balancer Controller の詳細については、「[Application Load Balancer を使用してアプリケーションと HTTP トラフィックをルーティングする](alb-ingress.md)」と「[Helm による AWS Load Balancer Controller のインストール](lbc-helm.md)」を参照してください。 + AWS Application Load Balancer と AWS Network Load Balancer のどちらかを選択する方法については、「[Best Practices for Load Balancing](https://docs.aws.amazon.com/eks/latest/best-practices/load-balacing.html)」を参照してください。 + AWS Application Load Balancer で Ingress リソース用に設定できる注釈のリストについては、「[AWS Load Balancer Controller Ingress annotations](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/annotations/)」を参照してください。 ### 前提条件 + 「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」の手順に従って Cilium がインストールされていること。 + 「[ハイブリッドノード向けに Cilium BGP を設定する](hybrid-nodes-cilium-bgp.md)」の手順に従って Cilium BGP コントロールプレーンを有効にしていること。BGP を使用しない場合は、別の方法を使用して、オンプレミスネットワークでオンプレミスポッド CIDR をルーティング可能にする必要があります。オンプレミスポッド CIDR をルーティング可能にしないと、ALB はポッド IP ターゲットの登録も接続もできません。 + コマンドライン環境に Helm がインストールされていること。詳細については、「[Setup Helm instructions](helm.md)」を参照してください。 + コマンドライン環境に eksctl がインストールされていること。詳細については、「[eksctl install instructions](install-kubectl.md#eksctl-install-update)」を参照してください。 ### 手順 1. ユーザーに代わって AWS API を呼び出すことを許可する、AWS Load Balancer Controller 用の IAM ポリシーをダウンロードします。 ``` curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/refs/heads/main/docs/install/iam_policy.json ``` 1. 前のステップでダウンロードしたポリシー を使用して、IAM ポリシーを作成します。 ``` aws iam create-policy \ --policy-name AWSLoadBalancerControllerIAMPolicy \ --policy-document file://iam_policy.json ``` 1. クラスター名 (`CLUSTER_NAME`)、AWS リージョン (`AWS_REGION`)、AWS アカウント ID (`AWS_ACCOUNT_ID`) の各値を自分の設定値に置き換えて、次のコマンドを実行します。 ``` eksctl create iamserviceaccount \ --cluster=CLUSTER_NAME \ --namespace=kube-system \ --name=aws-load-balancer-controller \ --attach-policy-arn=arn:aws:iam::AWS_ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy \ --override-existing-serviceaccounts \ --region AWS_REGION \ --approve ``` 1. eks-charts Helm チャートリポジトリを追加し、ローカル Helm リポジトリを更新して、チャートを最新の状態にします。 ``` helm repo add eks https://aws.github.io/eks-charts ``` ``` helm repo update eks ``` 1. AWS Load Balancer コントローラをインストールします。クラスター名 (`CLUSTER_NAME`)、AWS リージョン (`AWS_REGION`)、VPC ID (`VPC_ID`)、AWS Load Balancer Controller Helm チャートバージョン (`AWS_LBC_HELM_VERSION`) の各値を自分の設定値に置き換えて、次のコマンドを実行します。ハイブリッドノードと AWS クラウド内のノードの両方を使用して混合モードクラスターを実行している場合は、「[AWS ロードバランサーコントローラー](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-lbc)」の手順に従ってクラウドノード上で AWS Load Balancer Controller を実行できます。 + Helm チャートの最新バージョンを確認するには、`helm search repo eks/aws-load-balancer-controller --versions` を実行します。 ``` helm install aws-load-balancer-controller eks/aws-load-balancer-controller \ -n kube-system \ --version AWS_LBC_HELM_VERSION \ --set clusterName=CLUSTER_NAME \ --set region=AWS_REGION \ --set vpcId=VPC_ID \ --set serviceAccount.create=false \ --set serviceAccount.name=aws-load-balancer-controller ``` 1. AWS Load Balancer Controller が正常にインストールされたことを確認します。 ``` kubectl get -n kube-system deployment aws-load-balancer-controller ``` ``` NAME READY UP-TO-DATE AVAILABLE AGE aws-load-balancer-controller 2/2 2 2 84s ``` 1. サンプルアプリケーションを作成します。以下の例では、[Istio Bookinfo](https://istio.io/latest/docs/examples/bookinfo/) サンプルマイクロサービスアプリケーションを使用しています。 ``` kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml ``` 1. 次の内容で、`my-ingress-alb.yaml` という名前のファイルを作成します。 ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress namespace: default annotations: alb.ingress.kubernetes.io/load-balancer-name: "my-ingress-alb" alb.ingress.kubernetes.io/target-type: "ip" alb.ingress.kubernetes.io/scheme: "internet-facing" alb.ingress.kubernetes.io/healthcheck-path: "/details/1" spec: ingressClassName: alb rules: - http: paths: - backend: service: name: details port: number: 9080 path: /details pathType: Prefix ``` 1. Ingress 設定をクラスターに適用します。 ``` kubectl apply -f my-ingress-alb.yaml ``` 1. Ingress リソース用に ALB をプロビジョニングするには、数分かかる場合があります。ALB がプロビジョニングされると、ALB デプロイの DNS 名に対応するアドレスが Ingress リソースに割り当てられます。アドレスの形式は `-..elb.amazonaws.com` です。 ``` kubectl get ingress my-ingress ``` ``` NAME CLASS HOSTS ADDRESS PORTS AGE my-ingress alb * my-ingress-alb-..elb.amazonaws.com 80 23m ``` 1. ALB のアドレスを使用して Service にアクセスします。 ``` curl -s http//my-ingress-alb-..elb.amazonaws.com:80/details/1 | jq ``` ``` { "id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890" "details": "This is the details page" } ``` ## Cilium Ingress および Cilium Gateway の概要 Cilium Ingress は、Cilium のアーキテクチャに組み込みの機能であり、Kubernetes Ingress API または Gateway API を使用して管理できます。既存の Ingress リソースがない場合、AWS では Gateway API から始めることを推奨しています。Kubernetes ネットワークリソースを柔軟かつ表現力豊かに定義および管理できるためです。[Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/) の目的は、Kubernetes クラスターに Ingress、Load Balancing、Service Mesh のネットワークリソースを定義および管理する方法を標準化することにあります。 Cilium の Ingress 機能または Gateway 機能を有効にすると、Cilium オペレーターがクラスター内の Ingress/Gateway オブジェクトを照合し、各ノードの Envoy プロキシがレイヤー 7 (L7) ネットワークトラフィックを処理します。Cilium は、ロードバランサーなどの Ingress/Gateway インフラストラクチャを直接にはプロビジョニングしません。ロードバランサーと共に Cilium Ingress/Gateway を使用する場合は、ロードバランサーのツール (通常は Ingress コントローラーや Gateway コントローラー) を使用して、ロードバランサーのインフラストラクチャをデプロイおよび管理する必要があります。 Ingress/Gateway トラフィックの場合、Cilium がコアネットワークトラフィックと L3/L4 ポリシー適用を処理し、統合 Envoy プロキシが L7 ネットワークトラフィックを処理します。Cilium Ingress/Gateway の場合、Envoy が L7 ルーティングルール、ポリシー、リクエスト操作の適用、高度なトラフィック管理 (トラフィックの分割やミラーリングなど)、TLS の終了と発信を行います。Cilium の Envoy プロキシは、デフォルトでは独立した DaemonSet (`cilium-envoy`) としてデプロイされます。これにより、Envoy と Cilium エージェントを個別に更新、スケール、管理できます。 Cilium Ingress と Cilium Gateway の仕組みの詳細については、Cilium のドキュメントの「[Cilium Ingress](https://docs.cilium.io/en/stable/network/servicemesh/ingress/)」ページと「[Cilium Gateway](https://docs.cilium.io/en/stable/network/servicemesh/gateway-api/gateway-api/)」ページを参照してください。 ## Cilium Ingress と Cilium Gateway の比較 以下の表に、Cilium **バージョン 1.17.x** の Cilium Ingress 機能と Cilium Gateway 機能をまとめます。 | 機能 | Ingress | ゲートウェイ | | --- | --- | --- | | サービスタイプ LoadBalancer | はい | あり | | サービスタイプ NodePort | あり | いいえ1 | | ホストネットワーク | はい | あり | | 共有ロードバランサー | はい | あり | | 専用ロードバランサー | あり | なし2 | | ネットワークポリシー | はい | あり | | プロトコル | レイヤー 7 (HTTP(S)、gRPC) | レイヤー 7 (HTTP(S)、gRPC)3 | | TLS パススルー | はい | あり | | トラフィック管理 | パスおよびホストのルーティング | パスおよびホストのルーティング、URL のリダイレクトと書き換え、トラフィックの分割、ヘッダーの変更 | 1 Cilium Gateway による NodePort サービスのサポートは、Cilium バージョン 1.18.x ([\$127273](https://github.com/cilium/cilium/pull/27273)) で予定されています 2 Cilium Gateway による専用ロードバランサーのサポート ([\$125567](https://github.com/cilium/cilium/issues/25567)) 3 Cilium Gateway による TCP/UDP のサポート ([\$121929](https://github.com/cilium/cilium/issues/21929)) ## Cilium Gateway をインストールする ### 考慮事項 + Cilium では、以下の例に示すように、`nodePort.enabled` を `true` に設定する必要があります。Cilium の kube-proxy 置換機能を使用している場合は、`nodePort.enabled` を `true` に設定する必要はありません。 + Cilium では、以下の例に示すように、`envoy.enabled` を `true` に設定する必要があります。 + Cilium Gateway は、ロードバランサーモード (デフォルト) またはホストネットワークモードでデプロイできます。 + Cilium Gateway をロードバランサーモードで使用する場合は、Gateway リソースに `service.beta.kubernetes.io/aws-load-balancer-type: "external"` 注釈を設定する必要があります。これにより、Cilium が Gateway リソース用にタイプ LoadBalancer の Service を作成する際に、レガシー AWS クラウドプロバイダーがその Service 用に Classic Load Balancer を作成しなくなります。 + Cilium Gateway をホストネットワークモードで使用する場合、タイプ LoadBalancer の Service は無効になります。ホストネットワークモードは、ロードバランサーインフラストラクチャがない環境に有用です。詳細については、「[ホストネットワーク](#hybrid-nodes-ingress-cilium-host-network)」を参照してください。 ### 前提条件 1. コマンドライン環境に Helm がインストールされていること。「[Setup Helm instructions](helm.md)」を参照してください。 1. 「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」の手順に従って Cilium がインストールされていること。 ### 手順 1. Kubernetes Gateway API カスタムリソース定義 (CRD) をインストールします。 ``` kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_gatewayclasses.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_gateways.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_referencegrants.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml ``` 1. `cilium-gateway-values.yaml` というファイルを次の内容で作成します。以下の例では、デフォルトのロードバランサーモードを使用するように Cilium Gateway を設定しています。また、Envoy プロキシをハイブリッドノードでのみ実行するように設定している場合には、そのプロキシに別の `cilium-envoy` DaemonSet を使用するように設定しています。 ``` gatewayAPI: enabled: true # uncomment to use host network mode # hostNetwork: # enabled: true nodePort: enabled: true envoy: enabled: true affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid ``` 1. Helm 値ファイルをクラスターに適用します。 ``` helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \ --namespace kube-system \ --reuse-values \ --set operator.rollOutPods=true \ --values cilium-gateway-values.yaml ``` 1. Cilium オペレーター、エージェント、Envoy ポッドが動作していることを確認します。 ``` kubectl -n kube-system get pods --selector=app.kubernetes.io/part-of=cilium ``` ``` NAME READY STATUS RESTARTS AGE cilium-envoy-5pgnd 1/1 Running 0 6m31s cilium-envoy-6fhg4 1/1 Running 0 6m30s cilium-envoy-jskrk 1/1 Running 0 6m30s cilium-envoy-k2xtb 1/1 Running 0 6m31s cilium-envoy-w5s9j 1/1 Running 0 6m31s cilium-grwlc 1/1 Running 0 4m12s cilium-operator-68f7766967-5nnbl 1/1 Running 0 4m20s cilium-operator-68f7766967-7spfz 1/1 Running 0 4m20s cilium-pnxcv 1/1 Running 0 6m29s cilium-r7qkj 1/1 Running 0 4m12s cilium-wxhfn 1/1 Running 0 4m1s cilium-z7hlb 1/1 Running 0 6m30s ``` ## Cilium Gateway を設定する Cilium Gateway を Gateway オブジェクトで有効にするには、`gatewayClassName` を `cilium` に設定します。Cilium が Gateway リソース用に作成する Service を設定するには、Gateway オブジェクトの各種フィールドを使用します。ロードバランサーインフラストラクチャを設定するために Gateway コントローラーでよく使用される注釈を設定するには、Gateway オブジェクトの `infrastructure` フィールドを使用します。Cilium の LoadBalancer IPAM を使用する場合(「[サービスタイプ LoadBalancer](#hybrid-nodes-ingress-cilium-loadbalancer)」の例を参照)に、タイプ LoadBalancer の Service に使用する IP アドレスを設定するには、Gateway オブジェクトの `addresses` フィールドを使用します。Gateway 設定の詳細については、「[Kubernetes Gateway API specification](https://gateway-api.sigs.k8s.io/reference/spec/#gateway)」を参照してください。 ``` apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: my-gateway spec: gatewayClassName: cilium infrastructure: annotations: service.beta.kubernetes.io/... service.kuberentes.io/... addresses: - type: IPAddress value: listeners: ... ``` Cilium と Kubernetes Gateway の仕様では、GatewayClass、Gateway、HTTPRoute、GRPCRoute、ReferenceGrant の各リソースがサポートされています。 + 使用可能なフィールドのリストについては、「[HTTPRoute](https://gateway-api.sigs.k8s.io/api-types/httproute/HTTPRoute)」と「[GRPCRoute](https://gateway-api.sigs.k8s.io/api-types/grpcroute/GRPCRoute)」の仕様を参照してください。 + これらのリソースの使用と設定方法については、以下の「[Cilium Gateway をデプロイする](#hybrid-nodes-ingress-cilium-gateway-deploy)」セクションの例と[Cilium のドキュメント](https://docs.cilium.io/en/stable/network/servicemesh/gateway-api/gateway-api/#examples)の例を参照してください。 ## Cilium Gateway をデプロイする 1. サンプルアプリケーションを作成します。以下の例では、[Istio Bookinfo](https://istio.io/latest/docs/examples/bookinfo/) サンプルマイクロサービスアプリケーションを使用しています。 ``` kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml ``` 1. アプリケーションが正常に動作していることを確認します。 ``` kubectl get pods ``` ``` NAME READY STATUS RESTARTS AGE details-v1-766844796b-9965p 1/1 Running 0 81s productpage-v1-54bb874995-jmc8j 1/1 Running 0 80s ratings-v1-5dc79b6bcd-smzxz 1/1 Running 0 80s reviews-v1-598b896c9d-vj7gb 1/1 Running 0 80s reviews-v2-556d6457d-xbt8v 1/1 Running 0 80s reviews-v3-564544b4d6-cpmvq 1/1 Running 0 80s ``` 1. 次の内容で、`my-gateway.yaml` という名前のファイルを作成します。以下の例では、`service.beta.kubernetes.io/aws-load-balancer-type: "external"` 注釈を使用して、Cilium が Gateway リソース用にタイプ LoadBalancer の Service を作成する際に、レガシー AWS クラウドプロバイダーがその Service 用に Classic Load Balancer を作成しないようにしています。 ``` --- apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: my-gateway spec: gatewayClassName: cilium infrastructure: annotations: service.beta.kubernetes.io/aws-load-balancer-type: "external" listeners: - protocol: HTTP port: 80 name: web-gw allowedRoutes: namespaces: from: Same --- apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: http-app-1 spec: parentRefs: - name: my-gateway namespace: default rules: - matches: - path: type: PathPrefix value: /details backendRefs: - name: details port: 9080 ``` 1. クラスターに Gateway リソースを適用します。 ``` kubectl apply -f my-gateway.yaml ``` 1. Gateway リソースとその対応する Service が作成されたことを確認します。この段階では、Gateway リソースの `ADDRESS` フィールドに IP アドレスもホスト名も入力されておらず、Gateway リソースのタイプ LoadBalancer の Service にも同じく IP アドレスもホスト名も割り当てられていないはずです。 ``` kubectl get gateway my-gateway ``` ``` NAME CLASS ADDRESS PROGRAMMED AGE my-gateway cilium True 10s ``` ``` kubectl get svc cilium-gateway-my-gateway ``` ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cilium-gateway-my-gateway LoadBalancer 172.16.227.247 80:30912/TCP 24s ``` 1. [サービスタイプ LoadBalancer](#hybrid-nodes-ingress-cilium-loadbalancer) に進み、Cilium Load Balancer IPAM によって割り当てられた IP アドレスを使用するように Gateway リソースを設定します。さらに、[サービスタイプ NodePort](#hybrid-nodes-ingress-cilium-nodeport) または [ホストネットワーク](#hybrid-nodes-ingress-cilium-host-network) に進み、NodePort またはホストネットワークアドレスを使用するように Gateway リソースを設定します。 ## Cilium Ingress をインストールする ### 考慮事項 + Cilium では、以下の例に示すように、`nodePort.enabled` を `true` に設定する必要があります。Cilium の kube-proxy 置換機能を使用している場合は、`nodePort.enabled` を `true` に設定する必要はありません。 + Cilium では、以下の例に示すように、`envoy.enabled` を `true` に設定する必要があります。 + `ingressController.loadbalancerMode` を `dedicated` に設定した場合、Cilium は Ingress リソースごとに専用の Service を作成します。`ingressController.loadbalancerMode` を `shared` に設定した場合、Cilium はクラスター内のすべての Ingress リソースに対してタイプ LoadBalancer の共有 Service を作成します。`shared` ロードバランサーモードを使用する場合、`labels`、`annotations`、`type`、`loadBalancerIP` などの共有 Service の設定を Helm 値の `ingressController.service` セクションで行います。詳細については、「[Cilium Helm values reference](https://github.com/cilium/cilium/blob/v1.17.6/install/kubernetes/cilium/values.yaml#L887)」を参照してください。 + `ingressController.default` を `true` に設定した場合、Cilium はクラスターのデフォルトの Ingress コントローラーとして設定され、`ingressClassName` が Ingress リソースに指定されていない場合でも Ingress エントリを作成します。 + Cilium Ingress は、ロードバランサー (デフォルト)、ノードポート、ホストネットワークモードのいずれかでデプロイできます。Cilium をホストネットワークモードでインストールすると、タイプ LoadBalancer の Service およびタイプ NodePort モードの Service が無効になります。詳細については「[ホストネットワーク](#hybrid-nodes-ingress-cilium-host-network)」を参照してください。 + Helm 値では常に `ingressController.service.annotations` を `service.beta.kubernetes.io/aws-load-balancer-type: "external"` に設定します。これにより、レガシー AWS クラウドプロバイダーは、[Cilium Helm チャート](https://github.com/cilium/cilium/blob/main/install/kubernetes/cilium/templates/cilium-ingress-service.yaml)によって作成されたデフォルトの `cilium-ingress` Service 用に Classic Load Balancer を作成しなくなります。 ### 前提条件 1. コマンドライン環境に Helm がインストールされていること。「[Setup Helm instructions](helm.md)」を参照してください。 1. 「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」の手順に従って Cilium がインストールされていること。 ### 手順 1. `cilium-ingress-values.yaml` というファイルを次の内容で作成します。以下に、Cilium Ingress の設定例を示します。デフォルトのロードバランサー `dedicated` モードを使用すること、および Envoy プロキシに個別の `cilium-envoy` DaemonSet を使用してプロキシがハイブリッドノードでのみ動作することを設定しています。 ``` ingressController: enabled: true loadbalancerMode: dedicated service: annotations: service.beta.kubernetes.io/aws-load-balancer-type: "external" nodePort: enabled: true envoy: enabled: true affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: eks.amazonaws.com/compute-type operator: In values: - hybrid ``` 1. Helm 値ファイルをクラスターに適用します。 ``` helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \ --namespace kube-system \ --reuse-values \ --set operator.rollOutPods=true \ --values cilium-ingress-values.yaml ``` 1. Cilium オペレーター、エージェント、Envoy ポッドが動作していることを確認します。 ``` kubectl -n kube-system get pods --selector=app.kubernetes.io/part-of=cilium ``` ``` NAME READY STATUS RESTARTS AGE cilium-envoy-5pgnd 1/1 Running 0 6m31s cilium-envoy-6fhg4 1/1 Running 0 6m30s cilium-envoy-jskrk 1/1 Running 0 6m30s cilium-envoy-k2xtb 1/1 Running 0 6m31s cilium-envoy-w5s9j 1/1 Running 0 6m31s cilium-grwlc 1/1 Running 0 4m12s cilium-operator-68f7766967-5nnbl 1/1 Running 0 4m20s cilium-operator-68f7766967-7spfz 1/1 Running 0 4m20s cilium-pnxcv 1/1 Running 0 6m29s cilium-r7qkj 1/1 Running 0 4m12s cilium-wxhfn 1/1 Running 0 4m1s cilium-z7hlb 1/1 Running 0 6m30s ``` ## Cilium Ingress を設定する Cilium Ingress を Ingress オブジェクトで有効にするには、`ingressClassName` を `cilium` に設定します。Cilium が Ingress リソース用に作成した Service を設定するには、`dedicated` ロードバランサーモードを使用している場合には Ingress オブジェクトを使用し、`shared` ロードバランサーモードを使用している場合には Cilium/Helm 設定を使用します。こうした注釈は、Ingress コントローラーがロードバランサーインフラストラクチャを設定するときや、サービスタイプ、ロードバランサーモード、ポート、TLS パススルーといった Service のその他の属性を設定するときによく使用されます。以下に、主な注釈を示します。サポートされている注釈の完全なリストについては、Cilium のドキュメントの「[Cilium Ingress annotations](https://docs.cilium.io/en/stable/network/servicemesh/ingress/#supported-ingress-annotations)」を参照してください。 | 注釈 | 説明 | | --- | --- | | `ingress.cilium.io/loadbalancer-mode` | `dedicated`: 各 Ingress リソースのタイプ LoadBalancer の専用 Service (デフォルト)。 `shared`: すべての Ingress リソースのタイプ LoadBalancer の単一の Service。 | | `ingress.cilium.io/service-type` | `LoadBalancer`: Service は、タイプ LoadBalancer になります (デフォルト)。 `NodePort`: Service は、タイプ NodePort になります。 | | `service.beta.kubernetes.io/aws-load-balancer-type` | `"external"`: レガシー AWS クラウドプロバイダーは、タイプ LoadBalancer の Service に対して Classic Load Balancer をプロビジョニングしなくなります。 | | `lbipam.cilium.io/ips` | Cilium LoadBalancer IPAM から割り当てる IP アドレスのリスト | Cilium と Kubernetes Ingress の仕様は、Ingress パスのマッチングルールとして完全一致、プレフィックス一致、実装固有一致をサポートしています。Cilium は、実装固有マッチングルールとして正規表現をサポートしています。詳細については、Cilium のドキュメントの「[Ingress path types and precedence](https://docs.cilium.io/en/stable/network/servicemesh/ingress/#ingress-path-types-and-precedence)」と「[Path types examples](https://docs.cilium.io/en/stable/network/servicemesh/path-types/)」、さらにこのページの「[Cilium Ingress をデプロイする](#hybrid-nodes-ingress-cilium-ingress-deploy)」セクションの例を参照してください。 以下に、Cilium Ingress オブジェクトの例を示します。 ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress annotations: service.beta.kuberentes.io/... service.kuberentes.io/... spec: ingressClassName: cilium rules: ... ``` ## Cilium Ingress をデプロイする 1. サンプルアプリケーションを作成します。以下の例では、[Istio Bookinfo](https://istio.io/latest/docs/examples/bookinfo/) サンプルマイクロサービスアプリケーションを使用しています。 ``` kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml ``` 1. アプリケーションが正常に動作していることを確認します。 ``` kubectl get pods ``` ``` NAME READY STATUS RESTARTS AGE details-v1-766844796b-9965p 1/1 Running 0 81s productpage-v1-54bb874995-jmc8j 1/1 Running 0 80s ratings-v1-5dc79b6bcd-smzxz 1/1 Running 0 80s reviews-v1-598b896c9d-vj7gb 1/1 Running 0 80s reviews-v2-556d6457d-xbt8v 1/1 Running 0 80s reviews-v3-564544b4d6-cpmvq 1/1 Running 0 80s ``` 1. 次の内容で、`my-ingress.yaml` という名前のファイルを作成します。以下の例では、`service.beta.kubernetes.io/aws-load-balancer-type: "external"` 注釈を使用して、Cilium が Ingress リソース用にタイプ LoadBalancer の Service を作成する際に、レガシー AWS クラウドプロバイダーがその Service 用に Classic Load Balancer を作成しないようにしています。 ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress namespace: default annotations: service.beta.kubernetes.io/aws-load-balancer-type: "external" spec: ingressClassName: cilium rules: - http: paths: - backend: service: name: details port: number: 9080 path: /details pathType: Prefix ``` 1. Ingress リソースをクラスターに適用します。 ``` kubectl apply -f my-ingress.yaml ``` 1. Ingress リソースおよびその対応する Service が作成されたことを確認します。この段階では、Ingress リソースの `ADDRESS` フィールドに IP アドレスもホスト名も入力されておらず、Ingress リソースのタイプ LoadBalancer の共有または専用 Service にも同じく IP アドレスもホスト名も割り当てられていないはずです。 ``` kubectl get ingress my-ingress ``` ``` NAME CLASS HOSTS ADDRESS PORTS AGE my-ingress cilium * 80 8s ``` ロードバランサーモード `shared` の場合 ``` kubectl -n kube-system get svc cilium-ingress ``` ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cilium-ingress LoadBalancer 172.16.217.48 80:32359/TCP,443:31090/TCP 10m ``` ロードバランサーモード `dedicated` の場合 ``` kubectl -n default get svc cilium-ingress-my-ingress ``` ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cilium-ingress-my-ingress LoadBalancer 172.16.193.15 80:32088/TCP,443:30332/TCP 25s ``` 1. [サービスタイプ LoadBalancer](#hybrid-nodes-ingress-cilium-loadbalancer) に進み、Cilium Load Balancer IPAM によって割り当てられた IP アドレスを使用するように Ingress リソースを設定します。さらに、[サービスタイプ NodePort](#hybrid-nodes-ingress-cilium-nodeport) または [ホストネットワーク](#hybrid-nodes-ingress-cilium-host-network) に進み、NodePort またはホストネットワークアドレスを使用するように Ingress リソースを設定します。 ## サービスタイプ LoadBalancer ### 既存のロードバランサーインフラストラクチャ デフォルトでは、Cilium Ingress の場合も Cilium Gateway の場合も、Cilium は Ingress/Gateway リソース用にタイプ LoadBalancer の Kubernetes Service を作成します。Cilium が作成した Service の属性を設定するには、Ingress リソースと Gateway リソースを使用します。Ingress リソースまたは Gateway リソースを作成すると、Ingress または Gateway 用に外部公開された IP アドレスまたはホスト名がロードバランサーインフラストラクチャから割り当てられます。このインフラストラクチャは通常、Ingress コントローラーまたは Gateway コントローラーによってプロビジョニングされます。 Ingress コントローラーと Gateway コントローラーの多くが、ロードバランサーインフラストラクチャを検出および設定する際に注釈を使用します。Ingress コントローラーと Gateway コントローラーのこうした注釈は、上記の例に示すように、Ingress リソースまたは Gateway リソースに設定します。サポートされている注釈については、Ingress コントローラーまたは Gateway コントローラーのドキュメントを参照してください。また、よく使用されるコントローラーのリストについては、[Kubernetes Ingress のドキュメント](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/)と [Kubernetes Gateway のドキュメント](https://gateway-api.sigs.k8s.io/implementations/)を参照してください。 **重要** EKS Hybrid Nodes では、Cilium Ingress と Gateway を AWS Load Balancer Controller および AWS Network Load Balancer (NLB) と共に使用することはできません。これらを一緒に使用しようとすると、ターゲットが未登録になります。NLB の `target-type` が `ip` に設定されている場合 (EKS Hybrid Nodes で実行されるワークロードで NLB を使用するための要件)、NLB はタイプ LoadBalancer の Service を支援する Pod IP に直接接続しようとするためです。 ### ロードバランサーインフラストラクチャなし 環境にロードバランサーインフラストラクチャおよびその対応する Ingress/Gateway コントローラーがない場合、Ingress/Gateway リソースおよびその対応するタイプ LoadBalancer の Service を設定するには、Cilium の [Load Balancer IP Address Management](https://docs.cilium.io/en/stable/network/lb-ipam/) (LB IPAM) によって割り当てられた IP アドレスを使用します。Cilium LB IPAM は、オンプレミス環境の既知の IP アドレス範囲と共に設定できます。また、Cilium に組み込みのボーダーゲートウェイプロトコル (BGP) サポートまたは L2 のお知らせを使用して、LoadBalancer IP アドレスをオンプレミスネットワークにアドバタイズできます。 以下の例では、Ingress/Gateway リソースに使用する IP アドレスと共に Cilium の LB IPAM を設定する方法と、オンプレミスネットワークで LoadBalancer IP アドレスをアドバタイズするように Cilium BGP コントロールプレーンを設定する方法を示します。Cilium の LB IPAM 機能は、デフォルトで有効になっていますが、`CiliumLoadBalancerIPPool` リソースが作成されるまではアクティブ化されません。 #### 前提条件 + 「[Cilium Ingress をインストールする](#hybrid-nodes-ingress-cilium-ingress-install)」または「[Cilium Gateway をインストールする](#hybrid-nodes-ingress-cilium-gateway-install)」の手順に従って Cilium Ingress または Gateway がインストールされていること。 + 「[Cilium Ingress をデプロイする](#hybrid-nodes-ingress-cilium-ingress-deploy)」または「[Cilium Gateway をデプロイする](#hybrid-nodes-ingress-cilium-gateway-deploy)」の手順に従って、Cilium Ingress リソースまたは Gateway リソースがサンプルアプリケーションと共にデプロイされていること。 + 「[ハイブリッドノード向けに Cilium BGP を設定する](hybrid-nodes-cilium-bgp.md)」の手順に従って Cilium BGP コントロールプレーンを有効にしていること。BGP を使用しない場合にはこの前提条件をスキップできますが、Cilium LB IPAM によって割り当てられた LoadBalancer IP アドレスがオンプレミスネットワークでルーティング可能になるまで、Ingress リソースと Gateway リソースにアクセスできなくなります。 #### 手順 1. 必要に応じて、Ingress リソースまたは Gateway リソースにパッチを適用してタイプ LoadBalancer の Service に特定の IP アドレスを使用するようにリクエストしてください。特定の IP アドレスをリクエストしないと、Cilium は後続のステップで `CiliumLoadBalancerIPPool` リソースに設定する IP アドレス範囲から IP アドレスを割り当てます。以下のコマンドでは、`LB_IP_ADDRESS` をタイプ LoadBalancer の Service 用にリクエストする IP アドレスに置き換えます。 **ゲートウェイ** ``` kubectl patch gateway -n default my-gateway --type=merge -p '{ "spec": { "addresses": [{"type": "IPAddress", "value": "LB_IP_ADDRESS"}] } }' ``` **Ingress** ``` kubectl patch ingress my-ingress --type=merge -p '{ "metadata": {"annotations": {"lbipam.cilium.io/ips": "LB_IP_ADDRESS"}} }' ``` 1. `CiliumLoadBalancerIPPool` リソースを使用して Ingress/Gateway リソースの Load Balancer IP アドレス範囲を設定するファイルを `cilium-lbip-pool-ingress.yaml` という名前で作成します。 + Cilium Ingress を使用している場合、Cilium は Ingress リソース用に作成する Service に `cilium.io/ingress: "true"` ラベルを自動的に適用します。`CiliumLoadBalancerIPPool` リソース定義の `serviceSelector` フィールドでこのラベルを使用すると、LB IPAM の対象となる Service を選択できます。 + Cilium Gateway を使用している場合は、`CiliumLoadBalancerIPPool` リソース定義の `serviceSelector` フィールドで `gateway.networking.k8s.io/gateway-name` ラベルを使用して、LB IPAM の対象となる Gateway リソースを選択できます。 + `LB_IP_CIDR` を Load Balancer の IP アドレスに使用する IP アドレス範囲に置き換えます。単一の IP アドレスを選択するには、`/32` CIDR を使用します。詳細については、Cilium のドキュメントの「[LoadBalancer IP Address Management](https://docs.cilium.io/en/stable/network/lb-ipam/)」を参照してください。 ``` apiVersion: cilium.io/v2alpha1 kind: CiliumLoadBalancerIPPool metadata: name: bookinfo-pool spec: blocks: - cidr: "LB_IP_CIDR" serviceSelector: # if using Cilium Gateway matchExpressions: - { key: gateway.networking.k8s.io/gateway-name, operator: In, values: [ my-gateway ] } # if using Cilium Ingress matchLabels: cilium.io/ingress: "true" ``` 1. `CiliumLoadBalancerIPPool` リソースをクラスターに適用します。 ``` kubectl apply -f cilium-lbip-pool-ingress.yaml ``` 1. Ingress/Gateway リソースの IP アドレスが Cilium LB IPAM から割り当てられたことを確認します。 **ゲートウェイ** ``` kubectl get gateway my-gateway ``` ``` NAME CLASS ADDRESS PROGRAMMED AGE my-gateway cilium LB_IP_ADDRESS True 6m41s ``` **Ingress** ``` kubectl get ingress my-ingress ``` ``` NAME CLASS HOSTS ADDRESS PORTS AGE my-ingress cilium * LB_IP_ADDRESS 80 10m ``` 1. `CiliumBGPAdvertisement` リソースを使用して Ingress/Gateway リソースの LoadBalancer IP アドレスをアドバタイズするファイルを `cilium-bgp-advertisement-ingress.yaml` という名前で作成します。Cilium BGP を使用していない場合は、このステップをスキップできます。Ingress/Gateway リソースに使用する LoadBalancer IP アドレスは、次のステップでサービスをクエリできるように、オンプレミスネットワークでルーティング可能である必要があります。 ``` apiVersion: cilium.io/v2alpha1 kind: CiliumBGPAdvertisement metadata: name: bgp-advertisement-lb-ip labels: advertise: bgp spec: advertisements: - advertisementType: "Service" service: addresses: - LoadBalancerIP selector: # if using Cilium Gateway matchExpressions: - { key: gateway.networking.k8s.io/gateway-name, operator: In, values: [ my-gateway ] } # if using Cilium Ingress matchLabels: cilium.io/ingress: "true" ``` 1. `CiliumBGPAdvertisement` リソースをクラスターに適用します。 ``` kubectl apply -f cilium-bgp-advertisement-ingress.yaml ``` 1. Cilium LB IPAM から割り当てられた IP アドレスを使用して、サービスにアクセスします。 ``` curl -s http://LB_IP_ADDRESS:80/details/1 | jq ``` ``` { "id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890" } ``` ## サービスタイプ NodePort 環境にロードバランサーインフラストラクチャおよびその対応する Ingress コントローラーがない場合、ロードバランサーインフラストラクチャを自己管理している場合、または DNS ベースのロードバランシングを使用している場合は、Ingress リソース用にタイプ NodePort の Service を作成するように Cilium Ingress を設定できます。Cilium Ingress と共に NodePort を使用する場合、タイプ NodePort の Service は各ノード上でポート範囲 30000～32767 のポートに公開されます。このモードでは、トラフィックは NodePort 上のクラスター内にあるノードに到達すると、サービスを支援するポッドに転送されます。このポッドは、同じノードにあることもあれば、別のノードにあることもあります。 **注記** Cilium Gateway による NodePort サービスのサポートは、Cilium バージョン 1.18.x ([\$127273](https://github.com/cilium/cilium/pull/27273)) で予定されています ### 前提条件 + 「[Cilium Ingress をインストールする](#hybrid-nodes-ingress-cilium-ingress-install)」の手順に従って Cilium Ingress がインストールされていること。 + 「[Cilium Ingress をデプロイする](#hybrid-nodes-ingress-cilium-ingress-deploy)」の手順に従って、Cilium Ingress リソースがサンプルアプリケーションと共にデプロイされていること。 ### 手順 1. 既存の Ingress リソース `my-ingress` にパッチを適用して、そのリソースをタイプ LoadBalancer の Service から NodePort に変更します。 ``` kubectl patch ingress my-ingress --type=merge -p '{ "metadata": {"annotations": {"ingress.cilium.io/service-type": "NodePort"}} }' ``` Ingress リソースをまだ作成していない場合は、次の Ingress 定義をクラスターに適用することで作成できます。以下の Ingress 定義では、「[Cilium Ingress をデプロイする](#hybrid-nodes-ingress-cilium-ingress-deploy)」で説明されている Istio Bookinfo サンプルアプリケーションを使用していることに注意してください。 ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress namespace: default annotations: service.beta.kubernetes.io/aws-load-balancer-type: "external" "ingress.cilium.io/service-type": "NodePort" spec: ingressClassName: cilium rules: - http: paths: - backend: service: name: details port: number: 9080 path: /details pathType: Prefix ``` 1. Ingress リソース用の Service が、タイプ NodePort の Service を使用するように更新されたことを確認します。出力にある HTTP プロトコルのポートを書き留めます。以下の例では `32353` がこの HTTP ポートであり、後続のステップではこのポートを使用して Service をクエリします。タイプ NodePort の Service と共に Cilium Ingress を使用する利点は、パスとホストベースのルーティングを適用できるだけでなく、Ingress トラフィック用のネットワークポリシーも適用できることです。これは、Ingress のないタイプ NodePort の標準の Service ではできないことです。 ``` kubectl -n default get svc cilium-ingress-my-ingress ``` ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cilium-ingress-my-ingress NodePort 172.16.47.153 80:32353/TCP,443:30253/TCP 27m ``` 1. クラスター内のノードの IP アドレスを取得します。 ``` kubectl get nodes -o wide ``` ``` NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME mi-026d6a261e355fba7 Ready 23h v1.32.3-eks-473151a 10.80.146.150 Ubuntu 22.04.5 LTS 5.15.0-142-generic containerd://1.7.27 mi-082f73826a163626e Ready 23h v1.32.3-eks-473151a 10.80.146.32 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-09183e8a3d755abf6 Ready 23h v1.32.3-eks-473151a 10.80.146.33 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-0d78d815980ed202d Ready 23h v1.32.3-eks-473151a 10.80.146.97 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-0daa253999fe92daa Ready 23h v1.32.3-eks-473151a 10.80.146.100 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 ``` 1. ノードの IP アドレスと上記でキャプチャした NodePort を使用して、タイプ NodePort の Service にアクセスします。以下の例では、使用されるノード IP アドレスは `10.80.146.32` で、NodePort は `32353` です。これらをお使いの環境の値で置き換えます。 ``` curl -s http://10.80.146.32:32353/details/1 | jq ``` ``` { "id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890" } ``` ## ホストネットワーク タイプ NodePort の Service と同様に、ロードバランサーインフラストラクチャと Ingress または Gateway コントローラーがない場合や、外部ロードバランサーでロードバランシングを自己管理している場合は、ホストネットワークに Ingress リソースと Gateway リソースを直接公開するように Cilium Ingress および Cilium Gateway を設定できます。ホストネットワークモードが Ingress リソースまたは Gateway リソースに対して有効になっている場合、タイプ LoadBalancer の Service とタイプ NodePort モードの Service は自動的に無効になり、ホストネットワークモードは Ingress リソースまたは Gateway リソースごとにこれらの代替モードと相互に排他的になります。タイプ NodePort モードの Service と比較して、ホストネットワークモードは使用できるポート範囲の柔軟性が高く (NodePort の 30000～32767 という範囲に制限されません)、ホストネットワーク上で Envoy プロキシが動作するノードのサブセットを設定できます。 ### 前提条件 + 「[Cilium Ingress をインストールする](#hybrid-nodes-ingress-cilium-ingress-install)」または「[Cilium Gateway をインストールする](#hybrid-nodes-ingress-cilium-gateway-install)」の手順に従って Cilium Ingress または Gateway がインストールされていること。 ### 手順 #### ゲートウェイ 1. `cilium-gateway-host-network.yaml` という名前のファイルを作成し、次の内容を記述します。 ``` gatewayAPI: enabled: true hostNetwork: enabled: true # uncomment to restrict nodes where Envoy proxies run on the host network # nodes: # matchLabels: # role: gateway ``` 1. クラスターにホストネットワーク Cilium Gateway 設定を適用します。 ``` helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \ --namespace kube-system \ --reuse-values \ --set operator.rollOutPods=true \ -f cilium-gateway-host-network.yaml ``` Gateway リソースをまだ作成していない場合は、次の Gateway 定義をクラスターに適用することで作成できます。以下の Gateway 定義では、「[Cilium Gateway をデプロイする](#hybrid-nodes-ingress-cilium-gateway-deploy)」で説明されている Istio Bookinfo サンプルアプリケーションを使用しています。以下の例では、Gateway リソースは HTTP リスナーに `8111` ポートを使用するように設定されています。ホストネットワークで動作する Envoy プロキシの共有リスナーポートです。Gateway リソースに特権ポート (1023 未満) を使用する場合は、その手順を [Cilium のドキュメント](https://docs.cilium.io/en/stable/network/servicemesh/gateway-api/gateway-api/#bind-to-privileged-port)で確認してください。 ``` --- apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: my-gateway spec: gatewayClassName: cilium listeners: - protocol: HTTP port: 8111 name: web-gw allowedRoutes: namespaces: from: Same --- apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: http-app-1 spec: parentRefs: - name: my-gateway namespace: default rules: - matches: - path: type: PathPrefix value: /details backendRefs: - name: details port: 9080 ``` 適用した Cilium Envoy 設定を確認するには、次のコマンドを使用します。 ``` kubectl get cec cilium-gateway-my-gateway -o yaml ``` `cilium-gateway-my-gateway` Service の Envoy リスナーポートを取得するには、次のコマンドを使用します。この例では、`8111` が共有リスナーポートです。 ``` kubectl get cec cilium-gateway-my-gateway -o jsonpath={.spec.services[0].ports[0]} ``` 1. クラスター内のノードの IP アドレスを取得します。 ``` kubectl get nodes -o wide ``` ``` NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME mi-026d6a261e355fba7 Ready 23h v1.32.3-eks-473151a 10.80.146.150 Ubuntu 22.04.5 LTS 5.15.0-142-generic containerd://1.7.27 mi-082f73826a163626e Ready 23h v1.32.3-eks-473151a 10.80.146.32 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-09183e8a3d755abf6 Ready 23h v1.32.3-eks-473151a 10.80.146.33 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-0d78d815980ed202d Ready 23h v1.32.3-eks-473151a 10.80.146.97 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-0daa253999fe92daa Ready 23h v1.32.3-eks-473151a 10.80.146.100 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 ``` 1. ノードの IP アドレスと `cilium-gateway-my-gateway` リソースのリスナーポートを使用して、Service にアクセスします。以下の例では、使用されるノード IP アドレスは `10.80.146.32` であり、リスナーポートは `8111` です。これらをお使いの環境の値で置き換えます。 ``` curl -s http://10.80.146.32:8111/details/1 | jq ``` ``` { "id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890" } ``` #### Ingress アップストリームの Cilium の問題 ([\$134028](https://github.com/cilium/cilium/issues/34028)) により、ホストネットワークモードの Cilium Ingress では `loadbalancerMode: shared` を使用する必要があります。これにより、クラスター内のすべての Ingress リソースに対してタイプ ClusterIP の Service が 1 つだけ作成されます。Ingress リソースに特権ポート (1023 未満) を使用する場合は、その手順を [Cilium のドキュメント](https://docs.cilium.io/en/stable/network/servicemesh/ingress/#bind-to-privileged-port)で確認してください。 1. `cilium-ingress-host-network.yaml` という名前のファイルを作成し、次の内容を記述します。 ``` ingressController: enabled: true loadbalancerMode: shared # This is a workaround for the upstream Cilium issue service: externalTrafficPolicy: null type: ClusterIP hostNetwork: enabled: true # ensure the port does not conflict with other services on the node sharedListenerPort: 8111 # uncomment to restrict nodes where Envoy proxies run on the host network # nodes: # matchLabels: # role: ingress ``` 1. クラスターにホストネットワーク Cilium Ingress 設定を適用します。 ``` helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \ --namespace kube-system \ --reuse-values \ --set operator.rollOutPods=true \ -f cilium-ingress-host-network.yaml ``` Ingress リソースをまだ作成していない場合は、次の Ingress 定義をクラスターに適用することで作成できます。以下の Ingress 定義では、「[Cilium Ingress をデプロイする](#hybrid-nodes-ingress-cilium-ingress-deploy)」で説明されている Istio Bookinfo サンプルアプリケーションを使用しています。 ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress namespace: default spec: ingressClassName: cilium rules: - http: paths: - backend: service: name: details port: number: 9080 path: /details pathType: Prefix ``` 適用した Cilium Envoy 設定を確認するには、次のコマンドを使用します。 ``` kubectl get cec -n kube-system cilium-ingress -o yaml ``` `cilium-ingress` Service の Envoy リスナーポートを取得するには、次のコマンドを使用します。この例では、`8111` が共有リスナーポートです。 ``` kubectl get cec -n kube-system cilium-ingress -o jsonpath={.spec.services[0].ports[0]} ``` 1. クラスター内のノードの IP アドレスを取得します。 ``` kubectl get nodes -o wide ``` ``` NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME mi-026d6a261e355fba7 Ready 23h v1.32.3-eks-473151a 10.80.146.150 Ubuntu 22.04.5 LTS 5.15.0-142-generic containerd://1.7.27 mi-082f73826a163626e Ready 23h v1.32.3-eks-473151a 10.80.146.32 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-09183e8a3d755abf6 Ready 23h v1.32.3-eks-473151a 10.80.146.33 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-0d78d815980ed202d Ready 23h v1.32.3-eks-473151a 10.80.146.97 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 mi-0daa253999fe92daa Ready 23h v1.32.3-eks-473151a 10.80.146.100 Ubuntu 22.04.4 LTS 5.15.0-142-generic containerd://1.7.27 ``` 1. ノードの IP アドレスと `cilium-ingress` リソースの `sharedListenerPort` を使用して、Service にアクセスします。以下の例では、使用されるノード IP アドレスは `10.80.146.32` であり、リスナーポートは `8111` です。これらをお使いの環境の値で置き換えます。 ``` curl -s http://10.80.146.32:8111/details/1 | jq ``` ``` { "id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890" } ``` # ハイブリッドノード用にタイプ LoadBalancer の Service を設定する このトピックでは、Amazon EKS Hybrid Nodes で動作するアプリケーションに対してレイヤー 4 (L4) ロードバランシングを設定する方法について説明します。タイプ LoadBalancer の Kubernetes Service は、クラスターの外部に Kubernetes アプリケーションを公開するために使用されます。タイプ LoadBalancer の Service は、ワークロードのトラフィックを処理するために、クラウド環境やオンプレミス環境の物理的なロードバランサーインフラストラクチャと共によく使用されます。このロードバランサーインフラストラクチャは通常、環境固有のコントローラーでプロビジョニングされます。 AWS は、EKS Hybrid Nodes で実行されているタイプ LoadBalancer の Service 用に AWS Network Load Balancer (NLB) と Cilium をサポートしています。NLB を使用するか、Cilium を使用するかは、アプリケーショントラフィックのソースに基づきます。AWS では、アプリケーショントラフィックの発信元が AWS リージョンである場合には AWS NLB と AWS Load Balancer Controller を使用することを推奨しています。AWS では、アプリケーショントラフィックの発信元がローカルのオンプレミス環境またはエッジ環境である場合には Cilium に組み込みのロードバランシング機能を使用することを推奨しています。この機能は、お使いの環境にロードバランサーインフラストラクチャを搭載しているかどうかにかかわらず使用できます。 レイヤー 7 (L7) アプリケーショントラフィックのロードバランシングについては、「[ハイブリッドノード用に Kubernetes Ingress を設定する](hybrid-nodes-ingress.md)」を参照してください。EKS によるロードバランシングの全般的な情報については、「[Best Practices for Load Balancing](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html)」を参照してください。 ## AWS Network Load Balancer ハイブリッドノード上で実行されているワークロードのターゲットタイプが `ip` の場合、[AWS Load Balancer](aws-load-balancer-controller.md) および NLB を使用できます。ターゲットタイプ `ip` を使用している場合、NLB はトラフィックをポッドに直接転送して、Service レイヤーネットワークパスをバイパスします。NLB がハイブリッドノードのポッド IP ターゲットに到達するためには、オンプレミスネットワークでオンプレミスポッド CIDR をルーティング可能である必要があります。また、AWS Load Balancer Controller はウェブフックを使用し、EKS コントロールプレーンからの直接通信が必要です。詳細については、「[ハイブリッドノード用のウェブフックを設定する](hybrid-nodes-webhooks.md)」を参照してください。 + サブネット設定要件については「[Network Load Balancer を使用して TCP および UDP トラフィックをルーティングする](network-load-balancing.md)」を参照し、AWS Network Load Balancer と AWS Load Balancer Controller の詳細については「[Helm による AWS Load Balancer Controller のインストール](lbc-helm.md)」と「[Best Practices for Load Balancing](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html)」を参照してください。 + AWS Network Load Balancer でタイプ `LoadBalancer` の Service に適用できる設定については、「[AWS Load Balancer Controller NLB configurations](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/nlb/)」を参照してください。 ### 前提条件 + 「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」の手順に従って Cilium がインストールされていること。 + 「[ハイブリッドノード向けに Cilium BGP を設定する](hybrid-nodes-cilium-bgp.md)」の手順に従って Cilium BGP コントロールプレーンを有効にしていること。BGP を使用しない場合は、別の方法を使用して、オンプレミスネットワークでオンプレミスポッド CIDR をルーティング可能にする必要があります。詳細については、「[ルーティング可能なリモートポッド CIDR](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs)」を参照してください。 + コマンドライン環境に Helm がインストールされていること。「[Setup Helm instructions](helm.md)」を参照してください。 + コマンドライン環境に eksctl がインストールされていること。「[Setup eksctl instructions](install-kubectl.md#eksctl-install-update)」を参照してください。 ### 手順 1. ユーザーに代わって AWS API を呼び出すことを許可する、AWS Load Balancer Controller 用の IAM ポリシーをダウンロードします。 ``` curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/refs/heads/main/docs/install/iam_policy.json ``` 1. 前のステップでダウンロードしたポリシー を使用して、IAM ポリシーを作成します。 ``` aws iam create-policy \ --policy-name AWSLoadBalancerControllerIAMPolicy \ --policy-document file://iam_policy.json ``` 1. クラスター名 (`CLUSTER_NAME`)、AWS リージョン (`AWS_REGION`)、AWS アカウント ID (`AWS_ACCOUNT_ID`) の各値を自分の設定値に置き換えて、次のコマンドを実行します。 ``` eksctl create iamserviceaccount \ --cluster=CLUSTER_NAME \ --namespace=kube-system \ --name=aws-load-balancer-controller \ --attach-policy-arn=arn:aws:iam::AWS_ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy \ --override-existing-serviceaccounts \ --region AWS_REGION \ --approve ``` 1. eks-charts Helm チャートリポジトリを追加します。AWS は、このリポジトリを GitHub で管理しています。 ``` helm repo add eks https://aws.github.io/eks-charts ``` 1. ローカル Helm リポジトリを更新して、最新のチャートがあることを確認します。 ``` helm repo update eks ``` 1. AWS Load Balancer コントローラをインストールします。クラスター名 (`CLUSTER_NAME`)、AWS リージョン (`AWS_REGION`)、VPC ID (`VPC_ID`)、AWS Load Balancer Controller Helm チャートバージョン (`AWS_LBC_HELM_VERSION`) の各値を自分の設定値に置き換えます。Helm チャートの最新バージョンを確認するには、`helm search repo eks/aws-load-balancer-controller --versions` を実行します。ハイブリッドノードと AWS クラウド内のノードの両方を使用して混合モードクラスターを実行している場合は、「[AWS ロードバランサーコントローラー](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-lbc)」の手順に従ってクラウドノード上で AWS Load Balancer Controller を実行できます。 ``` helm install aws-load-balancer-controller eks/aws-load-balancer-controller \ -n kube-system \ --version AWS_LBC_HELM_VERSION \ --set clusterName=CLUSTER_NAME \ --set region=AWS_REGION \ --set vpcId=VPC_ID \ --set serviceAccount.create=false \ --set serviceAccount.name=aws-load-balancer-controller ``` 1. AWS Load Balancer Controller が正常にインストールされたことを確認します。 ``` kubectl get -n kube-system deployment aws-load-balancer-controller ``` ``` NAME READY UP-TO-DATE AVAILABLE AGE aws-load-balancer-controller 2/2 2 2 84s ``` 1. `tcp-sample-app.yaml` という名前のファイルにサンプルアプリケーションを定義します。以下の例では、TCP ポートでシンプルな NGINX デプロイを使用しています。 ``` apiVersion: apps/v1 kind: Deployment metadata: name: tcp-sample-app namespace: default spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: public.ecr.aws/nginx/nginx:1.23 ports: - name: tcp containerPort: 80 ``` 1. デプロイをクラスターに適用します。 ``` kubectl apply -f tcp-sample-app.yaml ``` 1. `tcp-sample-service.yaml` という名前のファイルにデプロイ用のタイプ LoadBalancer の Service を定義します。 ``` apiVersion: v1 kind: Service metadata: name: tcp-sample-service namespace: default annotations: service.beta.kubernetes.io/aws-load-balancer-type: external service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing spec: ports: - port: 80 targetPort: 80 protocol: TCP type: LoadBalancer selector: app: nginx ``` 1. サービス設定をクラスターに適用します。 ``` kubectl apply -f tcp-sample-service.yaml ``` 1. Service 用に NLB をプロビジョニングするには、数分かかる場合があります。NLB がプロビジョニングされると、NLB デプロイの DNS 名に対応するアドレスが Service に割り当てられます。 ``` kubectl get svc tcp-sample-service ``` ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE tcp-sample-service LoadBalancer 172.16.115.212 k8s-default-tcpsampl-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb..amazonaws.com 80:30396/TCP 8s ``` 1. NLB のアドレスを使用して Service にアクセスします。 ``` curl k8s-default-tcpsampl-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb..amazonaws.com ``` 以下に、出力例を示します。 ``` Welcome to nginx! [...] ``` 1. 作成した リソースをクリーンアップします。 ``` kubectl delete -f tcp-sample-service.yaml kubectl delete -f tcp-sample-app.yaml ``` ## Cilium クラスター内ロードバランシング Cilium は、EKS Hybrid Nodes で実行されているワークロードのクラスター内ロードバランサーとして使用できます。お使いの環境にロードバランサーインフラストラクチャがない場合に便利です。Cilium のロードバランシング機能は、kube-proxy 置換、Load Balancer IP Address Management (IPAM)、BGP コントロールプレーンなどの Cilium 機能を組み合わせて構築されています。これらの機能が担当する作業は以下のとおりです。 + **Cilium kube-proxy 置換**: バックエンドポッドへの Service トラフィックのルーティングを処理します。 + **Cilium Load Balancer IPAM**: タイプ `LoadBalancer` の Service に割り当てることができる IP アドレスを管理します。 + **Cilium BGP コントロールプレーン**: Load Balancer IPAM が割り当てた IP アドレスをオンプレミスネットワークにアドバタイズします。 Cilium の kube-proxy 置換を使用していない場合でも、Cilium Load Balancer IPAM と BGP コントロールプレーンを使用して、タイプ LoadBalancer の Service 用に IP アドレスを配分して割り当てることができます。Cilium の kube-proxy 置換を使用しない場合、バックエンドポッドへの Service のロードバランシングは、デフォルトでは EKS の kube-proxy ルールと iptables ルールによって処理されます。 ### 前提条件 + kube-proxy 置換が有効かどうかにかかわらず、「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」の手順に従って Cilium がインストールされていること。Cilium の kube-proxy 置換を使用するには、v4.19.57、v5.1.16、v5.2.0 以降の最新の Linux カーネルでオペレーティングシステムを実行している必要があります。ハイブリッドノード上での用途に対応した最新バージョンのオペレーティングシステムであれば、Red Hat Enterprise Linux (RHEL) 8.x を除き、すべてこの基準を満たしています。 + 「[ハイブリッドノード向けに Cilium BGP を設定する](hybrid-nodes-cilium-bgp.md)」の手順に従って Cilium BGP コントロールプレーンを有効にしていること。BGP を使用しない場合は、別の方法を使用して、オンプレミスネットワークでオンプレミスポッド CIDR をルーティング可能にする必要があります。詳細については、「[ルーティング可能なリモートポッド CIDR](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs)」を参照してください。 + コマンドライン環境に Helm がインストールされていること。「[Setup Helm instructions](helm.md)」を参照してください。 ### 手順 1. `CiliumLoadBalancerIPPool` リソースを使用してタイプ Load Balancer の Service 用に LoadBalancer IP アドレス範囲を設定するファイルを `cilium-lbip-pool-loadbalancer.yaml` という名前で作成します。 + `LB_IP_CIDR` を Load Balancer の IP アドレスに使用する IP アドレス範囲に置き換えます。単一の IP アドレスを選択するには、`/32` CIDR を使用します。詳細については、Cilium のドキュメントの「[LoadBalancer IP Address Management](https://docs.cilium.io/en/stable/network/lb-ipam/)」を参照してください。 + `serviceSelector` フィールドは、後続のステップで作成する Service の名前と一致するように設定されています。この設定の場合、このプールの IP は `tcp-sample-service` という名前の Service にのみ割り当てられます。 ``` apiVersion: cilium.io/v2alpha1 kind: CiliumLoadBalancerIPPool metadata: name: tcp-service-pool spec: blocks: - cidr: "LB_IP_CIDR" serviceSelector: matchLabels: io.kubernetes.service.name: tcp-sample-service ``` 1. `CiliumLoadBalancerIPPool` リソースをクラスターに適用します。 ``` kubectl apply -f cilium-lbip-pool-loadbalancer.yaml ``` 1. プール内に使用可能な IP アドレスが少なくとも 1 つあることを確認します。 ``` kubectl get ciliumloadbalancerippools.cilium.io ``` ``` NAME DISABLED CONFLICTING IPS AVAILABLE AGE tcp-service-pool false False 1 24m ``` 1. `CiliumBGPAdvertisement` リソースを使用して、次のステップで作成する Service 用にロードバランサー IP アドレスをアドバタイズするファイルを `cilium-bgp-advertisement-loadbalancer.yaml` という名前で作成します。Cilium BGP を使用していない場合は、このステップをスキップできます。Service に使用するロードバランサー IP アドレスは、最終ステップでサービスをクエリできるように、オンプレミスネットワークでルーティング可能である必要があります。 + `LoadBalancerIP` をタイプ `LoadBalancer` の Service 用にのみアドバタイズするように、`advertisementType` フィールドは `Service` に設定され、`service.addresses` は `LoadBalancerIP` に設定されます。 + `selector` フィールドは、後続のステップで作成する Service の名前と一致するように設定されています。この設定の場合、`tcp-sample-service` という名前の Service 用に `LoadBalancerIP` のみがアドバタイズされます。 ``` apiVersion: cilium.io/v2alpha1 kind: CiliumBGPAdvertisement metadata: name: bgp-advertisement-tcp-service labels: advertise: bgp spec: advertisements: - advertisementType: "Service" service: addresses: - LoadBalancerIP selector: matchLabels: io.kubernetes.service.name: tcp-sample-service ``` 1. `CiliumBGPAdvertisement` リソースをクラスターに適用します。Cilium BGP を使用していない場合は、このステップをスキップできます。 ``` kubectl apply -f cilium-bgp-advertisement-loadbalancer.yaml ``` 1. `tcp-sample-app.yaml` という名前のファイルにサンプルアプリケーションを定義します。以下の例では、TCP ポートでシンプルな NGINX デプロイを使用しています。 ``` apiVersion: apps/v1 kind: Deployment metadata: name: tcp-sample-app namespace: default spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: public.ecr.aws/nginx/nginx:1.23 ports: - name: tcp containerPort: 80 ``` 1. デプロイをクラスターに適用します。 ``` kubectl apply -f tcp-sample-app.yaml ``` 1. `tcp-sample-service.yaml` という名前のファイルにデプロイ用のタイプ LoadBalancer の Service を定義します。 + Service オブジェクトの `lbipam.cilium.io/ips` 注釈を使用して、ロードバランサー IP プールから特定の IP アドレスをリクエストできます。Service 用に特定の IP アドレスをリクエストしない場合は、この注釈を削除してもかまいません。 + レガシー AWS クラウドプロバイダーが Service の Classic Load Balancer を作成できないようにするには、`loadBalancerClass` 仕様フィールドが必要です。以下の例では、`io.cilium/bgp-control-plane` が Cilium の BGP コントロールプレーンをロードバランサークラスとして使用するように、このフィールドを設定しています。また、`io.cilium/l2-announcer` が Cilium の [L2 Announcements 機能](https://docs.cilium.io/en/latest/network/l2-announcements/)を使用するように、このフィールドを設定することもできます (現時点ではベータ版であり、AWS による正式なサポートはありません)。 ``` apiVersion: v1 kind: Service metadata: name: tcp-sample-service namespace: default annotations: lbipam.cilium.io/ips: "LB_IP_ADDRESS" spec: loadBalancerClass: io.cilium/bgp-control-plane ports: - port: 80 targetPort: 80 protocol: TCP type: LoadBalancer selector: app: nginx ``` 1. サービスをクラスターに適用します。Service は、アプリケーションへのアクセスに使用できる外部 IP アドレスと共に作成されます。 ``` kubectl apply -f tcp-sample-service.yaml ``` 1. Service が正常に作成されて、前のステップで作成した `CiliumLoadBalancerIPPool` から IP が割り当てられていることを確認します。 ``` kubectl get svc tcp-sample-service ``` ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE tcp-sample-service LoadBalancer 172.16.117.76 LB_IP_ADDRESS 80:31129/TCP 14m ``` 1. kube-proxy 置換モードで Cilium を使用している場合は、次のコマンドを実行して、Cilium が Service のロードバランシングを処理していることを確認できます。以下の出力では、`10.86.2.x` アドレスは Service のバックエンドポッドのポッド IP アドレスです。 ``` kubectl -n kube-system exec ds/cilium -- cilium-dbg service list ``` ``` ID Frontend Service Type Backend ... 41 LB_IP_ADDRESS:80/TCP LoadBalancer 1 => 10.86.2.76:80/TCP (active) 2 => 10.86.2.130:80/TCP (active) 3 => 10.86.2.141:80/TCP (active) ``` 1. Cilium が BGP を介してオンプレミスネットワークに IP アドレスをアドバタイズしていることを確認します。以下の例では、ハイブリッドノードが 5 つあり、それぞれが `tcp-sample-service` Service の `LB_IP_ADDRESS` をオンプレミスネットワークにアドバタイズしています。 ``` Node VRouter Prefix NextHop Age Attrs mi-026d6a261e355fba7 NODES_ASN LB_IP_ADDRESS/32 0.0.0.0 12m3s [{Origin: i} {Nexthop: 0.0.0.0}] mi-082f73826a163626e NODES_ASN LB_IP_ADDRESS/32 0.0.0.0 12m3s [{Origin: i} {Nexthop: 0.0.0.0}] mi-09183e8a3d755abf6 NODES_ASN LB_IP_ADDRESS/32 0.0.0.0 12m3s [{Origin: i} {Nexthop: 0.0.0.0}] mi-0d78d815980ed202d NODES_ASN LB_IP_ADDRESS/32 0.0.0.0 12m3s [{Origin: i} {Nexthop: 0.0.0.0}] mi-0daa253999fe92daa NODES_ASN LB_IP_ADDRESS/32 0.0.0.0 12m3s [{Origin: i} {Nexthop: 0.0.0.0}] ``` 1. 割り当てられたロードバランサー IP アドレスを使用して Service にアクセスします。 ``` curl LB_IP_ADDRESS ``` 以下に、出力例を示します。 ``` Welcome to nginx! [...] ``` 1. 作成した リソースをクリーンアップします。 ``` kubectl delete -f tcp-sample-service.yaml kubectl delete -f tcp-sample-app.yaml kubectl delete -f cilium-lb-ip-pool.yaml kubectl delete -f cilium-bgp-advertisement.yaml ``` # ハイブリッドノード用に Kubernetes ネットワークポリシーを設定する AWS は、EKS Hybrid Nodes と共に Cilium を CNI として使用する際に、ポッドの受信トラフィックと送信トラフィック用に Kubernetes ネットワークポリシー (レイヤー 3/レイヤー 4) をサポートします。AWS クラウド内のノードで EKS クラスターを実行している場合、AWS は [Kubernetes ネットワークポリシー用の Amazon VPC CNI](cni-network-policy.md) をサポートします。 このトピックでは、EKS Hybrid Nodes で Cilium および Kubernetes ネットワークポリシーを設定する方法について説明します。Kubernetes ネットワークポリシーの詳細については、Kubernetes のドキュメントの「[Kubernetes Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/)」を参照してください。 ## ネットワークポリシーの設定 ### 考慮事項 + AWS は、ポッドの送受信に関するアップストリームの Kubernetes ネットワークポリシーと仕様をサポートしています。AWS は、現時点では `CiliumNetworkPolicy` や `CiliumClusterwideNetworkPolicy` をサポートしていません。 + `policyEnforcementMode` Helm 値を使用すると、デフォルトの Cilium ポリシーの適用動作を制御できます。デフォルトの動作では、すべての送受信トラフィックが許可されます。ネットワークポリシーによってエンドポイントが選択されると、default-deny 状態に遷移して、明示的に許可したトラフィックのみが許可されます。[デフォルトポリシーモード](https://docs.cilium.io/en/stable/security/policy/intro/#policy-mode-default)と[ポリシー適用モード](https://docs.cilium.io/en/stable/security/policy/intro/#policy-enforcement-modes)の詳細については、Cilium のドキュメントを参照してください。 + 既存の Cilium インストールで `policyEnforcementMode` を変更する場合は、Cilium エージェント DaemonSet を再起動して、変更後のポリシー適用モードを適用する必要があります。 + `namespaceSelector` および `podSelector` を使用すると、ラベルが一致する名前空間およびポッドに対してトラフィックを許可または拒否できます。`namespaceSelector` および `podSelector` を `matchLabels` または `matchExpressions` と共に使用すると、それぞれのラベルに基づいて名前空間とポッドを選択できます。 + `ingress.ports` および `egress.ports` を使用すると、ポートおよびプロトコルに対してトラフィックを許可または拒否できます。 + `ipBlock` フィールドでは、ポッド IP アドレス ([\$19209](https://github.com/cilium/cilium/issues/9209)) に対してトラフィックを選択的に許可または拒否することはできません。ノード IP に `ipBlock` セレクターを使用する機能は、Cilium のベータ機能であり、AWS ではサポートされていません。 + Kubernetes ネットワークポリシーに使用可能なフィールドの詳細については、Kubernetes のドキュメントの「[NetworkPolicy resource](https://kubernetes.io/docs/concepts/services-networking/network-policies/#networkpolicy-resource)」を参照してください。 ### 前提条件 + 「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」の手順に従って Cilium がインストールされていること。 + コマンドライン環境に Helm がインストールされていること。「[Setup Helm instructions](helm.md)」を参照してください。 ### 手順 次の手順では、コンポーネントがアプリケーションの動作に必要な他のコンポーネントとのみ通信できるように、サンプルマイクロサービスアプリケーション用のネットワークポリシーを設定します。この手順では、[Istio Bookinfo](https://istio.io/latest/docs/examples/bookinfo/) サンプルマイクロサービスアプリケーションを使用します。 Bookinfo アプリケーションは、4 つの個別のマイクロサービスで構成されており、以下のような関係があります。 + **productpage**。productpage マイクロサービスは、details マイクロサービスと reviews マイクロサービスを呼び出して、ページに値を入力します。 + **details**。details マイクロサービスには、書籍情報が含まれています。 + **reviews**。reviews マイクロサービスには、書籍レビューが含まれています。また、ratings マイクロサービスも呼び出します。 + **ratings**。ratings マイクロサービスには、書籍レビューに伴う書籍ランキング情報が含まれています。 1. サンプルアプリケーションを作成します。 ``` kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml ``` 1. サンプルアプリケーションが正常に動作していることを確認し、productpage マイクロサービスのポッド IP アドレスを書き留めます。後続のステップでは、このポッド IP アドレスを使用して、各マイクロサービスをクエリします。 ``` kubectl get pods -o wide ``` ``` NAME READY STATUS RESTARTS AGE IP NODE details-v1-766844796b-9wff2 1/1 Running 0 7s 10.86.3.7 mi-0daa253999fe92daa productpage-v1-54bb874995-lwfgg 1/1 Running 0 7s 10.86.2.193 mi-082f73826a163626e ratings-v1-5dc79b6bcd-59njm 1/1 Running 0 7s 10.86.2.232 mi-082f73826a163626e reviews-v1-598b896c9d-p2289 1/1 Running 0 7s 10.86.2.47 mi-026d6a261e355fba7 reviews-v2-556d6457d-djktc 1/1 Running 0 7s 10.86.3.58 mi-0daa253999fe92daa reviews-v3-564544b4d6-g8hh4 1/1 Running 0 7s 10.86.2.69 mi-09183e8a3d755abf6 ``` 1. ネットワークポリシーをテストするために全体を通して使用されるポッドを作成します。このポッドは、`access: true` というラベルが付けられて `default` 名前空間に作成されることに注意してください。 ``` kubectl run curl-pod --image=curlimages/curl -i --tty --labels=access=true --namespace=default --overrides='{"spec": { "nodeSelector": {"eks.amazonaws.com/compute-type": "hybrid"}}}' -- /bin/sh ``` 1. productpage マイクロサービスへのアクセスをテストします。以下の例では、productpage ポッド (`10.86.2.193`) のポッド IP アドレスを使用して、マイクロサービスをクエリしています。この IP アドレスをお使いの環境の productpage ポッドのポッド IP アドレスに置き換えます。 ``` curl -s http://10.86.2.193:9080/productpage | grep -o ".*" ``` ``` Simple Bookstore App ``` 1. `exit` と入力してテスト用 curl ポッドを終了し、次のコマンドを実行してポッドに再アタッチできます。 ``` kubectl attach curl-pod -c curl-pod -i -t ``` 1. 以降の手順でネットワークポリシーの効果を実証するには、まず BookInfo マイクロサービスに対するトラフィックをすべて拒否するネットワークポリシーを作成します。deny ネットワークポリシーを定義するファイルを `network-policy-deny-bookinfo.yaml` という名前で作成します。 ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-bookinfo namespace: default spec: podSelector: matchExpressions: - key: app operator: In values: ["productpage", "details", "reviews", "ratings"] policyTypes: - Ingress - Egress ``` 1. クラスターに deny ネットワークポリシーを適用します。 ``` kubectl apply -f network-policy-default-deny-bookinfo.yaml ``` 1. BookInfo アプリケーションへのアクセスをテストします。以下の例では、productpage ポッド (`10.86.2.193`) のポッド IP アドレスを使用して、マイクロサービスをクエリしています。この IP アドレスをお使いの環境の productpage ポッドのポッド IP アドレスに置き換えます。 ``` curl http://10.86.2.193:9080/productpage --max-time 10 ``` ``` curl: (28) Connection timed out after 10001 milliseconds ``` 1. productpage ネットワークポリシーを定義するファイルを `network-policy-productpage.yaml` という名前で作成します。このポリシーには、以下のルールがあります。 + `access: true` というラベルが付いたポッド (前のステップで作成した curl ポッド) からの受信トラフィックを許可する + ポート `9080` で、details、reviews、ratings の各マイクロサービスに関する送信 TCP トラフィックを許可する + ポート `53` で、`kube-system` 名前空間内で動作する CoreDNS に関する送信 TCP/UDP トラフィックを許可する ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: productpage-policy namespace: default spec: podSelector: matchLabels: app: productpage policyTypes: - Ingress - Egress ingress: - from: - podSelector: matchLabels: access: "true" egress: - to: - podSelector: matchExpressions: - key: app operator: In values: ["details", "reviews", "ratings"] ports: - port: 9080 protocol: TCP - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system podSelector: matchLabels: k8s-app: kube-dns ports: - port: 53 protocol: UDP - port: 53 protocol: TCP ``` 1. クラスターに productpage ネットワークポリシーを適用します。 ``` kubectl apply -f network-policy-productpage.yaml ``` 1. curl ポッドに接続して、Bookinfo アプリケーションへのアクセスをテストします。productpage マイクロサービスへのアクセスが許可されるようになりましたが、他のマイクロサービスは依然として deny ネットワークポリシーの対象であるため、引き続き拒否されます。以下の例では、productpage ポッド (`10.86.2.193`) のポッド IP アドレスを使用して、マイクロサービスをクエリします。この IP アドレスをお使いの環境の productpage ポッドのポッド IP アドレスに置き換えます。 ``` kubectl attach curl-pod -c curl-pod -i -t ``` ``` curl -s http://10.86.2.193:9080/productpage | grep -o ".*" Simple Bookstore App ``` ``` curl -s http://10.86.2.193:9080/api/v1/products/1 {"error": "Sorry, product details are currently unavailable for this book."} ``` ``` curl -s http://10.86.2.193:9080/api/v1/products/1/reviews {"error": "Sorry, product reviews are currently unavailable for this book."} ``` ``` curl -s http://10.86.2.193:9080/api/v1/products/1/ratings {"error": "Sorry, product ratings are currently unavailable for this book."} ``` 1. details ネットワークポリシーを定義するファイルを `network-policy-details.yaml` という名前で作成します。このポリシーは、productpage マイクロサービスからの受信トラフィックのみを許可します。 ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: details-policy namespace: default spec: podSelector: matchLabels: app: details policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: productpage ``` 1. reviews ネットワークポリシーを定義するファイルを `network-policy-reviews.yaml` という名前で作成します。このポリシーは、productpage マイクロサービスからの受信トラフィックと、ratings マイクロサービスと CoreDNS への送信トラフィックのみを許可します。 ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: reviews-policy namespace: default spec: podSelector: matchLabels: app: reviews policyTypes: - Ingress - Egress ingress: - from: - podSelector: matchLabels: app: productpage egress: - to: - podSelector: matchLabels: app: ratings - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system podSelector: matchLabels: k8s-app: kube-dns ports: - port: 53 protocol: UDP - port: 53 protocol: TCP ``` 1. ratings ネットワークポリシーを定義するファイルを `network-policy-ratings.yaml` という名前で作成します。このポリシーは、productpage マイクロサービスと reviews マイクロサービスからの受信トラフィックのみを許可します。 ``` apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: ratings-policy namespace: default spec: podSelector: matchLabels: app: ratings policyTypes: - Ingress ingress: - from: - podSelector: matchExpressions: - key: app operator: In values: ["productpage", "reviews"] ``` 1. クラスターに details、reviews、ratings の各ネットワークポリシーを適用します。 ``` kubectl apply -f network-policy-details.yaml kubectl apply -f network-policy-reviews.yaml kubectl apply -f network-policy-ratings.yaml ``` 1. curl ポッドに接続して、Bookinfo アプリケーションへのアクセスをテストします。以下の例では、productpage ポッド (`10.86.2.193`) のポッド IP アドレスを使用して、マイクロサービスをクエリします。この IP アドレスをお使いの環境の productpage ポッドのポッド IP アドレスに置き換えます。 ``` kubectl attach curl-pod -c curl-pod -i -t ``` details マイクロサービスをテストします。 ``` curl -s http://10.86.2.193:9080/api/v1/products/1 ``` ``` {"id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890"} ``` reviews マイクロサービスをテストします。 ``` curl -s http://10.86.2.193:9080/api/v1/products/1/reviews ``` ``` {"id": "1", "podname": "reviews-v1-598b896c9d-p2289", "clustername": "null", "reviews": [{"reviewer": "Reviewer1", "text": "An extremely entertaining play by Shakespeare. The slapstick humour is refreshing!"}, {"reviewer": "Reviewer2", "text": "Absolutely fun and entertaining. The play lacks thematic depth when compared to other plays by Shakespeare."}]} ``` ratings マイクロサービスをテストします。 ``` curl -s http://10.86.2.193:9080/api/v1/products/1/ratings ``` ``` {"id": 1, "ratings": {"Reviewer1": 5, "Reviewer2": 4}} ``` 1. この手順で作成したリソースをクリーンアップします。 ``` kubectl delete -f network-policy-deny-bookinfo.yaml kubectl delete -f network-policy-productpage.yaml kubectl delete -f network-policy-details.yaml kubectl delete -f network-policy-reviews.yaml kubectl delete -f network-policy-ratings.yaml kubectl delete -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml kubectl delete pod curl-pod ``` # ハイブリッドノードの概念 *Amazon EKS Hybrid Nodes* を使用すると、オンプレミス環境またはエッジ環境で実行されている物理マシンまたは仮想マシンを、AWS クラウドで実行されている Amazon EKS クラスターに接続できます。このアプローチには多くの利点がありますが、単一のネットワーク環境で Kubernetes クラスターを運用することに慣れているユーザーにとっては、新しいネットワークの概念やアーキテクチャが導入されることにもなります。 以下のセクションでは、EKS Hybrid Nodes での Kubernetes とネットワーキングの概念、およびハイブリッドアーキテクチャにおけるトラフィックフローについて詳しく説明します。これらのセクションを理解するには、ポッド、ノード、サービス、Kubernetes コントロールプレーン、kubelet、kube-proxy の概念など、Kubernetes ネットワークに関する基本的な知識に精通している必要があります。 これらのページは、「[ハイブリッドノードにおけるネットワーキングの概念](hybrid-nodes-concepts-networking.md)」、「[ハイブリッドノードにおける Kubernetes の概念](hybrid-nodes-concepts-kubernetes.md)」、「[ハイブリッドノード向けネットワークトラフィックフロー](hybrid-nodes-concepts-traffic-flows.md)」の順に読むことをお勧めします。 **Topics** + [ハイブリッドノードにおけるネットワーキングの概念](hybrid-nodes-concepts-networking.md) + [ハイブリッドノードにおける Kubernetes の概念](hybrid-nodes-concepts-kubernetes.md) + [ハイブリッドノード向けネットワークトラフィックフロー](hybrid-nodes-concepts-traffic-flows.md) # ハイブリッドノードにおけるネットワーキングの概念 このセクションでは、EKS Hybrid Nodes のネットワークトポロジー設計の際に考慮すべき、コアネットワーキングの概念と制約について詳しく説明します。 ## EKS Hybrid Nodes におけるネットワーキングの概念 ![\[ハイブリッドノードのネットワーク概要図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/hybrid-nodes-highlevel-network.png) **ネットワークハブとしての VPC** クラウドの境界を越えるすべてのトラフィックは VPC を経由しますが、これには、AWS で稼働する EKS コントロールプレーンまたはポッドや、ハイブリッドノードまたはそうしたノードで稼働しているポッド間のトラフィックも含まれます。クラスターの VPC はハイブリッドノードと残りのクラスター部分のネットワークハブとして機能している、と考えるとよいでしょう。このアーキテクチャによってトラフィックとそのルーティングを完全に制御できますが、これを導入するには、VPC のルート、セキュリティグループ、ファイアウォールを適切に設定する責任を負うことにもなります。 **EKS コントロールプレーンから VPC に向かうトラフィック** EKS コントロールプレーンにより、**Elastic Network Interface (ENI)** が VPC にアタッチされ、これらの ENI によって、EKS API サーバーとの間でトラフィックが処理されます。EKS コントロールプレーンの ENI の配置は、クラスターを設定する際に制御します。なぜなら、クラスターの作成中に渡すサブネットに ENI がアタッチされるからです。 EKS では、セキュリティグループを、サブネットにアタッチする ENI に関連付けます。こうしたセキュリティグループにより、EKS コントロールプレーンとの間のトラフィックを、ENI を介して許可します。この点が EKS Hybrid Nodes では重要となります。ハイブリッドノードとそこで稼働しているポッドから EKS コントロールプレーン ENI へのトラフィックを許可する必要があるからです。 **リモートノードネットワーク** リモートノードネットワーク、具体的にはリモートノード CIDR は、ハイブリッドノードとして使用するマシンに割り当てる IP アドレスの範囲を意味します。ハイブリッドノードをプロビジョニングすると、それらはオンプレミスのデータセンターやエッジロケーションに配置されます。これらのネットワークドメインは、EKS コントロールプレーンおよび VPC のドメインとは異なります。また、各ハイブリッドノードには、IP アドレスが 1 つまたは複数あり、VPC 内のサブネットとは異なるリモートノード CIDR に基づいて設定されています。 こうしたリモートノード CIDR を使用して EKS クラスターを構成すると、EKS でそれが認識され、ハイブリッドノードの IP アドレスを宛先としたすべてのトラフィック (kubelet API へのリクエストなど) をクラスターの VPC 経由でルーティングできるようになります。`kubelet` API への接続は、`kubectl attach`、`kubectl cp`、`kubectl exec`、`kubectl logs`、`kubectl port-forward` の各コマンドで使用されます。 **リモートポッドネットワーク** ここでのリモートポッドネットワークとは、ハイブリッドノードで稼働するポッドに割り当てる IP アドレスの範囲を意味します。一般的には、これらの範囲で CNI を設定すると、CNI の IP Address Manager (IPAM) 機能によって、その範囲の一部が各ハイブリッドノードに割り当てられます。また、新規作成したポッドには、ポッドをスケジュールしたノードに割り当てた IP アドレスからアドレスが割り当てられます。 こうしたリモートポッド CIDR を使用して EKS クラスターを設定すると、EKS コントロールプレーンでそれが認識され、ハイブリッドノードで稼働しているポッドを宛先とするすべてのトラフィック (ウェブフックとの通信など) をクラスターの VPC 経由でルーティングできます。 ![\[リモートポッドネットワーク\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/hybrid-nodes-remote-pod-cidrs.png) **オンプレミスから VPC に向かうトラフィック** ハイブリッドノードに使用するオンプレミスネットワークのトラフィックは、EKS クラスターに使用する VPC にルーティングする必要があります。オンプレミスネットワークを VPC に接続する場合、複数用意されている [Network-to-Amazon VPC 接続オプション](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html)を利用することも、独自の VPN ソリューションを使用することもできます。 ここで重要なのは、AWS クラウド側の VPC とオンプレミスネットワーク間のルーティングを正しく設定することで、両方のネットワークの接続点を介して、適切なトラフィックが相互にルーティングされるようにすることです。 VPC では、リモートノードおよびリモートポッドネットワークに向かうすべてのトラフィックを、オンプレミスネットワークとの接続点 (ゲートウェイ) 経由でルーティングする必要があります。サブネットの一部に異なるルートテーブルがある場合は、ハイブリッドノードとそこで稼働しているポッドのルートを各ルートテーブルに設定する必要があります。これは、EKS コントロールプレーンの ENI がアタッチされるサブネットや、ハイブリッドノードと通信する必要のある EC2 のノードまたはポッドが含まれるサブネットにも当てはまります。 オンプレミスネットワークでは、ネットワークの設定によって、EKS クラスターの VPC や、ハイブリッドノードに必要なその他の AWS サービスとの間で生じるトラフィックを許可する必要があります。EKS クラスターのトラフィックは、ゲートウェイを双方向に通過することになります。 ## ネットワーキング上の制約 **完全にルーティングされたネットワーク** ここでの主な制約は、EKS コントロールプレーンとすべてのノード (クラウドまたはハイブリッドのノード) で生じるトラフィックが**完全にルーティング**されるネットワークを形成する必要があることです。つまり、すべてのノードが IP アドレスを使用してレイヤー 3 で互いに到達可能でなければなりません。 EKS コントロールプレーンとクラウドノードはフラットなネットワーク (VPC) 内にあるため、相互に到達可能な状態にありますが、ハイブリッドノードは異なるネットワークドメインに存在しています。そのため、VPC とオンプレミスネットワークでルーティング設定を追加して、ハイブリッドノードと他のクラスター部分との間で生じるトラフィックをルーティングする必要があります。ハイブリッドノードが互いに到達可能で、VPC からも到達可能な場合、ハイブリッドノードは、単一のフラットネットワークに配置することも、セグメント化した複数のネットワークに配置することもできます。 **ルーティング可能なリモートポッド CIDR** EKS コントロールプレーンがハイブリッドノードで稼働中のポッド (ウェブフックやメトリクスサーバーなど) と通信したり、クラウドノードで稼働中のポッドがハイブリッドノードで稼働中のポッドと通信 (ワークロードの East-West 通信) したりするには、リモートポッドの CIDR へのトラフィックが VPC からルーティング可能でなければなりません。つまり、VPC では、ポッドの CIDR に向かうトラフィックをゲートウェイ経由でオンプレミスネットワークにルーティングでき、オンプレミスネットワークでは、ポッドのトラフィックを適切なノードにルーティングできる必要があります。 ここで重要なのは、VPC とオンプレミスでポッドのルーティング要件に違いがあることです。VPC には、リモートポッドへのトラフィックがゲートウェイを通過する必要があることを認識させるだけで済み、リモートポッドの CIDR が 1 つしかない場合は、必要なルートも 1 つのみです。 この要件は、オンプレミスネットワーク内の、ハイブリッドノードと同じサブネットでローカルルーターに至るまでに生じるすべてのホップに当てはまります。このルーターは、各ノードに割り当てられたポッド CIDR スライスを認識する必要がある唯一のルーターです。これにより、特定のポッドに向かうトラフィックを、そのポッドがスケジュールされているノードに配信できます。 オンプレミスのポッド CIDR へのこうしたルートを、ローカルのオンプレミスルーターから VPC ルートテーブルに伝達することもできますが、これは必須ではありません。オンプレミスのポッド CIDR を頻繁に変更しているため、VPC ルートテーブルを更新してそれらの変更を反映する必要がある場合は、オンプレミスのポッド CIDR を VPC ルートテーブルに伝達することが推奨されます。しかし、こうしたケースはまれです。 オンプレミスのポッド CIDR へのルーティングは、必ずしも設定する必要はありません。ハイブリッドノードでウェブフックを実行する必要がない場合、またはクラウドノード上のポッドがハイブリッドノード上のポッドと通信する必要がない場合は、オンプレミスネットワークのポッド CIDR へのルーティングを設定しなくても済みます。 *では、ハイブリッドノードを使用するときに、オンプレミスのポッド CIDR 宛てトラフィックをルーティング可能にする理由について説明します。* VPC CNI を備えた EKS をクラウドノードに使用している場合、VPC CNI によって VPC からポッドに直接 IP が割り当てられます。つまり、クラウドポッドも EKS コントロールプレーンもポッド IP に直接到達できるため、特別なルーティングは必要ありません。 オンプレミスでポッドが稼働している場合 (クラウドで他の CNI を使用)、ポッドは、通常、分離されたオーバーレイネットワークで実行され、CNI によってポッド間のトラフィック配信が処理されます。これは通常、カプセル化によって行われます。つまり、ポッド間のトラフィックをノード間のトラフィックに変換し、両端でカプセル化とカプセル化解除を行います。そのため、ノードとルーターに設定をさらに追加する必要はありません。 ハイブリッドノードを使用したネットワークは、両方のトポロジーが組み合わさっているという点で独特なものです。つまり、EKS コントロールプレーンとクラウドノード (VPC CNI を使用) は、ノードとポッドが含まれるフラットなネットワークを想定して動作し、一方、ハイブリッドノードで稼働するポッドは、オーバーレイネットワーク内に存在し、カプセル化には VXLAN (Cilium のデフォルト) が使用されます。ハイブリッドノードで稼働するポッドは、オンプレミスネットワークと VPC 間のルーティングが可能であることを前提に、EKS コントロールプレーンとクラウドノードで稼働中のポッドに到達できます。ただし、オンプレミスネットワークのポッド CIDR 宛てトラフィックをルーティングしておらず、オーバーレイネットワークに到達したトラフィックを適切なノードに転送できない場合、オンプレミスのポッド IP に戻るトラフィックは、最終的にドロップされます。 # ハイブリッドノードにおける Kubernetes の概念 このページでは、EKS Hybrid Nodes システムアーキテクチャを支える Kubernetes の主要な概念について詳しく説明します。 ## VPC の EKS コントロールプレーン EKS コントロールプレーン ENI の IP は、`default` デフォルトの名前空間にある `kubernetes` `Endpoints` オブジェクトに保存されます。EKS では、ENI の新規作成や削除が行わると、このオブジェクトが更新され、IP リストが常に最新状態に保たれます。 これらのエンドポイントは、`kubernetes` サービスを通じて使用できます。このサービスも `default` の名前空間に存在します。この `ClusterIP` タイプのサービスには、クラスターのサービス CIDR に含まれる最初の IP が割り当てられます。例えば、サービス CIDR が `172.16.0.0/16` の場合、サービス IP は `172.16.0.1` になります。 通常、ポッドは (稼働がクラウドノード上かハイブリッドノード上かに関係なく) そのように EKS Kubernetes API サーバーにアクセスします。サービス IP を宛先 IP として使用し、これをいずれかの EKS コントロールプレーン ENI に設定されている実際の IP に変換します。こうした動作の主な例外として `kube-proxy` があります。これによって変換を設定するからです。 ## EKS API サーバーエンドポイント EKS API サーバーには `kubernetes` サービス IP 以外の方法でもアクセスできます。EKS では、クラスター作成時に Route53 DNS 名も作成されます。これが、EKS の `endpoint` API アクションを呼び出す際に、EKS クラスターの `DescribeCluster` フィールド値になります。 ``` { "cluster": { "endpoint": "https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com", "name": "my-cluster", "status": "ACTIVE" } } ``` パブリックエンドポイントアクセスクラスター、もしくはパブリックおよびプライベートエンドポイントアクセスクラスターでは、ハイブリッドノードで、この DNS 名がインターネット経由でルーティング可能なパブリック IP に解決されます (デフォルトの場合)。プライベートエンドポイントアクセスクラスターの場合、DNS 名は、EKS コントロールプレーン ENI のプライベート IP に解決されます。 `kubelet` と `kube-proxy` は、そのように Kubernetes API サーバーにアクセスします。すべての Kubernetes クラスタートラフィックを VPC 経由にする場合、クラスターをプライベートアクセスモードで設定するか、オンプレミスの DNS サーバーを変更して EKS クラスターエンドポイントを EKS コントロールプレーン ENI のプライベート IP に解決する必要があります。 ## `kubelet` エンドポイント `kubelet` では複数の REST エンドポイントが公開されており、これによってシステムの他の要素は、kubelet と通信し、各ノードの情報を収集しています。ほとんどのクラスターにおいて、`kubelet` サーバーに向かうトラフィックの大部分は、コントロールプレーンで生じたものですが、特定のモニタリングエージェントも kubelet と通信する場合があります。 このインターフェイスを通じて、`kubelet` では、ログの取得 (`kubectl logs`)、コンテナ内でのコマンド実行 (`kubectl exec`)、トラフィックのポート転送 (`kubectl port-forward`) といった各種リクエストが処理されます。こうしたリクエストでは、基盤のコンテナランタイム環境との通信が `kubelet` を介して行われるため、クラスター管理者や開発者にとってシームレスなユーザー体験が実現します。 この API で最も一般的なコンシューマーとなるのは Kubernetes API サーバーです。上記の `kubectl` コマンドのいずれかを使用すると、`kubectl` が API サーバーに API リクエストを送信し、その後 API サーバーが、ポッドが稼働しているノードの `kubelet` API を呼び出します。そのため、多くの場合、ノード IP が EKS コントロールプレーンから到達可能である必要があります。また、ノードルートを誤って設定すると、ポッドが稼働中であっても、ログや `exec` コマンドを利用できません。 **ノード IP** EKS コントロールプレーンは、ノードと通信する際に、`Node` オブジェクトのステータス (`status.addresses`) で報告されるアドレスの 1 つを使用します。 EKS クラウドノードでは、一般的に、ノード登録時に kubelet が EC2 インスタンスのプライベート IP を `InternalIP` として報告します。その後、Cloud Controller Manager (CCM) がこの IP を検証し、それが EC2 インスタンスに属していることを確認します。さらに、CCM は通常、インスタンスのパブリック IP (`ExternalIP`) と DNS 名 (`InternalDNS` と `ExternalDNS`) をノードステータスに追加します。 ただし、ハイブリッドノードには CCM はありません。EKS Hybrid Nodes CLI (`nodeadm`) を使用してハイブリッドノードを登録すると、CCM を介さずにノードのステータスでマシンの IP が直接報告されるように kubelet が設定されます。 ``` apiVersion: v1 kind: Node metadata: name: my-node-1 spec: providerID: eks-hybrid:///us-west-2/my-cluster/my-node-1 status: addresses: - address: 10.1.1.236 type: InternalIP - address: my-node-1 type: Hostname ``` マシンに複数の IP がある場合、kubelet は独自のロジックに従ってそれらの 1 つを選択します。選択される IP アドレスは `--node-ip` フラグで制御でき、このフラグは、`nodeadm` config の `spec.kubelet.flags` に渡すことが可能です。`Node` オブジェクトで報告された IP アドレスにのみ VPC からのルートが必要であり、マシンには、クラウドからアクセスできない他の IP アドレスを割り当てることができます。 ## `kube-proxy` `kube-proxy` は、各ノードのネットワークレイヤーでサービス抽象化を実装する役割を果たし、Kubernetes サービスに向かうトラフィックのネットワークプロキシおよびロードバランサーとして機能します。また、`kube-proxy` は、Kubernetes API サーバーを監視し、サービスとエンドポイントに関連した変更を継続的に確認することで、基盤となるホストのネットワークルールを動的に更新し、適切なトラフィック転送を維持します。 `iptables` モードの `kube-proxy` は、複数の `netfilter` チェーンをプログラミングして、サービストラフィックを処理します。こうしたルールによって、以下の階層が形成されます。 1. **KUBE-SERVICES チェーン**: すべてのサービストラフィックのエントリポイント。各サービスの `ClusterIP` とポートに一致するルールが定義されています。 1. **KUBE-SVC-XXX チェーン**: サービス固有のチェーンに、各サービスの負荷分散ルールが定義されています。 1. **KUBE-SEP-XXX チェーン**: エンドポイント固有のチェーンに、実際の `DNAT` ルールが定義されています。 次に示す `default` 名前空間内のサービス `test-server` の状況を確認してみましょう。\$1 サービス ClusterIP: `172.16.31.14` \$1 サービスポート: `80` \$1 バッキングポッド: `10.2.0.110`, `10.2.1.39`, `10.2.2.254` `iptables` ルールを検査するとき (`iptables-save –0— grep -A10 KUBE-SERVICES` を使用): 1. **KUBE-SERVICES** チェーンには、以下のように、サービスに一致するルールがあります。 ``` -A KUBE-SERVICES -d 172.16.31.14/32 -p tcp -m comment --comment "default/test-server cluster IP" -m tcp --dport 80 -j KUBE-SVC-XYZABC123456 ``` + このルールは、172.16.31.14:80 宛てのパケットに一致させる + コメントは、このルールの目的を示している: `default/test-server cluster IP` + 一致するパケットは `KUBE-SVC-XYZABC123456` チェーンにジャンプさせる 1. **KUBE-SVC-XYZABC123456** チェーンには、確率ベースの負荷分散ルールが定義されています。 ``` -A KUBE-SVC-XYZABC123456 -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-POD1XYZABC -A KUBE-SVC-XYZABC123456 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-POD2XYZABC -A KUBE-SVC-XYZABC123456 -j KUBE-SEP-POD3XYZABC ``` + 最初のルール: 33.3% の確率で `KUBE-SEP-POD1XYZABC` にジャンプさせる + 2 番目のルール: 50% の確率で残りのトラフィック (全体の 33.3%) を `KUBE-SEP-POD2XYZABC` にジャンプさせる + 最後のルール: 残りのすべてのトラフィック (合計の 33.3%) を `KUBE-SEP-POD3XYZABC` にジャンプさせる 1. 個々の **KUBE-SEP-XXX** チェーンで、DNAT (宛先 NAT) を実行します。 ``` -A KUBE-SEP-POD1XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.0.110:80 -A KUBE-SEP-POD2XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.1.39:80 -A KUBE-SEP-POD3XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.2.254:80 ``` + これらの DNAT ルールでは、宛先 IP とポートを書き換えて、トラフィックを特定のポッドに転送します。 + 各ルールによって、トラフィックの約 33.3% を処理し、`10.2.0.110`、`10.2.1.39`、`10.2.2.254` の間で均等な負荷分散を行います。 このマルチレベルチェーン構造により、`kube-proxy` では、データパスにプロキシプロセスを必要とせずに、カーネルレベルのパケット操作によってサービスの負荷分散およびリダイレクトを効率的に実装できます。 ### Kubernetes 運用への影響 ノードで `kube-proxy` の機能が失われると、ノードはサービストラフィックを適切にルーティングできなくなり、クラスターサービスに依存するポッドのタイムアウトや接続の失敗が発生します。この問題が特に深刻になりうるのは、ノードが最初に登録されたときです。CNI では、ポッドネットワークを設定する前に、Kubernetes API サーバーと通信して、ノードのポッド CIDR などの情報を取得する必要があります。それを行うには、`kubernetes` サービス IP を使用します。ただし、`kube-proxy` が起動できなかったり、適切な `iptables` ルールを設定できなかったりした場合、`kubernetes` サービス IP へのリクエストは EKS コントロールプレーン ENI の実際の IP に変換されません。その結果、CNI がクラッシュループに陥り、どのポッドも正しく稼働しなくなります。 前述したように、ポッドは Kubernetes API サーバーとの通信に `kubernetes` のサービス IP を使用しますが、そのように動作させるには、最初に `kube-proxy` に `iptables` ルールを設定する必要があります。 `kube-proxy` は、どのように API サーバーと通信するのでしょうか? `kube-proxy` は、Kubernetes API サーバーの実際の IP アドレス、またはそれらに解決される DNS 名を使用するように設定する必要があります。EKS の場合、デフォルトの `kube-proxy` が、クラスター作成時に EKS によって作成される Route53 DNS 名を指すように設定されます。この値は、`kube-system` 名前空間の `kube-proxy` ConfigMap で確認できます。この ConfigMap の内容は、`kube-proxy` ポッドに注入される `kubeconfig` であるため、`clusters–0—.cluster.server` フィールドを確認してください。この値は、EKS `DescribeCluster` API を呼び出した結果にある、EKS クラスターの `endpoint` フィールドと一致しています。 ``` apiVersion: v1 data: kubeconfig: |- kind: Config apiVersion: v1 clusters: - cluster: certificate-authority: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt server: https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com name: default contexts: - context: cluster: default namespace: default user: default name: default current-context: default users: - name: default user: tokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token kind: ConfigMap metadata: name: kube-proxy namespace: kube-system ``` ## ルーティング可能なリモートポッド CIDR この [ハイブリッドノードにおけるネットワーキングの概念](hybrid-nodes-concepts-networking.md) のページでは、ハイブリッドノードでウェブフックを実行したり、クラウドノードで稼働しているポッドがハイブリッドノードで稼働しているポッドと通信したりするための要件について詳しく説明します。ここでは重要な要件があります。特定のポッド IP を担当するノードを、オンプレミスルーターに認識させる必要があることです。これを実現する方法として、ボーダーゲートウェイプロトコル (BGP)、静的ルート、アドレス解決プロトコル (ARP) プロキシなどが挙げられます。以下のセクションでは、これらの方法について説明します。 **ボーダーゲートウェイプロトコル (BGP)** CNI でサポートされている場合 (Cilium や Calico など)、CNI の BGP モードを使用して、ノードごとのポッド CIDR へのルートをノードからローカルルーターに伝達できます。CNI の BGP モードを使用する場合、CNI は仮想ルーターとして機能するため、ローカルルーターは、ポッド CIDR が別のサブネットに属し、ノードはそのサブネットへのゲートウェイであると認識します。 ![\[ハイブリッドノード BGP ルーティング\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/hybrid-nodes-bgp.png) **静的ルート** または、ローカルルーターで静的ルートを設定することもできます。この方法を取ると、オンプレミスポッド CIDR を VPC に非常に簡単にルーティングできますが、最もエラーが発生しやすく、保守も困難になります。ルートが既存のノードと割り当てられたポッド CIDR で、常に最新の状態であることを確認しなければなりません。ノードの数が少なく、インフラストラクチャが静的である場合、これは実行可能なオプションであり、ルーターでの BGP 対応も不要になります。この方法を取る場合は、アドレスを IPAM によって決定せず、各ノードに割り当てるポッド CIDR スライスを使用して CNI を設定することをお勧めします。 ![\[ハイブリッドノードの静的ルーティング\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/hybrid-nodes-static-routes.png) **アドレス解決プロトコル (ARP) プロキシ** ARP プロキシは、オンプレミスのポッド IP をルーティング可能にするもう 1 つのアプローチであり、特に、ハイブリッドノードがローカルルーターと同じレイヤー 2 ネットワークにある場合に便利です。ARP プロキシを有効にすると、ノードは、その IP が別のサブネットに属している場合でも、ホストするポッド IP の ARP リクエストに応答します。 ローカルネットワーク上のデバイスがポッド IP に到達を試みる場合、最初に「この IP を持っているなら応答せよ」という ARP リクエストを送信します。該当するポッドをホストしているハイブリッドノードは、自分の MAC アドレスで応答し、「その IP のトラフィックを処理できます」と伝えます。これによって、ルーター設定を必要とせずに、ローカルネットワーク上のデバイスとポッドの間に直接のパスが作成されます。 これを機能させるには、CNI がプロキシ ARP 機能に対応している必要があります。Cilium は、設定によってプロキシ ARP を有効化できるように設計されています。ここで特に考慮すべき点は、ポッド CIDR が環境内の他のネットワークと重複しないようにすることです。重複すると、ルーティングの競合が生じる可能性があるからです。 このアプローチには、次のような利点があります。\$1 BGP でルーターを設定する必要はなく、静的ルートを維持する必要もない。\$1 ルーター設定を制御できない環境でも効果的に機能する。 ![\[ハイブリッドノード ARP プロキシ\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/hybrid-nodes-arp-proxy.png) ## ポッド間でのカプセル化 オンプレミス環境の CNI では、通常、カプセル化プロトコルによって、物理ネットワーク上で動作するオーバーレイネットワークが作成されます。この場合、再設定が不要になります。このセクションでは、このカプセル化の仕組みについて説明します。使用している CNI によっては、一部の詳細情報が異なる場合があります。 カプセル化では、元のポッドネットワークパケットを、基盤の物理ネットワークを介してルーティング可能な別のネットワークパケット内にラップします。これによって、ポッドの CIDR のルーティング方法が物理ネットワークで認識されていなくても、同じ CNI を実行しているノード間でポッドが通信できます。 Kubernetes で使用される最も一般的なカプセル化プロトコルは Virtual Extensible LAN (VXLAN) ですが、CNI に応じて、他のプロトコル (`Geneve` など) も利用できます。 ### VXLAN カプセル化 VXLAN では、UDP パケット内にレイヤー 2 イーサネットフレームをカプセル化します。ポッドが別のノードにある別のポッドにトラフィックを送信すると、CNI では、以下が実行されます。 1. ポッド A からのパケットをインターセプトする 1. 元のパケットを VXLAN ヘッダーにラップする 1. ラップしたパケットを、ノードの通常のネットワークスタックを介して宛先ノードに送信する 1. 宛先ノードの CNI が、パケットをラップ解除し、ポッド B に配信する VXLAN カプセル化中のパケット構造の変化を次に示します。 元のポッド間パケット ``` +-----------------+---------------+-------------+-----------------+ | Ethernet Header | IP Header | TCP/UDP | Payload | | Src: Pod A MAC | Src: Pod A IP | Src Port | | | Dst: Pod B MAC | Dst: Pod B IP | Dst Port | | +-----------------+---------------+-------------+-----------------+ ``` VXLAN カプセル化後 ``` +-----------------+-------------+--------------+------------+---------------------------+ | Outer Ethernet | Outer IP | Outer UDP | VXLAN | Original Pod-to-Pod | | Src: Node A MAC | Src: Node A | Src: Random | VNI: xx | Packet (unchanged | | Dst: Node B MAC | Dst: Node B | Dst: 4789 | | from above) | +-----------------+-------------+--------------+------------+---------------------------+ ``` この VXLAN ネットワーク識別子 (VNI) によって、異なるオーバーレイネットワークが区別されます。 ### ポッド通信のシナリオ **同じハイブリッドノード上のポッド** 同じハイブリッドノード上のポッドが通信する場合、通常はカプセル化は必要ありません。CNI では、ローカルルートが設定されます。これにより、ノードの内部仮想インターフェイスを介してポッド間のトラフィックを転送します。 ``` Pod A -> veth0 -> node's bridge/routing table -> veth1 -> Pod B ``` パケットはノードから出ることはなく、カプセル化を必要としません。 **異なるハイブリッドノード上のポッド** 異なるハイブリッドノード上のポッド間で通信するには、カプセル化が必要です。 ``` Pod A -> CNI -> [VXLAN encapsulation] -> Node A network -> router or gateway -> Node B network -> [VXLAN decapsulation] -> CNI -> Pod B ``` これにより、物理ネットワークでポッド IP のルーティングが認識されていなくても、ポッドトラフィックは、物理ネットワークインフラストラクチャを通過できます。 # ハイブリッドノード向けネットワークトラフィックフロー このページでは、EKS ハイブリッドノード向けネットワークトラフィックフローについて、いくつかのトラフィックタイプ別にエンドツーエンドでネットワークパスの図を示しながら詳しく説明します。 以下のトラフィックフローを取り上げます。 + [ハイブリッドノード `kubelet` から EKS コントロールプレーンまでのフロー](#hybrid-nodes-concepts-traffic-flows-kubelet-to-cp) + [EKS コントロールプレーンからハイブリッドノード (`kubelet` サーバー) までのフロー](#hybrid-nodes-concepts-traffic-flows-cp-to-kubelet) + [ハイブリッドノードで実行されているポッドから EKS コントロールプレーンまでのフロー](#hybrid-nodes-concepts-traffic-flows-pods-to-cp) + [EKS コントロールプレーンからハイブリッドノードで実行されているポッドまでのフロー (ウェブフック)](#hybrid-nodes-concepts-traffic-flows-cp-to-pod) + [ハイブリッドノードで実行されているポッド間](#hybrid-nodes-concepts-traffic-flows-pod-to-pod) + [クラウドノード上のポッドからハイブリッドノード上のポッドまでのフロー (東西トラフィック)](#hybrid-nodes-concepts-traffic-flows-east-west) ## ハイブリッドノード `kubelet` から EKS コントロールプレーンまでのフロー ![\[ハイブリッドノード kubelet から EKS コントロールプレーンまでのフロー\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/hybrid-nodes-kubelet-to-cp-public.png) ### リクエスト **1`kubelet`. がリクエストを開始する** ハイブリッドノード上の `kubelet` が EKS コントロールプレーンと通信する必要がある場合 (例えば、ノードステータスを報告するため、あるいはポッドの仕様を取得するため) には、ノード登録時に提供された `kubeconfig` ファイルが使用されます。この `kubeconfig` には、ダイレクト IP アドレスではなく、API サーバーエンドポイント URL (Route53 DNS 名) が記載されています。 `kubelet` がエンドポイントに対して DNS ルックアップを実行します (例: `https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com`)。パブリックアクセスクラスターでは、これは AWS で実行中の EKS サービスに属するパブリック IP アドレス (例: `54.239.118.52`) に解決されます。次に `kubelet` は、このエンドポイントへの安全な HTTPS リクエストを作成します。初期パケットは以下のようになります。 ``` +--------------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 52390 (random) | | | Dst: 54.239.118.52 | Dst: 443 | | +--------------------+---------------------+-----------------+ ``` **2. ローカルルーターのルーティング** 宛先 IP はパブリック IP アドレスであり、ローカルネットワークの一部ではないため、`kubelet` はこのパケットをそのデフォルトゲートウェイ (ローカルオンプレミスルーター) に送信します。ルーターは、宛先 IP を確認して、パブリック IP アドレスであると判断します。 パブリックトラフィックの場合、ルーターは通常、パケットをインターネットゲートウェイ、つまりインターネットへのアウトバウンドトラフィックを処理するボーダールーターに転送します。図では、これを省略しています。実際の転送は、オンプレミスネットワークがどのように設定されているかによって異なります。パケットは、オンプレミスのネットワークインフラストラクチャを通っていき、最終的にインターネットサービスプロバイダーのネットワークに到達します。 **3. EKS コントロールプレーンまでの配信** パケットは、パブリックインターネットとトランジットネットワークを横断していき、AWS のネットワークに到達します。AWS のネットワークは、パケットを適切なリージョンの EKS サービスエンドポイントにルーティングします。EKS サービスに到達したパケットは、クラスターの実際の EKS コントロールプレーンに転送されます。 これはパブリックインターネットを通るルーティングであり、他のトラフィックフローで見られるようなプライベート VPC をルーティングされていくパスとは異なります。その主な違いは、パブリックアクセスモードを使用した場合、ポッドからではなくオンプレミスの `kubelet` から EKS コントロールプレーンへのトラフィックが VPC を経由せず、代わりにグローバルインターネットインフラストラクチャを使用することです。 ### 応答 EKS コントロールプレーンは、`kubelet` リクエストを処理してレスポンスを返します。 **3. EKS コントロールプレーンがレスポンスを送信する** EKS コントロールプレーンはレスポンスパケットを作成します。このパケットには、ソースとしてパブリック IP、送信先としてハイブリッドノードの IP が含まれています。 ``` +--------------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 54.239.118.52 | Src: 443 | | | Dst: 10.80.0.2 | Dst: 52390 | | +--------------------+---------------------+-----------------+ ``` **2. インターネットでのルーティング** レスポンスパケットは、インターネットサービスプロバイダーが決定したルーティングパスをたどってインターネット経由で戻り、オンプレミスネットワークのエッジルーターに到達します。 **1. ローカルでの配信** オンプレミスのルーターは、パケットを受信し、宛先 IP (`10.80.0.2`) がローカルネットワークに属していると認識します。次に、受信したパケットをローカルネットワークインフラストラクチャ経由で転送します。パケットがターゲットのハイブリッドノードに到達すると、`kubelet` がレスポンスを受信して処理します。 ## ハイブリッドノード `kube-proxy` から EKS コントロールプレーンまでのフロー クラスターのパブリックエンドポイントアクセスを有効にすると、戻りのトラフィックはパブリックインターネットを使用します。このトラフィックは、ハイブリッドノードの `kube-proxy` から EKS コントロールプレーンへと進み、`kubelet` から EKS コントロールプレーンへのトラフィックと同じパスを通ります。 ## EKS コントロールプレーンからハイブリッドノード (`kubelet` サーバー) までのフロー ![\[EKS コントロールプレーンからハイブリッドノードまでのフロー\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/hybrid-nodes-cp-to-kubelet.png) ### リクエスト **1. EKS Kubernetes API サーバーがリクエストを開始する** EKS Kubernetes API サーバーは、ノードオブジェクトのステータスからノードの IP アドレス (`10.80.0.2`) を取得します。次に、送信先 IP が設定済みのリモートノード CIDR (`10.80.0.0/16`) に属しているため、このリクエストを VPC 内の ENI 経由でルーティングします。初期パケットは以下のようになります。 ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 67493 (random) | | | Dst: 10.80.0.2 | Dst: 10250 | | +-----------------+---------------------+-----------------+ ``` **2. VPC ネットワークでの処理** パケットは、ENI を出て VPC ネットワーキングレイヤーに入り、さらにルーティングするためにサブネットのゲートウェイ宛てに送信されます。 **3. VPC ルートテーブルのルックアップ** EKS コントロールプレーン ENI が含まれているサブネット用の VPC ルートテーブルには、リモートノード CIDR に固有のルート (図の 2 番目のルート) が登録されています。このルーティングルールに基づいて、パケットが VPC-to-onprem ゲートウェイに向けて送信されます。 **4. 境界を越えて移動する** ゲートウェイは、確立済みの接続 (Direct Connect や VPN など) 経由でクラウド境界を越えてオンプレミスネットワークにパケットを転送します。 **5. オンプレミスネットワークでの受信** パケットは、ハイブリッドノードが配置されているサブネット宛てのトラフィックを処理するローカルオンプレミスルーターに到達します。 **6. 最後の配信** ローカルルーターは、宛先 IP (`10.80.0.2`) アドレスが自身に直接接続されているネットワークに属しているかどうかを識別して、ターゲットのハイブリッドノードに直接パケットを転送し、そこで `kubelet` がリクエストを受信して処理します。 ### 応答 ハイブリッドノードの `kubelet` は、リクエストを処理してレスポンスを返します。レスポンスは、同じパスを逆方向にたどります。 ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 10250 | | | Dst: 10.0.0.132 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` **6. `kubelet` レスポンスを送信する** ハイブリッドノード (`10.80.0.2`) 上の `kubelet` は、送信元の IP を宛先としてレスポンスパケットを作成します。その宛先はローカルネットワークに属していないため、パケットはホストのデフォルトゲートウェイ、つまりローカルルーターに送信されます。 **5. ローカルルーターのルーティング** ルーターは、宛先 IP (`10.0.0.132`) が `10.0.0.0/16` に属していると判断します。ここには、AWS に接続しているゲートウェイを指すルートがあります。 **4. 境界を越えて戻る** パケットは、同じオンプレミスを通って VPC 接続 (Direct Connect や VPN など) まで戻り、クラウド境界を逆方向に横断します。 **3. VPC でのルーティング** パケットが VPC に到達すると、ルートテーブルは宛先 IP が VPC CIDR に属しているかどうかを識別します。パケットは VPC 内にルーティングされます。 **2. VPC ネットワークでの配信** VPC ネットワーキングレイヤーは、EKS コントロールプレーン ENI (`10.0.0.132`) を備えたサブネットにパケットを転送します。 **1. ENI での受信** パケットは、Kubernetes API サーバーにアタッチされている EKS コントロールプレーン ENI に到達します。これでラウンドトリップは完了です。 ## ハイブリッドノードで実行されているポッドから EKS コントロールプレーンまでのフロー ![\[ハイブリッドノードで実行されているポッドから EKS コントロールプレーンまでのフロー\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/hybrid-nodes-pod-to-cp.png) ### CNI NAT なし ### リクエスト ポッドは一般に、`kubernetes` サービスを介して Kubernetes API サーバーと対話します。サービス IP がクラスターのサービス CIDR の最初の IP となります。この規約により、CoreDNS が使用可能になる前に稼働する必要があるポッドが API サーバー (例えば、CNI) に到達できるようになります。リクエストは、サービス IP を宛先としてポッドを出ていきます。例えば、サービス CIDR が `172.16.0.0/16` である場合、サービス IP は `172.16.0.1` になります。 **1. ポッドがリクエストを開始する** ポッドは、ランダムな送信元ポートから API サーバーポート (443) 上の `kubernetes` サービス IP (`172.16.0.1`) にリクエストを送信します。パケットは以下のようになります。 ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 67493 (random) | | | Dst: 172.16.0.1 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` **2. CNI での処理** CNI は、宛先 IP が自身の管理するポッド CIDR に属していないことを検出します。**送信 NAT が無効になっている**ため、CNI はパケットを変更せずにホストネットワークスタックに渡します。 **3. ノードネットワークでの処理** パケットはノードのネットワークスタックに入り、そこで `netfilter` フックが kube-proxy によって設定された `iptables` ルールをトリガーします。以下の順序でルールがいくつか適用されます。 1. パケットはまず `KUBE-SERVICES` チェーンをヒットします。ここには、各サービスの ClusterIP とポートに対応するルールが含まれています。 1. その対応するルールは、`kubernetes` サービスの `KUBE-SVC-XXX` チェーンにジャンプします (`172.16.0.1:443` 宛てのパケット)。ここには、ロードバランシングルールが含まれています。 1. ロードバランシングルールは、コントロールプレーン ENI IP (`10.0.0.132` または `10.0.1.23`) 用に `KUBE-SEP-XXX` チェーンのいずれかをランダムに選択します。 1. 選択した `KUBE-SEP-XXX` チェーンには実際のルールがあり、それにより宛先 IP はサービス IP から選択されている IP に変更されます。これは、Destination Network Address Translation (宛先ネットワークアドレス変換、DNAT) と呼ばれます。 選択されている EKS コントロールプレーン ENI の IP を `10.0.0.132` とした場合、これらのルールが適用されると、パケットは以下のようになります。 ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 67493 (random) | | | Dst: 10.0.0.132 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` 宛先 IP がローカルネットワーク内にないため、ノードはパケットをデフォルトゲートウェイに転送します。 **4. ローカルルーターのルーティング** ローカルルーターは、宛先 IP (`10.0.0.132`) が VPC CIDR (`10.0.0.0/16`) に属していると判断して、AWS に接続しているゲートウェイに転送します。 **5. 境界を越えて移動する** パケットは、確立済みの接続 (Direct Connect や VPN など) 経由でクラウド境界を越えて VPC に移動します。 **6. VPC ネットワークでの配信** VPC ネットワーキングレイヤーは、EKS コントロールプレーン ENI (`10.0.0.132`) が存在する適切なサブネットにパケットをルーティングします。 **7. ENI での受信** パケットは、Kubernetes API サーバーにアタッチされている EKS コントロールプレーン ENI に到達します。 ### 応答 EKS コントロールプレーンは、リクエストを処理してポッドにレスポンスを返します。 **7. API サーバーがレスポンスを送信する** EKS Kubernetes API サーバーは、送信元の IP を宛先としてレスポンスパケットを作成します。パケットは以下のようになります。 ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 443 | | | Dst: 10.85.1.56 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` 宛先 IP が設定済みのリモートポッド CIDR (`10.85.0.0/16`) に属しているため、パケットはサブネットのルーターを次のホップとして VPC 内の ENI 経由で送信されます。 **6. VPC でのルーティング** VPC ルートテーブルにはリモートポッド CIDR (`10.85.0.0/16`) のエントリがあるため、このトラフィックは VPC-to-onprem ゲートウェイ宛てに送信されます。 **5. 境界を越えて移動する** ゲートウェイは、確立済みの接続 (Direct Connect や VPN など) 経由でクラウド境界を越えてオンプレミスネットワークにパケットを転送します。 **4. オンプレミスネットワークでの受信** パケットは、ローカルオンプレミスルーターに到達します。 **3. ノードへの配信** ルーターのテーブルには `10.80.0.2` を次のホップとした `10.85.1.0/24` のエントリがあるため、パケットはノードに配信されます。 **2. ノードネットワークでの処理** パケットがノードのネットワークスタックによって処理されると、`conntrack` (`netfilter` の一部) はポッドが最初に確立した接続とパケットを照合します。DNAT が最初に適用されたため、`conntrack` はソース IP を EKS コントロールプレーン ENI の IP から `kubernetes` サービス IP に書き換えることで DNAT を元に戻します。 ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 172.16.0.1 | Src: 443 | | | Dst: 10.85.1.56 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` **1. CNI での処理** CNI は、宛先 IP が自身のネットワーク内のポッドに属しているかどうかを識別して、適切なポッドネットワーク名前空間にパケットを配信します。 このフローは、なぜリモートポッド CIDR を VPC から各ポッドをホストする特定のノードに至るまで正しくルーティングできなければならないかを示しています。戻りパス全体は、クラウドとオンプレミスの両方のネットワーク全体にわたってポッド IP が適切にルーティングされるかどうかによって異なります。 ### CNI NAT あり このフローは、*CNI NAT がない*ものと非常によく似ていますが、重要な違いが 1 つあります。CNI は、パケットに送信元 NAT (SNAT) を適用してから、ノードのネットワークスタックにパケットを送信します。これにより、パケットの送信元 IP がノードの IP に変更されるため、追加でルーティングを設定することなく、ノードにパケットをルーティングできます。 ### リクエスト **1. ポッドがリクエストを開始する** ポッドは、ランダムな送信元ポートから EKS Kubernetes API サーバーポート (443) 上の `kubernetes` サービス IP (`172.16.0.1`) にリクエストを送信します。パケットは以下のようになります。 ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 67493 (random) | | | Dst: 172.16.0.1 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` **2. CNI での処理** CNI は、宛先 IP が自身の管理するポッド CIDR に属していないことを検出します。**送信 NAT が有効になっている**ため、CNI は SNAT をパケットに適用して送信元 IP をノードの IP に変更してから、パケットをノードのネットワークスタックに渡します。 ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 67493 (random) | | | Dst: 172.16.0.1 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` 注: この例ではわかりやすくするために CNI と `iptables` をそれぞれ別のブロックに分けていますが、実際には `iptables` を使用して NAT を適用する CNI もあります。 **3. ノードネットワークでの処理** ここでは、`kube-proxy` によって設定された `iptables` ルールが前の例と同じように動作して、パケットを EKS コントロールプレーン ENI のいずれかに負荷分散します。これでパケットは以下のようになります。 ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 67493 (random) | | | Dst: 10.0.0.132 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` 宛先 IP がローカルネットワーク内にないため、ノードはパケットをデフォルトゲートウェイに転送します。 **4. ローカルルーターのルーティング** ローカルルーターは、宛先 IP (`10.0.0.132`) が VPC CIDR (`10.0.0.0/16`) に属していると判断して、AWS に接続しているゲートウェイに転送します。 **5. 境界を越えて移動する** パケットは、確立済みの接続 (Direct Connect や VPN など) 経由でクラウド境界を越えて VPC に移動します。 **6. VPC ネットワークでの配信** VPC ネットワーキングレイヤーは、EKS コントロールプレーン ENI (`10.0.0.132`) が存在する適切なサブネットにパケットをルーティングします。 **7. ENI での受信** パケットは、Kubernetes API サーバーにアタッチされている EKS コントロールプレーン ENI に到達します。 ### 応答 EKS コントロールプレーンは、リクエストを処理してポッドにレスポンスを返します。 **7. API サーバーがレスポンスを送信する** EKS Kubernetes API サーバーは、送信元の IP を宛先としてレスポンスパケットを作成します。パケットは以下のようになります。 ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 443 | | | Dst: 10.80.0.2 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` 宛先 IP が設定済みのリモートノード CIDR (`10.80.0.0/16`) に属しているため、パケットはサブネットのルーターを次のホップとして VPC 内の ENI 経由で送信されます。 **6. VPC でのルーティング** VPC ルートテーブルにはリモートノード CIDR (`10.80.0.0/16`) のエントリがあるため、このトラフィックは VPC-to-onprem ゲートウェイ宛てに送信されます。 **5. 境界を越えて移動する** ゲートウェイは、確立済みの接続 (Direct Connect や VPN など) 経由でクラウド境界を越えてオンプレミスネットワークにパケットを転送します。 **4. オンプレミスネットワークでの受信** パケットは、ローカルオンプレミスルーターに到達します。 **3. ノードへの配信** ローカルルーターは、宛先 IP (`10.80.0.2`) アドレスが自身に直接接続されているネットワークに属しているかどうかを識別して、ターゲットのハイブリッドノードに直接パケットを転送します。 **2. ノードネットワークでの処理** パケットがノードのネットワークスタックによって処理されると、`conntrack` (`netfilter` の一部) はパケットをポッドが最初に確立した接続と照合します。元々 DNAT が適用されていたため、送信元 IP を EKS コントロールプレーン ENI の IP から `kubernetes` サービス IP に書き換えることで元に戻します。 ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 172.16.0.1 | Src: 443 | | | Dst: 10.80.0.2 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` **1. CNI での処理** CNI は、このパケットが以前に SNAT が適用された接続に属しているかどうかを識別します。これにより、SNAT が逆方向に適用されるため、宛先 IP がポッドの IP に戻ります。 ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 172.16.0.1 | Src: 443 | | | Dst: 10.85.1.56 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` CNI は、宛先 IP が自身のネットワーク内のポッドに属していることを検出して、適切なポッドネットワーク名前空間にパケットを配信します。 このフローは、CNI NAT の適用により、追加でポッド CIDR のルーティングを行うことなくパケットをノードにルーティングできるようにすることで、設定をどのように簡素化できるかを示しています。 ## EKS コントロールプレーンからハイブリッドノードで実行されているポッドまでのフロー (ウェブフック) ![\[EKS コントロールプレーンからハイブリッドノードで実行されているポッドまでのフロー\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/hybrid-nodes-cp-to-pod.png) このトラフィックパターンはウェブフックで最もよく見られるものであり、ウェブフックではハイブリッドノード上のポッドで実行されているウェブフックサーバーへの接続を EKS コントロールプレーンが直接開始する必要があります。例えば、アドミッションウェブフックを検証して変更するといった場合、このウェブフックはリソースの検証と変更のプロセス中に API サーバーによって呼び出されます。 ### リクエスト **1. EKS Kubernetes API サーバーがリクエストを開始する** クラスターに設定されたウェブフックが関連する API オペレーションによってトリガーされた場合、EKS Kubernetes API サーバーはそのウェブフックサーバーポッドに直接接続する必要があります。API サーバーはまず、そのウェブフックに関連付けられているサービスリソースまたはエンドポイントリソースでポッドの IP アドレスを検索します。 IP が `10.85.1.23` のハイブリッドノード上でウェブフックポッドが実行されている場合、EKS Kubernetes API サーバーはウェブフックエンドポイントへの HTTPS リクエストを作成します。`10.85.1.23` という宛先 IP は設定済みのリモートポッド CIDR (`10.85.0.0/16`) に属しているため、初期パケットは VPC の EKS コントロールプレーン ENI を介して送信されます。パケットは以下のようになります。 ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 41892 (random) | | | Dst: 10.85.1.23 | Dst: 8443 | | +-----------------+---------------------+-----------------+ ``` **2. VPC ネットワークでの処理** パケットは、EKS コントロールプレーン ENI を出て、サブネットのルーターを次のホップとする VPC ネットワーキングレイヤーに入ります。 **3. VPC ルートテーブルのルックアップ** EKS コントロールプレーン ENI が含まれているサブネット用の VPC ルートテーブルには、リモートポッド CIDR (`10.85.0.0/16`) に固有のルートが登録されています。このルーティングルールにより、パケットは VPC-to-onprem ゲートウェイ (例えば、Direct Connect や VPN 接続の場合は仮想プライベートゲートウェイ) 宛てに送信されます。 ``` Destination Target 10.0.0.0/16 local 10.85.0.0/16 vgw-id (VPC-to-onprem gateway) ``` **4. 境界を越えて移動する** ゲートウェイは、確立済みの接続 (Direct Connect や VPN など) 経由でクラウド境界を越えてオンプレミスネットワークにパケットを転送します。パケットがこの接続を通過するとき、パケットの送信元 IP アドレスと宛先 IP アドレスは元のまま維持されます。 **5. オンプレミスネットワークでの受信** パケットは、ローカルオンプレミスルーターに到達します。ルーターは、自身のルーティングテーブルに問い合わせて、10.85.1.23 アドレスに到達する方法を決定します。そのためにオンプレミスネットワークには、適切なハイブリッドノード宛てにトラフィックを送信するポッド CIDR へのルートが必要です。 この例の場合、ルーターのルートテーブルには IP が `10.80.0.2` のハイブリッドノード経由で `10.85.1.0/24` サブネットに到達できることを示すエントリが登録されています。 ``` Destination Next Hop 10.85.1.0/24 10.80.0.2 ``` **6. ノードへの配信** ルーターは、ルーティングテーブルのエントリに基づいて、パケットをハイブリッドノード (`10.80.0.2`) に転送します。ノードに到達したとき、パケットは EKS Kubernetes API サーバーから送信されたときと同じままで、宛先 IP は依然としてポッドの IP です。 **7. CNI での処理** ノードのネットワークスタックは、パケットを受信し、宛先 IP がノード自体の IP でないことを確認して、さらに処理するために CNI に渡します。CNI は、宛先 IP がこのノードでローカルに実行されているポッドに属しているかどうかを識別し、適切な仮想インターフェイス経由で適切なポッドにパケットを転送します。 ``` Original packet -> node routing -> CNI -> Pod's network namespace ``` ポッド内のウェブフックサーバーは、リクエストを受信して処理します。 ### 応答 ウェブフックポッドは、リクエストを処理してレスポンスを返します。レスポンスは、同じパスを逆方向にたどります。 **7. ポッドがレスポンスを送信する** ウェブフックポッドは、自身の IP を送信元とし、元のリクエスタ (EKS コントロールプレーン ENI) を宛先として、レスポンスパケットを作成します。 ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.23 | Src: 8443 | | | Dst: 10.0.0.132 | Dst: 41892 | | +-----------------+---------------------+-----------------+ ``` CNI は、このパケットが外部ネットワーク (ローカルポッドではない) に送信され、パケットが、元のソース IP を保持したままノードのネットワークスタックに渡されたことを確認します。 **6. ノードネットワークでの処理** ノードは、宛先 IP (`10.0.0.132`) がローカルネットワーク内にないと判断して、自身のデフォルトゲートウェイ (ローカルルーター) にパケットを転送します。 **5. ローカルルーターのルーティング** ローカルルーターは、自身のルーティングテーブルに問い合わせて、宛先 IP (`10.0.0.132`) が VPC CIDR (`10.0.0.0/16`) に属していると判断します。次に、AWS に接続しているゲートウェイにパケットを転送します。 **4. 境界を越えて移動する** パケットは、同じオンプレミスを通って VPC 接続まで戻り、クラウド境界を逆方向に横断します。 **3. VPC でのルーティング** パケットが VPC に到達すると、ルートテーブルは宛先 IP が VPC 内のサブネットに属しているかどうかを識別します。それに応じて、パケットは VPC 内にルーティングされます。 **2. と 1. EKS コントロールプレーン ENI での受信** パケットは、Kubernetes API サーバーにアタッチされている ENI に到達します。これでラウンドトリップは完了です。API サーバーは、ウェブフックレスポンスを受信し、このレスポンスに基づいて元の API リクエストの処理を続行します。 このトラフィックフローは、なぜリモートポッド CIDR を正しく設定してルーティングする必要があるかを示しています。 + VPC には、オンプレミスゲートウェイを指すリモートポッド CIDR のルートが登録されている必要があります。 + オンプレミスネットワークには、そうしたポッドをホストしている特定のノード宛てにトラフィックを送信するポッド CIDR のルートが登録されている必要があります。 + このルーティング設定がないと、ハイブリッドノード上のポッドで実行されているウェブフックやその他の同じようなサービスに EKS コントロールプレーンから到達できなくなります。 ## ハイブリッドノードで実行されているポッド間 ![\[ハイブリッドノードで実行されているポッド間\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/hybrid-nodes-pod-to-pod.png) このセクションでは、異なるハイブリッドノード上で実行されているポッド同士がどのように通信しているかについて説明します。この例では、CNI がカプセル化に VXLAN を使用しているものとします。これは、Cilium や Calico などの CNI でよく見られることです。プロセス全体は、Geneve や IP-in-IP など、他のカプセル化プロトコルに似ています。 ### リクエスト **1. ポッド A が通信を開始する** ノード 1 上のポッド A (`10.85.1.56`) が、ノード 2 上のポッド B (`10.85.2.67`) にトラフィックを送信しようとしています。初期パケットは以下のようになります。 ``` +------------------+-----------------+-------------+-----------------+ | Ethernet Header | IP Header | TCP/UDP | Payload | | Src: Pod A MAC | Src: 10.85.1.56 | Src: 43721 | | | Dst: Gateway MAC | Dst: 10.85.2.67 | Dst: 8080 | | +------------------+-----------------+-------------+-----------------+ ``` **2. CNI がパケットをインターセプトして処理する** ポッド A のパケットが自身のネットワーク名前空間を出ると、CNI がそのパケットをインターセプトします。CNI は自身のルーティングテーブルに問い合わせて、宛先 IP (`10.85.2.67`) はポッド CIDR に属している、この IP はローカルノードではなくノード 2 (`10.80.0.3`) に属している、パケットは VXLAN でカプセル化する必要がある、と判断します。 カプセル化するという判断は重要です。基盤となる物理ネットワークが、ノード IP 間のトラフィックをルーティングする方法は認識しているものの、ポッド CIDR を直接ルーティングする方法は認識していないためです。 CNI は、元のパケット全体を VXLAN フレーム内にカプセル化します。これにより、「パケット内のパケット」が次のような新しいヘッダー付きで効果的に作成されます。 ``` +-----------------+----------------+--------------+------------+---------------------------+ | Outer Ethernet | Outer IP | Outer UDP | VXLAN | Original Pod-to-Pod | | Src: Node1 MAC | Src: 10.80.0.2 | Src: Random | VNI: 42 | Packet (unchanged | | Dst: Router MAC | Dst: 10.80.0.3 | Dst: 8472 | | from above) | +-----------------+----------------+--------------+------------+---------------------------+ ``` このカプセル化の重要なポイントは、外側のパケットにはノード 1 (`10.80.0.2`) からノード 2 (`10.80.0.3`) までのアドレスが指定されること、UDP ポート `8472` は Cilium がデフォルトで使用する VXLAN ポートであること、VXLAN Network Identifier (VNI) はこのパケットが属するオーバーレイネットワークを識別すること、元のパケット (ポッド A の IP を送信元とし、ポッド B の IP を宛先とする) 全体が内側でもそのまま保持されることです。 これで、カプセル化されたパケットは、ノード 1 の通常のネットワークスタックに入って、他のパケットと同じ方法で処理されます。 1. **ノードネットワークでの処理**: ノード 1 のネットワークスタックは、宛先 (`10.80.0.3`) に基づいてパケットをルーティングします。 1. **ローカルネットワークでの配信**: + 両方のノードが同じレイヤー 2 ネットワークにある場合、パケットはノード 2 に直接送信されます。 + それぞれ別のサブネットにある場合、パケットはまずローカルルーターに転送されます。 1. **ルーターでの処理**: ルーターは、自身のルーティングテーブルに基づいてパケットを転送して、ノード 2 に配信します。 **3. 受信側のノードでの処理** カプセル化されたパケットがノード 2 (`10.80.0.3`) に到達すると、次のようになります。 1. ノードのネットワークスタックは、パケットを受信し、VXLAN パケット (UDP ポート `4789`) であると識別します。 1. パケットは、さらに処理するために CNI の VXLAN インターフェイスに渡されます。 **4. VXLAN カプセル化解除** ノード 2 上の CNI は、次のように VXLAN パケットを処理します。 1. 外側のヘッダー (イーサネット、IP、UDP、VXLAN) を取り除きます。 1. 内側の元のパケットを抽出します。 1. これで、パケットは元の形式に戻ります。 ``` +------------------+-----------------+-------------+-----------------+ | Ethernet Header | IP Header | TCP/UDP | Payload | | Src: Pod A MAC | Src: 10.85.1.56 | Src: 43721 | | | Dst: Gateway MAC | Dst: 10.85.2.67 | Dst: 8080 | | +------------------+-----------------+-------------+-----------------+ ``` ノード 2 上の CNI は、宛先 IP (`10.85.2.67`) を確認して、次の処理を行います。 1. この IP がローカルポッドに属しているかどうかを識別します。 1. 適切な仮想インターフェイス経由でパケットをルーティングします。 1. ポッド B のネットワーク名前空間にパケットを配信します。 ### 応答 ポッド B がポッド A に応答するときは、プロセス全体が逆方向になります。 1. ポッド B がポッド A (`10.85.1.56`) にパケットを送信します。 1. ノード 2 の CNI は、そのパケットを VXLAN でカプセル化し、宛先をノード 1 (`10.80.0.2`) に設定します。 1. カプセル化されたパケットがノード 1 に配信されます。 1. ノード 1 の CNI は、パケットをカプセル化解除し、元のレスポンスをポッド A に配信します。 ## クラウドノード上のポッドからハイブリッドノード上のポッドまでのフロー (東西トラフィック) ![\[クラウドノード上のポッドからハイブリッドノード上のポッドまでのフロー\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/hybrid-nodes-east-west.png) ### リクエスト **1. ポッド A が通信を開始する** EC2 ノード上のポッド A (`10.0.0.56`) がハイブリッドノード上のポッド B (`10.85.1.56`) にトラフィックを送信しようとしています。初期パケットは以下のようになります。 ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.56 | Src: 52390 (random) | | | Dst: 10.85.1.56 | Dst: 8080 | | +-----------------+---------------------+-----------------+ ``` VPC CNI では、ポッド A に VPC CIDR からの IP があるため、ポッド A は EC2 インスタンス上の ENI に直接アタッチされます。ポッドのネットワーク名前空間は VPC ネットワークに接続されているため、パケットは VPC ルーティングインフラストラクチャに直接入ります。 **2. VPC でのルーティング** VPC ルートテーブルにはリモートポッド CIDR (`10.85.0.0/16`) に固有のルートが登録されているため、このトラフィックは VPC-to-onprem ゲートウェイ宛てに送信されます。 ``` Destination Target 10.0.0.0/16 local 10.85.0.0/16 vgw-id (VPC-to-onprem gateway) ``` このルーティングルールに基づいて、パケットはオンプレミスネットワークに接続しているゲートウェイに向けて送信されます。 **3. 境界を越えて移動する** ゲートウェイは、確立済みの接続 (Direct Connect や VPN など) 経由でクラウド境界を越えてオンプレミスネットワークにパケットを転送します。このトランジットを全体を通して、パケットの送信元 IP アドレスと宛先 IP アドレスは元のまま維持されます。 **4. オンプレミスネットワークでの受信** パケットは、ローカルオンプレミスルーターに到達します。ルーターは、自身のルーティングテーブルに問い合わせて、10.85.1.56 アドレスに到達するための次のホップを決定します。オンプレミスルーターには、適切なハイブリッドノード宛てにトラフィックを送信するポッド CIDR へのルートが必要です。 ルーターのルートテーブルには IP `10.80.0.2` のハイブリッドノード経由で `10.85.1.0/24` サブネットに到達できることを示すエントリが登録されています。 ``` Destination Next Hop 10.85.1.0/24 10.80.0.2 ``` **5. ノードネットワークでの処理** ルーターは、パケットをハイブリッドノード (`10.80.0.2`) に転送します。パケットがノードに到達したとき、パケットのポッド A の IP は送信元のまま、ポッド B の IP は宛先のままです。 **6. CNI での処理** ノードのネットワークスタックは、パケットを受信し、宛先 IP が自身のものでないことを確認して、さらに処理するために CNI に渡します。CNI は、宛先 IP がこのノードでローカルに実行されているポッドに属しているかどうかを識別し、適切な仮想インターフェイス経由で適切なポッドにパケットを転送します。 ``` Original packet -> node routing -> CNI -> Pod B's network namespace ``` ポッド B は、パケットを受信し、必要に応じて処理します。 ### 応答 **6. ポッド B がレスポンスを送信する** ポッド B は、自身の IP を送信元、ポッド A の IP を宛先として、レスポンスパケットを作成します。 ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 8080 | | | Dst: 10.0.0.56 | Dst: 52390 | | +-----------------+---------------------+-----------------+ ``` CNI は、このパケットが外部ネットワーク宛てかどうかを識別して、ノードのネットワークスタックに渡します。 **5. ノードネットワークでの処理** ノードは、宛先 IP (`10.0.0.56`) がローカルネットワークに属していないと判断し、自身のデフォルトゲートウェイ (ローカルルーター) にパケットを転送します。 **4. ローカルルーターのルーティング** ローカルルーターは、自身のルーティングテーブルに問い合わせて、宛先 IP (`10.0.0.56`) が VPC CIDR (`10.0.0.0/16`) に属していると判断します。次に、AWS に接続しているゲートウェイにパケットを転送します。 **3. 境界を越えて移動する** パケットは、同じオンプレミスを通って VPC 接続まで戻り、クラウド境界を逆方向に横断します。 **2. VPC でのルーティング** パケットが VPC に到達すると、ルーティングシステムは宛先 IP が VPC 内のサブネットに属しているかどうかを識別します。パケットは、ポッド A をホストしている EC2 インスタンスに向けて、VPC ネットワーク経由でルーティングされます。 **1. ポッド A がレスポンスを受信する** パケットは、EC2 インスタンスに到達し、そこにアタッチされている ENI 経由でポッド A に直接配信されます。VPC CNI は VPC 内のポッドにオーバーレイネットワーキングを使用しないため、別途カプセル化解除は必要なく、パケットは元のヘッダーのまま届きます。 この東西トラフィックフローは、なぜリモートポッド CIDR を正しく設定して、両方向からルーティング可能にする必要があるかを示しています。 + VPC には、オンプレミスゲートウェイを指すリモートポッド CIDR のルートが登録されている必要があります。 + オンプレミスネットワークには、そうしたポッドをホストしている特定のノード宛てにトラフィックを送信するルートがポッド CIDR で登録されている必要があります。 # ハイブリッドノード `nodeadm` 参照 Amazon EKS Hybrid Nodes CLI (`nodeadm`) は、ハイブリッドノードコンポーネントのインストール、設定、登録、アンインストールを簡素化します。オペレーティングシステムイメージに `nodeadm` を含めると、ハイブリッドノードのブートストラップを自動化できます。詳細については、「[ハイブリッドノード用のオペレーティングシステムを準備する](hybrid-nodes-os.md)」を参照してください。 ハイブリッドノードの `nodeadm` バージョンは、Amazon EKS クラスター内のノードとして Amazon EC2 インスタンスをブートストラップするために使用される `nodeadm` バージョンとは異なります。適切な `nodeadm` バージョンのドキュメントとリファレンスに従ってください。このドキュメントページは、ハイブリッドノードの `nodeadm` バージョンを対象としています。 ハイブリッドノード `nodeadm` のソースコードは、https://github.com/aws/eks-hybrid GitHub リポジトリで公開されています。 **重要** root/sudo 権限を持つユーザーで `nodeadm` を実行する必要があります。 ## `nodeadm` のダウンロード `nodeadm` のハイブリッドノード版は Amazon CloudFront をフロントに置いた Amazon S3 でホストされます。各オンプレミスホストに `nodeadm` をインストールするにはオンプレミスホストから以下のコマンドを実行してください。 **x86\$164 ホストの場合** ``` curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/amd64/nodeadm' ``` **ARM ホストの場合** ``` curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/arm64/nodeadm' ``` 各ホストでダウンロードしたバイナリに実行可能ファイルのアクセス許可を追加します。 ``` chmod +x nodeadm ``` ## `nodeadm install` `nodeadm install` コマンドはハイブリッドノードを実行して Amazon EKS クラスターに結合するために必要なアーティファクトと依存関係をインストールするために使用されます。`nodeadm install` コマンドは各ハイブリッドノードで個別に実行することも、イメージビルドパイプライン中に実行して、オペレーティングシステムイメージにハイブリッドノードの依存関係をプリインストールすることもできます。 **使用方法** ``` nodeadm install [KUBERNETES_VERSION] [flags] ``` **位置引数** (必須 `KUBERNETES_VERSION` インストールする EKS Kubernetes のメジャーバージョンとマイナーバージョン (例: `1.32`) **Flags** | 名前 | 必要 | 説明 | | --- | --- | --- | | `-p`, `--credential-provider` | 正 | インストールする認証情報プロバイダー。サポートされている値は`iam-ra` および `ssm` です。詳細については「[ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md)」を参照してください。 | | `-s`, `--containerd-source` | 誤 | `containerd` のソース。`nodeadm` はOS ディストリビューション、Docker パッケージからの `containerd` のインストール、および `containerd` のインストールのスキップをサポートしています。 **[値]** `distro` - これはデフォルト値です。`nodeadm` は、EKS Kubernetes バージョンと互換性のある、ノード OS によって配布される最新の `containerd` パッケージをインストールします。`distro` は Red Hat Enterprise Linux (RHEL) オペレーティングシステムでサポートされる値ではありません。 `docker` — `nodeadm` は、EKS Kubernetes バージョンと互換性のある、Docker によって構築および配布された最新の `containerd` パッケージをインストールします。`docker` は Amazon Linux 2023 でサポートされる値ではありません。 `none` — `nodeadm` は `containerd` パッケージをインストールしません。`nodeadm init` を実行する前に、`containerd` を手動でインストールする必要があります。 | | `-r`, `--region` | FALSE | SSM エージェントといったアーティファクトをダウンロードするための AWS リージョンを指定します。デフォルトは `us-west-2` です。 | | `-t`, `--timeout` | FALSE | install コマンドの最大実行時間。入力は時間形式に従います。例: `1h23m`。install コマンドのデフォルトのダウンロードタイムアウトは 20 分に設定されています。 | | `-h`, `--help` | 誤 | 使用可能なフラグ、サブコマンド、位置値パラメータを含むヘルプメッセージを表示します。 | **例** 認証情報プロバイダーとして AWS システムマネージャー (SSM 使用して Kubernetes バージョン `1.32` をインストールする ``` nodeadm install 1.32 --credential-provider ssm ``` AWS システムマネージャー (SSM 認証情報プロバイダーとして、Docker を containerd のソースとして、ダウンロードタイムアウトを 20 分にして Kubernetes バージョン `1.32` をインストールします。 ``` nodeadm install 1.32 --credential-provider ssm --containerd-source docker --timeout 20m ``` 認証情報プロバイダーとして AWS IAM Roles Anywhere を使用して Kubernetes バージョン `1.32` をインストールする ``` nodeadm install 1.32 --credential-provider iam-ra ``` ## `nodeadm config check` `nodeadm config check` コマンドは提供されたノード設定にエラーがないか確認します。このコマンドはハイブリッドノード設定ファイルの正確性を検証するために使用できます。 **使用方法** ``` nodeadm config check [flags] ``` **Flags** | 名前 | 必要 | 説明 | | --- | --- | --- | | `-c`, `--config-source` | 正 | nodeadm 設定のソース。ハイブリッドノードの場合、入力は file スキームを使用する URI に従う必要があります。 | | `-h`, `--help` | 誤 | 使用可能なフラグ、サブコマンド、位置値パラメータを含むヘルプメッセージを表示します。 | **例** ``` nodeadm config check -c file://nodeConfig.yaml ``` ## `nodeadm init` `nodeadm init` コマンドはハイブリッドノードを起動し、設定された Amazon EKS クラスターに接続します。`nodeConfig.yaml` ファイルの設定方法の詳細については、「[SSM ハイブリッドアクティベーション用のノード設定](#hybrid-nodes-node-config-ssm)」または「[IAM Roles Anywhere 用のノード設定](#hybrid-nodes-node-config-iamra)」を参照してください。 **使用方法** ``` nodeadm init [flags] ``` **Flags** | 名前 | 必要 | 説明 | | --- | --- | --- | | `-c`, `--config-source` | 正 | `nodeadm` 設定のソース。ハイブリッドノードの場合、入力は file スキームを使用する URI に従う必要があります。 | | `-s`, `--skip` | 誤 | スキップする `init` のフェーズ。問題の修正に役立つ場合を除き、どのフェーズもスキップすることはお勧めしません。 **[値]** `install-validation` は、先行する install コマンドが正常に実行されたかどうかの確認をスキップします。 ノードでファイアウォールが有効になっている場合、`cni-validation` は Cilium または Calico CNI の VXLAN ポートが開かれているかどうかの確認をスキップします。 `node-ip-validation` は、ノード IP がリモートノードネットワークの CIDR 内に含まれているかどうかのチェックをスキップします。 | | `-h`, `--help` | FALSE | 使用可能なフラグ、サブコマンド、位置値パラメータを含むヘルプメッセージを表示します。 | **例** ``` nodeadm init -c file://nodeConfig.yaml ``` ## `nodeadm upgrade` `nodeadm upgrade` コマンドはインストールされているすべてのアーティファクトを最新バージョンにアップグレードし、ノードをブートストラップしてアップグレードされたアーティファクトを設定し、AWS の EKS クラスターに参加させます。アップグレードはノードで実行されているワークロードに対する破壊的なコマンドです。アップグレードを実行する前にはワークロードを別のノードに移動してください。 **使用方法** ``` nodeadm upgrade [KUBERNETES_VERSION] [flags] ``` **位置引数** (必須 `KUBERNETES_VERSION` インストールする EKS Kubernetes のメジャーバージョンとマイナーバージョン (例: `1.32`) **Flags** | 名前 | 必要 | 説明 | | --- | --- | --- | | `-c`, `--config-source` | 正 | `nodeadm` 設定のソース。ハイブリッドノードの場合、入力は file スキームを使用する URI に従う必要があります。 | | `-t`, `--timeout` | 誤 | アーティファクトのダウンロードのタイムアウト。入力は時間形式に従います。たとえば、1h23m です。upgrade コマンドのデフォルトのダウンロードタイムアウトは 10 分に設定されています。 | | `-s`, `--skip` | 誤 | スキップするアップグレードフェーズ。問題の修正に役立つ場合を除き、どのフェーズもスキップすることはお勧めしません。 **[値]** `pod-validation` はデーモンセットと静的ポッドを除くすべてのポッドがノード上で実行されていないことのチェックをスキップします。 `node-validation` はノードが隔離されているかどうかの確認をスキップします。 `init-validation` はアップグレードを実行する前にノードが正常に初期化されたかどうかの確認をスキップします。 `containerd-major-version-upgrade` は、ノードのアップグレード時に containerd のメジャーバージョンがアップグレードされないようにします。 | | `-h`, `--help` | FALSE | 使用可能なフラグ、サブコマンド、位置値パラメータを含むヘルプメッセージを表示します。 | **例** ``` nodeadm upgrade 1.32 -c file://nodeConfig.yaml ``` ``` nodeadm upgrade 1.32 -c file://nodeConfig.yaml --timeout 20m ``` ## `nodeadm uninstall` `nodeadm uninstall` コマンドはkubelet や containerd など、`nodeadm install` の実行中に `nodeadm` がインストールしたアーティファクトを停止および削除してください。uninstall コマンドはクラスターからハイブリッドノードをドレインまたは削除しないことに注意してください。ドレインと削除の操作は個別に実行する必要があります。詳細については「[ハイブリッドノードを削除する](hybrid-nodes-remove.md)」を参照してください。デフォルトではノードにポッドが残っている場合、`nodeadm uninstall` は続行されません。同様に、`nodeadm uninstall` は CNI 依存関係や、クラスターで実行している他の Kubernetes アドオンの依存関係を削除しません。ホストから CNI インストールを完全に削除するには「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」の手順を参照してください。オンプレミス認証情報プロバイダーとして AWS SSM ハイブリッドアクティベーションを使用している場合、`nodeadm uninstall` コマンドはホストを AWS SSM マネージドインスタンスから登録解除します。 **使用方法** ``` nodeadm uninstall [flags] ``` **Flags** | 名前 | 必要 | 説明 | | --- | --- | --- | | `-s`, `--skip` | 誤 | アンインストール時にスキップするフェーズ。問題の修正に役立つ場合を除き、どのフェーズもスキップすることはお勧めしません。 **[値]** `pod-validation` はデーモンセットと静的ポッドを除くすべてのポッドがノード上で実行されていないことのチェックをスキップします。 `node-validation` はノードが隔離されているかどうかの確認をスキップします。 `init-validation` はアンインストールを実行する前にノードが正常に初期化されたかどうかの確認をスキップします。 | | `-h`, `--help` | FALSE | 使用可能なフラグ、サブコマンド、位置値パラメータを含むヘルプメッセージを表示します。 | | `-f`, `--force` | FALSE | Kubernetes および CNI コンポーネントからの残存ファイルを含む可能性のある追加のディレクトリを強制的に削除します。 **警告** これにより、デフォルトの Kubernetes および CNI ディレクトリのすべてのコンテンツ (`/var/lib/cni`、`/etc/cni/net.d` など) が削除されます。これらの場所に独自のデータを保存する場合は、このフラグを使用しないでください。 nodeadm `v1.0.9` 以降、`./nodeadm uninstall --skip node-validation,pod-validation --force` コマンドは `/var/lib/kubelet` ディレクトリを削除しなくなりました。これは、マウントされたノードファイルシステムを含むことがある Pod ボリュームと volume-subpath ディレクトリが含まれている可能性があるためです。 **安全な処理のヒント** - マウントされたパスを削除すると、実際にマウントされたノードファイルシステムが誤って削除される可能性があります。`/var/lib/kubelet` ディレクトリを手動で削除する前に、すべてのアクティブなマウントを慎重に検査し、ボリュームを安全にマウント解除して、データ損失を回避します。 | **例** ``` nodeadm uninstall ``` ``` nodeadm uninstall --skip node-validation,pod-validation ``` ## `nodeadm debug` `nodeadm debug` コマンドは異常または誤設定のハイブリッドノードのトラブルシューティングに使用できます。以下の要件が満たされていることを検証します。 + ノードが認証情報を取得するために必要な AWS API へのネットワークアクセスがあること + ノードが設定されたハイブリッドノードの IAM ロールに対し AWS 認証情報を取得できること + ノードに EKS Kubernetes API エンドポイントへのネットワークアクセスがあり、EKS Kubernetes API エンドポイント証明書が有効であること + ノードが EKS クラスターに対し認証でき、クラスター内での ID が有効で、EKS クラスター用に設定された VPC を介して EKS クラスターにアクセスできること。 エラーが見つかった場合、コマンドの出力はトラブルシューティングのステップを提示します。特定の検証ステップは子プロセスを示しています。これらが失敗した場合、出力は検証エラーの下の stderr セクションに表示されます。 **使用方法** ``` nodeadm debug [flags] ``` **Flags** | 名前 | 必要 | 説明 | | --- | --- | --- | | `-c`, `--config-source` | 正 | `nodeadm` 設定のソース。ハイブリッドノードの場合、入力は file スキームを使用する URI に従う必要があります。 | | `--no-color` | FALSE | 色の出力を無効にします。自動化に役立ちます。 | | `-h`, `--help` | FALSE | 使用可能なフラグ、サブコマンド、位置値パラメータを含むヘルプメッセージを表示します。 | **例** ``` nodeadm debug -c file://nodeConfig.yaml ``` ## Nodeadm ファイルの場所 ### nodeadm のインストール `nodeadm install` を実行すると、以下のファイルおよびファイルの場所が設定されます。 | アーティファクト | パス | | --- | --- | | IAM Roles Anywhere | /usr/local/bin/aws\$1signing\$1helper | | Kubelet binary | /usr/bin/kubelet | | Kubectl binary | usr/local/bin/kubectl | | ECR Credentials Provider | /etc/eks/image-credential-provider/ecr-credential-provider | | AWS IAM オーセンティケーター | /usr/local/bin/aws-iam-authenticator | | SSM Setup CLI | /opt/ssm/ssm-setup-cli | | SSM Agent | Ubuntu の場合 - /snap/amazon-ssm-agent/current/amazon-ssm-agent RHEL および AL2023 の場合 - /usr/bin/amazon-ssm-agent | | Containerd | Ubuntu および AL2023 の場合 - /usr/bin/containerd RHEL の場合 - /bin/containerd | | Iptables | Ubuntu および AL2023 の場合 - /usr/sbin/iptables RHEL の場合 - /sbin/iptables | | CNI プラグイン | /opt/cni/bin | | インストール済みアーティファクトトラッカー | /opt/nodeadm/tracker | ### nodeadm init `nodeadm init` を実行すると、以下のファイルおよびファイルの場所が設定されます。 | 名前 | パス | | --- | --- | | Kubelet kubeconfig | /var/lib/kubelet/kubeconfig | | Kubelet 設定 | /etc/kubernetes/kubelet/config.json | | Kubelet systemd ユニット | /etc/systemd/system/kubelet.service | | イメージ認証情報プロバイダー設定 | /etc/eks/image-credential-provider/config.json | | Kubelet 環境ファイル | /etc/eks/kubelet/environment | | Kubelet 証明書 | /etc/kubernetes/pki/ca.crt | | Containerd 設定 | /etc/containerd/config.toml | | Containerd カーネルモジュール設定 | /etc/modules-load.d/contianerd.conf | | AWS 設定ファイル | /etc/aws/hybrid/config | | AWS 認証情報ファイル (認証情報ファイルを有効にする場合) | /eks-hybrid/.aws/credentials | | AWS 署名ヘルパーシステムユニット | /etc/systemd/system/aws\$1signing\$1helper\$1update.service | | Sysctl 設定ファイル | /etc/sysctl.d/99-nodeadm.conf | | Ca-certificates | /etc/ssl/certs/ca-certificates.crt | | Gpg キーファイル | /etc/apt/keyrings/docker.asc | | Docker リポジトリソースファイル | /etc/apt/sources.list.d/docker.list | ## SSM ハイブリッドアクティベーション用のノード設定 ハイブリッドノードの認証情報に AWS SSM ハイブリッドアクティベーションを使用する場合の `nodeConfig.yaml` の例を以下に示します。 ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: # Name of the EKS cluster region: # AWS Region where the EKS cluster resides hybrid: ssm: activationCode: # SSM hybrid activation code activationId: # SSM hybrid activation id ``` ## IAM Roles Anywhere 用のノード設定 ハイブリッドノードの認証情報用の AWS IAM Roles Anywhere の `nodeConfig.yaml` の例を以下に示します。 AWS IAM Roles Anywhere をオンプレミス認証情報プロバイダーとして使用する場合、`nodeadm` 設定で使用する `nodeName` はハイブリッドノードの IAM ロールを対象としたアクセス許可と一致する必要があります。たとえば、ハイブリッドノードの IAM ロールのアクセス許可ではロールセッション名がホスト証明書の CN と一致する場合しか AWS IAM Roles Anywhere がロールを引き受けることは許可されない場合、`nodeadm` 設定の `nodeName` は証明書の CN と同じである必要があります。使用する `nodeName` は 64 文字以下にする必要があります。詳細については、「[ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md)」を参照してください。 ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: # Name of the EKS cluster region: # AWS Region where the EKS cluster resides hybrid: iamRolesAnywhere: nodeName: # Name of the node trustAnchorArn: # ARN of the IAM Roles Anywhere trust anchor profileArn: # ARN of the IAM Roles Anywhere profile roleArn: # ARN of the Hybrid Nodes IAM role certificatePath: # Path to the certificate file to authenticate with the IAM Roles Anywhere trust anchor privateKeyPath: # Path to the private key file for the certificate ``` ## kubelet をカスタマイズするためのノード設定 (オプション) `nodeadm` 設定で kubelet 設定とフラグを渡すことができます。追加のノードラベル `abc.amazonaws.com/test-label` を追加する方法と、`shutdownGracePeriod` を 30 秒に設定するための設定については以下の例を参照してください。 ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: # Name of the EKS cluster region: # AWS Region where the EKS cluster resides kubelet: config: # Map of kubelet config and values shutdownGracePeriod: 30s flags: # List of kubelet flags - --node-labels=abc.company.com/test-label=true hybrid: ssm: activationCode: # SSM hybrid activation code activationId: # SSM hybrid activation id ``` ## containerd をカスタマイズするためのノード設定 (オプション) `nodeadm` 設定でカスタム containerd 設定を渡すことができます。`nodeadm` の containerd 設定はインライン TOML を受け入れます。containerd コンテンツストアで解凍されたイメージレイヤーの削除を無効にするための containerd の設定方法については以下の例を参照してください。 ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: # Name of the EKS cluster region: # AWS Region where the EKS cluster resides containerd: config: | # Inline TOML containerd additional configuration [plugins."io.containerd.grpc.v1.cri".containerd] discard_unpacked_layers = false hybrid: ssm: activationCode: # SSM hybrid activation code activationId: # SSM hybrid activation id ``` **注記** containerd のバージョン 1.x と 2.x では、異なる設定形式が使用されます。containerd 1.x は設定バージョン 2 を使用し、containerd 2.x は設定バージョン 3 を使用します。containerd 2.x は設定バージョン 2 と下位互換性がありますが、最適なパフォーマンスを得るには設定バージョン 3 をお勧めします。`containerd --version` を使用して containerd バージョンを確認するか、`nodeadm` のインストールログを確認します。設定のバージョニングの詳細については、https://containerd.io/releases/ を参照してください。 containerd 設定を使用して SELinux サポートを有効にすることもできます。containerd で SELinux が有効になっている場合はノードでスケジュールされたポッドで適切な securityContext と seLinuxOptions が有効になっていることを確認してください。セキュリティコンテキストの設定の詳細については[Kubernetes ドキュメント](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)を参照してください。 **注記** Red Hat Enterprise Linux (RHEL 8 および RHEL 9 では SELinux がデフォルトで有効になっており、ホスト上で strict に設定されています。Amazon Linux 2023 はデフォルトで SELinux が有効になっており、許可モードに設定されています。SELinux がホストで許可モードに設定されている場合、containerd で有効にしてもリクエストはブロックされませんが、ホストの SELinux 設定に従ってログに記録されます。 ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: # Name of the EKS cluster region: # AWS Region where the EKS cluster resides containerd: config: | # Inline TOML containerd additional configuration [plugins."io.containerd.grpc.v1.cri"] enable_selinux = true hybrid: ssm: activationCode: # SSM hybrid activation code activationId: # SSM hybrid activation id ``` # ハイブリッドノードのトラブルシューティング このトピックでは、Amazon EKS Hybrid Nodes の使用中に表示される一般的なエラーとその修復方法について説明します。その他のトラブルシューティング情報については、「[Amazon EKS クラスターとノードに関する問題をトラブルシューティングする](troubleshooting.md)」および * AWS re:Post* の「[Amazon EKS のナレッジセンタータグ](https://repost.aws/tags/knowledge-center/TA4IvCeWI1TE66q4jEj4Z9zg/amazon-elastic-kubernetes-service)」を参照してください。問題を解決できない場合は、AWS サポートにお問い合わせください。 **`nodeadm debug` を使用したノードのトラブルシューティング** ハイブリッドノードから `nodeadm debug` コマンドを実行して、ネットワークと認証情報の要件が満たされていることを検証できます。`nodeadm debug` コマンドの詳細については、「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。 **クラスターインサイトを使用してハイブリッドノードの問題を検出する** Amazon EKS クラスターインサイトには、クラスター内の EKS Hybrid Nodes の設定に関する一般的な問題を検出する*インサイトチェック*が含まれます。すべてのインサイトチェックの結果は AWS マネジメントコンソール、AWS CLI、および AWS SDK から表示できます。クラスターインサイトの詳細については、「[Kubernetes バージョンアップグレードの準備およびクラスターインサイトでの設定ミスのトラブルシューティング](cluster-insights.md)」を参照してください。 ## ハイブリッドノードのインストールに関するトラブルシューティング 以下のトラブルシューティングのトピックは、`nodeadm install` コマンドを使用してホストにハイブリッドノードの依存関係をインストールすることに関連しています。 ** `nodeadm` コマンドが `must run as root` に失敗した** `nodeadm install` コマンドは、ホストに対して root または `sudo` 権限を持つユーザーに実行させる必要があります。root または `sudo` 権限を持たないユーザーに `nodeadm install` を実行させると、`nodeadm` 出力に次のエラーが表示されます。 ``` "msg":"Command failed","error":"must run as root" ``` **依存関係に接続できない** `nodeadm install` コマンドは、ハイブリッドノードに必要な依存関係をインストールします。ハイブリッドノードの依存関係には、`containerd`、`kubelet`、`kubectl`、および AWS SSM または AWS IAM Roles Anywhere コンポーネントがあります。これらの依存関係をダウンロードするには、`nodeadm install` を実行している場所からアクセスする必要があります。アクセスする必要があるロケーションのリストの詳細については、「[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md)」を参照してください。アクセス権限がない場合は、次のようなエラーが `nodeadm install` 出力に表示されます。 ``` "msg":"Command failed","error":"failed reading file from url: ...: max retries achieved for http request" ``` **パッケージマネージャーの更新に失敗しました** `nodeadm install` コマンドは、ハイブリッドノードの依存関係をインストールする前に、`apt update`、`yum update`、`dnf update` のいずれかを実行します。このステップが失敗すると、次のようなエラーが表示される可能性があります。これを修正するには、`apt update`、`yum update`、`dnf update` のいずれかを実行してから `nodeadm install` を実行するか、`nodeadm install` を再実行します。 ``` failed to run update using package manager ``` **タイムアウトまたはコンテキストの期限を超過しました** `nodeadm install` を実行するときに、インストールプロセスのさまざまな段階でタイムアウトまたはコンテキストの期限を超過したことを示すエラーの問題が発生した場合、接続が遅くなり、タイムアウトが完了する前にハイブリッドノードの依存関係がインストールされない可能性があります。これらの問題を回避するには、`nodeadm` の `--timeout` フラグを使用して、依存関係のダウンロードのタイムアウト期間を延長できます。 ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --timeout 20m0s ``` ## ハイブリッドノードの接続のトラブルシューティング このセクションのトラブルシューティングトピックは、`nodeadm init` コマンドを使用してハイブリッドノードを EKS クラスターに接続するプロセスに関連しています。 **オペレーションエラーまたはサポートされていないスキーム** `nodeadm init` を実行するときに、`operation error` または `unsupported scheme` に関連するエラーが表示された場合は、`nodeConfig.yaml` が正しくフォーマットされ、`nodeadm` に渡されているか確認します。`nodeConfig.yaml` のフォーマットのオプションの詳細については、「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。 ``` "msg":"Command failed","error":"operation error ec2imds: GetRegion, request canceled, context deadline exceeded" ``` **ハイブリッドノード IAM ロールに `eks:DescribeCluster` アクションのアクセス許可がありません** `nodeadm init` を実行すると、`nodeadm` は EKS `DescribeCluster` アクションを呼び出して EKS クラスターに関する情報の収集を試みます。ハイブリッドノード IAM ロールに `eks:DescribeCluster` アクションのアクセス許可がない場合は、`nodeadm init` init の実行時に `nodeadm` に渡すノード設定で、Kubernetes API エンドポイント、クラスター CA バンドル、およびサービス IPv4 CIDR を渡す必要があります。ハイブリッドノード IAM ロールに必須のアクセス許可の詳細については、「[ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md)」を参照してください。 ``` "msg":"Command failed","error":"operation error EKS: DescribeCluster, https response error StatusCode: 403 ... AccessDeniedException" ``` **ハイブリッドノード IAM ロールに `eks:ListAccessEntries` アクションのアクセス許可がありません** `nodeadm init` を実行すると、`nodeadm` は EKS `ListAccessEntries`アクションを呼び出して、ハイブリッドノード IAM ロールに関連付けられた `HYBRID_LINUX` タイプのアクセスエントリが EKS クラスターにあるかどうかを検証しようとします。ハイブリッドノード IAM ロールに `eks:ListAccessEntries` アクションのアクセス許可がない場合は、`nodeadm init` コマンドの実行時に `--skip cluster-access-validation` フラグを渡す必要があります。ハイブリッドノード IAM ロールに必須のアクセス許可の詳細については、「[ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md)」を参照してください。 ``` "msg":"Command failed","error":"operation error EKS: ListAccessEntries, https response error StatusCode: 403 ... AccessDeniedException" ``` **リモートノードネットワークの CIDR にないノード IP** `nodeadm init` を実行するときに、指定されたリモートノードネットワークの CIDR の中にノードの IP アドレスがない場合、エラーが発生することがあります。エラーは次の例のような見た目になります。 ``` node IP 10.18.0.1 is not in any of the remote network CIDR blocks [10.0.0.0/16 192.168.0.0/16] ``` こちらの例では、IP 10.18.0.1 のノードが、リモートネットワークの CIDR 10.0.0.0/16 と 192.168.0.0/16 でクラスターを結合しようとしています。10.18.0.1 がいずれの範囲にもないため、エラーが発生しています。 `RemoteNodeNetworks` が正しく設定され、すべてのノード IP アドレスが含まれていることを確認します。ネットワーク設定の詳細については、「[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md)」を参照してください。 + お使いのクラスターが配置されているリージョンで次のコマンドを実行し、`RemoteNodeNetwork` 設定をチェックします。出力に表示された CIDR ブロックに、ご自身のノードの IP 範囲が含まれ、エラーメッセージに表示された CIDR ブロックと同一であることを確認します。同じでない場合は、クラスター名と `nodeConfig.yaml` のリージョンが、対象となるクラスターと一致していることを確認します。 ``` aws eks describe-cluster --name CLUSTER_NAME --region REGION_NAME --query cluster.remoteNetworkConfig.remoteNodeNetworks ``` + 対象のノードで作業していることを確認します。 + ホスト名と IP アドレスが、クラスターに登録しようとしているものと一致することを確認して、正しいノードで作業していることを確認します。 + このノードが正しいオンプレミスネットワーク (クラスターのセットアップ中に CIDR 範囲が `RemoteNodeNetwork` として登録されたネットワーク) にあることを確認します。 それでもやはりノード IP が想定されるものと異なる場合は、以下を確認します。 + IAM Roles Anywhere を使用している場合、`kubelet` が DNS ルックアップを IAM Roles Anywhere で実行し、`nodeName` がノード名 (使用できる場合) に関連付けられた IP を使用している。ノードの DNS エントリを維持している場合、これらのエントリがリモートノードネットワークの CIDR 内の IP を指していることを確認する。 + ノードに複数のネットワークインターフェイスがある場合、`kubelet` は、リモートノードネットワークの CIDR の、範囲外の IP アドレスを持つインターフェイスをデフォルトとして選択することがあります。別のインターフェイスを使用するには、ご自身の `nodeConfig.yaml` の `--node-ip` `kubelet` フラグを使用して、その IP アドレスを指定します。詳細については、「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。ノードで次のコマンドを実行すると、ノードのネットワークインターフェイスとその IP アドレスを確認できます。 ``` ip addr show ``` **ハイブリッドノードが EKS クラスターに表示されない** `nodeadm init` を実行して完了しても、ハイブリッドノードがクラスターに表示されない場合、ハイブリッドノードと EKS コントロールプレーン間のネットワーク接続に問題があるか、必要なセキュリティグループのアクセス許可が設定されていないか、Kubernetes ロールベースアクセスコントロール (RBAC) へのハイブリッドノード IAM ロールの必要なマッピングがない可能性があります。次のコマンドを使用して `kubelet` と `kubelet` ログのステータスを確認することで、デバッグプロセスを開始できます。クラスターに参加できなかったハイブリッドノードから次のコマンドを実行します。 ``` systemctl status kubelet ``` ``` journalctl -u kubelet -f ``` **クラスターと通信できません** ハイブリッドノードがクラスターコントロールプレーンと通信できなかった場合は、次のようなログが表示されることがあります。 ``` "Failed to ensure lease exists, will retry" err="Get ..." ``` ``` "Unable to register node with API server" err="Post ..." ``` ``` Failed to contact API server when waiting for CSINode publishing ... dial tcp : i/o timeout ``` これらのメッセージが表示された場合は、以下をチェックして、[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md) で説明されているハイブリッドノード要件を満たしていることを確認します。 + EKS クラスターに渡される VPC に、オンプレミスノードとオプションでポッド CIDR の Transit Gateway (TGW) または仮想プライベートゲートウェイ (VGW) へのルートがあることを確認します。 + EKS クラスターに追加のセキュリティグループがあり、オンプレミスノード CIDR とオプションでポッド CIDR のインバウンドルールがあることを確認します。 + EKS コントロールプレーンとの間のトラフィックを許可するようにオンプレミスルーターが設定されていることを確認します。 **Unauthorized** ハイブリッドノードが EKS コントロールプレーンと通信できたが、登録できなかった場合、次のようなログが表示されることがあります。以下のログメッセージの主な違いは `Unauthorized` エラーであることに注意してください。これは、必要なアクセス許可がないため、ノードがタスクを実行できなかったことを示します。 ``` "Failed to ensure lease exists, will retry" err="Unauthorized" ``` ``` "Unable to register node with API server" err="Unauthorized" ``` ``` Failed to contact API server when waiting for CSINode publishing: Unauthorized ``` これらのメッセージが表示された場合は、以下をチェックして、[ハイブリッドノードの認証情報を準備する](hybrid-nodes-creds.md) および [ハイブリッドノードのクラスターアクセスを準備する](hybrid-nodes-cluster-prep.md) のハイブリッドノードの要件の詳細を満たしていることを確認します。 + ハイブリッドノードのアイデンティティが、想定のハイブリッドノードの IAM ロールと一致することを確認します。これを行うには、ハイブリッドノードから `sudo aws sts get-caller-identity` を実行します。 + ハイブリッドノード IAM ロールに必要なアクセス許可があることを確認します。 + クラスターにハイブリッドノード IAM ロールの EKS アクセスエントリがあることを確認するか、`aws-auth` ConfigMap にハイブリッドノード IAM ロールのエントリがあることを確認します。EKS アクセスエントリを使用している場合は、ハイブリッドノード IAM ロールのアクセスエントリが `HYBRID_LINUX` アクセスタイプであることを確認します。`aws-auth` ConfigMap を使用している場合は、ハイブリッドノード IAM ロールのエントリが、「[ハイブリッドノードのクラスターアクセスを準備する](hybrid-nodes-cluster-prep.md)」で説明されている要件と形式を満たしていることを確認します。 ### ハイブリッドノードが EKS クラスターに登録されているのにステータス `Not Ready` が表示される ハイブリッドノードが EKS クラスターに正常に登録されたが、ハイブリッドノードのステータスが `Not Ready` である場合、最初に確認すべきことは、コンテナネットワークインターフェイス (CNI) のステータスです。CNI をインストールしていない場合は、ハイブリッドノードのステータスが `Not Ready` であることが予想されます。CNI が正常にインストールされ実行されると、ノードのステータスは `Ready` に移行します。CNI をインストールしようとしたが、正常に実行されていない場合は、このページの「[ハイブリッドノード CNI のトラブルシューティング](#hybrid-nodes-troubleshooting-cni)」を参照してください。 **証明書署名リクエスト (CSR) が保留中のままである** ハイブリッドノードを EKS クラスターに接続した後、ハイブリッドノードの保留中の CSR がある場合、ハイブリッドノードは自動承認の要件を満たしていません。ハイブリッドノードの CSR は、ハイブリッドノードの CSR が `eks.amazonaws.com/compute-type: hybrid` ラベル付きノードによって作成され、CSR に次のサブジェクト代替名 (SAN) がある場合、自動的に承認および発行されます: 少なくとも 1 つの DNS SAN はノード名と等しく、IP SAN はリモートノードネットワークの CIDR に属するものです。 **ハイブリッドプロファイルは既に存在します** `nodeadm` 設定を変更し、ノードを新しい設定に再登録しようとすると、ハイブリッドプロファイルが既に存在するが、その内容が変更されたことを示すエラーが表示されることがあります。設定変更の合間に `nodeadm init` を実行する代わりに、`nodeadm uninstall` を実行し、その後に `nodeadm install` と `nodeadm init` を実行します。これにより、設定の変更に伴う適切なクリーンアップが保証されます。 ``` "msg":"Command failed","error":"hybrid profile already exists at /etc/aws/hybrid/config but its contents do not align with the expected configuration" ``` **ハイブリッドノードがプライベート API の解決に失敗しました** `nodeadm init` 実行後、`no such host` が存在するために EKS Kubernetes API サーバーへの接続に失敗したことを示すエラーが `kubelet` ログに表示された場合は、オンプレミスネットワークまたはホストレベルで EKS Kubernetes API エンドポイントの DNS エントリを変更する必要がある場合があります。「* AWS Route53 documentation*」の「[Forwarding inbound DNS queries to your VPC](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html)」を参照してください。 ``` Failed to contact API server when waiting for CSINode publishing: Get ... no such host ``` **EKS コンソールでハイブリッドノードを表示できない** ハイブリッドノードが登録されているのに、EKS コンソールで表示できない場合は、コンソールの表示に使用している IAM プリンシパルのアクセス許可を確認してください。使用している IAM プリンシパルには、コンソールでリソースを表示するための特定の最小の IAM および Kubernetes アクセス許可が必要です。詳細については、「[AWS マネジメントコンソール に Kubernetes リソースを表示する](view-kubernetes-resources.md)」を参照してください。 ## ハイブリッドノードのトラブルシューティングの実行 EKS クラスターに登録されたハイブリッドノードのステータスが `Ready` で、その後ステータスが `Not Ready` に移行した場合、ノードに CPU、メモリ、使用可能なディスク容量の十分なリソースがない、ノードが EKS コントロールプレーンから切断されているなど、さまざまな問題が異常なステータスの原因となった可能性があります。以下のステップを使用してノードのトラブルシューティングを行うことができます。問題を解決できない場合は、AWS サポートにお問い合わせください。 ハイブリッドノードから `nodeadm debug` を実行して、ネットワークと認証情報の要件が満たされていることを確認します。`nodeadm debug` コマンドの詳細については、「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。 **ノードのステータスを取得する** ``` kubectl get nodes -o wide ``` **ノードの条件とイベントを確認する** ``` kubectl describe node NODE_NAME ``` **ポッドのステータスを取得する** ``` kubectl get pods -A -o wide ``` **ポッドの条件とイベントを確認する** ``` kubectl describe pod POD_NAME ``` **ポッドログを確認する** ``` kubectl logs POD_NAME ``` **`kubectl` ログを確認する** ``` systemctl status kubelet ``` ``` journalctl -u kubelet -f ``` **ポッドのライブネスプローブが失敗しているか、ウェブフックが機能していない** ハイブリッドノードで動作しているアプリケーション、アドオン、またはウェブフックが正しく起動しない場合、ポッドへの通信をブロックするネットワークの問題が発生する可能性があります。EKS コントロールプレーンがハイブリッドノードで動作しているウェブフックに接続するには、リモートポッドネットワークで EKS クラスターを設定し、VPC ルーティングテーブルにオンプレミスポッド CIDR のルートを設定し、ターゲットを Transit Gateway (TGW)、仮想プライベートゲートウェイ (VPW)、または VPC をオンプレミスネットワークに接続するために使用するその他のゲートウェイとして設定する必要があります。ハイブリッドノードのネットワーク要件の詳細については、「[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md)」を参照してください。さらに、オンプレミスのファイアウォールでこのトラフィックを許可し、ルーターがポッドに適切にルーティングできることを確認する必要があります。ハイブリッドノードでウェブフックを実行するための要件の詳細については、「[ハイブリッドノード用のウェブフックを設定する](hybrid-nodes-webhooks.md)」を参照してください。 このシナリオの一般的なポッドログメッセージを以下に示します。ここでは、ip-address は Kubernetes サービスのクラスター IP です。 ``` dial tcp :443: connect: no route to host ``` **`kubectl logs` または `kubectl exec` コマンドが機能していない (`kubelet` API コマンド)** 他の `kubectl` コマンドは正常に実行されているのに、`kubectl attach`、`kubectl cp`、`kubectl exec`、`kubectl logs`、`kubectl port-forward` コマンドがタイムアウトした場合は、リモートネットワークの設定に問題がある可能性があります。これらのコマンドはクラスターを介してノードの `kubelet` エンドポイントに接続しています。詳細については、「[`kubelet` エンドポイント](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-kubelet-api)」を参照してください。 ノード IP とポッド IP が、ご自身のクラスター向けに設定したリモートノードネットワークおよびリモートポッドネットワーク CIDR の範囲に含まれていることを確認します。以下のコマンドを使用して IP の割り当てを調べます。 ``` kubectl get nodes -o wide ``` ``` kubectl get pods -A -o wide ``` これらの IP を、設定したリモートネットワークの CIDR と比較して、適切にルーティングされていることを確認します。ネットワークの設定要件については、「[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md)」を参照してください。 ## ハイブリッドノード CNI のトラブルシューティング ハイブリッドノードで最初に Cilium または Calico を起動する際に問題が発生した場合は、多くの場合、ハイブリッドノードまたはハイブリッドノードで稼働する CNI ポッドと EKS コントロールプレーン間のネットワークの問題が原因です。環境が「ハイブリッドノードのネットワークを準備する」の要件を満たしていることを確認します。問題を分割すると分かりやすくなります。 EKS クラスター設定 RemoteNodeNetwork と RemotePodNetwork の設定は正しいですか? VPC の設定 VPC ルーティングテーブルに、Transit Gateway または Virtual Private Gateway のターゲットを持つ RemoteNodeNetwork と RemotePodNetwork のルートはありますか? セキュリティグループの構成 RemoteNodeNetwork および RemotePodNetwork のインバウンドルールとアウトバウンドルールはありますか? オンプレミスのネットワーク EKS コントロールプレーンとハイブリッドノード、およびハイブリッドノードで実行されているポッドとの間のルートとアクセスはありますか? CNI の設定 オーバーレイネットワークを使用している場合、CNI の IP プール設定は、ウェブフックを使用している場合に EKS クラスター用に設定された RemotePodNetwork と一致していますか? **CNI がインストールされていないハイブリッドノードのステータス `Ready`** ハイブリッドノードのステータスが `Ready` と表示されているが、クラスターに CNI をインストールしていない場合は、ハイブリッドノードに古い CNI アーティファクトが存在する可能性があります。デフォルトでは、Helm などのツールを使用して Cilium と Calico をアンインストールしても、ディスク上のリソースは物理マシンや仮想マシンからは削除されません。さらに、これらの CNI のカスタムリソース定義 (CRD) は、古いインストールからクラスターにまだ存在する場合があります。詳細については、「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」の「Cilium と Calico の削除」セクションを参照してください。 **Cilium のトラブルシューティング** ハイブリッドノードで Cilium の実行に問題がある場合は、Cilium ドキュメントの「[トラブルシューティング手順](https://docs.cilium.io/en/stable/operations/troubleshooting/)」を参照してください。以下のセクションでは、ハイブリッドノードへの Cilium のデプロイに固有の問題について説明します。 **Cilium が起動しない** 各ハイブリッドノードで実行されている Cilium エージェントが開始されていない場合は、Cilium エージェントポッドのログにエラーがないか確認します。Cilium エージェントを起動するには、EKS Kubernetes API エンドポイントへの接続が必要です。この接続が正しく設定されていない場合、Cilium エージェントの起動は失敗します。この場合、Cilium エージェントポッドログに次のようなログメッセージが表示されます。 ``` msg="Unable to contact k8s api-server" level=fatal msg="failed to start: Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" ``` Cilium エージェントはホストネットワークで実行されます。EKS クラスターは、Cilium 接続用に `RemoteNodeNetwork` で設定する必要があります。EKS クラスターに `RemoteNodeNetwork` のインバウンドルールを持つ追加のセキュリティグループがあり、VPC に`RemoteNodeNetwork` のルートがあり、EKS コントロールプレーンへの接続を許可するようにオンプレミスネットワークが正しく設定されていることを確認します。 Cilium オペレータが実行されていて、一部の Cilium エージェントが動作しているが、すべてが動作していない場合は、クラスター内のすべてのノードに割り当てるポッド IP があることを確認します。Cilium 設定で `clusterPoolIPv4PodCIDRList` でクラスタープール IPAM を使用するときに、割り当て可能なポッド CIDR のサイズを設定します。ノードごとの CIDR サイズは、Cilium 設定の `clusterPoolIPv4MaskSize` 設定で設定されます。詳細については、Cilium ドキュメントの「[Expanding the cluster pool](https://docs.cilium.io/en/stable/network/concepts/ipam/cluster-pool/#expanding-the-cluster-pool)」を参照してください。 **Cilium BGP が機能しない** Cilium BGP コントロールプレーンを使用して、ポッドまたはサービスアドレスをオンプレミスネットワークにアドバタイズする場合は、次の Cilium CLI コマンドを使用して、BGP がリソースへのルートをアドバタイズしているかどうかを確認できます。Cilium CLI をインストールする手順については、Cilium ドキュメントの「[Cilium CLI のインストール](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-the-cilium-cli)」を参照してください。 BGP が正しく動作している場合は、ハイブリッドノードの出力に Session State `established` が含まれている必要があります。場合によっては、ネットワークチームと協力して、環境のローカル AS、ピア AS、ピアアドレスの正しい値を特定する必要があります。 ``` cilium bgp peers ``` ``` cilium bgp routes ``` Cilium BGP を使用してタイプ `LoadBalancer` のサービスの IP をアドバタイズする場合は、`CiliumLoadBalancerIPPool` と Service の両方に同じラベルが必要です。ラベルは、`CiliumBGPAdvertisement` のセレクタで使用する必要があります。次に例を示します。Cilium BGP を使用して LoadBalancer タイプのサービスの IP をアドバタイズしている場合、Cilium エージェントの再起動中に BGP ルートが中断される可能性があります。詳細については、「Cilium documentation」の「[Failure Scenarios](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane-operation/#failure-scenarios)」を参照してください。 **サービス** ``` kind: Service apiVersion: v1 metadata: name: guestbook labels: app: guestbook spec: ports: - port: 3000 targetPort: http-server selector: app: guestbook type: LoadBalancer ``` **CiliumLoadBalancerIPPool** ``` apiVersion: cilium.io/v2alpha1 kind: CiliumLoadBalancerIPPool metadata: name: guestbook-pool labels: app: guestbook spec: blocks: - cidr: serviceSelector: matchExpressions: - { key: app, operator: In, values: [ guestbook ] } ``` **CiliumBGPAdvertisement** ``` apiVersion: cilium.io/v2alpha1 kind: CiliumBGPAdvertisement metadata: name: bgp-advertisements-guestbook labels: advertise: bgp spec: advertisements: - advertisementType: "Service" service: addresses: - ExternalIP - LoadBalancerIP selector: matchExpressions: - { key: app, operator: In, values: [ guestbook ] } ``` **Calico のトラブルシューティング** ハイブリッドノードで Calico の実行に問題がある場合は、Calico ドキュメントの「[トラブルシューティング手順](https://docs.tigera.io/calico/latest/operations/troubleshoot/)」を参照してください。以下のセクションでは、Calico をハイブリッドノードにデプロイする際に特有の問題について説明します。 次の表は、Calico コンポーネントと、それらがデフォルトでノードネットワークまたはポッドネットワークで実行されているかどうかをまとめたものです。ポッドの送信トラフィックに NAT を使用するように Calico を設定した場合、オンプレミスネットワークはオンプレミスノード CIDR にトラフィックをルーティングするように設定する必要があり、VPC ルーティングテーブルはトランジットゲートウェイ (TGW) または仮想プライベートゲートウェイ (VGW) をターゲットとするオンプレミスノード CIDR のルートで設定する必要があります。ポッドの送信トラフィックに NAT を使用するように Calico を設定していない場合は、オンプレミスネットワークがオンプレミスポッド CIDR にトラフィックをルーティングするように設定し、VPC ルーティングテーブルをトランジットゲートウェイ (TGW) または仮想プライベートゲートウェイ (VGW) をターゲットとするオンプレミスポッド CIDR のルートで設定する必要があります。 | コンポーネント | Network | | --- | --- | | Calico API サーバー | ノード | | Kubernetes 用の Calico コントローラー | ポッド | | Calico ノードエージェント | ノード | | Calico `typha` | ノード | | Calico CSI ノードドライバー | ポッド | | Calico 演算子 | ノード | **Calico リソースは、遮断されたノードでスケジュールまたは実行されています** DaemonSet として実行されない Calico リソースには、デフォルトで柔軟な許容範囲があり、ポッドのスケジュールや実行の準備が整っていない遮断されたノードでスケジュールできます。以下を含めるようにオペレータのインストールを変更することで、DaemonSet Calico 以外のリソースの許容範囲を厳しくすることができます。 ``` installation: ... controlPlaneTolerations: - effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 300 - effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists tolerationSeconds: 300 calicoKubeControllersDeployment: spec: template: spec: tolerations: - effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 300 - effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists tolerationSeconds: 300 typhaDeployment: spec: template: spec: tolerations: - effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 300 - effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists tolerationSeconds: 300 ``` ## 認証情報のトラブルシューティング AWS SSM ハイブリッドアクティベーションと AWS IAM Roles Anywhere の両方で、ハイブリッドノードから次のコマンドを実行して、ハイブリッドノード IAM ロールの認証情報がハイブリッドノードで正しく設定されていることを検証できます。ノード名とハイブリッドノード IAM ロール名が想定どおりであることを確認します。 ``` sudo aws sts get-caller-identity ``` ``` { "UserId": "ABCDEFGHIJKLM12345678910:", "Account": "", "Arn": "arn:aws:sts:::assumed-role/" } ``` ** AWSSystems Manager (SSM) のトラブルシューティング** ハイブリッドノードの認証情報に AWS SSM ハイブリッドアクティベーションを使用している場合は、`nodeadm` によってハイブリッドノードにインストールされている次の SSM ディレクトリとアーティファクトに注意してください。SSM エージェントの詳細については、「*AWS Systems Manager ユーザーガイド*」の「[SSM Agent の使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html)」を参照してください。 | 説明 | 場所 | | --- | --- | | SSM エージェント | Ubuntu - `/snap/amazon-ssm-agent/current/amazon-ssm-agent` RHEL & AL2023 - `/usr/bin/amazon-ssm-agent` | | SSM エージェントログ | `/var/log/amazon/ssm` | | AWS 認証情報 | `/root/.aws/credentials` | | SSM Setup CLI | `/opt/ssm/ssm-setup-cli` | **SSM エージェントを再起動する** SSM エージェントを再起動することで解決できる問題もあります。以下のコマンドを使用して再起動できます。 **AL2023 およびその他のオペレーティングシステム** ``` systemctl restart amazon-ssm-agent ``` **Ubuntu** - ``` systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent ``` **SSM エンドポイントへの接続を確認する** ハイブリッドノードから SSM エンドポイントに接続できることを確認します。SSM エンドポイントのリストについては、「[AWS Systems Manager endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/ssm.html)」を参照してください。以下のコマンドの `us-west-2` を、AWS SSM ハイブリッドアクティベーションの AWS リージョンに置き換えます。 ``` ping ssm.us-west-2.amazonaws.com ``` **登録された SSM インスタンスの接続ステータスを表示する** 次の AWS CLI コマンドを使用して、SSM ハイブリッドアクティベーションに登録されているインスタンスの接続ステータスを確認できます。マシン ID をインスタンスのマシン ID に置き換えます。 ``` aws ssm get-connection-status --target mi-012345678abcdefgh ``` **SSM セットアップ CLI チェックサムの不一致** `nodeadm install` の実行時に、`ssm-setup-cli` チェックサムの不一致に問題がある場合は、ホストに古い既存の SSM インストールがないことを確認する必要があります。ホストに古い SSM インストールがある場合は、それらを削除して `nodeadm install` を再実行し、問題を解決します。 ``` Failed to perform agent-installation/on-prem registration: error while verifying installed ssm-setup-cli checksum: checksum mismatch with latest ssm-setup-cli. ``` **SSM `InvalidActivation`** インスタンスを AWS SSM に登録する際にエラーが表示された場合は、`nodeConfig.yaml` の `region`、`activationCode`、および `activationId` が正しいことを確認します。EKS クラスターの AWS リージョンは、SSM ハイブリッドアクティベーションのリージョンと一致する必要があります。これらの値が誤って設定されている場合は、次のようなエラーが表示されることがあります。 ``` ERROR Registration failed due to error registering the instance with AWS SSM. InvalidActivation ``` **SSM `ExpiredTokenException`: リクエストに含まれているセキュリティトークンが有効期限切れです** SSM エージェントが認証情報を更新できない場合は、「`ExpiredTokenException`」が表示されることがあります。このシナリオでは、ハイブリッドノードから SSM エンドポイントに接続できる場合、認証情報の更新を強制するために SSM エージェントを再起動する必要がある場合があります。 ``` "msg":"Command failed","error":"operation error SSM: DescribeInstanceInformation, https response error StatusCode: 400, RequestID: eee03a9e-f7cc-470a-9647-73d47e4cf0be, api error ExpiredTokenException: The security token included in the request is expired" ``` **register machine コマンドの実行中の SSM エラー** マシンを SSM に登録する際にエラーが発生した場合は、`nodeadm install` を再実行して、すべての SSM 依存関係が正しくインストールされていることを確認する必要があります。 ``` "error":"running register machine command: , error: fork/exec /opt/aws/ssm-setup-cli: no such file or directory" ``` **SSM `ActivationExpired`** `nodeadm init` の実行時に、アクティベーションの有効期限が切れたために SSM へのインスタンスの登録がエラーになった場合は、新しい SSM ハイブリッドアクティベーションを作成し、新しい SSM ハイブリッドアクティベーションの `activationCode` と `activationId` で `nodeConfig.yaml` を更新して、`nodeadm init` を再実行する必要があります。 ``` "msg":"Command failed","error":"SSM activation expired. Please use a valid activation" ``` ``` ERROR Registration failed due to error registering the instance with AWS SSM. ActivationExpired ``` **SSM がキャッシュされた認証情報を更新できませんでした** キャッシュされた認証情報の更新に失敗した場合、`/root/.aws/credentials` ファイルはホストで削除されている可能性があります。まず、SSM ハイブリッドアクティベーションをチェックして、アクティブであること、およびアクティベーションを使用するようにハイブリッドノードが正しく設定されていることを確認します。`/var/log/amazon/ssm` で SSM エージェントログを確認し、SSM 側で問題を解決したら `nodeadm init` コマンドを再実行します。 ``` "Command failed","error":"operation error SSM: DescribeInstanceInformation, get identity: get credentials: failed to refresh cached credentials" ``` **SSM のクリーンアップ** ホストから SSM エージェントを削除するには、次のコマンドを実行します。 ``` dnf remove -y amazon-ssm-agent sudo apt remove --purge amazon-ssm-agent snap remove amazon-ssm-agent rm -rf /var/lib/amazon/ssm/Vault/Store/RegistrationKey ``` ** AWSIAM Roles Anywhere のトラブルシューティング** ハイブリッドノードの認証情報に AWS IAM Roles Anywhere を使用している場合は、`nodeadm` によってハイブリッドノードにインストールされている次のディレクトリとアーティファクトに注意してください。IAM Roles Anywhere のトラブルシューティングの詳細については、「*AWS IAM Roles Anywhere User Guide*」の「[Troubleshooting AWS IAM Roles Anywhere identity and access](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/security_iam_troubleshoot.html)」を参照してください。 | 説明 | 場所 | | --- | --- | | IAM Roles Anywhere CLI | `/usr/local/bin/aws_signing_helper` | | デフォルトの証明書の場所と名前 | `/etc/iam/pki/server.pem` | | デフォルトのキーの場所と名前 | `/etc/iam/pki/server.key` | **IAM Roles Anywhere がキャッシュされた認証情報の更新に失敗しました** キャッシュされた認証情報の更新に失敗した場合は、`/etc/aws/hybrid/config` の内容を確認し、`nodeadm` 設定で IAM Roles Anywhere が正しく設定されていることを確認します。`/etc/iam/pki` が存在することを確認します。各ノードには一意の証明書とキーが必要です。デフォルトでは、認証情報プロバイダーとして IAM Roles Anywhere を使用する場合、`nodeadm` は証明書の場所と名前に `/etc/iam/pki/server.pem` を使用し、プライベートキーに `/etc/iam/pki/server.key` を使用します。`sudo mkdir -p /etc/iam/pki` を使用してディレクトリに証明書とキーを配置する前に、ディレクトリの作成が必要になる場合があります。証明書の内容は、以下のコマンドで確認できます。 ``` openssl x509 -text -noout -in server.pem ``` ``` open /etc/iam/pki/server.pem: no such file or directory could not parse PEM data Command failed {"error": "... get identity: get credentials: failed to refresh cached credentials, process provider error: error in credential_process: exit status 1"} ``` ** の実行が許可されていない IAM Roles Anywhere`sts:AssumeRole`** `kubelet` ログで、IAM Roles Anywhere の使用時に `sts:AssumeRole` オペレーションに対するアクセス拒否の問題が表示された場合は、ハイブリッドノード IAM ロールの信頼ポリシーをチェックして、IAM Roles Anywhere サービスプリンシパルがハイブリッドノード IAM ロールを引き受けることができることを確認します。さらに、ハイブリッドノード IAM ロールの信頼ポリシーでトラストアンカー ARN が正しく設定されていること、およびハイブリッドノード IAM ロールが IAM Roles Anywhere プロファイルに追加されていることを確認します。 ``` could not get token: AccessDenied: User: ... is not authorized to perform: sts:AssumeRole on resource: ... ``` ** を設定することが許可されていない IAM Roles Anywhere`roleSessionName`** `kubelet` ログで、`roleSessionName` の設定にアクセス拒否の問題が発生した場合は、IAM Roles Anywhere プロファイルで `acceptRoleSessionName` を true に設定していることを確認します。 ``` AccessDeniedException: Not authorized to set roleSessionName ``` ## オペレーティングシステムのトラブルシューティング ### RHEL **使用権限管理者またはサブスクリプションマネージャーの登録失敗** `nodeadm install` を実行中で、使用権限登録の問題によりハイブリッドノードの依存関係のインストールに失敗した場合、ホストに Red Hat ユーザー名とパスワードを適切に設定していることを確認してください。 ``` This system is not registered with an entitlement server ``` ### Ubuntu **GLIBC が見つかりません** オペレーティングシステムに Ubuntu を使用し、ハイブリッドノードを持つ認証情報プロバイダーに IAM Roles Anywhere を使用していて、GLIBC が見つからない問題がある場合は、その依存関係を手動でインストールすることで問題を解決できます。 ``` GLIBC_2.32 not found (required by /usr/local/bin/aws_signing_helper) ``` 次のコマンドを実行して依存関係をインストールします。 ``` ldd --version sudo apt update && apt install libc6 sudo apt install glibc-source ``` ### Bottlerocket Bottlerocket 管理コンテナを有効にしている場合、SSH を使用してこれにアクセスし、昇格された権限を使って高度なデバッグとトラブルシューティングを行うことができます。以下のセクションでは、Bottlerocket ホストのコンテキストで実行する必要があるコマンドを記載しています。管理コンテナにアクセスすると、`sheltie` を実行すれば Bottlerocket ホストで完全なルートシェルを取得することができます。 ``` sheltie ``` 以下のセクションにあるコマンドは、各コマンドの前に `sudo chroot /.bottlerocket/rootfs` を付けることで管理者コンテナシェルから実行することもできます。 ``` sudo chroot /.bottlerocket/rootfs ``` **ログ収集に logdog を使用する** Bottlerocket には、トラブルシューティングを目的に、ログとシステム情報とを効率的に収集する `logdog` ユーティリティがあります。 ``` logdog ``` `logdog` ユーティリティは、Bottlerocket ホストのさまざまな場所からログを収集し、それらを tarball と組み合わせます。デフォルトでは、tarball は `/var/log/support/bottlerocket-logs.tar.gz` で作成され、`/.bottlerocket/support/bottlerocket-logs.tar.gz` にあるホストコンテナからアクセスすることができます。 **journalctl を使用したシステムログへのアクセス** 次のコマンドを使用することで、`kubelet`、`containerd` などのさまざまなシステムサービスのステータスをチェックしたりログを表示したりできます。`-f` フラグは、ログをリアルタイムでフォローします。 `kubelet` サービスのステータスを確認し `kubelet` ログを取得するときは、以下を実行します。 ``` systemctl status kubelet journalctl -u kubelet -f ``` `containerd` サービスのステータスを確認し、オーケストレーションされた `containerd` インスタンスのログを取得するときは、以下を実行します。 ``` systemctl status containerd journalctl -u containerd -f ``` `host-containerd` サービスのステータスを確認し、ホスト `containerd` インスタンスのログを取得するときは、以下を実行します。 ``` systemctl status host-containerd journalctl -u host-containerd -f ``` ブートストラップコンテナとホストコンテナのログを取得するときは、以下を実行します。 ``` journalctl _COMM=host-ctr -f ```