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 を構築してみようと思います！