ブログ | CTO オフィス

F5 金曜日: イングレス対イングレス

ロリ・マクヴィッティ サムネイル
ロリ・マクヴィッティ
2018年12月28日公開

DevOps と NetOps の世界が衝突し、コンテナ環境がネットワークで従来使用されてきた定義を包含するようになるにつれて、データ パスとコンテナ環境に関して、しばしば混乱を招く用語「イングレス」の使用を検討することが賢明であると思われます。

イングレスとエグレスという用語は、従来、データセンターの観点からネットワーク上のトラフィックの方向を説明するために使用されてきました。 Ingress は受信、egress は送信です。

コンテナ環境が成熟するにつれて、イングレスという用語は、非常に具体的でアプリケーションに重点を置いた定義を持つようになりました。

イングレス。 クラスター内のサービスへの外部アクセス (通常は HTTP) を管理する API オブジェクト。 Ingress は、負荷分散、SSL 終了、名前ベースの仮想ホスティングを提供できます。

ここで立ち止まって、Kubernetes 環境で定義されている Ingress リソースは、コンテナ境界自体内で実行されることが想定される機能について記述していることに注意することが重要です。 

各イングレスは、外部リクエストを受け入れ、Kubernetes イングレス リソースによって指定されたルールに基づいて、それらのリクエストを適切な Kubernetes サービスに送信するリバース プロキシです。 次に、このサービスは、通常はネイティブのレイヤー 4 (TCP) 負荷分散アルゴリズムを使用して、関連付けられたコンテナーのセット間で要求の負荷を分散します。 これは、統合された API を外部に公開する方法の 1 つです。 イングレスは API 呼び出し (URI パス) を解析し、コンテナ クラスター内の適切なコンテナ ホスト型マイクロサービスに配布します。

F5 は従来の Kubernetes イングレスと同じ機能を提供しますが、SNI ルーティングとレイヤー 4 (TCP) ロード バランシングの形で追加機能も提供します。 SNI (サーバー名インジケーター) ルーティングを実行する機能は、実際のペイロード/メッセージを復号化せずに、F5 がヘッダーの情報に基づいてリクエストを適切にルーティングできるため、メッセージ交換のエンドツーエンドの TLS 暗号化を希望するユーザーにとってメリットとなります。 これにより、リクエストに適用できる機能の範囲が制限されますが (たとえば、悪意のあるコンテンツをスキャンすることはできません)、規制上または運用上の理由でコンテンツを暗号化したままにする必要があるアーキテクチャに必要なサポートが提供されます。 レイヤー 4 (TCP) ロード バランシングは、Kubernetes スタイルの Ingress サービスをスケーリングするために、コンテナー環境の外部でよく使用されます。 

F5 は通常、コンテナ環境の外部に展開されます。 これは、クラスターを外部に公開する、つまりコンテナー クラスターで構成されるサービスへのパブリック アクセスを提供するための負荷分散ソリューションとしてよく使用されます。 CNCF の調査によると、回答者の 67% がクラスター サービスを外部に公開するためにロード バランサー オプションを選択し、さらに 33% がイングレス (L7) 機能を活用しています。

Kubernetes イングレスと同じ機能を提供するために、コンテナネイティブの「コネクタ」を使用して、トラフィック ポリシーを定義するポリシーの更新を容易にします。 このコネクタはコンテナ オーケストレータ (通常は Kubernetes ですが、Red Hat OpenShift も人気があります) 内に常駐し、コンテナ オーケストレータと統合されます。 F5 イングレスとの通信は API を介して行われます。更新には、イングレス リソース定義 (HTTP ルーティング ポリシー) の変更と、現在のサービス定義に影響するコンテナ インスタンスの起動や削除などの構成の変更が含まれます。

シンプルなイングレス サービスよりも F5 を使用する利点は、受信トラフィックと送信トラフィックに高度な機能を適用できることです。 F5 を使用すると、コンテナ環境やアーキテクチャ、またはアプリケーション自体を変更することなく、セキュリティ、ヘッダー強化、クライアント固有のパフォーマンス最適化を適用できます。

追加リソース: