さて、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
本日は以上です！