- ライター：奈良 昌紀
- 通信事業者のデータセンターにおいてネットワーク・サーバー運用を経験した後、ネットワンシステムズに入社。帯域制御やWAN高速化製品担当を経て、2008年から仮想化関連製品を担当。現在は主にクラウド、仮想インフラの管理、自動化、ネットワーク仮想化を担当。
目次
VMware vSphere with Tanzuとは
以前vSphere 7の新機能としてご紹介させていただいたvSphere with Kubernetes (Project Pacific)はVMware Cloud Foundation(VCF)上での利用が前提となっており、VMware NSX-T Data Centerが必須でしたが、今回リリースされたvSphere 7 Update 1からは、vSphere with TanzuとしてVCF/NSX-Tがない環境でもvSphereの分散仮想スイッチ環境でTanzu Kubernetes Gridが利用可能になりました。ただし、このモードではSupervisor Clusterで提供される機能(サービス)はTanzu Kubernetes Gridに限定されており、仮想マシンをコンテナのように扱うことができるvSphere Pod機能は利用することはできないのでご注意ください。
従来のvSphere with Kubernetesでは、NSX-Tが提供する論理スイッチ、論理ルーター、ロードバランサーを利用してvSphereクラスターをSupervisor Clusterとして構成していましたが、vSphere 7 Update 1で今回サポートされたvSphere Server Networkモードは、vSphereの分散仮想スイッチ機能と仮想アプライアンスとして提供されるLoad Balancer(HAProxy)を組み合わせてSupervisor Cluster向けのコントロールプレーン(Master)を構成し、Tanzu Kubernetes Gridを利用するためのCluster APIをホストします。Supervisor ClusterにはMasterのみが存在し、ESXiホストはNodeとして登録されません。
Supervisor Clusterを構成するには、従来のvSphereと同じくワークロード管理画面のウィザードを利用する必要があります。これまでのワークロード管理のウィザード画面にネットワークスタックを選択するオプションが追加されており、「NSX-T」と「vCenter Server Network」が選択可能になっています。(NSX-Tが構成されていない環境ではNSX-Tを選択することができません)
vCenter Server Networkを利用したワークロード管理機能を有効化する前に、vSphere with Tanzu Quick Start Guide Introductionを参考にネットワーク構成を決定し、HAProxyを仮想マシンとしてデプロイしておく必要があります。HAProxyはManagementとWorkloadの２種類のネットワークに接続する必要があり、ManagementネットワークはvCenterやSupervisor Control VMの管理用の通信に利用され、WorkloadネットワークはTanzu Kubernetes Gridが作成するKubernetesクラスターの各NodeのIPアドレスや、各種サービス向けのロードバランシング用のVIPに利用されます。
vCenter Server Networkを選択すると、ロードバランサメニューで、デプロイしたHAProxyに関する情報や、Workloadネットワークの中で、ロードバランシング用のVIPとして利用するネットワークの範囲を指定します。ワークロード管理が、HAProxyのData Plane APIを利用してコントロールプレーン用のロードバランサーが構成されます。
ワークロード管理の構成が完了すると、vSphere Client上でネームスペースを作成し、kubectlコマンドでSupervisor Clusterにログインすることが可能になります。
$ kubectl vsphere login --server=10.44.59.51 \
--insecure-skip-tls-verify --tanzu-kubernetes-cluster-namespace ns1 $ kubectl config use-context ns1 Switched to context "ns1". $ kubectl get node NAME STATUS ROLES AGE VERSION 422a669d7678999f2ee9a847e2219ec5 Ready master 150m v1.18.2-6+38ac483e736488 422a7d807403ec1f9073e86c3c599851 Ready master 159m v1.18.2-6+38ac483e736488 422a819cf2461d208936bf1c43886288 Ready master 151m v1.18.2-6+38ac483e736488
Guest Clusterのネットワーク機能
Supervisor Cluster上にGuest Clusterとして作成されるTanzu Kubernetes Cluster(TKC)にも新たな機能が追加されています。これまではCNIとしてCalicoしか利用できませんでしたが、新たにAntreaを利用することが可能になりました。AntreaはOpen vSwitchをデータプレーンとして利用するオープンソースのCNIです。Network Policyに対応しており設定されたポリシーはiptablesではなくOpen vSwitchのOpenFlowテーブルとして構成されます。Antreaを利用するには、以下のようなマニフェストを利用します。(デフォルトCNIもAntreaに変更されているため、cniを指定しない場合もAntreaが利用されます。)
apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
name: tkc01
spec:
distribution:
version: v1.18
settings:
network:
cni:
name: antrea
pods:
cidrBlocks:
- 193.0.2.0/16
services:
cidrBlocks:
- 195.51.100.0/12
topology:
controlPlane:
class: guaranteed-small
count: 3
storageClass: k8s-storage
workers:
class: guaranteed-small
count: 3
storageClass: k8s-storage
HAProxyはGuest ClusterのMasterノードに対する負荷分散も提供するため、Guest Clusterを複数Master構成とすることが可能です。また、作成したGuest Cluster上でtype=LoadBalancerとしてServiceを作成した場合もSupervisor Clusterのvmware-system-lbapi-controller-managerがHAProxyのData Plane API経由でロードバランサーを構成し、HAProxy経由でGuest Cluster上のPodを公開することが可能です。Kubernetesにおいて一般的に、アプリケーションをクラスター外部に公開するにはIngress Controllerを利用します。Contour Ingress ControllerはオープンソースのIngress Controllerで、Envoyを内部で利用しています。Guest ClusterにContour Ingress Controllerをtype=LoadBalancerとして構成し、Guest Cluster上でIngressリソースを作成することで、HAProxy経由でGuest Cluster内のPodにアクセスする事が可能になります。
$ kubectl get svc -n projectcontour NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE contour ClusterIP 195.62.190.2388001/TCP 107m envoy LoadBalancer 195.54.115.247 192.168.30.67 80:32156/TCP,443:32366/TCP 107m
まとめ
vSphere 7.0 U1よりサポートされた、vSphereネットワークスタックを利用したワークロード管理の構成により、これまで導入の敷居が高かったKubernetesクラスター機能の敷居が低くなります。導入に向けて検討を開始したいお客様は是非弊社担当営業までお問い合わせください。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
