**このページの改善にご協力ください** このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。 # ハイブリッドノードでオンプレミスのワークロードを実行する ハイブリッドノードが有効になっている 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)」を参照してください。