ネットワーク

NGINX Plus Ingress Controller を触ってみた(CRD 設定編)

NGINX Plus Ingress Controller の機能を最大限活用するための設定方法とは。

こんにちは。 narai です。 最近バタバタしていましたが、やっと時間が取れたので、NGINX Plus Ingress Controller の具体的な設定方法について書いていきます。

なお、この記事は「NGINX Ingress Controller を触ってみた」の続きとなります。

 


NGINX Plus Ingress Controller の設定方法について

初めに、Kubernetes における Ingress Controller の役割は Ingress の情報に沿って、Service へ振り分けることとなります。
しかしながら、Ingress で定義できることは「ホスト名/path ベースのルーティング、SSL 終端」に限られています。
Header を精査したり、namespace を超えて転送したり、URL path を書き換えたりといったことは定義できません。

では、どうするかというと、Ingress の annotation で拡張するか、各種 Ingress Controller がリリースしている Custom Resource Definition (以後、CRD) を使用することで、より柔軟な制御を行うことが可能となります。
CRD の詳細については、こちらを確認いただきたいのですが、簡単に言えば、各メーカーが作成した独自の Kubernetes リソースとなります。

NGINX Plus Ingress Controller は、Ingress の annotation と CRD の両方が利用できますが、ここでは CRD を使用する方法についてみて行きましょう。

CRD を使用することで、NGINX が持つ以下のような機能を提供することができるようになります。

  • namespace を越えた振り分け
  • リクエスト内容(ヘッダ等)に応じた振り分けやトラフィック分割
  • アドレス制限や Rate 制限、外部認証
  • URL path の書き換え
  • WAF

などなど。。。

なお、これから紹介する CRD は F5 NGINX にて開発、保守されている nginx (plus) ingress controller にて利用可能です。
Kubernetes コミュニティにて開発、保守されている nginx ingress では利用できませんのでご注意ください。

NGINX Plus Ingress Controller のCRD

NGINX Plus Ingress Controller では以下のようなカスタムリソースを利用できます。

  • VirtualServer
  • VirtualServerRoute
  • TransportServers
  • policies

それぞれの役割としては、

  • VirtualServer は Ingress の替わりとなり、Service への振り分け方法を設定します。
  • VirtualServerRoute と policies は namespace を超えた振り分けや Rate 制限、アクセス制御等を設定します。
  • TransportServer は TLS パススルーや TCP/UDP の振り分け方法を設定します。

また、これらのカスタムリソースは Kubernetes には含まれておりませんので、別途、デプロイする必要があります。
前回の Blog 記事の Install で実施した以下のコマンドが該当します。

$ kubectl apply -f common/crds/k8s.nginx.org_virtualservers.yaml
$ kubectl apply -f common/crds/k8s.nginx.org_virtualserverroutes.yaml
$ kubectl apply -f common/crds/k8s.nginx.org_transportservers.yaml
$ kubectl apply -f common/crds/k8s.nginx.org_policies.yaml

 

では、CRD を使用して NGINX Plus Ingress Controller を設定して行きましょう。
今回は、VirtualServer および VirtualServerRoute を使用して、path ベースの振り分けや  namespace を超えたルーティングを試します。

 

VirtualServer による path ベースの振り分け

今回は以下のように、main.exsample.com 宛の通信にて path が /dev であれば dev-svc に、 /prod であれば prod-svc に振り分ける設定をします。

まずは、Ingress Controller 用の Service (ing-svc) を以下のように作成します。

      

このマニュフェストをデプロイすることで、クライアント → ing-svc(Service) → nginx-plus-ingress-controller(pod) まで繋がるようになります。
ただ、この状態では nginx-plus-ingress-controller は振り分けルールを認識していません。
そこで、Ingress の替わりとなる VirtualServer を作成して振り分けルールを設定します。※VirtualServer があれば Ingress は不要です。

設定方法としては upstreams に振り分け先の Service を登録して、routes で、path と upstream を関連付けます。

 
 

このマニュフェストをデプロイすることで、 /dev であれば dev-svc に /prod であれば prod-svc に振り分けることができるようになります。
ちなみに、この VirtualServer の設定を nginx のコンフィグにするとこんな感じになります。

upstream にバランシング先のサーバーを登録して、location で紐づけるという構成なので、非常に似ています。
そのため、nginx と同じような感覚で設定できるため、学習コストが低いのも CRD を利用するメリットになります。

 

 

namespace を超えた分散

では、もう一つ。
Kubernetes では namespace という概念があり、これにより複数のチーム・プロジェクトが共通の Kubernetes 環境を安全に利用できます。namespace の詳細はこちらをご覧ください。  
namespace は非常に便利な機能ですが、Ingress ではこの namespace を跨いだ振り分けを設定できません。CRD を使用することで namespace を跨いだ振り分け設定が可能になります。
 
ここでは以下のように、Ingress と pod が異なる namespace の構成における振り分けの設定を行います。
 
 
設定方法としては、各 namespace 毎に VirtualServerRoute を設定し、VirtualServer でどの VirtualServerRoute を参照するかを指定します。
各オブジェクトのイメージとしては以下のようになります。

具体的な設定方法としては、各 namespace 毎の振り分けルールを VirtualServerRoute で設定し、VirtualServer にて、path と VirtualServerRoute を関連付けます。

 

これをデプロイすることで、namespace を超えて振り分けが可能になります。
namespace 毎に Service をデプロイする必要がなくなる上、環境を分けられるので作業範囲の住み分けができそうですね。

まとめ

冒頭で書いた通り、CRD を使用すると NGINX が持っている様々な機能を利用することができるようになります。
 マニュフェストも NGINX の設定と似た感じで作成できるため、ぜひ、NGINX Plus Ingress Controller を試してみてください。

また、今回ご紹介した設定は基本的なところになります。
Header の操作やアプリケーション試験のために特定通信のみの振り分け等、より柔軟な振り分け方法についても記事にしていきますので、お待ちください。

この記事に関連する製品・サービス

この記事に関連する記事