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 –」はかなり参考になります。

Cluster API と Tanzu Kubernetes Grid

　TKG は　Cluster API をもとに Cluster プロビジョニングとライフサイクル管理を実現しています。
　ただ、Cluster API の docs と TKG のアーキ docs を比較してみれば、以下の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 と連携できるようになりまして、vSphere with Tanzu の TKG Service の仕組みを利用して、テナントごとに TKC をデプロイできるようになりました。
　
　ただ、vSphere with Tanzu はマルチテナントのシナリオにおいて、いろいろリミテーションがあります。よりマルチテナンシのある TKG multicloud のサポートはようやく VCD 10.3.2 + CSE 3.1.1 で実現できるようになりました。
　
　マルチテナントのシナリオでの TKGS と TKGｍの比較および VCD 10.3.2 + CSE 3.1.1 の構築ガイドは以前投稿した「VMware Cloud Director 10.3 テナントに TKGm Cluster をデプロイしてみる」を参照してください。

　流れとして 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 の初期バージョンもリリースされました。

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