第8章 イングレスを使ったHTTPロードバランサ
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
どのアプリケーションにとっても重要なのは、そのアプリケーションとの間でネットワークトラフィックをやり取りすることだ。 第7章で説明したように、Kubernetesには、サービスをクラスタの外部に公開できるようにする一連の機能がある。 多くのユーザや単純なユースケースでは、これらの機能で十分だ。
しかし、Serviceオブジェクトは(OSIモデルによる)レイヤー4で演算子として動作する。1つまり、TCPとUDPコネクションを転送するだけで、コネクションの内部は見ない。このため、クラスタ上で多くのアプリケーションをホスティングする場合、多くの異なる公開サービスが使用される。これらのサービスがtype: NodePort の場合、クライアントにサービスごとに固有のポートに接続させる必要がある。 これらのサービスがtype: LoadBalancer の場合、サービスごとに(多くの場合高価か希少な)クラウドのリソースを割り当てることになる。しかし、HTTP(レイヤー7)ベースのサービスであれば、もっといい方法がある。
Kubernetes以外の状況で同様の問題を解決する場合、ユーザはしばしば "バーチャルホスティング "というアイデアに頼る。これは、1つのIPアドレスで多くのHTTPサイトをホストする仕組みだ。 通常、ユーザはロードバランサやリバースプロキシを使って、HTTP(80)とHTTPS(443)ポートで着信接続を受け付ける。そのプログラムはHTTP接続を解析し、Host ヘッダと要求されたURLパスに基づいて、HTTP呼び出しを他のプログラムにプロキシする。このようにして、ロードバランサまたはリバースプロキシは、トラフィックをデコードし、着信接続を適切な「アップストリーム」サーバに向ける。
KubernetesはHTTPベースのロードバランサシステムをIngressと呼び出している。Ingressは、先ほど説明した「仮想ホスティング」パターンを実装するKubernetesネイティブな方法だ。このパターンのより複雑な側面の1つは、ユーザがロードバランサの構成ファイルを管理しなければならないことだ。ダイナミックな環境では、またバーチャルホストのセットが拡大するにつれて、これは非常に複雑になる可能性がある。Kubernetes Ingressシステムは、(a)コンフィギュレーションを標準化し、(b)標準のKubernetesオブジェクトに移動し、(c)複数のIngressオブジェクトをロードバランサ用の単一のコンフィギュレーションにマージすることで、これを簡素化する。
典型的なソフトウェアベースの実装は、図8-1に示すようなものである。Ingressコントローラは、2つの部分からなるソフトウェアシステムである。1つ目はIngressプロキシで、type: LoadBalancer のサービスを使用してクラスタの外部に公開される。 このプロキシはリクエストを「アップストリーム」サーバに送信する。もう1つのコンポーネントはIngress reconciler、or演算子である。Ingress演算子は、Kubernetes APIでIngressオブジェクトを読み取り監視し、Ingressリソースで指定された通りにトラフィックをルーティングするためにIngressプロキシを再設定する役割を担う。多くの異なるIngress実装がある。これら2つのコンポーネントが1つのコンテナにまとめられているものもあれば、Kubernetesクラスタに別々にデプロイされる別個のコンポーネントであるものもある。 ...