高速性と拡張性：KubernetesのIngress制御を担うF5 BIG-IP

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

コンテナの世界では、混沌と同じくらい混乱も広がっています。コンテナオーケストレーション環境には、日々新たな機能やコンポーネントが登場しているように見えます。コンテナの利用が実験的な段階を越え、事業の存続に関わる領域へと広がるなか、この分野は今なお成熟の途上にあり、こうした進化は欠かせません。

コンテナ導入を推進する主な要因として、スピードとスケールが挙げられます。スピードはデリバリーだけでなく開発にも大きく関わるため、スケールが重視されます。ただし、単なるプロトコルのスケールではありません。ここで取り上げるのは、アプリケーションのスケールです。

この違いは重要です。コンテナは、マイクロサービスを格納する可能性が最も高いと評価されています。また、マイクロサービスの基本原則の1つは、通信をAPI経由に限定することです。このAPIはTCPではなくHTTPをベースとしているため、スケールにはより高度なソリューションが必要です。

ほとんどのコンテナオーケストレーション環境には、標準的なスケーリングに対応するプロキシが標準搭載されています。つまり、TCPレイヤーでの従来型のロードバランシング（POLB）です。こうしたプロキシでは、IPアドレスとポートが共通言語となります。IPアドレスとポートの組み合わせに基づいてサービスを区別する環境では十分に機能しますが、APIバージョン、URI、ホスト名など、HTTPレイヤーの特性によって区別されるアプリケーション（サービス）にはあまり適していません。これらはアプリケーションレイヤー（HTTP）の構成要素であり、求められる速度でルーティングとスケーリングを行うには、より高度なプロキシが必要です。クライアント側のエンティティからリクエストを受信した時点で、これらの構成要素を考慮する必要がありますが、ほとんどのコンテナ向け標準スケーリングソリューションでは対応できません。

このニーズに応えるものとして登場したのが、Ingress*制御という概念です。 Ingress制御とは、基本的にはアプリケーションルーティングまたはHTTPルーティングを指します。ほかにも、レイヤー7スイッチング、コンテンツスイッチングなど、今世紀に入ってから十数通りの名称で呼ばれてきた機能です。Ingress制御では、アプリケーション（HTTP）レイヤーでサービスを識別することを前提とし、コンテナ環境内でルーティングやスケーリングを決定する際に、その識別情報に基づいて処理します。

しかし、コンテナ環境の前段にF5 BIG-IPを置くだけで、Ingress制御と呼ぶことはできません。必要な規模の拡張性とスピードの両方を実現するには、Ingressコントローラーをコンテナオーケストレーション環境と統合する必要もあるためです。そのためには、コンテナ環境内で動作し、コンテナオーケストレーションとBIG-IPにネイティブに対応するものが必要です。

この役割を担うのが、BIG-IP Controller for Kubernetesです。これはKubernetes Pod内で動作するDockerコンテナであり、BIG-IPをKubernetes Ingressコントローラーとして使用できるようにします。Kubernetes Ingressリソースを読み取り、適切なオブジェクトを使用してBIG-IPを自動的に構成することで、目的のアプリケーションレイヤー構成に基づいてリクエストをスケーリングできます。

このコントローラーが利用可能になる前は、BIG-IPを使用して、コンテナオーケストレーション環境の内部で稼働する第2層のプロキシ群にトラフィックを「分散」させるのが一般的でした。Ingress制御を担っていたのは、それらのプロキシです。しかし、この構成をやめるべき理由はいくつかあります。たとえば、可用性を確保する対象の内部で可用性サービスを実行するという、再帰的で厄介な問題が生じます。

ほかにも、次のような理由があります。

• DDoS攻撃の緩和を有効化
• Take advantage of a Webアプリケーションファイアウォールを活用してAPIとアプリを保護
• IPv6クライアントからIPv4コンテナ化アプリを利用できるようにする
• TLS処理をBIG-IPにオフロードし、自己署名証明書を使用して再暗号化
• アプリケーション高速化オプションを使用してパフォーマンスを向上

理由が何であれ、BIG-IPをKubernetesのIngressコントローラーとして使用できることに変わりはありません。スケーリングのために2つの異なる階層を用意する必要はありません。2つ目のスケーリング階層をなくすことで、デリバリーとデプロイの両方を高速化し、デプロイを簡素化できます。さらに、セキュリティ、速度、スケーラビリティに対応する多様な高度なサービスを有効化できるプラットフォームも提供します。

BIG-IP Controller for Kubernetesの詳細については、こちらをご覧ください。また、Docker Hubから入手するか、次のコマンドで直接プルすることもできます。

docker pull f5networks/k8s-bigip-ctlr

スケールを続けましょう。

* はい、大文字の「I」は重要です。従来のネットワーク用語で、単に「環境へのアクセス」を意味する「ingress」と、HTTPルーティングを指す「Ingress」を区別するためです。確かに、必要以上に複雑にしてしまう傾向はありますが、開発者がネットワーク構成要素を実装し、アプリケーションの配信方法にとどまらず、さまざまな概念を再定義しているのが現状です。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事