さて、13日目で親ガメ(Bootstrapマシン)をデプロイし、14日目で子ガメ(Managementクラスタ)をデプロイしてきました。本日は、いよいよ孫ガメ(Tanzu Kubernetes Cluster)をデプロイしたいと思います！

#Tanzu Kubernetes Cluster (TKC)
まず、毎回正式名称を書くのも大変なので、今後はTKCと呼ばせていただきます。
ここで疑問に思うのは、「なんでわざわざManagementクラスタとかを事前にインストールしたの？普通にOSS版のKubernetesとkubeadmだけをインストールした方が速いんだけど・・・」と、思うかもしれません。仰る通り、一つのKubernetesクラスタを作るだけなら、凄く遠回りなやり方です。でも、あなたの組織内で、複数のKubernetesクラスタを構築したいようであれば、TKGの利用をオススメします。そう、TKGは子ガメをデプロイしてからが凄いんです！メリットは、主にこの２つです。

爆速K8sクラスタ(TKC)構築
CNI(Container Network Interface)やCSI(Container Storage Interface)などの必要なものが、予め統合されている（OSS版K8sは、自前で別途インストールが必要）

#TKCのデプロイ
実践するのが早いでしょう。さっそくコマンドを叩いてみます。

踏み台

$ tkg create cluster my-cluster --plan dev --vsphere-controlplane-endpoint 192.168.5.52
# (コマンドは上記の1行だけ！以下、数行ログが出力されるが省略)
Workload cluster 'my-cluster' created

$\huge{これだけです。}$
どうしてもこれを強調したくて、Qiitaで使えるHTMLタグを調べちゃいましたｗ
開発者がK8sクラスタを建てる分には、EKSやGKEなど、他のK8sマネージド・サービスにも引けをとらないんじゃないでしょうか。コマンド実行後、2台のVMが生成され起動するのが、vCenterから確認できます。
私の環境だと、VMがない状態から4分強でKubernetesクラスタが出来ちゃいました。ネットワークやストレージの速度がエンタープライズ仕様であれば、2台だと3分位のイメージです。

次は、対象のTKCに接続するためのコンテキストを取得します

踏み台

# 現在のTKC一覧。接続したいクラスタ名を確認
$ tkg get cluster
 NAME        NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES
 my-cluster  default    running  1/1           1/1      v1.19.3+vmware.1  <none>

# 現在のコンテキストを確認。Managementクラスタに接続されていることが分かる
$ kubectl config current-context
tkg-mgmt-vsphere-20201213161849-admin@tkg-mgmt-vsphere-20201213161849

# 以下のコマンドで、クレデンシャル情報が~/.kube/configに格納される。
$ tkg get credentials my-cluster
Credentials of workload cluster 'my-cluster' have been saved
You can now access the cluster by running 'kubectl config use-context my-cluster-admin@my-cluster'

# 上記のコマンドを使って接続
$ kubectl config use-context my-cluster-admin@my-cluster
Switched to context "my-cluster-admin@my-cluster".

# CURRENTに*がついているのが現在のコンテキスト。my-clusterに接続されているのが分かる。
$ kubectl config get-contexts
CURRENT   NAME                                                                    CLUSTER                           AUTHINFO                                NAMESPACE
*         my-cluster-admin@my-cluster                                             my-cluster                        my-cluster-admin
          tkg-mgmt-vsphere-20201213161849-admin@tkg-mgmt-vsphere-20201213161849   tkg-mgmt-vsphere-20201213161849   tkg-mgmt-vsphere-20201213161849-admin

TKGはマルチクラスタ環境が前提のため、こういったK8sコンテキストの切り替えは、慣れる必要があるでしょう。次は、クラスタ情報を見てきます。

踏み台

$ kubectl get nodes -o wide
NAME                               STATUS   ROLES    AGE   VERSION            INTERNAL-IP     EXTERNAL-IP     OS-IMAGE                 KERNEL-VERSION   CONTAINER-RUNTIME
my-cluster-control-plane-pcrtb     Ready    master   44m   v1.19.3+vmware.1   192.168.5.103   192.168.5.103   VMware Photon OS/Linux   4.19.150-1.ph3   containerd://1.4.1
my-cluster-md-0-84c478775f-648zk   Ready    <none>   41m   v1.19.3+vmware.1   192.168.5.105   192.168.5.105   VMware Photon OS/Linux   4.19.150-1.ph3   containerd://1.4.1

$ kubectl get pods -A
NAMESPACE     NAME                                                     READY   STATUS    RESTARTS   AGE
kube-system   antrea-agent-4cx59                                       2/2     Running   0          45m
kube-system   antrea-agent-kkl9j                                       2/2     Running   0          43m
kube-system   antrea-controller-5d594c5cc7-rjv8q                       1/1     Running   0          45m
kube-system   coredns-5d6f7c958-s2hkn                                  1/1     Running   0          45m
kube-system   coredns-5d6f7c958-x5vs9                                  1/1     Running   0          45m
kube-system   etcd-my-cluster-control-plane-pcrtb                      1/1     Running   0          45m
kube-system   kube-apiserver-my-cluster-control-plane-pcrtb            1/1     Running   0          45m
kube-system   kube-controller-manager-my-cluster-control-plane-pcrtb   1/1     Running   0          45m
kube-system   kube-proxy-l4w8n                                         1/1     Running   0          43m
kube-system   kube-proxy-wz46t                                         1/1     Running   0          45m
kube-system   kube-scheduler-my-cluster-control-plane-pcrtb            1/1     Running   0          45m
kube-system   kube-vip-my-cluster-control-plane-pcrtb                  1/1     Running   0          45m
kube-system   vsphere-cloud-controller-manager-fbjwr                   1/1     Running   0          45m
kube-system   vsphere-csi-controller-5b6f54ccc5-tpftf                  5/5     Running   0          45m
kube-system   vsphere-csi-node-fkqzs                                   3/3     Running   0          43m
kube-system   vsphere-csi-node-qs8f8                                   3/3     Running   0          45m

Antreaやcsiのコントローラ、kube-vipが既にインストールされていることが分かります。
続いて、作成されたVMのリソース量も見てみましょう。ControlPlane。

続いて、Worker

どちらもまだAPPが稼働していないので、そんなにリソースを消費していないですね。一方、ストレージはちょこちょこ消費します。もっとSSDを搭載しておけば良かったかな・・・。

#TKCのデプロイオプション
ついでに、デフォルトとは異なるクラスタ構成でのデプロイ方法をまとめてみました。

踏み台

# vSphereの基本の型（Dev環境:ControlPlane1台、Worker1台)。
# vSphereだけ、ControlPlane用にVIPの指定が必要(TKG v1.2.xの制限)。
tkg create cluster (クラスタ名) --vsphere-controlplane-endpoint (IPかFQDN) --plan dev

# AzureやAWS環境では、VIP指定が要らない。
tkg create cluster (クラスタ名) --plan dev

# 本番構成(ControlPlane3台、Worker3台)
tkg create cluster (クラスタ名) --vsphere-controlplane-endpoint (IPかFQDN) --plan prod

# ControlPlaneやWorkerの台数を、個別指定が可能
tkg create cluster (クラスタ名) --vsphere-controlplane-endpoint (IPかFQDN) --plan dev --controlplane-machine-count 5 --worker-machine-count 10

# 管理クラスタと異なるマシンサイズのTKCを作成。small/medium/large/extra-large から選べる。
tkg create cluster (クラスタ名) --vsphere-controlplane-endpoint (IPかFQDN) --plan dev --size small

# ControlPlaneやWorkerのマシンサイズも、個別に指定が可能
tkg create cluster (クラスタ名) --vsphere-controlplane-endpoint (IPかFQDN) --plan dev --controlplane-size large --worker-size extra-large

# 管理クラスタの別namespace上に、TKCをデプロイ。（例：staging用に同じクラスタを用意する）
tkg create cluster (クラスタ名) --vsphere-controlplane-endpoint (IPかFQDN) --plan dev --namespace staging

# 利用可能なK8sバージョンの確認(要Base OSのテンプレート準備)
tkg get kubernetesversions
# 異なるK8sバージョンでデプロイ(↑の情報を使う)
tkg create cluster (クラスタ名) --vsphere-controlplane-endpoint (IPかFQDN) --plan dev --kubernetes-version v1.17.13

# calico CNIでデプロイ (--cni noneで、CNIなしも可能)
tkg create cluster (クラスタ名) --vsphere-controlplane-endpoint (IPかFQDN) --plan dev --cni calico

# TKCにOIDC認証の有効化(要Dex/Gangwayのインストール)
tkg create cluster (クラスタ名) --vsphere-controlplane-endpoint (IPかFQDN) --plan dev --enable-cluster-options oidc

# autoscale (v1.2.1からの新機能。まだ自分は試していない・・)
tkg create cluster (クラスタ名) --vsphere-controlplane-endpoint (IPかFQDN) --plan dev --enable-cluster-options autoscaler

こうしてみると、、結構多機能でした! TKC凄いなｗ
ただ、毎回VIP指定のオプションは辛いな。。TKG v1.2で改悪されたところですね。。今後のバージョンに期待。

TKCのカスタム編集

一度、yamlに吐き出してテンプレートにしておくと、細かいスペックを編集したり、再利用しやすいです。

# テンプレートの作成
tkg create cluster (クラスタ名) --vsphere-controlplane-endpoint (IPかFQDN) --plan dev  --dry-run > my-cluster-config.yaml
# viなどでパラメータを変更した後、そのファイルを利用してデプロイ
tkg create cluster my-cluster --manifest my-cluster-config.yaml

本日は以上です！