Amazon EKS Hybrid Nodes への Dive Deep

この記事は A deep dive into Amazon EKS Hybrid Nodes (記事公開日: 2024 年 1 月 27 日) を翻訳したものです。

この記事は、AWS の Kubernetes Principal Product Manager である Chris Splinter、AWS の Sr. Container Specialist Solutions Architect である Elamaran Shanmugam、AWS の Containers Specialist Solutions Architect である Re Alvarez Parmar が執筆しました。

Amazon Elastic Kubernetes Service (Amazon EKS) の新機能である Amazon EKS Hybrid Nodes の一般提供を re:Invent 2024 で発表できることをうれしく思います。EKS Hybrid Nodes を使用すると、ユーザーはオンプレミスとエッジのインフラを Amazon EKS クラスターのノードとして使用できるため、クラウド・オンプレミス・エッジ環境にわたって統一された Kubernetes の管理体験を実現できます。これは、モダナイゼーション・機械学習(ML)・メディアストリーミング・製造ワークロードなど、さまざまなユースケースで使用できます。

AWS クラウドで、新規開発あるいはモダナイズされたアプリケーションのために Kubernetes を利用しているユーザーは、しばしばこれらの機能をオンプレミスおよびエッジ環境で実行されているアプリケーションの管理にまで拡張したいと考えています。これは、レイテンシーの低減、データ依存性、データ主権、規制、ポリシー上の理由からです。これまで、オンプレミスのデータセンターやエッジ環境で Kubernetes を実行しようとするユーザーは、オープンソースの Kubernetes やそれに似たセルフマネージド Kubernetes ソリューションを実行および運用する必要がありました。オンプレミスでの Kubernetes を自身で運用することは複雑で、運用上のオーバーヘッドを追加することになり、最終的にはイノベーションとモダナイゼーションの計画を遅らせることになります。

EKS Hybrid Nodes は、ユーザーがオンプレミスおよびエッジの既存のキャパシティをマネージドな Amazon EKS コントロールプレーンにノードとして接続できるようにすることで、その複雑さとオーバーヘッドを削減します。これにより、オンプレミスでの Kubernetes の運用を効率化し、クラウドでワークロードを実行するためにユーザーが慣れ親しんだ EKS クラスター、機能、インテグレーション、ツールを使用して、オンプレミスでの一貫した運用体験が可能になります。

オーバービュー

EKS Hybrid Nodes を使用するには、オンプレミスのネットワークと EKS クラスターのある Amazon Virtual Private Cloud (Amazon VPC) 間の接続が必要です。 AWS Direct Connect、AWS Site-to-Site VPN、独自の VPN ソリューションを使用して、EKS クラスターとハイブリッドノード間のプライベート接続を作成できます。EKS Hybrid Nodes は、Amazon EKS のコントロールプレーンからワーカーノードへの通信に使用されている既存の仕組みを再利用します。したがって、AWS リージョン上の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスとオンプレミス環境で実行されているハイブリッドノードの両方を、同じ EKS クラスター内で実行できます。 EKS Hybrid Nodes は「Bring Your Own Infrastructure」のアプローチを使用しており、ハイブリッドノードとして使用するインフラストラクチャとオペレーティングシステムのプロビジョニングと管理はお客様の責任となります。既存のベアメタルサーバーまたは仮想化されたインフラストラクチャをハイブリッドノードのコンピューティングとして使用できます。現在、Amazon Linux 2023、Ubuntu、Red Hat Enterprise Linux (RHEL) が、ハイブリッドノードとの互換性のため AWS でサポートされているオペレーティングシステムです。

EKS Hybrid Nodes は、オンプレミスの各ホストで実行する EKS Hybrid Nodes CLI (nodeadm) を使用してインストールされ、EKS クラスターに接続できます。あるいは、ハイブリッドノードのブートストラップの自動化のために、ゴールデン OS イメージに nodeadm とハイブリッドノードの依存関係を含めることができます。これは、クラウドの EC2 インスタンスの Amazon EKS 最適化 Amazon Machine Images (AMI) で使用される仕組みと同様です。ハイブリッドノードが EKS クラスターへの接続を試みると、AWS Systems Manager ハイブリッドアクティベーションまたは IAM Roles Anywhere によってプロビジョニングされた一時的な AWS Identity and Access Management (IAM) 認証情報を使用して、ハイブリッドノードを EKS コントロールプレーンに安全に接続します。

EKS Hybrid Nodes は、CoreDNS・kube-proxy・Amazon Managed Service for Prometheus エージェントレススクレイパー・AWS Distro for Open Telemetry・CloudWatch Observability Agent・IAM Roles for Service Accounts (IRSA)・EKS Pod Identity など、クラスターネットワーキング、可観測性、Pod 認証のためのいくつかの Amazon EKS アドオンと機能もサポートしています。 Pod ネットワーキングの場合、ハイブリッドノードで使用するために Cilium と Calico Container Networking Interface (CNI) がサポートされています。

EKS Hybrid Nodes の仕組みの詳細については、EKS Hybrid Nodes ユーザーガイドを参照してください。

アーキテクチャ

EKS Hybrid Nodes を使用する前に、クラウドにホストされた Amazon EKS コントロールプレーンとお客様の環境で実行されているハイブリッドノード間のネットワークフローを理解する必要があります。ハイブリッドノードとそれらで実行されるリソースに使用するノードと Pod のネットワークは、IPv4 RFC-1918 Classless Inter-Domain Routing (CIDR) を使用する必要があります。ハイブリッドノード対応の EKS クラスターを作成するときに、これらのオンプレミスのノードと Pod ネットワークの CIDR を渡します。VPC とオンプレミスのルーティングテーブルは、エンドツーエンドのハイブリッドノードのトラフィックフローのために、このようなネットワークで構成する必要があります。ハイブリッドノードのネットワーキング要件の詳細については、Amazon EKS ユーザーガイドの「ハイブリッドノード用のネットワークを準備する」を参照してください。

図 1 : EKS Hybrid Nodes のハイブリッドネットワーキングアーキテクチャ

次の表は、ハイブリッドノードのネットワーキングアーキテクチャの主要な部分をまとめたものです。

環境	コンポーネント	説明
AWS リージョン	EKS クラスター設定	ログ、kubectl exec、ポートフォワードなどの Kubernetes 操作のため、EKS コントロールプレーンと kubelet 間の通信に EKS クラスター RemoteNodeNetwork 設定が必要です。
AWS リージョン	EKS クラスター設定	EKS コントロールプレーンと Webhook 間の通信には、 EKS クラスター設定の RemotePodNetwork が必要です。`RemotePodNetwork` は設定することをおすすめしますが、もしハイブリッドノードで Webhook を実行していない場合、厳密には必要ありません。
AWS リージョン	EKS クラスター VPC	VPC のルーティングテーブルには、VPC からのトラフィックの出口として使用しているゲートウェイをターゲットとして、`RemoteNodeNetwork` および `RemotePodNetwork` を送信先とするルートが必要です。ゲートウェイは通常、AWS Transit Gateway または Virtual Private Gateway (VGW) になります。
AWS リージョン	EKS クラスターセキュリティグループ	EKS コントロールプレーンへのインバウンドアクセスと、`RemoteNodeNetwork` および `RemotePodNetwork` へのアウトバウンドアクセスを許可する必要があります。
オンプレミス	オンプレミスファイヤウォール	EKS コントロールプレーンへのインバウンドアクセスと、`RemoteNodeNetwork` および `RemotePodNetwork` へのアウトバウンドアクセスを許可する必要があります。
オンプレミス	オンプレミスルーター	オンプレミスルーターは `RemoteNodeNetwork` および `RemotePodNetwork` へのトラフィックをルーティングできなければなりません。
オンプレミス	Container Networking Interface (CNI)	CNI で設定するオーバーレイネットワーク CIDR は、`RemotePodNetwork` と同じでなければなりません。ホストネットワーキングを使用している場合は、ノード CIDR が `RemoteNodeNetwork` と同じである必要があります。

ウォークスルー

このウォークスルーでは、Systems Manager ハイブリッドアクティベーションを使用してハイブリッドノードの IAM 認証情報を設定し、ハイブリッドノード対応の EKS クラスターを作成し、ハイブリッドノードを EKS クラスターに接続し、アプリケーションの実行準備が整うように Cilium CNI をインストールします。このウォークスルーでは、EKS クラスターの作成に AWS Command Line Interface (AWS CLI) と AWS CloudFormation を使用していますが、AWS マネジメントコンソール、eksctl CLI、Terraform などの他のインターフェースを代わりに使用することもできます。

前提条件

このソリューションを完了するには、以下の前提条件が必要になります。

オンプレミス環境と AWS 間のハイブリッドネットワーク接続
物理マシンや仮想マシンなどのインフラストラクチャ
ハイブリッドノードと互換性のあるオペレーティングシステム
AWS CLI バージョン 2.22.8 以降、または適切な認証情報を持つ 1.36.13 以降
eksctl CLI
このウォークスルーの手順を実行する IAM ユーザーは、次のアクションの IAM アクセス許可を持っている必要があります: iam:CreatePolicy、iam:CreateRole、iam:AttachRolePolicy、ssm:CreateActivation、eks:CreateCluster

ハイブリッドノードのための認証情報の準備

クラウド上の EC2 インスタンスで動作している EKS ノードと同様に、ハイブリッドノードは EKS コントロールプレーンに接続するために IAM ロールを必要とします。次に、ハイブリッドノードの IAM ロールは、Systems Manager ハイブリッドアクティベーションまたは IAM Roles Anywhere とともに使用され、一時的な IAM 認証情報がプロビジョニングされます。一般的に、オンプレミス環境に既存の公開鍵基盤(PKI)と証明書がない場合は、Systems Manager ハイブリッドアクティベーションを推奨します。既存の PKI と証明書がある場合は、これらを IAM Roles Anywhere で使用できます。

ハイブリッドノードに使用する IAM ロールには、以下のアクセス許可が必要です。

ハイブリッドノードが EKS クラスターに接続する際に、EKS クラスターの情報を収集する必要があります。そのためには、ハイブリッドノード CLI (nodeadm) が eks:DescribeCluster アクションを実行するためのアクセス許可が必要です。eks:DescribeCluster アクションを有効にしない場合は、nodeadm init を実行するときに nodeadm に渡すノードの設定に、Kubernetes API エンドポイント、クラスター CA バンドル、サービス IPv4 CIDR を指定する必要があります。
AmazonEC2ContainerRegistryPullOnly ポリシーで定義されているような、Amazon Elastic Container Registry (Amazon ECR) からコンテナイメージを取得する kubelet のためのアクセス許可が必要です。
Systems Manager を使用する場合は、AmazonSSMManagedInstanceCore ポリシーで定義されているような nodeadm init が Systems Manager ハイブリッドアクティベーションを使用するためのアクセス許可と、nodeadm uninstall でインスタンスの登録を解除するための ssm:DeregisterManagedInstance アクションと ssm:DescribeInstanceInformation アクションを使用するアクセス許可が必要です。

これらのステップでは、AWS CLI と CloudFormation を使用して、前述のアクセス許可を持つハイブリッドノードの IAM ロールを作成します。次に、AWS CLI を使用して、ハイブリッドノードの IAM ロールを使用して Systems Manager ハイブリッドアクティベーションを作成します。

まず最初に、CloudFormation テンプレートを AWS CLI を実行するマシンにダウンロードします。

curl -OL 'https://raw.githubusercontent.com/aws/eks-hybrid/refs/heads/main/example/hybrid-ssm-cfn.yaml'

デフォルトでは、CloudFormation テンプレートは ssm:DeregisterManagedInstance のアクセス許可を、ハイブリッドノードの IAM ロールがクラスター用に作成したハイブリッドアクティベーションに関連付けられたインスタンスのみ登録解除できるよう制限しています。ハイブリッドノードの IAM ロールのアクセス許可で使用される SSMDeregisterConditionTagKey と SSMDeregisterConditionTagValue は、後のステップで示す Systems Manager ハイブリッドアクティベーションの作成時に適用するタグと対応している必要があります。

# Define environment variables
EKS_CLUSTER_NAME=my-hybrid-cluster
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text)
AWS_REGION=${AWS_REGION:=us-west-2}
EKS_CLUSTER_ARN=arn:aws:eks:${AWS_REGION}:${AWS_ACCOUNT_ID}:cluster/${EKS_CLUSTER_NAME}
ROLE_NAME=AmazonEKSHybridNodesRole

# Create cfn-ssm-parameters.json
cat << EOF > cfn-ssm-parameters.json { "Parameters": { "RoleName": "$ROLE_NAME", "SSMDeregisterConditionTagKey": "EKSClusterARN", "SSMDeregisterConditionTagValue": "$EKS_CLUSTER_ARN" } } EOF

CloudFormation スタックをデプロイします。AWS_REGION をハイブリッドアクティベーションを作成する希望の AWS リージョンに置き換えます。ハイブリッドアクティベーションのリージョンは、EKS クラスターのリージョンと同じである必要があります。

aws cloudformation deploy \
    --stack-name EKSHybridRoleSSM \
    --region ${AWS_REGION} \
    --template-file hybrid-ssm-cfn.yaml \
    --parameter-overrides file://cfn-ssm-parameters.json \
    --capabilities CAPABILITY_NAMED_IAM

ハイブリッドノードの IAM ロールを作成した後、次のステップはその IAM ロールを使用して Systems Manager ハイブリッドアクティベーションを作成することです。デフォルトでは、Systems Manager ハイブリッドアクティベーションは 24 時間有効で、最大有効期限は 30 日です。ハイブリッドアクティベーションを作成するときに、2024-08-01T00:00:00 のようなタイムスタンプ形式で --expiration-date を指定できます。 Systems Manager を認証情報プロバイダーとして使用する場合、ハイブリッドノードのノード名は設定できず、mi-012345678abcdefgh という形式で Systems Manager によって自動生成されます。Systems Manager コンソールのFleet Manager 下で、Systems Manager マネージドインスタンスを表示および管理できます。

次のコマンドを使用して、前のステップで作成した IAM ロールを --iam-role フラグで渡して、Systems Manager のハイブリッドアクティベーションを作成します。前のステップで作成したハイブリッドノードの IAM ロールに設定された信頼ポリシーに対応するハイブリッドアクティベーションを作成するときに適用するタグに注意してください。Systems Manager の create-activation コマンドの出力は、後のステップで EKS クラスターにハイブリッドノードを接続するときに使用するアクティベーションコードとアクティベーション ID が含まれているので、必ず保存してください。

# Define environment variables
EKS_CLUSTER_NAME=my-hybrid-cluster
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text)
AWS_REGION=${AWS_REGION:=us-west-2}
EKS_CLUSTER_ARN=arn:aws:eks:${AWS_REGION}:${AWS_ACCOUNT_ID}:cluster/${EKS_CLUSTER_NAME}
ROLE_NAME=AmazonEKSHybridNodesRole

# Create SSM hybrid activation
aws ssm create-activation \
     --region ${AWS_REGION} \
     --default-instance-name eks-hybrid-nodes \
     --description "Activation for EKS hybrid nodes" \
     --iam-role ${ROLE_NAME} \
     --tags Key=EKSClusterARN,Value=${EKS_CLUSTER_ARN} \
     --registration-limit 5

ハイブリッドノードのための EKS クラスターを作成する

これらのステップでは、AWS CLI と CloudFormation を使用して、EKS クラスターの IAM ロールとハイブリッドノード対応の EKS クラスターを作成します。

まず最初に、CloudFormation テンプレートを AWS CLI を実行するマシンにダウンロードします。

curl -OL 'https://raw.githubusercontent.com/aws/eks-hybrid/refs/heads/main/example/hybrid-eks-cfn.yaml'

デフォルトでは、CloudFormation テンプレートは EKS クラスターをプライベートエンドポイント接続で作成します。これは、Kubernetes API エンドポイントに VPC 内からのみアクセスできることを意味します。

パブリックエンドポイント接続が必要な場合は、CloudFormation パラメータファイルで ClusterEndpointConnectivity を Public に設定できます。

次の CloudFormation パラメータファイルの例では、ハイブリッドノードの要件を満たす既存のサブネットを使用しています。これは、Direct Connect を介してオンプレミス環境に接続された Transit Gateway にアタッチされた VPC 内のサブネットです。 Amazon EKS は、EKS コントロールプレーンから VPC への接続性のために、提供されたサブネットに Elastic Network Interfaces (ENI) をアタッチします。 CloudFormation テンプレートは、RemoteNodeCIDR 、RemotePodCIDR、EKS コントロールプレーンからのトラフィックを許可するセキュリティグループも作成します。

cfn-eks-parameters.json ファイル内の値を、ご自身の環境の値に置き換えてください。

cat << EOF > cfn-eks-parameters.json { "Parameters": { "ClusterName": "my-hybrid-cluster", "ClusterRoleName": "EKSHybridClusterRole", "SubnetId1": "subnet-0b65cdc4812345678", "SubnetId2": "subnet-02f526cd012345678", "VpcId": "vpc-0a5f3bee960d6ec71", "RemoteNodeCIDR": "10.80.150.0/24", "RemotePodCIDR": "10.80.2.0/23", "K8sVersion": "1.31" } } EOF

CloudFormation スタックをデプロイします。クラスターが作成される希望の AWS リージョンで AWS_REGION を置き換えます。

aws cloudformation deploy \
    --stack-name EKSHybridCluster \
    --region ${AWS_REGION} \
    --template-file hybrid-eks-cfn.yaml \
    --parameter-overrides file://cfn-eks-parameters.json \
    --capabilities CAPABILITY_NAMED_IAM

クラスターのプロビジョニングには数分かかります。次のコマンドで CloudFormation スタックのステータスを確認できます。

aws cloudformation describe-stacks \
    --stack-name EKSHybridCluster \
    --region ${AWS_REGION} \
    --query 'Stacks[].StackStatus'

EKS クラスターを作成したら、ハイブリッドノードの IAM ロールを使用して Amazon EKS アクセスエントリを作成します。これにより、ノードがクラスターに参加できるようになります。詳細については、Amazon EKS ユーザーガイドの「ハイブリッドノードのクラスターアクセスを準備する」を参照してください。

# Define environment variables
EKS_CLUSTER_NAME=my-hybrid-cluster
ROLE_NAME=AmazonEKSHybridNodesRole

# Create access entry with type HYBRID_LINUX
aws eks create-access-entry \
    --cluster-name ${EKS_CLUSTER_NAME} \
    --principal-arn ${ROLE_NAME} \
    --type HYBRID_LINUX

EKS クラスターへのハイブリッドノードのインストールと接続

ハイブリッドノードの IAM ロール、Systems Manager ハイブリッドアクティベーション、EKS Hybrid Nodes が有効化された EKS クラスターを作成した後に、EKS クラスターにハイブリッドノードを作成、アタッチする準備が整います。 x86_64 または ARM の物理マシンや仮想マシンで前提条件を満たしていれば、ハイブリッドノードとして使用できます。インストール、設定、登録など、ハイブリッドノードのライフサイクル管理を簡略化するために設計された nodeadm と呼ばれるハイブリッドノード CLI があります。AL2023 Amazon EKS 最適化 AMI に基づいて Amazon EKS 用のカスタム AMI を構築したことがある場合、nodeadm にすでに慣れているかもしれません。 AL2023 Amazon EKS 最適化 AMI で使用されているクラウドバージョンの nodeadm は、ハイブリッドノードの nodeadm バージョンとは異なるため、デプロイしたい対象に基づいて適切なバージョンを使用する必要があることに注意してください。

ハイブリッドノード CLI はブートストラッププロセスで 2 つのステップを実行します。まず、ホスト上に必要な依存関係(kubelet、containerd、Systems Manager エージェント/IAM Roles Anywhere ツールなど) をインストールします。次に、依存関係を構成し開始することで、ノードが EKS クラスターに参加できるようにします。Amazon EKS は Packer テンプレートを提供しており、これを使用して Ubuntu と RHEL のハイブリッドノード用のイメージを作成できます。ハイブリッドノードを繰り返し作成したり、ブートストラッププロセスを自動化したい場合は、事前構築済みのイメージを使用することで時間を節約し、個々のホストで依存関係の取得を個別のプロセスとして実行する必要がなくなります。

ハイブリッドノードの依存関係をインストールするには、nodeadm install コマンドを実行します。以下の例では、Kubernetes バージョン 1.31 と認証情報プロバイダーとして ssm を使用しています。 EKS Hybrid Nodes は、標準サポートと拡張サポートのもとにある Amazon EKS と同じ Kubernetes バージョンをサポートしています。

ホスト上で root/sudo 権限を持つユーザーで nodeadm を実行する必要があることに注意してください。

sudo nodeadm install 1.31 --credential-provider ssm

必要な依存関係がノードにあるときは、設定のため nodeConfig.yaml を作成します。ノードの設定ファイルには、クラスター情報と認証に使用されるメカニズム(Systems Manager ハイブリッドアクティベーションまたは IAM Roles Anywhere) の 2 つの主要な詳細の設定が含まれています。

以下は、Systems Manager ハイブリッドアクティベーションを使用するハイブリッドノードの nodeConfig.yaml ファイルの例です。SSM_ACTIVATION_CODE と SSM_ACTIVATION_ID を、前の Systems Manager アクティベーションを作成するステップの出力値に置き換えてください。

apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: my-hybrid-cluster
    region: us-west-2
  hybrid:
    ssm:
      activationCode: SSM_ACTIVATION_CODE
      activationId: SSM_ACTIVATION_ID

ハイブリッドノードを EKS クラスターに接続するには、nodeConfig.yaml で nodeadm init コマンドを実行します。

sudo nodeadm init -c file://nodeConfig.yaml

コマンドが正常に完了し、kubelet のログにエラーがない場合、ハイブリッドノードは EKS クラスターに参加したことになります。これは、EKS クラスターの「コンピュートタブ」に移動 (IAM プリンシパルが表示権限を持っていることを確認してください) して EKS コンソールで確認するか、kubectl get nodes で確認できます。

NAME                   STATUS     ROLES    AGE    VERSION
mi-036ecab1709d75ee1   Not Ready  <none>   1h     v1.31.2-eks-94953ac

クラスターに代替の CNI がまだインストールされていない場合、CNI がインストールされ実行されるまで、接続したノードは Not Ready 状態のままです。

ハイブリッドノードのために CNI をインストール

ハイブリッドノードの CNI として Cilium と Calico がサポートされています。これらの CNI は、Helm などのツールを使って管理できます。 Amazon VPC CNI はハイブリッドノードと互換性がなく、VPC CNI はデフォルトでeks.amazonaws.com/compute-type: hybrid ラベルに対して Anti-Affinity が設定されています。ハイブリッドノードで Cilium と Calico を運用する詳細については、Amazon EKSユーザーガイドの「ハイブリッドノードの CNI を設定する」を参照してください。

CNI の DaemonSets がハイブリッドノード上にのみスケジュールされることを保証するために、nodeadm によってハイブリッドノードがクラスタに参加したときに自動的に適用される eks.amazonaws.com/compute-type=hybrid ラベルに対する Affinity を構成できます。このラベルにより、ワークロードの配置を制御できるようになり、CNI を含むコンポーネントをハイブリッドノード上で実行するかしないかを決定できます。

次の cilium-values.yaml は、Cilium をインストールするための Helm の Values を示しています。ハイブリッドノードのラベルに対するアフィニティと IP Address Management (IPAM) の設定に注意してください。この例では、Cluter Pool overlay IPAM モードを使用しています。ここで clusterPoolIPv4PodCIDRList を設定し、これは EKS クラスター作成時に指定した RemotePodNetwork の CIDR に対応する必要があります。以下の例の 10.80.2.0/23 を RemotePodNetwork の値に置き換えてください。この例では、clusterPoolIPv4MaskSize が 25 に設定されているため、ノードごとに 128 個の IP アドレスが割り当てられます。

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: eks.amazonaws.com/compute-type
          operator: In
          values:
          - hybrid
ipam:
  mode: cluster-pool
  operator:
    clusterPoolIPv4MaskSize: 25
    clusterPoolIPv4PodCIDRList:
    - 10.80.2.0/23
operator:
  unmanagedPodWatcher:
    restart: false

cilium-values.yaml ファイルを設定して作成した後、Helm を使用して Cilium をインストールできます。

CILIUM_VERSION=1.16.4

helm repo add cilium https://helm.cilium.io/

helm install cilium cilium/cilium \
    --version ${CILIUM_VERSION} \
    --namespace kube-system \
    --values cilium-values.yaml

CNI をデプロイした後、再度 kubectl get nodes を実行し、ノードが Ready 状態であることを確認してください。

NAME                   STATUS     ROLES    AGE    VERSION
mi-036ecab1709d75ee1   Ready      <none>   1h     v1.31.2-eks-94953ac

ハイブリッドノード上で実行されるワークロードの Ingress とロードバランシング

多くのユースケースでは、Kubernetes クラスターで実行されているワークロードは、外部リソースにアクセスできるようにクラスターの外部に公開する必要があります。通常 Kubernetes では Ingress とロードバランサーを介して Service を公開することで実現されます。ハイブリッドノードでは、アプリケーショントラフィックには 2 つの一般的な経路があります。1 つ目は、AWS リージョンからオンプレミスのハイブリッドノード上で実行されているワークロードに接続するアプリケーショントラフィックです。2 つ目は、オンプレミス環境内に留まるアプリケーショントラフィックです。

AWS リージョンから発信されるアプリケーショントラフィックでは、Direct Connect または AWS Site-to-Site VPN で接続されたハイブリッドノード上のワークロードに、ターゲットタイプ ip の Application Load Balancer (ALB) または Network Load Balancer (NLB) と合わせて、AWS Load Balancer Controller を使用できます。AWS Load Balancer Controller は webhook を利用するため、ハイブリッドノード上で AWS Load Balancer Controller を実行する場合は、EKS クラスターの作成時に RemotePodNetwork を設定する必要があります。

オンプレミス環境のローカルアプリケーショントラフィックついては、ハイブリッドノードで使用するためのさまざまなパートナーおよび Kubernetes コミュニティのオプションがあります。オプションを選択する際には、オンプレミス環境の既存のテクノロジーとアプリケーション要件を考慮してください。オンプレミス環境の一般的なオプションには、Cilium (BGP または L2-aware ロードバランシング)、Calico (BGP ロードバランシング)、MetalLB、NGINX、HAProxy、Apache APISIX、Emissary Ingress、Citrix Ingressが含まれます。また、Istio などのサービスメッシュテクノロジーも、他のオプションと同様の機能を提供します。一般的に、Amazon EKS とハイブリッドノードは 100% のアップストリーム Kubernetes と互換性があり、Ingress とロードバランシングのほとんどの Kubernetes オプションを、ハイブリッドノード上で実行されているアプリケーションに使用できます。

クリーンアップ

次のコマンドを使用すると、前のステップで作成したリソースを削除して、料金が発生しないようにすることができます。異なる CloudFormation スタック名を使用した場合は、次のコマンドで EKSHybridRoleSSM と EKSHybridCluster を自身が使用したスタック名に置き換えてください。

aws cloudformation delete-stack --stack-name EKSHybridCluster

aws cloudformation delete-stack --stack-name EKSHybridRoleSSM

# to remove hybrid nodes components from your hosts
sudo nodeadm uninstall --skip node-validation,pod-validation

ローンチパートナー

EKS Hybrid Nodes のローンチには、Independent Software Vendors(ISV)、Independent Hardware Vendors(IHV)、Operating System vendors(OSV) などの様々なパートナーが参加しました。彼らと協力し、Kubernetes コミュニティの中で活動していくことを楽しみにしています。このローンチに参加したパートナーのリストは以下の通りです。リストされている ISV のいくつかは、Amazon EKS および EKS Anywhere でサードパーティソフトウェアを検証するためのフレームワークである Conformitron を通じて、ソフトウェアソリューションを検証しました。これにより、GitOps ドリブンなインテグレーションを EKS Hybrid Nodes に拡張しています。ユーザーは、これらのパートナーが提供する検証済みソリューションをデプロイして、ハイブリッドノードを操作できます。これにより、シークレット管理、ストレージ、デバイスの分散したフリート全体でのサードパーティコンポーネントのメンテナンスなど、一般的な本番環境での準備の領域に対処できます。

AccuKnox (ISV) は、クラウドネイティブと Kubernetes 環境のためのゼロトラストセキュリティソリューションの提供に焦点を当てたサイバーセキュリティ企業です。同社のプラットフォームは、Kubernetes デプロイメントの高度なランタイムセキュリティ、ネットワークセグメンテーション、コンプライアンス自動化を提供します。
AMD (IHV)は、彼らの EPYC プロセッサーとデータセンターおよびクラウドコンピューティングの分野で大きな進歩を遂げている半導体企業です。これらの高性能 CPU は、コンピュート集中型ワークロードの優れた価格パフォーマンス比を実現するように設計されており、Kubernetes デプロイメントにとって魅力的なオプションです。
Aqua (ISV) は、コンテナおよびサーバーレス環境の包括的な保護を提供するクラウドネイティブセキュリティソリューションの主要プロバイダーです。同社のプラットフォームは、ランタイム保護、脆弱性スキャン、コンプライアンス実施を含む、Kubernetes デプロイメントへの高度なセキュリティ機能を提供します。
CIQ (OSV) は、Rocky Linux のハイパフォーマンスコンピューティング (HPC) ソリューションとエンタープライズサポートに特化した企業です。同社は、コンテナ化と Kubernetes オーケストレーションの専門知識を提供しており、特に科学技術コンピューティングワークロードに対応しています。CIQ のソリューションは、コンピュート集中型アプリケーションと HPC 環境向けの Kubernetes デプロイメントの最適化に役立ちます。
Continent 8 Technologies (IHV) は、セキュアホスティングと接続ソリューションに特化したグローバル IT マネージドサービスプロバイダーです。主要なハードウェアベンダーではありませんが、Kubernetes デプロイメントをサポートできるクラウドサービスとインフラを提供しています。Continent 8 の規制市場における専門知識は、グローバルネットワークと組み合わせることで、厳しい規制要件を持つ業界向けの堅牢でコンプライアンスに準拠した Kubernetes クラスターのホスティング環境を AWS サービスと組み合わせて提供できます。
Dell Technologies (IHV) は、サーバー、ストレージ、ネットワーキング機器を含む Kubernetes デプロイメントをサポートできる幅広いハードウェアソリューションを提供する主要グローバルテクノロジー企業です。PowerEdge サーバーと VxRail ハイパーコンバージドインフラストラクチャは、コンテナ化されたワークロードを実行するための堅牢なプラットフォームを提供します。Dell のハードウェアソリューションは、AWS サービスと統合してパワフルなハイブリッドクラウド環境を作成し、オンプレミスとクラウドインフラストラクチャ間でシームレスな Kubernetes デプロイメントを可能にします。
Dynatrace (ISV) は、Kubernetes を含むクラウド環境のアプリケーションパフォーマンスモニタリング(APM) および可観測性ソリューションを提供する主要なソフトウェアインテリジェンスプラットフォームです。この AI 搭載プラットフォームは、AWS 上で実行されているコンテナ化されたアプリケーション、マイクロサービス、Kubernetes クラスターの深い可視性を提供します。
HashiCorp (ISV) は、AWS 上の Kubernetes デプロイメントを強化する一連の強力なオープンソースツールを提供しています。Infrastructure as Code の Terraform、シークレット管理の Vault、サービスネットワーキングの Consul などの製品は、Amazon EKS やその他の AWS サービスとシームレスに統合されます。
Kong (ISV) は、Kubernetes 環境のための堅牢なソリューションを提供する主要な API ゲートウェイおよびサービス接続プラットフォームです。Kubernetes Ingress Controller と API 管理ツールは、Amazon EKS やその他の AWS サービスとシームレスに統合され、マイクロサービスアーキテクチャのトラフィック制御、セキュリティ、可観測性を高めます。
Kubecost (ISV) は、Kubernetes 環境のリアルタイムのコスト可視性と最適化を提供するソフトウェアソリューションです。このプラットフォームは、Amazon EKS やその他の Kubernetes クラスター上で実行されるコンテナ化されたワークロードの詳細なコスト割り当て、モニタリング、予測を提供します。
NetApp (ISV) は、クラウドデータサービスとストレージソリューションのリーダーであり、Kubernetes 環境での永続ストレージの管理に役立つ強力なツールを提供しています。Astra 製品ラインは、スナップショット、バックアップ、AWS で実行される Kubernetes ワークロードの移行機能など、コンテナ化されたアプリケーションのデータ管理機能を提供します。
New Relic (ISV) は、Kubernetes 環境の包括的なモニタリングとパフォーマンス管理ソリューションを提供する主要な可観測性プラットフォームです。このプラットフォームは、Amazon EKS やその他の AWS サービス上で実行されているコンテナ化されたアプリケーション、マイクロサービス、Kubernetes クラスターの深い可視性を提供します。
Nirmata (ISV) は、複数の環境にまたがる Kubernetes クラスターのデプロイ、運用、ガバナンスを簡素化する Kubernetes 管理プラットフォームです。このソリューションは、組織が Amazon EKS やその他のKubernetes デプロイメント全体で一貫してセキュリティとコンプライアンス基準を適用できるように、ポリシーベースの Kubernetes の自動化を提供します。
PerfectScale (ISV) は、Kubernetes 環境でのリソース使用量とコスト効率を強化するために設計された AI 搭載最適化プラットフォームです。このソリューションは、Amazon EKS やその他の Kubernetes デプロイメントにおけるコンテナの適切なサイズ調整とクラスターリソースの最適化のためのインテリジェントな推奨事項を提供します。
Pulumi (ISV) は、開発者がおなじみのプログラミング言語を使用してクラウドリソースを定義および管理できるようにする、最新の Infrastructure as Code プラットフォームです。このソリューションは、Amazon EKS やその他のマネージド Kubernetes サービスを含む、AWS 上での Kubernetes クラスターのデプロイと管理のための強力なツールを提供します。
Solo.io (ISV) は、クラウドネイティブ環境のサービスメッシュと API ゲートウェイテクノロジーに特化したAPI インフラストラクチャソリューションの主要プロバイダーです。Gloo プラットフォームは、Amazon EKS やその他の AWS サービス上の Kubernetes デプロイメントのための高度なトラフィック管理、セキュリティ、可観測性機能を提供します。
Spectro Cloud (ISV) は、AWS を含む多様な環境にまたがる Kubernetes クラスターをデプロイおよび運用できる革新的な Kubernetes 管理プラットフォームを提供しています。このソリューションは、チームがオープンソースの柔軟性とエンタープライズ製品の管理容易性を組み合わせたカスタマイズされた Kubernetes スタックを作成できるようにする、クラスター管理のユニークなアプローチを提供します。
Sysdig (ISV) は、DevOps チームがコンテナ化されたアプリケーションを簡単にモニタリング、トラブルシューティング、セキュリティ保護できるようにする、Kubernetes 環境のための強力なコンテナインテリジェンスプラットフォームです。
Tetrate (ISV) は、サービスメッシュソリューションの主要プロバイダーであり、マイクロサービスベースの最新アプリケーションのエンタープライズグレードなインフラストラクチャを提供しています。同社の主力製品である Tetrate Service Bridge は、Amazon EKS やマルチクラスター、マルチクラウドデプロイメント全体で、包括的なアプリケーション接続、セキュリティ、可観測性を提供するために Istio の機能を拡張します。

まとめ

オンプレミスまたはエッジで Kubernetes 上のワークロードを実行するには、通常、オープンソースの Kubernetes とツールやプロセスを定義および統合するのに時間、労力、メンテナンスが必要です。これにより、チームの運用上の負担が増え、オンプレミスとクラウドの環境間にサイロが生まれます。EKS Hybrid Nodes を使用すると、このトイルを削減し、オンプレミスのデプロイをクラウドでワークロードを実行する方法に近づけることができます。オンプレミスのアプリケーションをモダナイズしたい場合、既存のオンプレミスハードウェアを使用したい場合、データを特定の国に保持することでデータローカライゼーションの要件を満たしたい場合など、EKS Hybrid Nodes を使用することで、Kubernetes コントロールプレーンの運用オーバーヘッドに対処することなく、効率的にオンプレミスのワークロードを実行できます。

EKS Hybrid Nodes の詳細と使用方法については「EKS Hybrid Nodes ユーザーガイド」をご覧ください。また、EKS Hybrid Nodes の仕組み、機能、ベストプラクティスについて解説している re:Invent 2024 のセッション (KUB205) もご確認ください。

翻訳はソリューションアーキテクトの後藤が担当しました。原文はこちらです。

Amazon Web Services ブログ