**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# AWS Outposts でローカル Amazon EKS クラスターを準備して、ネットワークの切断に備える
ローカルネットワークが AWS Cloud との接続を失った場合でも、Outpost にあるローカル Amazon EKS クラスターは引き続き使用できます。このトピックでは、ネットワークの切断とそれに関連する考慮事項に備えて、ローカルクラスターを準備する方法について説明します。
+ ローカルクラスターにより、計画外の一時的なネットワーク切断中も安定してオペレーションを継続できます。AWSOutposts は、データセンター内の AWS Cloud の拡張機能として機能する完全に接続された製品であることに変わりはありません。Outpost と AWS Cloud 間のネットワークが切断された場合には、接続の復元を試みることをお勧めします。手順については、「AWS Outpostsユーザーガイド」の「[AWS Outposts ラックネットワークのトラブルシューティングチェックリスト](https://docs.aws.amazon.com/outposts/latest/userguide/network-troubleshoot.html)」を参照してください。ローカルクラスター上の問題をトラブルシューティングする方法については、「[AWS Outposts でローカル Amazon EKS クラスターをトラブルシューティングする](eks-outposts-troubleshooting.md)」を参照してください。
+ Outposts は、Outpost の接続状態を監視するために使用できる `ConnectedStatus` 指標を出力します。詳細については、「AWS Outposts ユーザーガイド」の「[Outposts メトリクス](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-cloudwatch-metrics.html#outposts-metrics)」を参照してください。
+ ローカルクラスターでは、[AWS Identity and Access Management authenticator for Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator) を使用する、デフォルトの認証メカニズムとして IAM を使用します。ネットワークの切断中には、IAM は使用できません。ですから、ローカルクラスターが、ネットワークの切断中にクラスターの接続に使用できる `x.509` 証明書を使用する代替認証メカニズムをサポートします。クラスターの `x.509` 証明書を取得して使用する方法については、「[ネットワーク切断中のローカルクラスターへの認証](#outposts-network-disconnects-authentication)」を参照してください。
+ ネットワークの切断中に Route 53 にアクセスできない場合は、オンプレミス環境上にあるローカル DNS サーバーを使用することを検討してください。Kubernetes コントロールプレーンインスタンスは静的 IP アドレスを使用します。ローカル DNS サーバーを使用する代わりに、エンドポイントのホスト名と IP アドレスを使用してクラスターに接続するホストを設定できます。詳細については、AWS Outposts ユーザーガイドの [DNS](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html#dns) を参照してください。
+ ネットワークの切断中にアプリケーショントラフィックの増加が予想する場合は、クラウドに接続したときにクラスターに予備のコンピューティング容量をプロビジョニングできます。Amazon EC2 インスタンスは AWS Outposts の料金に含まれています。そのため、スペアインスタンスを実行しても AWS の使用コストには影響しません。
+ ネットワークが切断されている間、ワークロードの作成、更新、スケーリングオペレーションを有効にするには、アプリケーションのコンテナイメージにローカルネットワークを介してアクセスでき、クラスターに十分な容量がある必要があります。ローカルクラスターはコンテナレジストリをホストしません。Pod がそれらのノードで以前に実行されていた場合、コンテナイメージはノードにキャッシュされます。アプリケーションのコンテナイメージをクラウドの Amazon ECR から通常にプルする場合は、ローカルキャッシュまたはレジストリの実行を検討してください。ローカルキャッシュまたはレジストリは、ネットワーク切断中にワークロードリソースの作成、更新、スケーリングオペレーションが必要になった場合に便利です。
+ ローカルクラスターは、Amazon EBS を永続ボリュームのデフォルトストレージクラスとして使用し、Amazon EBS 永続ボリュームのライフサイクルを管理するために Amazon EBS CSI ドライバーを使用しています。ネットワークの切断中は、Amazon EBS によってバックアップされる Pod を作成、更新、またはスケーリングすることはできません。これらのオペレーションにはクラウド内の Amazon EBS API への呼び出しが必要だからです。ステートフルワークロードをローカルクラスターにデプロイしていて、ネットワークの切断中に作成、更新、またはスケーリングオペレーションが必要な場合は、別のストレージメカニズムの使用を検討してください。
+ AWS Outposts が、関連する AWS リージョン内 API (Amazon EBS または Amazon S3 の API など) にアクセスできない場合、Amazon EBS スナップショットを作成または削除することはできません。
+ ALB (Ingress) と AWS Certificate Manager (ACM) を統合すると、証明書がプッシュされ、AWS Outposts ALB コンピューティングインスタンスのメモリに保存されます。現在の TLS ターミネーションは、AWS リージョンとの接続が切断された場合でも引き続き機能します。このコンテキストでの変更操作は失敗します (新しい入力定義、新しい ACM ベースの証明書 API 操作、ALB コンピューティングスケール、証明書のローテーションなど)。詳細については、「AWS Certificate Manager ユーザーガイド」の「[マネージド型の証明書の更新のトラブルシューティング](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-renewal.html)」を参照してください。
+ Amazon EKS コントロールプレーンのログは、ネットワークの切断中に Kubernetes コントロールプレーンインスタンスでローカルにキャッシュされます。再接続すると、ログは親 AWS リージョンの CloudWatch Logs に送信されます。[Prometheus](https://prometheus.io/)、[Grafana](https://grafana.com/)、または Amazon EKS パートナーソリューションを使用して、Kubernetes API サーバーのメトリクスエンドポイントを使用して、またはログに Fluent Bit を使用してクラスターをローカルで監視できます。
+ アプリケーショントラフィックに Outposts で AWS Load Balancer Controller を使用している場合、AWS Load Balancer Controller が前面にある既存の Pod は、ネットワークの切断中もトラフィックを受信し続けます。ネットワーク切断中に作成された新しい Pod は、Outpost が AWS クラウドに再接続されるまでトラフィックを受信しません。ネットワーク切断中のスケーリングのニーズに対応するために、AWS Cloud に接続している間はアプリケーションのレプリカ数を設定することを検討してください。
+ Amazon VPC CNI plugin for Kubernetes は、デフォルトで[セカンダリ IP モード](https://aws.github.io/aws-eks-best-practices/networking/vpc-cni/#overview)になります。`WARM_ENI_TARGET`=`1` で構成されているため、プラグインは使用可能な IP アドレスの「完全な伸縮性ネットワークインターフェイス」を維持できます。接続されていない状態でのスケーリングのニーズに応じて、`WARM_ENI_TARGET`、`WARM_IP_TARGET`、`MINIMUM_IP_TARGET` の値を変更することを検討してください。詳細については、「GitHub」の「プラグインの [readme](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) ファイル」を参照してください。各インスタンスタイプによりサポートされる Pod の最大数のリストについては、GitHub の [eni-max-pods.txt](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/misc/eni-max-pods.txt) ファイルを参照してください。
## Kubernetes ポッドのフェイルオーバー動作を調整する
ネットワークの切断中、Kubernetes ノードライフサイクルコントローラーでは、到達できないノードを効果が `NoExecute` の `node.kubernetes.io/unreachable` テイントでマークします。デフォルトでは、許容範囲が一致しないポッドは 300 秒 (5 分) 後に削除されます。この動作は、DaemonSets を使用するか、アプリケーションポッドで `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) を参照してください。
## ネットワーク切断中のローカルクラスターへの認証
AWS Identity and Access Management (IAM) は、ネットワークの切断中は使用できません。切断されている間は、IAM 認証情報を使用してローカルクラスターを認証することはできません。しかしながら、切断時に `x509` 証明書を使用して、ローカルネットワークを介してクラスターに接続できます。切断時に使用するクライアント `X509` 証明書をダウンロードして保存する必要があります。このトピックでは、証明書を作成して使用し、クラスターが接続されていない状態のときにクラスターを認証する方法を説明します。
1. 証明書署名リクエストを作成します。
1. 証明書署名リクエストを生成します。
```
openssl req -new -newkey rsa:4096 -nodes -days 365 \
-keyout admin.key -out admin.csr -subj "/CN=admin"
```
1. Kubernetes で証明書署名リクエストを作成します。
```
BASE64_CSR=$(cat admin.csr | base64 -w 0)
cat << EOF > admin-csr.yaml
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: admin-csr
spec:
signerName: kubernetes.io/kube-apiserver-client
request: ${BASE64_CSR}
usages:
- client auth
EOF
```
1. `kubectl` を使用して証明書署名リクエストを作成します。
```
kubectl create -f admin-csr.yaml
```
1. 証明書登録リクエストのステータスを確認します。
```
kubectl get csr admin-csr
```
出力例は次のとおりです。
```
NAME AGE REQUESTOR CONDITION
admin-csr 11m kubernetes-admin Pending
```
Kubernetes が証明書署名リクエストを作成しました。
1. 証明書署名リクエストを承認します。
```
kubectl certificate approve admin-csr
```
1. 証明書署名リクエストの承認のステータスを再確認します。
```
kubectl get csr admin-csr
```
出力例は次のとおりです。
```
NAME AGE REQUESTOR CONDITION
admin-csr 11m kubernetes-admin Approved
```
1. 証明書を取得して検証します。
1. 証明書を取得する。
```
kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt
```
1. 証明書を検証する。
```
cat admin.crt
```
1. `admin` ユーザーのクラスターロールバインディングを作成します。
```
kubectl create clusterrolebinding admin --clusterrole=cluster-admin \
--user=admin --group=system:masters
```
1. 接続されていない状態のユーザースコープの kubeconfig を生成します。
ダウンロードした `admin` 証明書を使用して `kubeconfig` ファイルを生成できます。次のコマンドの {{my-cluster}} と {{apiserver-endpoint}} を置き換えます。
```
aws eks describe-cluster --name my-cluster \
--query "cluster.certificateAuthority" \
--output text | base64 --decode > ca.crt
```
```
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
```
1. `kubeconfig` ファイルを表示する。
```
kubectl get nodes --kubeconfig admin.kubeconfig
```
1. Outpost で既にサービスが稼働している場合は、この手順をスキップしてください。Outpost で実行されているサービスが Amazon EKS のみで、その Outpost が現在本番環境ではない場合は、ネットワークの切断をシミュレートできます。ローカルクラスターで本番環境に入る前に、切断をシミュレートして、接続されていない状態でもクラスターにアクセスできることを確認できます。
1. Outpostを AWS リージョンに接続するネットワークデバイスにファイアウォールルールを適用します。これにより、Outpost のサービスリンクが切断されます。新しいインスタンスを作成することはできません。現在実行中のインスタンスは、AWS リージョンおよびインターネットへの接続を失います。
1. `x509` 証明書を使用して、切断時にローカルクラスターへの接続をテストできます。`kubeconfig` を前の手順で作成した `admin.kubeconfig` に必ず変更してください。{{my-cluster}} の部分は、お客様のローカルクラスター名に置き換えます。
```
kubectl config use-context admin@my-cluster --kubeconfig admin.kubeconfig
```
ローカルクラスターが接続されていない状態で問題が発生した場合は、サポートチケットを開くことをお勧めします。