**このページの改善にご協力ください** このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。 # EC2 インスタンスストアを設定した AWS Outposts にローカルの Amazon EKS クラスターを準備して、ネットワークの切断に備える ローカルネットワークを AWS Cloud へとつなぐ AWS Outposts サービスリンクが接続を失った場合でも、Outposts にあるローカルの Amazon EKS クラスターは引き続き使用できます。このトピックでは、ネットワーク切断に備えてローカルクラスターを準備する方法とその際の考慮事項について説明します。 + ローカルクラスターにより、計画外の一時的なネットワーク切断中も安定してオペレーションを継続できます。AWSOutposts は、データセンター内の AWS Cloud の拡張機能として機能する完全に接続された製品であることに変わりはありません。Outposts と AWS Cloud との間のネットワーク接続が切断された場合には、接続の復元を試みることをお勧めします。手順については、「*AWS Outposts ユーザーガイド*」の「[AWS Outposts ラックネットワークのトラブルシューティングチェックリスト](https://docs.aws.amazon.com/outposts/latest/userguide/network-troubleshoot.html)」を参照してください。 + Outposts は、Outpost の接続状態を監視するために使用できる `ConnectedStatus` 指標を出力します。詳細については、「AWS Outposts ユーザーガイド」の「[Outposts メトリクス](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-cloudwatch-metrics.html#outposts-metrics)」を参照してください。 ## ネットワーク切断中の認証 ローカルクラスターは、複数の認証メカニズムをサポートしています。それぞれのメカニズムでネットワーク切断時の可用性が異なります。 | [Authentication mechanism] (認証メカニズム) | 切断中に使用可能か? | | --- | --- | | AWS IAM (アクセスエントリ、`aws-auth` ConfigMap) | 不可。IAM には AWSリージョンへの接続が必要です。 | | OIDC (お客様提供のプロバイダー) | プロバイダーの所在地によって異なります。OIDC プロバイダーが Outposts のローカルネットワークから到達可能であれば、認証は引き続き機能します。 | | x.509 クライアント証明書 | はい。証明書は、Kubernetes API サーバーによってローカルに検証されます。 | | サービスアカウント用 IAM ロール (IRSA、IAM roles for service accounts) | 不可。「[切断中の IRSA と Pod Identity](#eks-outposts-instance-store-network-disconnects-irsa)」を参照してください。 | | EKS Pod Identity | 不可。「[切断中の IRSA と Pod Identity](#eks-outposts-instance-store-network-disconnects-irsa)」を参照してください。 | ### x.509 クライアント証明書 ネットワーク切断中も `kubectl` へのアクセスを維持するには、切断が発生する前にクライアント X.509 証明書を作成しておきます。 管理者証明書を作成するには: 1. プライベートキーと証明書署名リクエスト (CSR) を生成します。 ``` openssl req -new -newkey rsa:4096 -nodes \ -keyout admin.key -out admin.csr -subj "/CN=admin" ``` 1. Kubernetes `CertificateSigningRequest` リソースを作成して承認します。 ``` cat admin.csr | base64 | tr -d '\n' > admin.csr.b64 ``` ``` apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata: name: admin-csr spec: request: signerName: kubernetes.io/kube-apiserver-client usages: - client auth ``` ``` kubectl apply -f admin-csr.yaml kubectl certificate approve admin-csr ``` 1. 署名付き証明書を取得する: ``` kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt ``` 1. `ClusterRoleBinding` を作成して管理者アクセスを付与します。 ``` kubectl create clusterrolebinding admin --clusterrole=cluster-admin \ --user=admin --group=system:masters ``` 1. 証明書を使用する `kubeconfig` を構築します。 ``` kubectl config --kubeconfig admin.kubeconfig set-cluster my-cluster \ --certificate-authority=ca.crt --server $APISERVER_ENDPOINT --embed-certs kubectl config --kubeconfig admin.kubeconfig set-credentials admin \ --client-certificate=admin.crt --client-key=admin.key --embed-certs kubectl config --kubeconfig admin.kubeconfig set-context admin@my-cluster \ --cluster my-cluster --user admin kubectl config --kubeconfig admin.kubeconfig use-context admin@my-cluster ``` ### 切断中のクラスターエンドポイントの DNS 解決 ローカルクラスターの Kubernetes API サーバーエンドポイントは、Amazon Route 53 にホストされ、Amazon EKS がサブネットに作成するクロスアカウントの Elastic Network Interface (ENI) のプライベート IP アドレスに解決されます。これらの ENI には、通常のクラスターオペレーション中に変更されない静的なプライベート IP アドレスがあります。 ネットワークの切断中、Outposts は Route 53 に到達できないため、ローカルな解決パスを準備しない限り、クラスターエンドポイントのホスト名は解決されません。次の 3 つのカテゴリに属するクライアントが API サーバーに到達する必要があります。 + `kubectl` を実行している**クラスター管理者**。 + ノードハートビートを送信し、仕様をプルする**ワーカーノード** (`kubelet`)。 + 各ノード上の **`kube-proxy`**。これがクラスターサービス IP をセットアップします。 #### オプション 1: ローカルな DNS ソリューション (推奨) AWS は、Outposts が切断されている間、クラスターエンドポイントレコードをキャッシュして処理する DNS ソリューションをローカルにデプロイすることを推奨しています。オンプレミス環境で、クラスターエンドポイントレコードをキャッシュする独自の DNS サーバーを実行できます。 DNS ソリューションをローカルに使用する場合は、`kubeconfig` とワーカーノード AMI がクラスターエンドポイントのホスト名 (ENI IP アドレスではない) を指すようにして、ローカルの DNS ソリューションと一致した解決にすることをお勧めします。 #### オプション 2: 静的 IP ベースのアクセス ローカルの DNS ソリューションを実行しない場合は、静的 IP ベースのアクセスを使用できます。 + **管理者:** クロスアカウントの ENI プライベート IP アドレスを直接指すように `kubeconfig` を設定します。ENI を検索するには、AWS アカウント内で説明に `Amazon EKS {{cluster-name}} ` が含まれているネットワークインターフェイスを検索します。各 ENI の IP アドレスは、通常の運用であればクラスターが存続する間安定しています。 + **ワーカーノード (Amazon EKS 最適化 AMI):** Amazon EKS 最適化 AMI からワーカーノードを起動すると、ブートストラップスクリプトが ENI の IP アドレスを使用してクラスターエンドポイントを `/etc/hosts` に追加します。追加の設定は必要ありません。 + **ワーカーノード (カスタム AMI):** クラスターエンドポイントのホスト名と ENI の IP アドレスをカスタムブートストラップの `/etc/hosts` に追加します。そうしないと、切断されている間、`kubelet` と `kube-proxy` は API サーバーに到達できません。 **重要** クロスアカウントの ENI が削除されたり、その IP アドレスが変更されたりした場合、例えば、そうした削除や変更のために Amazon EKS が再アタッチできなくなった場合は、静的 IP ベースのアクセスを使用するノードと管理者をすべて手動で更新する必要があります。ローカルの DNS ソリューションでは、手動による介入は必要ありません。 ### 切断中のポッドの DNS 解決 切断中にオペレーションを実行しても DNS に障害が発生しないようにするには、`kubelet’s `resolvConf` 設定を上書きするようにワーカーノード起動テンプレートを設定します。ユーザーデータで、カスタム `resolv.conf` ファイル (`/etc/kubernetes/resolv.conf` など) を作成して、`nameserver 10.0.0.2` のみ (VPC 検索ドメインなし) を含め、`NodeConfig` に `spec.kubelet.config.resolvConf: /etc/kubernetes/resolv.conf` を設定します。これにより、ポッドの DNS 設定から ` {{region-code}}.compute.internal` 検索ドメインが削除されるため、切断中は到達不能な VPC DNS リゾルバーにクエリが転送されなくなります。 次の例に、ワーカーノードのユーザーデータを示します。 ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY" --BOUNDARY Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash mkdir -p /etc/kubernetes echo "nameserver [.replaceable]``10.0.0.2``" > /etc/kubernetes/resolv.conf --BOUNDARY Content-Type: application/node.eks.aws --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster ... kubelet: config: resolvConf: /etc/kubernetes/resolv.conf --BOUNDARY-- ``` ### 切断中の IRSA と Pod Identity **重要** IRSA と EKS Pod Identity は、AWS リージョンで動作する AWS STS に依存します。ネットワークの切断中、IRSA または Pod Identity を使用するワークロードは新しい認証情報を取得できません。既存の認証情報は、一定期間後に期限切れになります。 ネットワークの切断中もワークロードを利用可能なままにする必要がある場合は、リージョンベースの AWS サービスに対して機能面や運用面で依存関係を持つことはお勧めしません。 ## 切断中の `etcd` の動作 ネットワークの切断中、`etcd` スナップショットをバックアップすることはできません。切断中に複数の `etcd` インスタンスが使用できなくなった場合、`etcd` はクォーラムを失い、Kubernetes API オペレーションは Outposts が再接続して `etcd` クォーラムが復元されるまで使用できません。既に実行されているワークロードは引き続き動作します。 ## 切断中のコントロールプレーンのログ記録 ネットワークの切断中に、コントロールプレーンのログはコントロールプレーンインスタンスにローカルにキャッシュされます。接続が復元されると、ログは親 AWS リージョンの Amazon CloudWatch Logs に送信されます。コントロールプレーンにログ記録エージェントをインストールまたは維持する必要はありません。 ## ローカルオブザーバビリティ 切断中にクラスターをローカルでモニタリングするには、[Prometheus](https://prometheus.io/)、[Grafana](https://grafana.com/)、またはその他のサードパーティーソリューションを使用して Kubernetes API サーバーメトリクスエンドポイントをスクレイプします。 ## ローカルイメージリポジトリ 追加のレプリカでデプロイをスケールしたり、切断中のポッド障害から復旧したりするには、コンテナイメージリポジトリ (Docker レジストリなど) をローカルに保持するか、切断前にイメージをノードにキャッシュしておく必要があります。ネットワークの切断中、Amazon ECR は利用できません。 ## Kubernetes ポッドのフェイルオーバー動作を調整する ネットワークの切断中、Kubernetes コントロールプレーンは AWS リージョンと通信できません。ノードが到達不能になった場合、Kubernetes のデフォルトの動作はタイムアウトの期間後にポッドを削除することです。許容範囲と `tolerationSeconds` ポッド仕様に沿ってこの動作を調整して、パーティション中にポッドを再スケジュールする速度を制御できます。詳細なガイダンスと例については、「Amazon EKS ベストプラクティスガイド」の「*Kubernetes ポッドのフェイルオーバー動作を調整する*」(https://docs.aws.amazon.com/eks/latest/best-practices/hybrid-nodes-network-disconnection-best-practices.html\#tune\_kubernetes\_pod\_failover\_behavior) を参照してください。 ## ネットワークの切断をシミュレートする ローカルクラスターで本番環境に入る前に、切断をシミュレートして、接続されていない状態でもクラスターにアクセスできることを確認できます。 1. Outpostを AWS リージョンに接続するネットワークデバイスにファイアウォールルールを適用します。これにより、Outpost のサービスリンクが切断されます。 1. 作成した X.509 証明書を使用して、ローカルクラスターへの接続をテストします。 ``` kubectl --kubeconfig admin.kubeconfig get nodes ``` **注記** Outposts でサービスが既に本番稼働環境にある場合は、切断をシミュレートしないでください。サービスリンクを切断すると、Outposts で実行中のすべてのサービスに影響が及びます。