私は GCP で K8S を使用してきました (GKE とプラットフォームが提供する HTTPS グローバル ロード バランサー) が、K8S に数百のドメインと数十の独自のパブリック バックエンド サイトがあり、各サイトが独自のバックエンド サービス定義を取得し、単一のロード バランサーに接続されます。
クラスターはネイティブの VPC IP アドレスでセットアップされていないため、すべてのサイトが定義された NodePort サービスを取得し、その NodePort がバックエンド サービスに追加されます。このため、ロード バランサーからのヘルス チェックは、実際にはポッドが完全にクラスター内の別の場所にある可能性がある場合でも、単一のポッドがエラー応答を返すと、グループ全体が異常であると見なされることを意味するため、多少間違っています。同様に、NodePort 構成により、要求が 1 つのグループ (ゾーン) にルーティングされ、K8S サービスによって別のゾーン内の別のノードへのルートが処理される可能性があります。
クラスターでネイティブ VPC IP が有効になっている場合は、ネットワーク エンドポイント グループ (NEG) を使用してサイトを構成し、ポッドに直接ルーティングして、迂回ルーティングとヘルス チェックを処理できます。ただし、ロード バランサーの複雑さが軽減されるわけではありません。
ただし、Istio ゲートウェイ、nginx、ambassador、traefik などの K8S へのゲートウェイを追加すると、レイヤー 7 ルーティングを K8s で構成できるレイヤーがすべて提供され、Google ロード バランサーの構成数が最小限に抑えられ、不足している機能が追加されます。 .
レイヤー 7 ゲートウェイを追加するこの方法は、アプリケーションの全体的な信頼性を低下させますか?