第22回 『NGINX Ingress Controllerで実現するミッションクリティカルなコンテナ環境とは』

記事をシェアする:

こんにちは。F5ネットワークスでソリューションアーキテクトを担当しております小峰と申します。今回はF5ならではのネットワーク目線で、NGINX Ingress Controllerについてお話させて頂きます。

コンテナ環境が広がりを見せるなか、「ミッションクリティカル」な要件が必要なコンテナアプリケーションも増えてきています。本記事ではk8s Ingress（以下Ingress）に焦点を当て、柔軟な通信制御や認証機能、セキュリティ、などなど、今までk8sの外で実現されていた機能をk8s上で構築し、理想的なCICDを実現する方法についてお話します。
皆さまのミッションクリティカルなコンテナ環境構築にお役に立てますと幸いです。

k8sで実現する理想的なCICD

本記事ではタイトルの通りIngressに焦点を当てたお話となっていますので、最初にIngressについておさらいし、Ingressを活用した理想的なCICDについて考えてみます。ミッションクリティカルなコンテナ環境にはCICDは必須の要件となります。

まずはIngressについてですが、k8s上でアプリケーションを構築・運用する際に重要な役割を果たすモジュールの１つである「Ingress」とは一体何者でしょうか。
Ingressとは・・・

詳細はこちらから

細かい話はさておき、少し言い方を変えると「k8s上に複数あるServiceに対して、リクエストをパスやヘッダー、Cookie等の値をみて振り分けるk8sのL7LBみたいなもの」がIngressとなります。
Ingressには主にIngressリソースとIngressコントローラーがあり、IngressリソースでL7LBの設定を行い、その設定をIngressコントローラーが理解して処理をする、となります。

• Ingressリソース
  Ingressの機能を実現するための動作、振る舞いを定義する設定ファイル、マニフェストファイルです。例えば下記がIngressリソースの例となります。

詳細はこちらから

上記の場合、「/foo」で始まるパスのリクエストを受信した場合「service1」に振り分け、「/bar」で始まるパスで受信した場合「service2」に振り分けます。

• Ingressコントローラー
  Ingressリソースを作成しても、それを処理する実態がなければ動きません。Ingressリソースの設定を実現するモジュール、それがIngressコントローラーとなります。Ingressコントローラーとして提供されているモジュールがいくつかありますので、後ほど紹介します。

前置きが長くなりましたが・・・、それではIngressを活用した理想的なCICDについてお話します。

ざっくり言うとIngress = L7LBとなるわけですが、一般的なアプリケーションの構成として、クラウドでもオンプレでも必ずアプリケーションの手前にはLoad Balancerが存在し、L7LBの役割を実行しています。パスベースの振り分けや、ヘッダー・Cookieを見ての振り分け、そこにはアプリケーションの特性に合わせた振り分けロジックが存在します。

モノリシックなアプリケーションの場合、L7LBの設定手順はどうなるのでしょうか。アプリ開発チームからインフラチームへ申請があり、作業手順書を作成してレビューし、エンジニアをアサインして土日の深夜に作業を行う、という手順になるかもしれません。これだと迅速なデプロイメントの妨げとなってしまいます。（Ansible等での自動化で解決する方法も有効な解決策です。）

これがk8sになるとL7LBをIngressで実現できるようになります。

k8sの様々な仕組みやIngressの仕組み、周辺にあるCICDツール等と組み合わせることで、L7LBの設定もアプリケーションの一部として容易に管理（Infrastructure as Code、IaC）することができるようになり、迅速なデプロイメントを実現することができます。ネットワーク設定がブロッカーになることを避けることができるのです。

アプリ開発チームの皆さま、インフラチームの同僚に一言、「これからL7LBは我々が面倒見るよ！」と相談してみましょう！

人気のIngressモジュールは？

世の中ではどのようなモジュールがIngressとしての機能を実行しているのでしょうか。ちょっと古いですがCNCFのアンケートを見てみましょう。

詳細はこちらから(PDF)

１番人気はNGINXとなります。次いでEnvoyやOpenShift Routerでも使われているHAProxy、５番手にはF5（BIG-IP）も入っています。BIG-IPは上記で説明したユースケースの通り、k8sの手前に配置されてIngressの役割を果たすLoad Balancerとして、となります。

アンケート結果を参考に、皆様の環境に最適な「Ingress」機能を実現していきましょう。

NGINX Ingress Controllerの使える機能（１）

ここで、一番人気のNGINX Ingress Controllerの便利な機能を紹介させてください。

「顧客管理と課金管理、まったく別のチームが開発しているから、Ingressの設定もそれぞれに任せたいな・・」
「アプリの一部は外注しているから、後でIngressリソースにそのアプリの設定を追加するより、Ingressリソースごと外注先にお願いできないかな・・その部分だけ切り出せないかな・・」

k8sでのアプリケーションが広がっていくと、このような要望が出てくるかと思います。ここでお役にたてるのがNGINX Ingress ControllerのCRD（Custom Resource Definition）です。ここではVirtualServer/VirtualServerRouteの２つを紹介します。

上記のサンプルを見て頂くと、左のVirtualServerでパス毎に細かい振り分けを行う「route」を定義し、細かい振り分けの実態を右のVirtualServerRouteで定義しています。

アプリケーションの一部として動作するIngressの仕組みを切り出すことで、それぞれのアプリ開発チームや外注先で専用の設定（VitrualServerRouteの設定）を行う事ができるようになります。他のアプリケーションとは分離されてIngressを管理することができるようになるのです。

「設定だけではなくてNGINX Ingress ControllerのPod自体も分けたい」ということであれば、Ingressクラスを活用して各チームそれぞれで異なるNGINX Ingress Controller Podを起動して管理することができます。

【関連情報】

• Ingress Classについての詳細はこちら
• NGINX Ingress Controller CRDの細かい設定や解説などはこちら

NGINX Ingress Controllerの使える機能（２）

もう１つご紹介したい機能はセキュリティとなります。

k8sでアプリケーションを構築する際の課題として、常にセキュリティは上位に入っています。k8s自体や、クラウド・オンプレ環境の監視、設定が正しいかどうか、デフォルトパスワードのまま放置されていないか、もしくはSASTやペネトレーション診断を行いアプリケーション自体が脆弱ではないかの診断、そもそも古いLog4j等の脆弱なモジュールが使われていないか、等、セキュリティの課題は尽きることがありません。

そのような状況で、Ingressがお役に立てるセキュリティ対策があります。
どんなに環境がセキュアでも、アプリケーション自体もセキュアで、様々なセキュリティ診断をパスしたとしても、脆弱性は突然やってきます。2021年末のLog4jのように・・・。突然やってくる驚異に対しては、やはりリアルタイムに攻撃を遮断する必要があります。
Ingressが外部からの通信を各Serviceに振り分ける役割を担っているのであれば、そこで攻撃を遮断することができれば、皆さまのアプリケーションをよりセキュアにできるのではないでしょうか。

NGINX Ingress Controllerであれば、今動いているNGINXにWAF機能を搭載することができます。（有償版のNGINX Ingress Controllerに限ります。）

WAFの細かい説明はここでは省きますが、特別なフォーマットで設定を・・ということではなく、k8sのマニフェストファイルでセキュリティポリシーを設定することができ、アプリ開発チームがIaCでNGINXを運用している場合、Security as Codeとしてセキュリティ機能も追加してCICDに組み込むことも可能です。

L7LBもセキュリティも、アプリケーションに近ければ近いほど迅速に管理することができ、頻繁なデプロイメントや脆弱性等への最速な対応を可能にします。

いかがでしたでしょうか。
詳細は日本IBM様主催のコンテナ共創センターでの2023年1月の勉強会でお話させて頂きますので、ぜひともご参加ください。

コンテナ共創センター１月の勉強会（#21）

Ingressの機能をNGINX Ingress Controllerでフル活用し、ぜひ皆さまの「ミッションクリティカル」なコンテナアプリケーションの構築にお役立てください！

公式サイトはこちら