下文的 Tanzu 特指 vSphere with Tanzu（簡稱 TKGs），除此之外，Tanzu 還有另一個版本 Tanzu Kubernetes Grid，一般簡稱 TKGm。
Tanzu 架構說明
Tanzu 和市面上其他的 Kubernetes 發行版有個很大不同，即其他發行版更類似于 K8s 安裝程式，而 Tanzu 則是一個 K8s 排程平台，Tanzu 下使用者需要先部署出一個主管叢集（Supervisor Cluster），此叢集基于 K8s 建構，但是并非用于生産，而是專門用來建立和管理其他 K8s 叢集，其他叢集專門用于傳遞給最終的業務部門來使用，這裡的其他叢集在 Tanzu 下被稱作客戶叢集（Guest Cluster）。
Tanzu 的這種架構很類似于公有雲的傳遞模式，當使用者需要 K8s 跑業務時，管理者可以快速通過主管叢集拉起一個 K8s 給到使用者，當使用者使用完此叢集後，又可以快速進行回收，使得 K8s 叢集變成一項可即時擷取的服務。
這種模型并非一時興起，而是能預見的一種趨勢，即 K8s 最終會是以叢集的形式傳遞給使用者，而非僅給使用者使用資源的權限。這裡面的原因多種多樣，筆者僅列舉幾項：
- 衆口難調：在傳統 VM 架構下，無論是誰需要資源，都可以直接傳遞個 VM 給對方，差異無非是資源大小；而在 Kubernetes 下，使用者可能不止需要資源，還會需要 API 的掌控權，因為 K8s 的核心就是 API Server，開發者常常需要将 K8s 與其他平台進行內建，而不同系統的開發者常常使用不同的開發平台，很難統一，這時候，做一個集中式的大叢集然後做好權限/API/資源管理的複雜度遠遠大于直接傳遞一整個平台；
- 雞蛋放在多個籃子裡：在以前 vSphere 的世界裡，每個客戶都會建立很多叢集來承載不同業務，每個叢集都會是一個單獨的故障域，同理，K8s 環境下也可以建立多個叢集，單個叢集故障隻會影響部分系統，不會影響其他業務；
- 運維複雜度：從 K8s 大規模使用開始，就有很多人的觀念是 K8s 太複雜了，是以隻能部署一兩套來運維，多個叢集管理不過來，但這種觀點存在一些疏漏，比如：單個叢集上勢必會承載非常多的業務，随便做一個叢集變更可能都需要與非常多的部門打招呼設定變更視窗，如果協調不一緻最終整個叢集會變成不敢維護，時間長了就會成為曆史包袱，未來擴容時考慮到産品更新和硬體支援，隻能建立叢集..這樣反複惡性循環（現在部分企業裡的 OpenStack 就是這樣的不可維護狀态）。Tanzu 針對 K8s 的更新運維做了很多改進，使得更新過程無風險且自動化，再加上多叢集的架構，使得 Tanzu 可運維性非常強。
OK，回到正題。
Tanzu 從網絡層面有兩類，一類是使用 NSX-T 作為底層承載網，另一類是使用 vDS 作為承載網，本文介紹前者的一些細節。
在 NSX+Tanzu 架構下，網絡會劃分為兩類：
- 管理網：
- ESXi、vCenter、NSX Manager、DNS 等管理型元件之間通信的網絡
- Tanzu 主管叢集會有一張網卡接入管理網，與上述元件進行通信，排程 vSphere 資源
- 業務網：
- 所有未來承載業務的網絡，包括 K8s node 以及其中的 Pod，都會通過此網絡通信
- 主管叢集 API Server 也會運作在此網絡内（很重要）
- 客戶叢集的 API Server 也會運作在此網絡内（很重要）
- 所有業務網最終都會由 NSX 自動置備，使用者需要預先規劃好 IP 位址範圍
部署 Tanzu 主管叢集前期準備
在部署 Tanzu 主管叢集前，需要預先完成下列工作：
1、部署一套完整的 NSX-T（具體方法見：https://blog.51cto.com/sparkgo/5478574 中的傳統模式）
2、準備内容庫：内容庫用于存放 Kubernetes 發行版的 OVA，可以手動去這裡下載下傳再上傳到内容庫，或者直接讓 vCenter 能夠通路網際網路，訂閱線上的内容庫位址并線上拉取 OVA（方法見這裡）。
3、準備 vSphere 存儲政策：在傳統 VM 環境下，一般使用者很少去使用存儲政策，需要建立 VM 時直接将 VM 指定到相應的 Datastore 中，但是在 Tanzu 下，所有存儲相關的排程均是由系統自動完成的，存儲政策在此處的作用就是設定 Tanzu 可以使用的存儲。比如叢集裡有 4 個 Datastore，我可以使用基于标記的存儲政策，僅設定 Tanzu 可以使用其中的兩個 Datastore。
4、叢集需要開啟 HA 模式和 DRS 全自動模式：開啟這兩者是為了保證 Tanzu 可以正确排程 VM 的建立，以及保證高可用。
相關配置截圖如下：
1、NSX-T 部署後檢查
NSX-T 與 vCenter 對接正常：
主機準備狀态正常：
T0 配置正确，關聯了 Edge Cluster：
在 vCenter 側可以看到 VDS 被辨別為 NSX 交換機：
2、準備内容庫
建立内容庫（此處使用線上按需拉取方式）：
3、準備虛拟機存儲政策
本文為了可控性，使用基于标記的虛拟機存儲政策。
在 vCenter 的下列位置可以找到添加标記類别以及标記的地方：
添加存儲類别：
添加存儲标記，關聯上述類别：
為 Datastore 配置設定标記：
配置基于标記的存儲政策：
4、叢集 HA 及 DRS 配置
網絡規劃
| 名稱 | 網段 | 描述 |
| 命名空間網絡 | 10.40.0.0/18 | 供 Guest Cluster VM 及 Native Pod 使用 |
| 服務 CIDR | 10.40.64.0/18 | 供主管叢集内 Service 使用 |
| 輸入 CIDR | 10.40.128.0/18 | 供負載均衡器使用 |
| 主管叢集管理網絡 | 10.10.50.125~129 | 主管叢集管理網絡 IP 位址範圍 |
部署 Tanzu 主管叢集
在完成上述的前期準備後，即可按照向導進行主管叢集的開啟，配置截圖如下：
1、設定網絡模式為 NSX-T
2、選擇相應的叢集，如果此處提示叢集不相容，則需要檢視 vCenter 系統中的 /storage/log/vmware/wcp/wcpsvc.log 檔案擷取具體報錯資訊
3、設定主管叢集的存儲政策
4、設定主管叢集的管理網絡，一般管理網絡需要 5 個可用位址（3 個實位址 +1 個虛拟位址 +1 個滾動更新位址），這些位址需要能和 vCenter 以及其他管理網段通信，一般使用 vDS 端口組即可。如果 vCenter 等管理元件使用 .local 結尾的域名，則必須在 DNS 搜尋域中加入域名字尾
5、設定工作負載網絡。這些網絡未來都會由 NSX 來自動建立，使用者需要配置設定多個網段給 NSX，這些網段不能和已有網絡重疊
6、設定全局内容庫，内容庫中存放的是未來部署 K8s 叢集的 OVA 檔案
7、設定主管叢集的規模，一般 POC 環境使用小型即可
整個建立過程大緻會有 20+ 分鐘，耐心等待即可。
等待部署完成後，配置狀态會變為“正在運作”，并且會有一個控制平面節點位址，此位址由 NSX 負載均衡器接管：
在 vSphere 叢集中會出現一個 Namespace 資源池，裡面有三台控制虛拟機，每台分别有一張網卡接入之前配置的管理網絡中，一張接入 NSX 自動建立的分段中：
相應地，可以在 NSX 看到系統自動置備了 T1 網關：
在 Tanzu+NSX 架構下，所有叢集内的 ClusterIP 類型的 Service 均會由 NSX DLB （分布式 LB）來實作，是以在 NSX 界面中可以直接看到所有服務；叢集内釋出的 Loadbalancer 類型的 Service 均會由普通的運作在 Edge 節點的 LB 來實作，在 NSX 界面中也可以看到相關服務：
最後，通路控制平面節點位址，可以正常通路，此處提供了 kubectl 和 kubectl-vsphere CLI 工具，用于連接配接到主管叢集和業務叢集：
部署客戶叢集
本文會建構一個 Pod 可路由的 K8s 叢集，部署全路由 K8s 叢集有下列前置條件：
- vCenter 版本 7.0U3 及以上
- 主管叢集 k8s 版本至少：v1.21.0+vmware.wcp.2
- TanzuKubernetesCluster API 版本為 v1alpha2
- 客戶叢集 K8s 版本至少：v1.21.2---vmware.1-tkg.1.ee25d55
為客戶叢集建立命名空間
選中 vSphere 叢集，右鍵選擇“建立命名空間”：
設定命名空間名稱：
在 7.0U3 版本之後，建立命名空間時多了一個“替代叢集網絡設定”的開關，通過此開關可以覆寫預設的網絡相關配置，做到不同租戶（命名空間）有不同的網絡設定：
建立完成後需要為命名空間關聯 VM 類和内容庫：
其中 VM 類用于表示未來租戶可以使用的 VM 規格，VM 類可以按需建立或者使用預設的：
内容庫用于存放 Kubernetes 發行版 OVA 檔案
最後，為命名空間關聯存儲政策：
登陸主管叢集并檢查
在上個章節的最後一部分，主管叢集的 UI 中提供了兩個 CLI 工具，其中一個名為 kubectl-vsphere 的工具用于登入主管叢集，具體指令如下（此處使用 [email protected] 使用者登入）：
kubectl-vsphere login --insecure-skip-tls-verify --server=https://10.40.160.1 -u [email protected] 根據提示切換到相應的 context：
kubectl config use-context 10.40.160.1 檢視 node 狀态均為 Ready，可以看到環境中有三個 Master 節點，分别為三台主管叢集 VM 節點，一台 ESXi 作為 Worker 節點：
kubectl get node 通過下列指令可以看到之前為客戶叢集建立的命名空間可以正常看到：
kubectl get ns 接着在 ns1 下分别檢視 tkr（Kubernetes 發行版）、storageclass（存儲政策）及 vmclass（VM 類），确認可以正常讀取到：
kubectl -n ns1 get tkr
kubectl -n ns1 get sc
kubectl -n ns1 get vmclass 建立客戶叢集
準備下列客戶叢集 YAML 檔案：
#cat tkc.yaml
apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster
metadata:
name: tkgs-v2-cluster-routable-pods
spec:
topology:
controlPlane:
replicas: 1
# vmClass 需要與關聯給命名空間的 VM 類比對
vmClass: best-effort-medium
# storageClass 需要與關聯給命名空間的存儲政策一緻
storageClass: tanzu-storage-profile
tkr:
reference:
name: v1.21.6---vmware.1-tkg.1.b3d708a
nodePools:
- name: worker-nodepool-a1
replicas: 1
vmClass: best-effort-medium
storageClass: tanzu-storage-profile
tkr:
reference:
name: v1.21.6---vmware.1-tkg.1.b3d708a
settings:
storage:
defaultClass: tanzu-storage-profile
network:
cni:
#使用全路由 pod 時，CNI 名稱為 antrea-nsx-routed
name: antrea-nsx-routed
services:
cidrBlocks: ["10.96.0.0/12"]
serviceDomain: tanzukubernetescluster.local
pods:
#使用全路由 pod 時，cdir Blocks 處需要留白，此 cidr 将由 NSX 自動配置設定
cidrBlocks:
trust:
additionalTrustedCAs:
- name: CA
data: LS0tLS1CRUdJTi<此處省略>0NUM1ZHJveG1UaC9sS2NBPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo= 運作下列指令建立客戶叢集，并檢視建立狀态：
kubectl -n ns1 apply -f tkc.yaml
kubectl -n ns1 get tkc 之後在 vCenter 中即可看到有 VM 在建立中：
等待 5~10 分鐘後，叢集建立完畢：
和主管叢集類似，NSX 也會為客戶叢集自動置備網絡，配置好相應的 T1 網關和路由：
同時會添加下列防火牆規則，這些規則預設隻允許叢集 CIDR 到 Node 節點的通路，其他所有入向會被拒絕（LB 服務除外），通過這種方式可以有效保護叢集内節點的安全：
登入客戶叢集
在叢集建立完成後，可以參照此文章來擷取叢集的 kubeconfig 檔案。
具體方法為找到命名空間下的名稱包含 kubeconfig 的 secret，然後将其轉碼并輸出到指定檔案，例如 tkc-kubeconfig-admin：
kubectl -n ns1 get secrets
kubectl -n ns1 get secret tkgs-v2-cluster-routable-pods-kubeconfig -o jsonpath='{.data.value}' | base64 -d > tkc-kubeconfig-admin 接着建立一個 clusterrolebinding，為預設的 admin 使用者賦予 privileged 權限（詳細參見此文章和此文章）：
kubectl --kubeconfig tkc-kubeconfig-admin create clusterrolebinding default-tkg-admin-privileged-binding --clusterrole=psp:vmware-system-privileged --group=system:authenticated 業務部署測試
通過上文導出的 kubeconfig 檔案檢視叢集節點狀态：
kubectl --kubeconfig tkc-kubeconfig-admin get nodes -o wide 準備下列 YAML 檔案：
# cat avi-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: avi-demo
name: avi-demo
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: avi-demo
template:
metadata:
labels:
app: avi-demo
spec:
containers:
- env:
- name: hostinfo
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: spec.nodeName
image: dyadin/avi-demo:v2
imagePullPolicy: IfNotPresent
name: avi-demo
ports:
- containerPort: 80
name: http
protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
annotations:
name: avi-demo-lb
spec:
ports:
- name: http
port: 80
protocol: TCP
targetPort: 80
selector:
app: avi-demo
type: LoadBalancer 應用此 YAML 檔案，檢視 Pod 狀态及 IP：
kubectl --kubeconfig tkc-kubeconfig-admin apply -f avi-demo.yaml
kubectl --kubeconfig tkc-kubeconfig-admin get po -o wide 接着運作 traceroute 通路外部，可以觀察到 Pod 能夠直接和外部網絡通信，中間未經過 NAT 轉換。
kubectl --kubeconfig tkc-kubeconfig-admin exec -it <pod-name> -- traceroute -n 10.10.50.9 目标端抓包可以直接看到 Pod 真實 IP 位址：
檢視相應業務釋出情況，進行通路測試：
kubectl --kubeconfig tkc-kubeconfig-admin get svc