翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ネットワーク切断による安定性のベストプラクティス
高可用性ネットワーク
ハイブリッドノードと Kubernetes コントロールプレーン間のネットワーク切断を回避する最善の方法は、オンプレミス環境と AWS との間の冗長で回復力のある接続を使用することです。これらのソリューションを使用した高可用性ハイブリッドネットワークの設計の詳細については、AWS Direct Connect Resiliency Toolkit と AWS Site-to-Site VPN のドキュメントを参照してください。
可用性の高いアプリケーション
アプリケーションを設計するときは、障害ドメインとさまざまなタイプの停止の影響を考慮してください。Kubernetes には、ノード、ゾーン、リージョンのドメイン間でアプリケーションレプリカをデプロイおよび維持する組み込みメカニズムが用意されています。これらのメカニズムの使用は、アプリケーションのアーキテクチャ、環境、可用性の要件によって異なります。例えば、ステートレスアプリケーションは多くの場合、複数のレプリカでデプロイでき、任意のホストとインフラストラクチャ容量を移動できます。また、ノードセレクタとトポロジ分散制約を使用して、異なるドメイン間でアプリケーションのインスタンスを実行できます。Kubernetes で回復力のあるアプリケーションを構築するためのアプリケーションレベルの手法の詳細については、「EKS ベストプラクティスガイド
Kubernetes は、ポッドを他のノードに移動するかどうかを決定するときに、Kubernetes コントロールプレーンから切断されたノードのゾーン情報を評価します。ゾーン内のすべてのノードに到達できない場合、Kubernetes はそのゾーン内のノードのポッドエビクションをキャンセルします。ベストプラクティスとして、複数のデータセンターまたは物理的なロケーションでノードが実行されているデプロイがある場合は、データセンターまたは物理的なロケーションに基づいて各ノードにゾーンを割り当てます。クラウド内のノードで EKS を実行すると、このゾーンラベルは AWS cloud-controller-manager によって自動的に適用されます。ただし、cloud-controller-manager はハイブリッドノードでは使用されないため、この情報を kubelet 設定で渡すことができます。ハイブリッドノードのノード設定でゾーンを設定する方法の例を以下に示します。ハイブリッドノード CLI () を使用してハイブリッドノードをクラスターに接続すると、設定が渡されますnodeadm。topology.kubernetes.io/zone ラベルの詳細については、Kubernetes ドキュメント
apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster region: my-region kubelet: flags: - --node-labels=topology.kubernetes.io/zone=dc1 hybrid: ...
ネットワークモニタリング
ハイブリッド接続に AWS Direct Connect または AWS Site-to-Site VPN を使用する場合は、CloudWatch アラーム、ログ、メトリクスを活用してハイブリッド接続の状態を観察し、問題を診断できます。詳細については、「AWS Direct Connect リソースのモニタリング」および「AWS Site-to-Site VPN 接続のモニタリング」を参照してください。
EKS コントロールプレーンで実行されている node-lifecycle-controller によって報告されたNodeNotReadyイベントのアラームを作成することをお勧めします。これにより、ハイブリッドノードでネットワークの切断が発生している可能性があります。このアラームを作成するには、 Controller Manager の EKS コントロールプレーンのログ記録を有効にし、「ノードのステータス変更イベントメッセージの記録」メッセージのメトリクスフィルターを status=NodeNotReady」で CloudWatch に作成します。メトリクスフィルターを作成したら、目的のしきい値に基づいてこのフィルターのアラームを作成できます。詳細については、CloudWatch ドキュメントの「ログのアラーム」を参照してください。
Transit Gateway (TGW) と Virtual Private Gateway (VGW) の組み込みメトリクスを使用して、TGW または VGW との間のネットワークトラフィックを監視できます。これらのメトリクスのアラームを作成して、ハイブリッドノードと EKS コントロールプレーン間の潜在的なネットワーク問題を示すネットワークトラフィックが通常のレベルを下回るシナリオを検出できます。TGW および VGW メトリクスを次の表に示します。
| ゲートウェイ | メトリクス | 説明 |
|---|---|---|
|
Transit Gateway |
BytesIn |
TGW がアタッチメント (EKS コントロールプレーンからハイブリッドノード) から受信したバイト数 |
|
Transit Gateway |
BytesOut |
TGW からアタッチメント (ハイブリッドノードから EKS コントロールプレーン) に送信されたバイト数 |
|
仮想プライベートゲートウェイ |
TunnelDataIn |
VPN トンネルを介して接続の AWS 側からカスタマーゲートウェイ (EKS コントロールプレーンからハイブリッドノード) に送信されたバイト数 |
|
仮想プライベートゲートウェイ |
TunnelDataOut |
VPN トンネルを介してカスタマーゲートウェイ (ハイブリッドノードから EKS コントロールプレーン) から接続の AWS 側で受信したバイト数 |
CloudWatch Network Monitor
EKS には、クラスターとアプリケーションの正常性をモニタリングするためのオプションがいくつか用意されています。クラスターの状態については、EKS コンソールのオブザーバビリティダッシュボードを使用して、問題を迅速に検出、トラブルシューティング、修正できます。Amazon Managed Service for Prometheus、AWS Distro for Open Telemetry (ADOT)、CloudWatch を使用して、クラスター、アプリケーション、インフラストラクチャのモニタリングを行うこともできます。EKS オブザーバビリティオプションの詳細については、「クラスターのパフォーマンスをモニタリングし、ログを表示する」を参照してください。
ローカルトラブルシューティング
ハイブリッドノードと EKS コントロールプレーン間のネットワーク切断に備えるために、セカンダリモニタリングとログバックエンドを設定して、リージョンの AWS サービスに到達できない場合にアプリケーションのオブザーバビリティを維持できます。たとえば、AWS Distro for Open Telemetry (ADOT) コレクターを設定して、メトリクスとログを複数のバックエンドに送信できます。crictl CLI などのローカルツールを使用して、通常 Kubernetes API サーバーエンドポイントをクエリするkubectl他の Kubernetes API 互換クライアントの代わりとして、ポッドやコンテナとローカルでやり取りすることもできます。の詳細についてはcrictl、cri-tools GitHub のcrictlドキュメントcrictlコマンドを示します。
ホストで実行されているポッドを一覧表示します。
crictl pods
ホストで実行されているコンテナを一覧表示します。
crictl ps
ホストで実行されているイメージを一覧表示します。
crictl images
ホストで実行されているコンテナのログを取得します。
crictl logs CONTAINER_NAME
ホストで実行されているポッドの統計情報を取得します。
crictl statsp
アプリケーションネットワークトラフィック
ハイブリッドノードを使用する場合は、アプリケーショントラフィックのネットワークフローと、アプリケーションをクラスターの外部に公開するために使用するテクノロジーを検討して理解することが重要です。アプリケーションの負荷分散と進入のテクノロジーは、ネットワークの切断時に動作が異なります。たとえば、アプリケーションの負荷分散に Cilium の BGP コントロールプレーン機能を使用している場合、ネットワークの切断中にポッドとサービスの BGP セッションがダウンする可能性があります。これは、BGP スピーカー機能が Cilium エージェントと統合されており、Kubernetes コントロールプレーンから切断されると Cilium エージェントが継続的に再起動するためです。再起動の理由は、Cilium のヘルスチェックが失敗したことが原因です。これは、そのヘルスが Kubernetes コントロールプレーンへのアクセスと組み合わされているためです (CFP: #31702
リモート AWS サービスへの依存関係を確認する
ハイブリッドノードを使用する場合は、オンプレミス環境またはエッジ環境の外部にあるリージョンの AWS サービスに対する依存関係に注意してください。例としては、アプリケーションデータ用の Amazon S3 または Amazon RDS へのアクセス、メトリクスとログ用の Amazon Managed Service for Prometheus または CloudWatch の使用、リージョンが発信するトラフィック用の Application and Network Load Balancer の使用、Amazon Elastic Container Registry からのコンテナのプルなどがあります。これらのサービスは、オンプレミス環境と AWS 間のネットワーク切断中はアクセスできません。オンプレミス環境が AWS とネットワークが切断されやすい場合は、AWS サービスの使用を確認し、それらのサービスへの接続が失われてもアプリケーションの静的安定性が損なわれないことを確認します。
Kubernetes ポッドのフェイルオーバー動作を調整する
ホスト間で移植できないアプリケーションのネットワーク切断中、またはポッドフェイルオーバー用の予備容量がないリソースに制約のある環境では、ポッドフェイルオーバー動作を調整するオプションがあります。一般的に、アプリケーションのリソース要件を考慮し、ノードに障害が発生した場合にアプリケーションの 1 つ以上のインスタンスが別のホストにフェイルオーバーするのに十分な容量を持つことが重要です。
-
オプション 1 - DaemonSets を使用する: このオプションは、クラスター内のすべてのノードで実行できるアプリケーションと実行する必要があるアプリケーションに適用されます。DaemonSets は到達不可能なテイントを許容するように自動的に設定されます。これにより、DaemonSet ポッドはネットワーク切断によってノードにバインドされます。
-
オプション 2 - 到達不可能なテイント
tolerationSecondsに合わせて調整する: ネットワークの切断中にポッドがノードにバインドされたままになる時間を調整できます。これを行うには、アプリケーションポッドを設定して、指定した期間 (tolerationSecondsアプリケーション仕様の )NoExecuteにわたって到達不可能なテイントを許容します。このオプションでは、ネットワークが切断されると、アプリケーションポッドはtolerationSecondsの有効期限が切れるまでノードにバインドされたままになります。を使用して到達不可能なテイントtolerationSecondsを増やすと、到達不可能なホストで実行されているポッドNoExecuteが他の到達可能な正常なホストに移動するのに時間がかかる可能性があるため、慎重に検討してください。 -
オプション 3: カスタムコントローラー:
NoExecuteKubernetes で到達不可能なテイントをモニタリングするカスタムコントローラー (またはその他のソフトウェア) を作成して実行できます。このテイントが検出されると、カスタムコントローラーはアプリケーション固有のメトリクスをチェックしてアプリケーションのヘルスを評価できます。アプリケーションが正常であれば、カスタムコントローラーは到達不可能なテイントを削除し、ネットワーク切断中のノードからのポッドのエビクションを防ぐことができます。
到達不可能なテイントtolerationSecondsに対して を使用してデプロイを設定する方法の例を以下に示します。この例では、 tolerationSecondsは 1800 (30 分) に設定されています。つまり、到達できないノードで実行されているポッドは、ネットワークの切断が 30 分以上続く場合にのみ削除されます。
apiVersion: apps/v1 kind: Deployment metadata: ... spec: ... tolerations: - key: "node.kubernetes.io/unreachable" operator: "Exists" effect: "NoExecute" tolerationSeconds: 1800
