イングレス コントローラー: 新しい名前、馴染みのある機能

口語表現。 これらは、その地域特有の意味を持つ単語やフレーズであり、その地域に住んでいない人々を困惑させる可能性があります。 たとえば、外出中に喉が渇いたときは、バブラーを探します。 あなたはおそらく（スコニーではないと推測しますが）水飲み場を探しているでしょう。 ウィスコンシン州では、距離をマイルではなく時間で測ります。 信号機は「止まって進む」信号です。 だって、それがあなたのすることだから。

私の夫（彼はネイティブではない）のお気に入りの笑い言葉は「C'mere once.」です。 私にとって、そして私がそれを使用する子供たちにとって意味があること以上の説明はしません。 そして私たちは本質的に、「Up North」が方向ではなく、話し手にとって特定の場所かもしれないが、「すべてから逃れるために行く場所」を表すウィスコンシン州出身者全員に共通する意味合いを持つ場所であることを理解しています。

どこか別の場所で育ったあなたは、おそらく独自のリストを持っているでしょう。 しかし、これは私のブログなので、私のものを使うことができます。

しかし、今日のポイントは、意味論そのもののレッスンではなく、むしろ、あなたのすぐ身近な、より局所的な現象へのその適用性についてです。 少なくとも、あなたの裏庭があなたの組織であれば。

コンテナと、その必須の自動クラスタリング制御システム (オーケストレーションと呼ばれることが多い) の登場により、意図しない結果として、州境の一方から他方へ口語表現が強制的に導入されるようになりました。 ちなみに、これはまさに IT へのアプリ開発です。

コンテナ口語表現の奇妙なケース

要求される規模の柔軟性と信頼性を実現するために必要な機能の多くは、以前は本番環境のみだった特定のサービスをコンテナ「環境」に移行することを意味しています。 これらの機能は、軽量統合 (API とメッセージ キューイング) を使用して、これまでは完全に実装されたクラウド コンピューティング環境でのみ実現できた自動スケーリングと高可用性のアプリケーションを実現し、現在ではその環境に表面上「組み込まれている」状態になっています。

そうすることで、負荷分散機能は、小さなデーモンのようなサービスを介してポッド/ノードにネイティブに実装されます。 高度ではありませんが (ネットワーク負荷分散機能よりわずかに上くらい)、設計された目的を果たします。 これらのサービスは、いわばプラグイン可能であり、より高度な機能 (そして、期待されるのはアルゴリズム) を解き放つ他のプロジェクト (オープンソースおよびベンダー提供) を有効にできます。

しかし、これらの負荷分散機能自体では、最終的に私たちが求めている（そして実稼働環境で必要な）スケールと高可用性は実現されません。 また、HTTP (L7) のスマートさを必要とする API のルーティングもできません。 マイクロサービスに支えられ、API ファサードが前面に置かれた最新のアプリケーションを効率的にスケールアウトするには、それが必要です。 より強力な解決策が必要です。

ここで、イングレス コントローラが登場します。 これらは、URI と HTTP ヘッダーに基づいて入力トラフィックを分析して誘導し、アプリケーション層のルーティングとスケーラビリティを実現する「ロード バランサー」です。

何が起こったかというと、イングレス コントローラを作成 (およびその後使用) した開発者が、基本的に、私たち (ネット オペレーション) がトラフィック管理、アプリケーション配信、またはコンテンツ スイッチング/ルーティングと呼ぶものを再作成したのです。 私たちは長年にわたり、netops や dev(ops) でさまざまな用語を使用してきました。 アプリ ルーティングとページ ルーティングも、開発者が L7 ルーティングを説明するために使用する用語です。 この概念はどちらのグループにとっても馴染みのないものではない。 しかし、用語、つまり口語表現はそうなのです。

イングレス コントローラは、コンテナ クラスター内の適切な (仮想) サービスにリクエストをルーティングする役割を担います。 そのサービスは別の負荷分散プロキシである場合もあれば、コンテナ システム固有の構成である場合もあります。 どちらの場合でも、イングレス コントローラの役割は、HTTP リクエストの HTTP ヘッダー内のレイヤー 7 (HTTP) 値に基づいてトラフィックをルーティングすることです。 通常、これは URI ですが、ホスト名やその他のカスタム値 (バージョン番号や API キーなど) の場合もあります。

イングレス コントローラは、ヘッダーから値を抽出すると、リソース ファイルで記述されたポリシーを使用して、その値を配布する方法を決定します。 均等に分配することも、サービスの 1 つのバージョンに 75%、別のバージョンに 25% を送信することもできます。 そういう意味ではかなり柔軟です。 イングレス コントローラーにはさらに監視 (ヘルスとステータス) の責任があり、「デッド」サービスにリクエストを配布しないように細心の注意を払う必要があります。

ネットオペレーターの皆さん、聞き覚えがありますか? それは基本的にスマートな（L7 対応）プロキシ（BIG-IP など）の機能であるため、当然のことです。

これらがどのように似ているかがわかったところで、いくつかの違いがあることをお伝えします。 特に、イングレス コントローラは宣言的に構成されます。 つまり、その構成は、コントローラー自体の外部にあるリソース ファイル内の記述によって決定されます。 これは、入力トラフィックを制御および誘導する従来のスマート プロキシとは異なります。 従来のスマート プロキシは、環境の信頼できるソースです。 イングレス コントローラはそうではありません。 そのためには、実装の柔軟性を可能にする一種の「抽象化レイヤー」として機能するファイルを探します。 つまり、そのコンポーネント (または補完的なコンポーネント) はそれを読み取り、解釈し、その説明に適した構成を作成する必要があります。 そしてそれを最新の状態に保つ必要があります。 コンテナ化された環境の入口制御における変動性はシステムのより深いところにおける変動性よりも少ないですが、それでも変化するため、監視する必要があります。

結局のところ、イングレス コントローラは、外部からのリクエストをコンテナ化された環境内の適切なリソースにアプリケーション層でルーティングする役割を担っています。 これはまさにスマート ロード バランサーの定義です。

名前は変わったかもしれませんが、機能はほとんど同じです。