ネットワーク切断の準備

ローカルネットワークが AWS クラウド との接続を失った場合でも、Outpost にあるローカル Amazon EKS クラスターは引き続き使用できます。このトピックでは、ネットワークの切断とそれに関連する考慮事項に備えて、ローカルクラスターを準備する方法について説明します。

ネットワークの切断に備えてローカルクラスターを準備する際の考慮事項:

• ローカルクラスターにより、計画外の一時的なネットワーク切断中も安定してオペレーションを継続できます。AWS Outposts は、データセンター内の AWS クラウド の拡張機能として機能する完全に接続された製品であることに変わりはありません。Outpost と AWS クラウド 間のネットワークが切断された場合には、接続の復元を試みることをお勧めします。手順については、AWS Outposts ユーザーガイドの「AWS Outposts ラックネットワークのトラブルシューティングチェックリスト」を参照してください。ローカルクラスター上の問題をトラブルシューティングする方法については、「AWS Outposts での Amazon EKS のローカルクラスターのトラブルシューティング」を参照してください。

• Outposts は、Outpost の接続状態を監視するために使用できる ConnectedStatus 指標を出力します。詳細については、AWS Outposts ユーザーガイドの「Outposts メトリクス」を参照してください。

• ローカルクラスターでは、Kubernetes の AWS Identity and Access Management 認証を使用する、デフォルトの認証メカニズムとして IAM を使用します。ネットワークの切断中には、IAM は使用できません。ですから、ローカルクラスターが、ネットワークの切断中にクラスターの接続に使用できる x.509 証明書を使用する代替認証メカニズムをサポートします。クラスターの x.509 証明書を取得して使用する方法については、「ネットワーク切断中のローカルクラスターへの認証」を参照してください。

• ネットワークの切断中に Route 53 にアクセスできない場合は、オンプレミス環境上にあるローカル DNS サーバーを使用することを検討してください。Kubernetes コントロールプレーンインスタンスは静的 IP アドレスを使用します。ローカル DNS サーバーを使用する代わりに、エンドポイントのホスト名と IP アドレスを使用してクラスターに接続するホストを設定できます。詳細については、AWS Outposts ユーザーガイドの DNS を参照してください。

• ネットワークの切断中にアプリケーショントラフィックの増加が予想する場合は、クラウドに接続したときにクラスターに予備のコンピューティング容量をプロビジョニングできます。Amazon EC2 インスタンスは AWS Outposts の料金に含まれています。そのため、スペアインスタンスを実行しても AWS の使用コストには影響しません。

• ネットワークが切断されている間、ワークロードの作成、更新、スケーリングオペレーションを有効にするには、アプリケーションのコンテナイメージにローカルネットワークを介してアクセスでき、クラスターに十分な容量がある必要があります。ローカルクラスターはコンテナレジストリをホストしません。Pods がそれらのノードで以前に実行されていた場合、コンテナイメージはノードにキャッシュされます。アプリケーションのコンテナイメージをクラウドの Amazon ECR から通常にプルする場合は、ローカルキャッシュまたはレジストリの実行を検討してください。ローカルキャッシュまたはレジストリは、ネットワーク切断中にワークロードリソースの作成、更新、スケーリングオペレーションが必要になった場合に便利です。

• ローカルクラスターは、Amazon EBS を永続ボリュームのデフォルトストレージクラスとして使用し、Amazon EBS 永続ボリュームのライフサイクルを管理するために Amazon EBS CSI ドライバーを使用しています。ネットワークの切断中は、Amazon EBS によってバックアップされる Pods を作成、更新、またはスケーリングすることはできません。これらのオペレーションにはクラウド内の 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 ユーザーガイド」の「マネージド型の証明書の更新のトラブルシューティング」を参照してください。

• Amazon EKS コントロールプレーンのログは、ネットワークの切断中に Kubernetes コントロールプレーンインスタンスでローカルにキャッシュされます。再接続すると、ログは親 AWS リージョン の CloudWatch Logs に送信されます。Prometheus、Grafana、または Amazon EKS パートナーソリューションを使用して、Kubernetes API サーバーのメトリクスエンドポイントを使用して、またはログに Fluent Bit を使用してクラスターをローカルで監視できます。

• アプリケーショントラフィックに Outposts で AWS Load Balancer Controller を使用している場合、AWS Load Balancer Controller が前面にある既存の Pods は、ネットワークの切断中もトラフィックを受信し続けます。ネットワーク切断中に作成された新しい Pods は、Outpost が AWS クラウド に再接続されるまでトラフィックを受信しません。ネットワーク切断中のスケーリングのニーズに対応するために、AWS クラウド に接続している間はアプリケーションのレプリカ数を設定することを検討してください。

• Amazon VPC CNI plugin for Kubernetes はセカンダリ IP モードのデフォルト設定に戻ります。WARM_ENI_TARGET=1 で構成されているため、プラグインは使用可能な IP アドレスの「完全な伸縮性ネットワークインターフェイス」を維持できます。接続されていない状態でのスケーリングのニーズに応じて、WARM_ENI_TARGET、WARM_IP_TARGET、MINIMUM_IP_TARGET の値を変更することを検討してください。詳細については、「GitHub」の「プラグインの readme ファイル」を参照してください。各インスタンスタイプによりサポートされる Pods の最大数のリストについては、GitHub の eni-max-pods.txt ファイルを参照してください。

ネットワーク切断中のローカルクラスターへの認証

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"
      

   2. 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
      

2. kubectl を使用して証明書署名リクエストを作成します。

   kubectl create -f admin-csr.yaml
   

3. 証明書登録リクエストのステータスを確認します。

   kubectl get csr admin-csr
   

   出力例は次のとおりです。

   NAME       AGE   REQUESTOR                       CONDITION
   admin-csr  11m   kubernetes-admin                Pending

   Kubernetes が証明書署名リクエストを作成しました。

4. 証明書署名リクエストを承認します。

   kubectl certificate approve admin-csr
   

5. 証明書署名リクエストの承認のステータスを再確認します。

   kubectl get csr admin-csr
   

   出力例は次のとおりです。

   NAME       AGE   REQUESTOR                     CONDITION
   admin-csr  11m   kubernetes-admin              Approved

6. 証明書を取得して検証します。

   1. 証明書を取得する。

      kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt
      

   2. 証明書を検証する。

      cat admin.crt
      

7. admin ユーザーのクラスターロールバインディングを作成します。

   kubectl create clusterrolebinding admin --clusterrole=cluster-admin \
       --user=admin --group=system:masters
   

8. 接続されていない状態のユーザースコープの 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
   

9. kubeconfig ファイルを表示する。

   kubectl get nodes --kubeconfig admin.kubeconfig
   

10. Outpost で既にサービスが稼働している場合は、この手順をスキップしてください。Outpost で実行されているサービスが Amazon EKS のみで、その Outpost が現在本番環境ではない場合は、ネットワークの切断をシミュレートできます。ローカルクラスターで本番環境に入る前に、切断をシミュレートして、接続されていない状態でもクラスターにアクセスできることを確認できます。

    1. Outpostを AWS リージョン に接続するネットワークデバイスにファイアウォールルールを適用します。これにより、Outpost のサービスリンクが切断されます。新しいインスタンスを作成することはできません。現在実行中のインスタンスは、AWS リージョン およびインターネットへの接続を失います。

    2. x509 証明書を使用して、切断時にローカルクラスターへの接続をテストできます。kubeconfig を前の手順で作成した admin.kubeconfig に必ず変更してください。my-cluster の部分は、お客様のローカルクラスター名に置き換えます。

       kubectl config use-context admin@my-cluster --kubeconfig admin.kubeconfig
       

    ローカルクラスターが接続されていない状態で問題が発生した場合は、サポートチケットを開くことをお勧めします。