NSX-ALB による Kubernetes Ingress サービスの高度化 - Part 1

VMware はコンテナネットワーキング向けのソリューションとして、IaaS、CaaS からアプリケーション層に至る様々なレイヤの製品をご提供しています。

Kubernetes を下支えする IaaS/vSphere 環境のネットワーク＆セキュリティ機能である NSX-T DataCenter と、ロードバランサー機能である NSX-ALB (Advanced LoadBalancer)
Kubernetes のクラスターネットワーキング機能として NSX-T を活用する NCP (NSX Container Plugin)
Tanzu 製品群にも組み込まれているオープンソースの CNI である Antrea
NSX ALB を外部 LB として利用し、Service LoadBalancer や Ingress 機能を実現する AKO (Avi Kubernetes Operator)
Pod のサイドカープロキシーとして動作するサービスメッシュ技術により、コンテナレベルでのネットワーキングとセキュリティを提供する Tanzu Service Mesh

NSX-ALB を様々な Kubernetes 環境の上で Ingress や LoadBalancer としてご利用いただくための仕組みとして、AKO (Avi Kubernetes Operator) というコンポーネントをご提供しています。このブログでは、この AKO の機能や拡張機能をご紹介します。

Avi Kubernetes Operator (AKO)

Avi Kubernetes Operator (AKO) は、K8s クラスター上に展開されるアプリケーションのために L4-L7 ロードバランサーの制御機能を提供する、オープンソースのソフトウェアです。

GitHub: https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes

K8s クラスター上の Pod として動作し、K8s 制御プレーンでのリソース設定に基づいて NSX-ALB Controller を制御します。 “Avi” という言葉は VMware が 2019 年に買収した Avi Networks の社名に由来しており、Avi Networks が開発していた LB 製品が現在の NSX-ALB の前身となっています。

AKO は K8s API server 上の Ingress 等のオブジェクトの変更を検出すると、対応する NSX-ALB Controller の設定を更新します。NSX-ALB Controller は適切なトラフィック制御を実現するためにデータプレーンコンポーネントである Service Engine (SE) をプログラムし、ロードバランサー機能 (以下、Virtual Service) を実際に K8s アプリケーションに対して提供します。Service Engine 上の Virtual Service は K8s クラスタの外にあるロードバランサーとして動作します。

NSX-ALB という包括的なロードバランサー製品と組み合わせることで、AKO は以下のような利点を K8s Ingress サービスにもたらします。

統合的なソリューション: LB、Ingress、セキュリティ、WAF、GSLB、DNS、IPAM といった機能を包括的に K8s に提供します。
シンプルな運用: NSX-ALB Controller により、すべての K8s Ingress や LB サービスを中央集中型で管理します。設定の管理やトラブルシュートが単一のコントローラで実行できるようになります。
多様なオブザーバビリティ: すべての K8s Ingress と LB コンポーネントにまたがるアプリケーション分析とリアルタイムのテレメトリ機能を提供します。イベントやアラートの管理、トラフィック状態やログの分析などをリッチな UI を使って実行できます。
動的なコンテナ環境に対応する柔軟な自動化: NSX-ALB のエラスティックスケーリング機能を使って、複数の LB インスタンス (Service Engine) を用いたトラフィック分散処理を実現します。大量のトラフィックを扱う、あるいは動的に変動するアプリケーションの処理に適しています。
- 参考ブログ: VMware がお届けする、伸び縮みするロードバランサーとは？

AKO は様々な IaaS や K8s に対応可能です。インフラ観点では、VMware vSphere 以外に Azure, GCP, AWS のパブリッククラウドに対応しています。K8s としては VMware Tanzu Kubernetes Grid (TKG) はもちろん、OpenShift やパブリッククラウドのマネージド K8s (GKE, AKS, EKS) にも対応しています。CNI としては Calico, Flannel, Antrea, OpenShift SDN, NCP (VMware NSX) に対応しています。

AKO の機能

AKO を用いることで、NSX-ALB Enterprise Edition が提供する高度な ADC 機能を K8s 環境で利用できるようになります。利用可能な機能の概要は以下のとおりです。

L4 Virtual Service : Service type LoadBalancer に対応する Virtual Service と Pool の作成、および関連するネットワーク設定の追加
L7 Virtual Service : Ingress に対応する Virtual Service と Poolの作成、および関連するネットワーク設定の追加
L7 Policy : L7 Virtual Service に適用する NSX-ALB 各種機能のコントロール(CRD を用いた制御)
GSLB : AMKO による GSLB 設定のコントロール
WAF : L7 Virtual Service に対する WAF Profile の適用
マルチテナンシー : K8s クラスターに対する NSX-ALB テナントの割り当て
トラフィック分析 : トラフィック分析ポリシーの適用、高度な分析UI
高信頼性 : Service Engine が有する HA 機能の利用 (Active/Standby, Active/Active, Elastic N+M)
伸縮性 : コンテナの拡張に応じて柔軟に Virtual Service のリソース(SE)をスケーリング

L4/L7 Virtual Serivce の展開

K8s Service type LoadBalancer や Ingress への対応は AKO の最も基本的な機能です。これらのリソースの作成を契機とする L4/L7 Virtual Service の展開の流れは以下のようになります。

ユーザが Ingress/Routes/Service LB と CRD を設定
AKO はこれらのオブジェクト情報を K8s Master から取得
AKO は Ingress/Route/Svc LB 情報を解釈し、NSX-ALB の API をコールする
NSX-ALB Controller は IPAM を使って IP アドレスを割り当て、FQDN を DNS で公開する
Service Engine は Ingress/Route/Svc LB の Virtual Service を実現する

Virtual Service の展開完了後、端末から VIP にリクエストを送ると、Service Engine は負荷分散設定に基づいてバックエンド Pod を選択し、リクエストを送信します。

AKO による Pod へのネットワーク接続性

外部ロードバランサーを利用する場合の悩みの一つが、Pod へのルーティングの実装ではないかと思います。一般的に K8s では Pod は K8s ノード内のネットワークに接続されますが、そのネットワークへの直接的なルーティングができない場合、ロードバランサーのプールメンバーとして直接 Pod を登録できません。そのような場合に NodePort を利用することがありますが、NodePort では外部ロードバランサーを介した Pod への負荷分散パスが必ずしも適正にならないことがあります。

最新の AKO では、ユーザのネットワーク構成や用途に応じて、ClusterIP、NodePort、NodePortLocal の3つのネットワーク接続モードを提供しています。

ClusterIP モード

このモードでは、AKO は Pod へ直接負荷分散を行うことを前提に Service Engine をプログラムします。Pod に対応する Service に ClusterIP が設定されている必要があります。Pod への直接ルーティングができない環境の場合は、Service Engine に各 Pod Network へのルーティング設定を自動的に追加します。(SE と K8s ノードが L2 隣接であることが前提)

NodePort モード

このモードでは、AKO は NodePort を介して Pod へ負荷分散を行います。Pod に対応する Service に NodePort が設定されている必要があります。Service Engine と K8s ノードが L2 隣接である必要はありません。Service Engine で負荷分散を実施した後、さらに NodePort で負荷分散を行うため、必ずしも適正な転送パスにならない場合があります。また個々の Pod に対するパーシステンスやヘルスモニタはサポートされません。

NodePortLocal モード

このモードでは、AKO は Antrea NodePortLocal (NPL) を介して Pod へ負荷分散を行います。K8s で Antrea CNI を使用しており、NodePortLocal が有効になっている必要があります。NodePortLocal についてはこちらの記事もご参照下さい。Service Engine と K8s ノードが L2 隣接である必要はありません。このモードでは Service Engine は NPL に対して負荷分散を行いますが、NPL と Pod が1対1に対応するため、Podに対するパーシステンスやヘルスモニタが有効です。

AKO のデプロイ

AKO のデプロイ方法は環境に依存して複数存在します。詳細はこちらをご参照下さい。アップストリームな K8s にデプロイする場合は Helm の利用が一般的です。Helm を使ったインストール方法はこちらです。

VMware TKG 環境においては、TKG クラスタを展開する際に同時に AKO を展開することが可能です。以下の VMware Japan Blog では最新の TKG 1.5 での NSX-ALB 展開手順についても解説されていますので、合わせてご参照いただけると幸いです。

Tanzu Kubernetes Grid 1.5 を vSphere にデプロイしてみる

実際にやってみた

それでは、実際に AKO を使って Virtual Service を展開する例をご紹介したいと思います。今回利用した環境はアップストリームな K8s 環境で、Helm を利用して AKO をインストールしていますが、AKO 自体は TKG 環境で展開されるものと基本的には同じです(一部の初期設定値は異なりますが)。ClusterIP モードを使用することを想定しているため、Service Engine と K8s ノードは L2 隣接にしています。

今回利用した環境のコンポーネントとバージョンは以下のとおりです。

Kubernetes 1.21.9
NSX-ALB 21.1.3, AKO 1.6.1
vSphere 7.0.3, vCenter 7.0.3

NSX-ALB の初期設定

AKO の利用を開始する前に、NSX-ALB の初期設定を行う必要があります。すでにいくつかの VMware Japan Blog で初期設定の方法が説明されておりますので、ここでは今回の環境のご紹介だけしたいと思います。

まずロードバランサーを実行する仮想インフラ (NSX-ALB では “Cloud” と呼びます) の構成です。NSX-ALB UI で インフラストラクチャ＞クラウド と移動し設定を行います。今回は既存の “Default-Cloud” を変更して、この環境の vSphere/vCenter と連携して Service Engine (SE) の自動作成や制御ができるように設定します。

インフラストラクチャタブでは vCenter の管理者ユーザとIPアドレスなどを設定します。

IP アドレス管理プロファイルを新規作成し、この Cloud 内でIPアドレスの自動割当対象にするネットワークを選択します。

次に Data Center タブに移動して SE の展開に利用する vSphere Datacenter を選択します。

さらにネットワークタブで管理用に利用するネットワークとアドレス設定、Service Engine Group を指定します。ここではデフォルトで存在する “Default-Group” を指定しています。

次に インフラストラクチャ＞クラウドリソース＞サービスエンジングループ と移動し、“Default-Cloud” を選択します。先ほど Cloud の設定で指定した “Default-Group” を選択し、必要に応じて変更します。ここでは高可用性モードを アクティブ/アクティブ に変更し、複数の Service Engine に分散して Virtual Service を実行するモードを選択しています。

次に インフラストラクチャ＞クラウドリソース＞ネットワーク に移動し、”Default-Cloud” を選択します。この Cloud 内で NSX-ALB が認識しているネットワークがリスト表示されるので、IPAM で設定したネットワーク(ここでは “VLAN 2900”) を選んで編集します。必要に応じてサブネットを追加し、IPAMが管理するIPアドレスプールの範囲を設定します。

ここまでの設定状態は以下のとおりです。AKO はまだ展開していません。上述のとおり、Service Engine と K8s ノードは同じ “VLAN 2900” に面して L2 隣接となっています。

AKO の設定

今回はこちらの Helm インストールを利用して AKO を展開しています(今回実施したステップはここでは省略します)。 TKG の中で展開した場合、あるいは Helm を利用した場合でも、AKO の設定は K8s の ConfigMap “avi-k8s-config” として記録されます。以下のコマンドを実行して、AKO の設定を確認することができます。

> kubectl get configmap avi-k8s-config -n avi-system -o yaml

今回の環境では以下のような結果となりました。

apiVersion: v1
data:
  apiServerPort: "8080"
  autoFQDN: default
  bgpPeerLabels: '[]'
  cloudName: Default-Cloud
  clusterName: kubeadm-cluster
  cniPlugin: antrea
  controllerIP: 172.16.128.45
  controllerVersion: 21.1.3
  defaultDomain: ""
  defaultIngController: "true"
  deleteConfig: "false"
  disableStaticRouteSync: "false"
  enableEVH: "false"
  enableEvents: "true"
  enableRHI: "false"
  fullSyncFrequency: "1800"
  istioEnabled: "false"
  layer7Only: "false"
  logLevel: WARN
  noPGForSNI: "false"
  nodeKey: ""
  nodeNetworkList: '[{"cidrs":["172.19.0.0/24"],"networkName":"VLAN 2900"}]'
  nodeValue: ""
  nsSyncLabelKey: ""
  nsSyncLabelValue: ""
  nsxtT1LR: ""
  passthroughShardSize: SMALL
  serviceEngineGroupName: Default-Group
  serviceType: ClusterIP
  servicesAPI: "false"
  shardVSSize: SMALL
  tenantName: admin
  vipNetworkList: '[{"cidr":"172.19.0.0/24","networkName":"VLAN 2900"}]'
  vipPerNamespace: "false"
kind: ConfigMap
metadata:
  annotations:
    meta.helm.sh/release-name: ako-1643099082
    meta.helm.sh/release-namespace: avi-system
  creationTimestamp: "2022-01-25T08:24:47Z"
  labels:
    app.kubernetes.io/managed-by: Helm
  name: avi-k8s-config
  namespace: avi-system
  resourceVersion: "10781367"
  uid: 69b96575-b9eb-4c54-a0cd-cc72565aaad9

cloudName が “Default-Cloud”、serviceEngineGroupName が “Default-Group” に設定されています。また nodeNetworkList と vipNetworkList のネットワーク名が “VLAN 2900” に設定されています(これらの設定値は Helm インストール時に与えています)。

また serviceType が “ClusterIP” に設定されています。serviceType は上述のネットワーク接続性オプションを設定するパラメータです。つまりこの AKO クラスタは ClusterIP モードで動作するようになっています。しかしこの環境では Pod への直接ルーティングをサポートしないので、Service Engine/Virtual Service から Pod へのルートを AKO が自動的に設定することになります。

実は AKO をデプロイした時点で静的ルーティング設定が実行されています。NSX-ALB UI で インフラストラクチャ＞クラウドリソース＞ルーティング に移動し、”Default-Cloud” を選択して、スタティックルートタブを開きます。

上記のスタティックルートのうち下の3つは、3台ある K8s ノード内の Pod Network (192.168.0.0/24, 192.168.0.1/24, 192.168.0.2/24) に対するネクストホップを各ノードのIPアドレス(172.19.0.201, 202, 203)に指定しています。Service Engine と各 K8s ノードは L2 隣接なので、このルート設定に従って Virtual Service から Pod へのルーティングができるようになっています。

AKO 展開後の状態は以下のようになります。

Service type LoadBalancer のデプロイ

では、実際にワークロードを展開して、Virtual Service が自動的に作成されることを確認します。予めデモ用の Pod (lb-demo) を作成します。これは、その Pod のホスト情報を返却するような httpd コンテナです。次に以下のような Service LoadBalancer マニフェストを作成して適用します。

apiVersion: v1
kind: Service
metadata:
  name: lb-demo
spec:
  type: LoadBalancer
  selector:
    app: lb-demo
  ports:
  - port: 80
    protocol: TCP

> kubectl apply -f lb-demo.yaml
service/lb-demo created
>
> kubectl get services
NAME         TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)        AGE
kubernetes   ClusterIP      10.96.0.1        <none>         443/TCP        78d
lb-demo      LoadBalancer   10.103.109.197   172.19.0.212   80:30542/TCP   8m21s

この Service Engine Group で初めて Virtual Service を作った場合は、vCenter を介して ESXi 上に Serice Engine が自動的にデプロイされ、その上に lb-demo に対応する L4 Virtual Service が作成されます。NSX-ALB UI で アプリケーション＞仮想サービス と移動すると、”kubeadm-cluster–default-lb-demo” という名前で Virtual Service が作成されており、“172.19.0.212” というアドレスと “80” 番のサービスポートが割り当てられていることが分かります。