Kubernetes（以下 K8s）の環境にコンテナ化されたアプリケーションをデプロイして、サービスを提供する形態が増えてきました。アプリケーションのリリースサイクルの高速化や Time-To-Market を短縮するために、今後も導入が増え続けることが予想されます。ところで、利用者は K8s 環境のアプリケーションにどのようにアクセスするのでしょうか。K8s クラスタ内にデプロイされたアプリケーションを外部に公開し、利用者がアクセスできようにする役割を担うのがロードバランサーです。本ブログでは、VMware が提供する NSX Advanced Load Balancer（以下 NSX ALB） と K8s との共通点を深掘りしながら、アプリケーションデリバリーにおけるサービス品質向上と運用効率化を実現する仕組みについて解説します。
１．コントロールプレーンとデータプレーンの分離
K8sを構成する要素として、マスターとノードがあります。マスターは、クラスタ全体の管理を担うコントロールプレーンとしての役割を担います。K8sに対してリソースを作成したり、状態を取得したりするためには、マスターのコンポーネントの一つである kube-apiserver 経由で行う必要があります。一方ノードは、Podと呼ばれるコンテナ化されたアプリケーションを実行します。
NSX ALB は、コントロールプレーンとデータプレーンが分離したアーキテクチャを採用しています。コントロールプレーンの役割を担う Controller は統合管理や分析可視化、オーケストレータとしての機能を提供します。管理者がLB を作成したり、状態を取得したりするためには、Controller 経由で行う必要があります。一方、データプレーンの役割を担う Service Engine はロードバランサー（以下 LB）の実体として、サーバ負荷分散や GSLB (Global Server Load Balancing)、WAF (Web Application Firewall) などの機能を提供します。
２．アプリケーション設定の集中管理
K8s では、アプリケーションから設定情報や TLS 証明書を分離し、K8s のリソース（ConfigMap/Secret）として集中管理することができます。アプリケーションは、それらの K8s リソースをコンテナ内のファイルとしてマウントすることで、参照することができます。設定情報や TLS 証明書をアプリケーションのイメージに組み込む必要がないため、変更が必要な場合でもイメージの再作成は不要になります。
NSX ALB でも、アプリケーションの設定情報や TLS 証明書、各種プロファイルなどをコントローラで集中管理しています。アプリケーション負荷分散に必要な仮想サービスを作成した際、設定情報や TLS 証明書はコントローラ側で管理され、適切な LB に反映されます。設定変更が必要な場合はコントローラ側で実施するため、管理者が個々の LB に対して直接設定変更する必要はありません。
３．リソース利用効率の向上
K8s では複数のノードを一つの大きなリソースプールとして扱うことができます。そしてコンテナ技術の活用により、複数のアプリケーションが同じノードに同居できます。アプリケーションごとにサーバを分けたり、冗長構成を組んだりしないため、リソースの利用効率が向上します。
NSX ALB でも、複数の LB を一つの大きなリソースプールとして扱うことで、LB を抽象化します。LB は Active-Active 構成が組めるため、Active-Standby 構成時における Standby の余剰リソースを排除できます。また、強力なマルチテナントと RBAC 機能を有しているため、複数のテナント・サービスが同じ LB に同居することができるため、LB を分けて準備する必要もありません。
４．スケジューリング
アプリケーションをデプロイする際、必要なリソース要求や各ノードの空リソース状況を踏まえ、K8s は適切なノードで Pod を実行するようにスケジューリングします。ユーザはどのノードに Pod を配置するかを管理する必要はありません。もちろん、Affinity/Anti-Affinity や Taint/Toleration という仕組みを使うことで、Podの役割や負荷特性に合わせて最適なノードへスケジューリングするように制御することも可能です。
NSX ALB でも、仮想サービスをデプロイした際、必要なリソース要求や LB のリソース空き状況、ネットワーク要件、可用性などを踏まえ、最適な LB に仮想サービスが構成されます。LB を新たにデプロイする必要がある場合も同様の条件が考慮され、最適な物理サーバ上に LB が配置されます。管理者はどの物理サーバに LB を配置するかを考えたり、どの LB に仮想サービスを構成するかを管理したりする必要はありません。もちろん、仮想サービスに求められる性能要件や SLA、本番/開発環境などの特性に合わせて、どの LB に構成するかを柔軟に制御することも可能です。
5．宣言的設定
K8s の API の特徴として、手順を１つ１つ呼び出す”命令的”ではなく、何を達成したいかを告げる”宣言的”であることが挙げられます。サービスの望ましい状態を設定ファイル（マニフェスト）に記述し K8s に反映させることで、K8s は現在の状態を望ましい状態に一致させるように動作します。どのような状態からアプリケーションをデプロイしても、必ず同じ状態になることが保証される冪等性があるといえます。
NSX ALB では、サービスの望ましい状態（何のアプリケーションをどのサーバに割り振るのか等）を仮想サービス/プールとして宣言することで、その状態になるように、コントローラはプロビジョニングやコンフィギュレーションを行います。具体的な以下の一連のプロセスがバックグラウンドで行われています。
６．セルフヒーリング
K8s には自己回復機能があります。上述の宣言的設定に基づいて動作します。たとえば、あるサービスで3個の Pod を実行していることが望ましい状態の場合、ノード障害等で1個の Pod が消滅したとき、K8s は望ましい状態に一致させるべく、新しい Pod を健全なノードに再デプロイします。
NSX ALB でも同様の機能を提供します。たとえば、ある仮想サービス（VIP）が3台の LB で構成されていることが望ましい状態の場合、仮に1台の LB が障害等で停止したとき、コントローラはその障害を検知した上で問題のあるLBを切り離し、そのLBで動作していた仮想サービスを別の健全なLBに再配置します。再配置先のLBが存在しない場合、コントローラは新しい LB を再デプロイし、仮想サービスをリストアします。このように、コントローラが望ましい状態へ自動的に戻してくれるために、LB1台1台の状態を気にする運用から解放され、管理者はLB全体のリソースと仮想サービスの状態だけを管理すればよくなります。
７．スケーリング
アプリケーションの負荷に応じて、性能を拡張する方法は大きく分けて2種類があります。スケールアップでは、Pod に割り当てる CPU やメモリを増やすことで性能を上げることができます。一方、スケールアウトでは、Pod の数を増やして性能を上げることができます。K8s では、Pod が必要なリソース要求を調整したり、ReplicaSet で Pod の数を増減したり、HorizontalPodAutoscaler で CPU 使用率等のメトリクスに応じて Pod 数を自動調整したりできます。
NSX ALB はソフトウェア型ロードバランサーであるが故に、LB に割り当てる CPU やメモリ等のリソースを柔軟に制御することができます。また、デフォルト Active-Active 構成で動作するため、LB の数を増やしたり減らしたりすることも容易に行えます。さらに、CPU 使用率やスループット、同時コネクション数、PPS等のメトリクスに応じて LB 数を自動調整することもできます。
８．ローリングアップデート
K8s ではアプリケーションをサービス影響なくバージョンアップすることが可能です。たとえば、２つの Pod A,B で同じアプリケーションが稼働している場合、Pod-A へのリクエストの割り振りを停止した上で、Pod-A のアプリケーションのバージョンアップを実施します。バージョンアップ完了後、Pod-A へのリクエストの割り振りを再開し、今度は Pod-B への割り振りを停止した上で、Pod-B のアプリケーションをバージョンアップします。
NSX ALB でもサービス影響なくバージョンアップすることが可能です。2台の LB A,B が Active-Active で構成されている場合、まず LB-A へのリクエストの割り振りを停止します。その際、新規コネクションの割り振りを停止しますが、既存コネクションは継続的に処理することでサービス影響を最小化します。すべてのコネクションが正常終了した状態で LB-A はバージョンアップを実施します。バージョンアップ完了後は、LB-A へのリクエストの割り振りを再開し、今度は LB-B のバージョンアップが同様の手順で行われます。
９．クラウド間のポータビリティ
K8s では、オンプレミスやクラウドを問わず、あらゆる環境で提供される IT インフラを抽象化し、同じ方法で K8s のリソースをデプロイすることができます。クラウド間のポータビリティ（可搬性）が備わっているため、特定の環境に依存されず、ロックインされるリスクも低いのが特徴です。
NSX ALB は、あらゆる環境で動かすことができるマルチクラウド対応のロードバランサーです。オンプレミス（vSphere や NSX-T など）やパブリッククラウド（AWS や Azure、GCP など）、さらにパブリッククラウド上に構築したVMware環境(VMC on AWS や AVS、OCVS、GCVE など)におけるアプリケーションデリバリーを抽象化することで、個々の環境ごとの構成やポリシーの違いを吸収し、同じ方法で LB や仮想サービスをデプロイすることができます。たとえば、オンプレミスの vSphere 環境にデプロイしていた LB について、同じ方法で AWS 環境にデプロイしたり、移行したりすることができるのです。
まとめ
K8s が多くのユーザに支持されてきた先進的なプラットフォームであることは間違いありません。そして NSX ALB には K8s との共通点が多く、先進的な機能を提供できることをご理解いただけたと思います。本ブログでは触れていませんが、アプリケーション開発者や DevOps/SRE 担当者が K8s 環境で Ingress/Service(type: Load Balancer)のマニフェストを定義することで、NSX ALB に必要な仮想サービス/プールを自動設定するような連携が可能です。アプリケーションデリバリーをセルフサービス化することで、従来のオペレーションを変革することができます。ぜひ、NSX ALB をお試しください。
～ NSX ALB 関連ブログ ～
〜お知らせ〜
※VMwareでは、各種製品をクラウド上でご評価いただくHands-on Labs（HOL） という仕組みを無償でご提供しています。
今回ご紹介した各種ソリューションへの最初の一歩の入り口としてぜひご活用ください。
おすすめのHOLメニューはこちらから
- VMware NSX Advanced Load Balancer (Avi Networks) – Getting Started (HOL-2337-01-NET)
- VMware NSX Advanced Load Balancer (Avi Networks) – Global Server Load Balancing (HOL-2337-02-NET)
- VMware NSX Advanced Load Balancer (Avi Networks) Web Application Security (HOL-2337-03-NET)
- VMware NSX Advanced Load Balancer (Avi Networks) with Kubernetes (HOL-2337-04-NET)
- Migrate to NSX Advanced Load Balancer (Avi) using the Migration Toolkit (HOL-2337-05-NET)
