目次
きっかけ
実験したいことが出てきてしまい、自宅で Kubernetes を触りたくなりました。
これまで Kubernetes を触る場合は Google Kubernetes Engine（GKE）ばかりを使っていたのですが、 今回実験したいのは IoT の世界でいうエッジ側の話なので、できればオンプレミス相当の Kuberentes クラスタが欲しいところです。
そんなわけで、これ幸いと自宅の vSphere 環境で Cluster API を叩いてゲストクラスタを作ることにしました。Cluster API は、2019 年に VMware から発表された VMware Tanzu や Project Pacific の実装でも使われているそうで、そういう意味でも興味のあるところです。
VMware Tanzu や Project Pacific は、エントリの本筋ではないので細かくは書きませんが、めっちゃ雑に書くと、vSphere と Kubernetes がイケてる感じにくっついたヤツです。
Cluster API とは
Cluster API は、Kubernetes っぽいお作法で Kubernetes クラスタそれ自体を管理できる仕組みです。Kubernetes の SIG のプロジェクト として開発が進められています。
最新バージョンは 2019 年 9 月にリリースされた v1alpha2 で、現在は v1alpha3 が開発中です。バージョン名を見てもわかる通り、現段階ではいわゆるアルファ版ですし、ドキュメントでも『プロトタイプだよ』『どんどん変わるからね』と記載されているので、ごりごりに使い込むのはまだちょっと待ったほうがよさそうですね。
Cluster API is still in a prototype stage while we get feedback on the API types themselves. All of the code here is to experiment with the API and demo its abilities, in order to drive more technical feedback to the API design. Because of this, all of the codebase is rapidly changing.
https://github.com/kubernetes-sigs/cluster-api/blob/master/README.md
Kubernetes クラスタを構成するノードは、多くの場合は仮想マシンです。その仮想マシンは、パブリッククラウド上だったりオンプレミスの vSphere 上や OpenStack 上だったりで動いているわけですが、Cluster API では、そうしたプラットフォームごとに Provider なる実装が用意されており、環境差異を抽象化してくれます。これにより、異なる環境でも同一の操作感で Kubernetes クラスタを管理できます。
今回は vSphere 環境上の Kubernetes クラスタの構成が目的なので、vSphere 用の Provider を使って作業します。
構成要素と構成の流れ
最終的には、いわゆる Kubernetes らしく業務や開発で様々なアプリケーションを動作させることになる Kubernetes クラスタと、それらを管理するためだけの Kubernetes クラスタ、の大きく二種類の Kubernetes クラスタができあがります。
前者がゲストクラスタ（ワークロードクラスタ）、後者がマネジメントクラスタなどと呼ばれるようです。Cluster API はこのうちのマネジメントクラスタに組み込まれており、この Cluster API によってゲストクラスタのライフサイクルを簡単に管理できるということです。
もう少し具体的にいえば、例えば Kubernetes クラスタ自体は cluster リソースとして、あるいはそれを構成するノードの仮想マシンは machine リソースとして扱えるようになり、通常の pod リソースや deployment リソースと同じように、自分以外の Kubernetes クラスタの構成が管理できるということです。
構築の観点では、つまりマネジメントクラスタができさえすれば Cluster API 環境はほぼ完成と言えるわけですが、実際にはマネジメントクラスタ自身もマネジメントクラスタで管理するため、手順はちょっと複雑です。
マネジメントクラスタの作り方はいくつかあるようですが、今回は vSphere 用 Provider の Getting Started の通り、以下のような流れで構成を進めます。
- 作業用端末（図中 Workstation）に Docker や kuberctl など必要なモノを揃えて、マニフェストファイルを生成する
- Docker 上に作業用の Kubernetes クラスタ（ブートストラップクラスタ）を作り、Cluster API を導入する
- 導入した Cluster API を使って、マニフェストファイルに従って本当のマネジメントクラスタを作る
- マネジメントクラスタに Cluster API 環境を移行（Pivoting）して、ブートストラップクラスタを消す
最終的なマネジメントクラスタを作るためにさらに別の Kubernetes クラスタ（ブートストラップクラスタ）が必要なあたりがわりとややこしいですが、そういうものみたいです。
ここまでできたら、Cluster API の本来の利用方法の通り、マニフェストファイルに従ってゲストクラスタを作ったり消したり拡張したり縮小したりできます。
構築の準備
前述した流れの通り、マネジメントクラスタを構築するには、ブートストラップクラスタが動作できる環境が必要です。また、マネジメントクラスタが動作する vSphere 環境でも、少し準備が必要です。
作業端末の整備
作業前提を整えます。作業用の端末は、ブートストラップクラスタの動作と、それを用いたマネジメントクラスタの構築ができる必要があり、このために、
が必要です。Windows でもおそらく動くとは思いますが、今回は作業用の Ubuntu 端末を別に用意して使っています。
Docker は適当に入れます。今回の端末は Ubuntu 19.10 なので、19.04 用のバイナリを無理やり入れます。
$ sudo apt update
$ sudo apt install apt-transport-https ca-certificates curl software-properties-common
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu disco stable"
$ sudo apt update
$ sudo apt install docker-ce docker-ce-cli containerd.io
$ sudo usermod -aG docker ${USER}
clusterctl と Kind、kubectl はバイナリをダウンロードするだけです。
$ curl -Lo ./clusterctl https://github.com/kubernetes-sigs/cluster-api/releases/download/v0.2.9/clusterctl-darwin-amd64
$ chmod +x ./clusterctl
$ mv ./clusterctl ~/bin
$ curl -Lo ./kind https://github.com/kubernetes-sigs/kind/releases/download/v0.6.1/kind-$(uname)-amd64
$ chmod +x ./kind
$ mv ./kind ~/bin
$ curl -Lo ./kubectl https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl
$ chmod +x ./kubectl
$ mv ./kubectl ~/bin
が、clusterctl は v1alpha2 の時点ですでに DEPRECATED 扱いでした。
しかしながら代替手段がよくわかっていないし、Cluster API のドキュメント 通りではなにやらうまく動かない（kubeconfig 用の secret ができあがらない）ので、v1alpha3 が出て情報が増えてきたらどうにかします。
あと、Kind の最新リリースは現時点で 0.7.0 ですが、それを使うと後続の作業がうまく動かなかったので、ひとつ古い 0.6.1 を指定しています。
vSphere 環境での OVA テンプレートの展開
vSphere 環境用の Provider を使って Kubernetes クラスタを作った場合、最終的にできあがる Kubernetes のノードは vSphere 環境上の仮想マシンです。
この仮想マシンの元になるテンプレートが用意されているので、これをあらかじめデプロイして、テンプレートに変換しておきます。
Ubuntu 版と CentOS 版がありますが、今回は Ubuntu 版の最新の 1.16.3 を使いました。
その他のイメージのリンクは リポジトリに一覧 されています。
vSphere 環境でのフォルダとリソースプールの作成
マネジメントクラスタとゲストクラスタを入れるフォルダ（仮想マシンインベントリのヤツ）とリソースプールを作ります。入れ物としてただあればよいので、設定は適当で大丈夫です。
マネジメントクラスタの構成
では、実際の構築を進めます。ブートストラップクラスタを作り、そこで Cluster API を動作させて、それを通じて最終的なマネジメントクラスタを作ります。
はじめに、構成に必要な環境変数を、envvars.txt にまとめて定義します。内容はそれぞれの環境に依存するので書き換えが必要です。
$ cat envvars.txt
# vCenter config/credentials
export VSPHERE_SERVER='192.168.0.201' # (required) The vCenter server IP or FQDN
export VSPHERE_USERNAME='administrator@vsphere.local' # (required) The username used to access the remote vSphere endpoint
export VSPHERE_PASSWORD='my-secure-password' # (required) The password used to access the remote vSphere endpoint
# vSphere deployment configs
export VSPHERE_DATACENTER='kuro-dc01' # (required) The vSphere datacenter to deploy the management cluster on
export VSPHERE_DATASTORE='nfs-ds01' # (required) The vSphere datastore to deploy the management cluster on
export VSPHERE_NETWORK='ext-vm' # (required) The VM network to deploy the management cluster on
export VSPHERE_RESOURCE_POOL='k8s' # (required) The vSphere resource pool for your VMs
export VSPHERE_FOLDER='k8s' # (optional) The VM folder for your VMs, defaults to the root vSphere folder if not set.
export VSPHERE_TEMPLATE='template_ubuntu-1804-kube-v1.16.3' # (required) The VM template to use for your management cluster.
export VSPHERE_DISK_GIB='50' # (optional) The VM Disk size in GB, defaults to 20 if not set
export VSPHERE_NUM_CPUS='2' # (optional) The # of CPUs for control plane nodes in your management cluster, defaults to 2 if not set
export VSPHERE_MEM_MIB='2048' # (optional) The memory (in MiB) for control plane nodes in your management cluster, defaults to 2048 if not set
export SSH_AUTHORIZED_KEY='ssh-rsa AAAAB...6Ix0= kuro@kuro-ubuntu01' # (optional) The public ssh authorized key on all machines in this cluster
# Kubernetes configs
export KUBERNETES_VERSION='1.16.3' # (optional) The Kubernetes version to use, defaults to 1.16.2
export SERVICE_CIDR='100.64.0.0/13' # (optional) The service CIDR of the management cluster, defaults to "100.64.0.0/13"
export CLUSTER_CIDR='100.96.0.0/11' # (optional) The cluster CIDR of the management cluster, defaults to "100.96.0.0/11"
export SERVICE_DOMAIN='cluster.local' # (optional) The k8s service domain of the management cluster, defaults to "cluster.local"
続けて、このファイルを使って、マネジメントクラスタの構成を定義したマニフェストファイル群を生成します。この作業のための専用のコンテナイメージが用意されているので、これに食べさせます。
$ docker run --rm \
-v "$(pwd):/out" \
-v "$(pwd)/envvars.txt":/envvars.txt:ro \
gcr.io/cluster-api-provider-vsphere/release/manifests:latest \
-c management-cluster
Checking 192.168.0.201 for vSphere version
Detected vSphere version 6.7.1
Generated ./out/management-cluster/addons.yaml
Generated ./out/management-cluster/cluster.yaml
Generated ./out/management-cluster/controlplane.yaml
Generated ./out/management-cluster/machinedeployment.yaml
Generated /build/examples/pre-67u3/provider-components/provider-components-cluster-api.yaml
Generated /build/examples/pre-67u3/provider-components/provider-components-kubeadm.yaml
Generated /build/examples/pre-67u3/provider-components/provider-components-vsphere.yaml
Generated ./out/management-cluster/provider-components.yaml
WARNING: ./out/management-cluster/provider-components.yaml includes vSphere credentials
これで、./out/management-cluster 配下にマニフェストファイル群が出力されました。
$ ls -l ./out/management-cluster/
total 268
-rw-r--r-- 1 kuro kuro 19656 Feb 11 08:54 addons.yaml
-rw-r--r-- 1 kuro kuro 933 Feb 11 08:54 cluster.yaml
-rw-r--r-- 1 kuro kuro 3649 Feb 11 08:54 controlplane.yaml
-rw-r--r-- 1 kuro kuro 2576 Feb 11 08:54 machinedeployment.yaml
-rw-r--r-- 1 kuro kuro 240747 Feb 11 08:54 provider-components.yaml
で、あとはこれらを clusterctl に食べさせるだけです。
$ clusterctl create cluster \
--bootstrap-type kind \
--bootstrap-flags name=management-cluster \
--cluster ./out/management-cluster/cluster.yaml \
--machines ./out/management-cluster/controlplane.yaml \
--provider-components ./out/management-cluster/provider-components.yaml \
--addon-components ./out/management-cluster/addons.yaml \
--kubeconfig-out ./out/management-cluster/kubeconfig
NOTICE: clusterctl has been deprecated in v1alpha2 and will be removed in a future version.
I0211 08:55:09.414116 2332 createbootstrapcluster.go:27] Preparing bootstrap cluster
I0211 08:55:59.745617 2332 clusterdeployer.go:82] Applying Cluster API stack to bootstrap cluster
...
I0211 08:56:02.302440 2332 clusterdeployer.go:87] Provisioning target cluster via bootstrap cluster
...
I0211 08:56:02.454960 2332 applymachines.go:46] Creating machines in namespace "default"
I0211 08:59:12.512879 2332 clusterdeployer.go:105] Creating target cluster
...
I0211 08:59:13.394821 2332 clusterdeployer.go:123] Pivoting Cluster API stack to target cluster
...
I0211 08:59:56.665878 2332 clusterdeployer.go:164] Done provisioning cluster. You can now access your cluster with kubectl --kubeconfig ./out/management-cluster/kubeconfig
I0211 08:59:56.666586 2332 createbootstrapcluster.go:36] Cleaning up bootstrap cluster.
主要なログだけ抜粋していますが、これだけで、
- Kind を使って、作業端末の Docker 上にブートストラップクラスタを構築する
- ブートストラップクラスタに Cluster API を導入する
- その Cluster API を使って、マニフェスト通りに vSphere 環境上にマネジメントクラスタをデプロイする
- 仮想マシンをテンプレートからデプロイする
- 仮想マシンをクラスタのコントロールプレーンとして構成する
- ブートストラップクラスタ上に構成していた Cluster API の環境をマネジメントクラスタに移行する（Pivoting）
が実行され、最終的な形でマネジメントクラスタができあがります。
完成したマネジメントクラスタへの接続に必要な情報は、./out/management-cluster/kubeconfig に保存されています。kubectl の設定ファイルをこれに切り替えてコマンドを実行すると、マネジメントクラスタ自体の情報や、machine リソースとしての自分自身の存在が確認できます。
$ export KUBECONFIG="$(pwd)/out/management-cluster/kubeconfig"
$ kubectl cluster-info
Kubernetes master is running at https://192.168.0.27:6443
KubeDNS is running at https://192.168.0.27:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
$ kubectl get machines
NAME PROVIDERID PHASE
management-cluster-controlplane-0 vsphere://42069f1f-21ac-45be-69b9-e94702d3062b running
vSphere 環境では、仮想マシン management-cluster-controlplane-0 の存在が確認できるはずです。
ここまででマネジメントクラスタができたので、Cluster API 環境は完成です。あとは好きなように Cluster API を使ってゲストクラスタを作ったり消したり拡張したり縮小したりできます。
ゲストクラスタの構成
実際に、Cluster API を使って、新しくゲストクラスタを構成します。
Cluster API は、Kubernetes のお作法で Kubernetes クラスタ自体が管理できるので、つまり、クラスタの構成情報も、Pod や Deployment などほかの Kubernetes リソースと同じように、マニフェストファイルで定義されます。よって、ゲストクラスタを作るには、その構成を定義したマニフェストファイルが必要です。
本来はきちんと中身を書くべきっぽいですが、マネジメントクラスタ用のマニフェストファイルを作ったのと同じ方法でゲストクラスタ用のマニフェストファイル群も作れるので、ここではそれを利用します。
$ docker run --rm \
-v "$(pwd):/out" \
-v "$(pwd)/envvars.txt":/envvars.txt:ro \
gcr.io/cluster-api-provider-vsphere/release/manifests:latest \
-c workload-cluster-1
Checking 192.168.0.201 for vSphere version
Detected vSphere version 6.7.1
Generated ./out/workload-cluster-1/addons.yaml
Generated ./out/workload-cluster-1/cluster.yaml
Generated ./out/workload-cluster-1/controlplane.yaml
Generated ./out/workload-cluster-1/machinedeployment.yaml
Generated /build/examples/pre-67u3/provider-components/provider-components-cluster-api.yaml
Generated /build/examples/pre-67u3/provider-components/provider-components-kubeadm.yaml
Generated /build/examples/pre-67u3/provider-components/provider-components-vsphere.yaml
Generated ./out/workload-cluster-1/provider-components.yaml
WARNING: ./out/workload-cluster-1/provider-components.yaml includes vSphere credentials
ゲストクラスタの定義と、コントロールプレーンの定義が、
./out/workload-cluster-1/cluster.yaml./out/workload-cluster-1/controlplane.yaml
に含まれます。また、ワーカノードの定義は、
./out/workload-cluster-1/machinedeployment.yaml
です。自分でマニフェストをいじる場合は、この辺をどうにかする必要があるということですね。
実際にデプロイするには、kubectl の接続先をマネジメントクラスタに切り替えてから、先の 3 つのファイルをマネジメントクラスタに突っ込みます。
$ export KUBECONFIG="$(pwd)/out/management-cluster/kubeconfig"
$ kubectl apply -f ./out/workload-cluster-1/cluster.yaml
cluster.cluster.x-k8s.io/workload-cluster-1 created
vspherecluster.infrastructure.cluster.x-k8s.io/workload-cluster-1 created
$ kubectl apply -f ./out/workload-cluster-1/controlplane.yaml
kubeadmconfig.bootstrap.cluster.x-k8s.io/workload-cluster-1-controlplane-0 created
machine.cluster.x-k8s.io/workload-cluster-1-controlplane-0 created
vspheremachine.infrastructure.cluster.x-k8s.io/workload-cluster-1-controlplane-0 created
$ kubectl apply -f ./out/workload-cluster-1/machinedeployment.yaml
kubeadmconfigtemplate.bootstrap.cluster.x-k8s.io/workload-cluster-1-md-0 created
machinedeployment.cluster.x-k8s.io/workload-cluster-1-md-0 created
vspheremachinetemplate.infrastructure.cluster.x-k8s.io/workload-cluster-1-md-0 created
この作業によって、まずコントロールプレーンがデプロイされ、続けてワーカノードがデプロイされます。vSphere 環境でも順次仮想マシンがデプロイされパワーオンされていく様子が観察できるでしょう。
デプロイが完了すると、以下のように、マネジメントクラスタが Kubernetes クラスタ自体を cluster リソースや machine リソースとして管理できている状態になります。
$ kubectl get clusters
NAME PHASE
management-cluster provisioned
workload-cluster-1 provisioned
$ kubectl get machines
NAME PROVIDERID PHASE
management-cluster-controlplane-0 vsphere://42069f1f-21ac-45be-69b9-e94702d3062b running
workload-cluster-1-controlplane-0 vsphere://4206f835-1e8d-3473-943f-0e2cc4b04319 running
workload-cluster-1-md-0-78469c8cf9-fr22j vsphere://4206661b-9be8-cede-eeee-68ddbbdeb872 running
workload-cluster-1-md-0-78469c8cf9-jnqnw vsphere://4206861f-e133-4a53-2008-3346c81ed8e3 running
ゲストクラスタへの接続情報は、secret リソースとして保持されています。これを kubeconfig として保存することで、kubectl でゲストクラスタに接続できるようになります。
$ kubectl get secrets
NAME TYPE DATA AGE
...
workload-cluster-1-kubeconfig Opaque 1
...
$ kubectl get secret workload-cluster-1-kubeconfig -o=jsonpath='{.data.value}' | \
{ base64 -d 2>/dev/null || base64 -D; } >./out/workload-cluster-1/kubeconfig
実際に接続すれば、当たり前ですがゲストクラスタやノードの情報が確認できます。
$ export KUBECONFIG="$(pwd)/out/workload-cluster-1/kubeconfig"
$ kubectl cluster-info
Kubernetes master is running at https://192.168.0.28:6443
KubeDNS is running at https://192.168.0.28:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
workload-cluster-1-controlplane-0 NotReady master 3m14s v1.16.3
workload-cluster-1-md-0-78469c8cf9-fr22j NotReady <none> 90s v1.16.3
表示されている通り、この段階ではノードは NotReady です。これは CNI プラグインが構成されていないからで、雑にいえば、この Kubernetes クラスタ内のコンテナネットワークに使う実装を明示する必要があるということです。
コンテナネットワークの実装には Flannel とか Calico とかいろいろありますが、ゲストクラスタ用マニフェスト群の中にある ./out/workload-cluster-1/addons.yaml で Calico を構成できるので、今回はこれを使います。
適用してしばらく待つと、ノードが Ready になり、ゲストクラスタの完成です。
$ kubectl apply -f ./out/workload-cluster-1/addons.yaml
configmap/calico-config created
...
serviceaccount/calico-kube-controllers created
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
workload-cluster-1-controlplane-0 Ready master 4m22s v1.16.3
workload-cluster-1-md-0-78469c8cf9-fr22j Ready <none> 2m38s v1.16.3
ゲストクラスタの拡張
Kubernetes って、アプリケーションのスケールアウトが kubectl scale だけでできてめっちゃラクですよね。
というのと同じノリで、ゲストクラスタもめっちゃラクにスケールアウトできるので、やってみましょう。
ノードの管理はマネジメントクラスタから行うので、接続先を切り替えて、machinedeployment をスケールさせます。
$ export KUBECONFIG="$(pwd)/out/management-cluster/kubeconfig"
$ kubectl scale md workload-cluster-1-md-0 --replicas=3
machinedeployment.cluster.x-k8s.io/workload-cluster-1-md-0 scaled
$ kubectl get machines
NAME PROVIDERID PHASE
management-cluster-controlplane-0 vsphere://42069f1f-21ac-45be-69b9-e94702d3062b running
workload-cluster-1-controlplane-0 vsphere://4206f835-1e8d-3473-943f-0e2cc4b04319 running
workload-cluster-1-md-0-78469c8cf9-fr22j vsphere://4206661b-9be8-cede-eeee-68ddbbdeb872 running
workload-cluster-1-md-0-78469c8cf9-jnqnw vsphere://4206861f-e133-4a53-2008-3346c81ed8e3 running
workload-cluster-1-md-0-78469c8cf9-nxvht vsphere://4206ec88-6607-1699-8051-e1447a448983 running
これだけでノードが 3 台になりました。仮想マシンも増えています。
簡単ですね。
ゲストクラスタのロードバランサの構成
おまけです。
vSphere が組み込みでロードバランサを持っていないから仕方ないですが、 現状、Cluster API でゲストクラスタを構成するときには、ロードバランサは構成できません。
このままだと、ゲストクラスタで kubectl expose で --type=LoadBalancer しても EXTERNAL-IP が永遠に pending のままで、外部に公開できません。
GitHub でも issue があります し、めっちゃがんばると多分オンプレミス環境でも NSX-T とかでどうにかできるとは思いますが、その域に達していないので、とりあえず MetalLB を突っ込んで解決します。
MetalLB とは
ロードバランサが使えずにサービスを外部に公開できない、というのは、ベアメタル環境で Kubernetes を使うときによく遭遇する話題のようで、そういうヒト向けの仮想ロードバランサの実装です。
実際には正しい負荷分散にはならないみたいですが、ものすごく気軽に使えますし、アクセス経路の提供という意味では充分機能するので便利です。
MetalLB の構成と初期設定
公式のドキュメント に従います。インストール用のマニフェストファイルを突っ込んだあと、
$ kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.8.3/manifests/metallb.yaml
namespace/metallb-system created
...
deployment.apps/controller created
ドキュメントの Layer 2 Configuration の通りに設定用マニフェストファイルを作って突っ込みます。IP アドレスのレンジは任意で修正します。
$ cat metallb.yaml
apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
address-pools:
- name: default
protocol: layer2
addresses:
- 192.168.0.50-192.168.0.99
$ kubectl apply -f metallb.yaml
configmap/config created
これだけです。
動作確認
Kubernetes のチュートリアルのヤツ を作って、
$ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
deployment.apps/hello-world created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-world-f9b447754-6rrt9 1/1 Running 0 68s
hello-world-f9b447754-b6psq 1/1 Running 0 68s
hello-world-f9b447754-ml5w8 1/1 Running 0 68s
hello-world-f9b447754-nprbn 1/1 Running 0 68s
hello-world-f9b447754-wpgv5 1/1 Running 0 68s
expose します。
$ kubectl expose deployment hello-world --type=LoadBalancer
service/hello-world exposed
$ kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-world LoadBalancer 100.69.189.221 192.168.0.50 8080:32015/TCP 6s
kubernetes ClusterIP 100.64.0.1 <none> 443/TCP 4h55m
$ kubectl describe services hello-world
...
Endpoints: 100.113.190.67:8080,100.113.190.68:8080,100.97.109.3:8080 + 2 more...
...
EXTERNAL-IP に MetalLB で設定したレンジの IP アドレスが振られていますし、エンドポイントも 5 つです。
実際にこの IP アドレスにアクセスすると、正しく表示が返ってきます。無事に動いているようです。
$ curl http://192.168.0.50:8080/
Hello Kubernetes!
まとめ
vSphere 環境で Cluster API を使って Kubernetes クラスタを管理できる状態を整えました。
最初の作業はちょっとだけ手間ですが、いちどできてしまうとスケールも相当楽なので使いやすそうです。ロードバランサ周りが NSX-T などふくめいい感じにできるようになってくると、活用の幅も広がりそうですね。
VMware Tanzu や Project Pacific でも Kubernetes クラスタのライフサイクル管理は謳われているので、この手の作業が導入作業も含めて GUI や API 経由でポチポチ簡単にできるようになるのだろうと勝手に思っています。GA になったら触ってみます。
