Cluster API と Tanzu Kubernetes Grid から VMware Cloud Director の KaaS まで

# Cluster API とは
　Cluster API は Kubernetes のサブプロジェクトで、Kuberenetes Cluster のプロビジョニングの自動化を図るツールです。

　Kubernetes は node 管理、container auto-healing など便利な container のオーケストレーション機能を提供してますが、Kubernetes Cluster 自体の構築はやや面倒です。kubeadm などのインストールツールもありますが、結局ノード（VMもしくはベアメタル）の準備、NWの準備などの手間がかかります。
　
　そこで Cluster API が登場し、Kuberenetes API で Kuberenetes を構築することを可能にしました。
　Cluster API は Kubernetes Custom Resource Definitions の機能を利用し、Cluster、Machine、MachineDeployment など Kubernetes cluster の構成要素を Kubernetes の kind として定義し、宣言形式で Kubernetes cluster を定義できるようにしました。

　さらに、各 VM ベンダー（AWS / Azure / vSphereなど）が Cluster API のプラグインとの連携によって、Cluster API が VM のプロビから、K8s Cluster 構成までの一連タスクを自動化できます。

　Cluster API の需要とアーキについて、[進藤さんのブログ「Kubernetes Cluster API – Part 1 –」](https://blog.shin.do/2019/09/kubernetes-cluster-api-part1/)はかなり参考になります。

# Cluster API と Tanzu Kubernetes Grid
　TKG は　Cluster API をもとに Cluster プロビジョニングとライフサイクル管理を実現しています。
　ただ、Cluster API の docs と [TKG のアーキ docs](https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.5/vmware-tanzu-kubernetes-grid-15/GUID-tkg-concepts.html) を比較してみれば、以下の2点の違いが分かります。

　**1. Bootstrap の位置付け** 
　   Cluster API の場合、Management Cluster の構成の流れとして、
        　① 手動で Bootstrap (docker/kind/k8s) を作り
　② Bootstrap に ClusterAPI および VM ベンダープラグインを入れることによって、Bootstrap を Management Cluster に「変換」
　③ Management Cluster（元Bootstrap）から Workload Cluster を払い出す

　TKG の場合、デプロイ時に同じく Bootstrap の準備が必要です。流れとして、
　① Bootstrap に docker を入れる
　② tanzu init コマンドで Management Cluster を初期化する。裏で、Bootstrap に Cluster API はもちろん入れますし、さらに、Bootstrap を利用して、Management Cluster を別の Cluster として払い出し、払い出された Cluster に Cluster API も入れておく。
　③ Management Cluster（Bootstrap とは違うもの）から Workload Cluster を払い出す
　
　この三段構成（Bootstrap -> Management Cluster -> Workload Cluster）のメリットとして、
　1) Management Cluster の cluster 構成（multi node Control Plane / Workernode）が容易にできる
　2) 同じ環境に複数な Management Cluster が必要な場合（例えばテナントで分けたい）、共通の Bootstrap で実現可能
　3) Management Cluster のライフサイクル管理も Cluster API で実現可能

　**2. tanzu cli**
　仕組み上の違いではないですが、TKG は tanzu cli が提供されて、やや面倒な Cluster API 構築手順および Cluster ライフサイクル管理などを CLI コマンドで隠蔽してくれます。管理者として楽になります。

# Cluster API と VMware Cloud Director
　VMware Cloud Director は VMware が Service Provider さん向けに提供しているサービスプラットフォームを構築する製品です。
　十数年の歴史があって、vSphere ベースでの IaaS プラットフォームに関してはかなり成熟度が高いです。
　
　ただ、近年で、AWS / Azure / GCP などの Hyper-scaler をはじめ、CaaS / PaaS / SaaS など仮想マシン以外の付加価値が提供できるサービスがかなり豊富になってきています。Service Provider にとっても、IaaS のみでは未来が明るくないことが明らかになっていますので、より多種類のサービスの提供を模索しています。
　その中で、IaaS と関連性が高いのはやはり K8s as a Service であり、そして、それを基礎に CaaS / MEC / CICD などの部分を積み上げていくのはいいでしょう。
　
　VMware Cloud Director もその動向とニーズに応じて、積極的に KaaS に関連する部分を強化しています。
　2020年11月から [VCD 10.2 が vSphere with Tanzu と連携](https://blogs.vmware.com/cloudprovider/2020/11/vmware-cloud-director-10-2-integrates-with-vmware-tanzu.html)できるようになりまして、vSphere with Tanzu の TKG Service の仕組みを利用して、テナントごとに TKC をデプロイできるようになりました。
　
　ただ、vSphere with Tanzu はマルチテナントのシナリオにおいて、いろいろリミテーションがあります。よりマルチテナンシのある TKG multicloud のサポートはようやく [VCD 10.3.2 + CSE 3.1.1 で実現できる](https://blogs.vmware.com/cloudprovider/2021/11/kubernetes-as-a-service-with-vmware-cloud-director-and-container-service-extension-3-1-1.html)ようになりました。
　
　マルチテナントのシナリオでの TKGS と TKGｍ の比較および VCD 10.3.2 + CSE 3.1.1 の構築ガイドは以前投稿した[「VMware Cloud Director 10.3 テナントに TKGm Cluster をデプロイしてみる」](https://qiita.com/cchen/items/0532932ea3cc3d5eb22c)を参照してください。

　流れとして TKGm の方に傾けつつあります。但し、CSE 3.1.1 の TKGｍ の詳細を確認してみると分かりますが、まだまだ制限が多くて、Tanzu の TKGm とはまだ距離があります。その最重要な違いとして、CSE 3.1.1 はまだ Cluster API をサポートしていないです。なので、Multi Node Control Plane / Cluster Upgrade / Tanzu CLI などサービス運用として重要な機能が欠けています。

　でも VCD の進化がかなり早くて、最新の CSE 3.1.2 ではすでに Cluster API がサポートできるようになりました。
　さらに VCD と Cluster API の掛け橋である [CAPVCD の初期バージョン](https://github.com/vmware/cluster-api-provider-cloud-director/blob/0.5.0/README.md)もリリースされました。

　次回から CAPVCD を構築してみようと思います！