コンテナ業界では混乱と同じくらい混乱が起きています。 コンテナ オーケストレーション環境の世界には、毎日何らかの新しい機能やコンポーネントが登場しているようです。 それは必要なことです。なぜなら、コンテナの使用が実験的なものから実存的なものへと拡大するにつれて、まだ成熟の途上にあるからです。
速度と規模は、コンテナ導入の 2 つの主な推進要因の 1 つです。 前者は、提供と同じくらい開発に関するものであり、したがって規模に重点が置かれます。 しかし、単なるバニラ プロトコルのスケールではなく、アプリケーションのスケールについて話しています。
その区別は重要です。 コンテナにはマイクロサービスが含まれる可能性が最も高いと投票されており、マイクロサービスの基本ルールの 1 つは API のみを介した通信です。 TCP ではなく HTTP に基づく API であるため、拡張性のためにはよりスマートなソリューションが必要です。
ほとんどのコンテナ オーケストレーション環境には、バニラ スケールが可能なプロキシが「すぐに使える」状態で付属しています。 これは、TCP 層での単純な古い負荷分散 (POLB)を意味します。 IP アドレスとポートはこれらのプロキシの共通言語です。 これらは、IP アドレスとポートの組み合わせに基づいてサービスが差別化される環境では適切に機能しますが、API バージョン、URI、ホスト名などの HTTP レイヤーの特性によって差別化されるアプリケーション (サービス) ではそれほどうまく機能しません。 これらはアプリケーション層 (HTTP) 構造であり、必要な速度でルーティングおよびスケーリングするには、よりスマートなプロキシが必要です。 これらの構造は、クライアント側のエンティティからのリクエストを受け取ったときに考慮される必要がありますが、これはコンテナのほとんどの標準的なスケール ソリューションでは提供できません。
このニーズに応えて、Ingress* コントロールの概念が生まれました。 イングレス制御は、基本的に、アプリまたは HTTP ルーティング、レイヤー 7 スイッチング、コンテンツ スイッチング、あるいは世紀の変わり目以降にこの機能が付けられてきた 12 個ほどの名前のいずれかです。 イングレス制御は、アプリケーション (HTTP) 層でのサービスの差別化を想定しており、コンテナ環境内でルーティングとスケーリングの決定を行うときにそれに応じて動作します。
しかし、コンテナ環境の前に F5 BIG-IP を配置するだけで、Ingress 制御と呼ぶことはできません。 これは、必要なスケールと速度を実現するには、Ingress コントローラーもコンテナ オーケストレーション環境に統合する必要があるためです。 そのためには、コンテナ オーケストレーションと BIG-IP をネイティブにサポートするコンテナ環境内に存在するものが必要です。
それがKubernetes 用の BIG-IP コントローラーの機能です。 これはKubernetes Pod で実行される Docker コンテナであり、BIG-IP を Kubernetes Ingress コントローラーとして使用できるようになります。 つまり、Kubernetes Ingress リソースを読み取り、適切なオブジェクトを使用して BIG-IP を自動的に構成し、必要なアプリケーション レイヤー構造に基づいてリクエストがスケーリングされるようにすることができます。
さて、このコントローラーが利用可能になる前は、コンテナ オーケストレーション環境内で実行されているプロキシの第 2 層全体にトラフィックを「スプレー」するために BIG-IP を使用する傾向がありました。 これらのプロキシは Ingress の制御を提供しました。 これをやめるべき理由はいくつかありますが、その中には、可用性を提供している対象の内部で可用性サービスを実行するという再帰的な問題も含まれます。
その他の良い理由としては、次のものが挙げられます。
理由が何であれ、実際には BIG-IP を Kubernetes の Ingress コントローラーとして使用できます。 スケーリングするために 2 つの異なる層は必要ありません。 2 番目のスケール層を排除することで、配信と展開の速度が向上し、展開が簡素化されると同時に、セキュリティ、速度、スケールのためのさまざまな高度なサービスを有効にできるプラットフォームが提供されます。
BIG-IP コントローラー for Kubernetes の詳細については、こちら をご覧ください。また、こちらのDocker ハブから入手するか、直接プルすることもできます。
docker pull f5networks/k8s-bigip-ctlr
スケールオン。
* はい、大文字の「I」は重要です。これは、単に「環境へのアクセス」を指す従来のネットワーク用語「ingress」と区別するためです。一方、「Ingress」は「HTTP ルーティング」を指すために使用されます。 確かに、私たちは物事を必要以上に難しくしがちですが、開発者がネットワーク構造を実装し、アプリの配信方法以上のものを再定義しているのが現実です。