本主題說明如何為工作負載叢集自訂網繭和容器網路,包括使用預設 Antrea 以外的叢集網路介面 (CNI),以及在具有 VMware NSX 網路的 vSphere 上,針對工作負載叢集,支援可公開路由的無 NAT IP 位址。
當您使用 Tanzu CLI 部署工作負載叢集時,叢集中會自動啟用 Antrea 叢集網路介面 (CNI)。或者,您可以啟用 Calico CNI 或您自己的 CNI 提供者。
由於自動管理的套件由 Tanzu Kubernetes Grid 管理,因此您通常不需要更新其組態。但是,您可能希望建立使用自訂 CNI (如 Calico) 的工作負載叢集。以下幾節提供用來設定自訂 CNI (如 Calico) 的步驟。
由獨立管理叢集部署且版本低於 1.2.x 的 Tanzu Kubernetes Grid,然後升級到 v1.3 的工作負載叢集將繼續使用 Calico 作為 CNI 提供者。您無法變更這些叢集的 CNI 提供者。
透過在組態檔中指定 CNI
變數,可以變更要從獨立管理叢集部署的工作負載叢集的預設 CNI。CNI
變數支援以下選項:
antrea
:啟用 Antrea。calico
:啟用 Calico。請參閱 Calico CNI。Windows 不支援此選項。none
:允許您啟用自訂 CNI 提供者。請參閱自訂 CNI。如果未設定 CNI
變數,則依預設會啟用 Antrea。
若要在工作負載叢集中啟用 Calico,請在組態檔中指定以下內容:
CNI: calico
叢集建立程序完成後,您可以依照連線到並檢查工作負載叢集中所述檢查叢集。
若要在工作負載叢集中啟用除 Calico 以外的自訂 CNI 提供者,請執行以下步驟:
建立叢集時,請在組態檔中指定 CNI: none
。例如:
CNI: none
在將 CNI 套用至叢集之前,叢集建立程序不會成功。您可以在管理叢集上的叢集 API 記錄中,監控叢集建立程序。如需如何存取叢集 API 記錄的指示,請參閱記錄和監控。
初始化叢集後,將 CNI 提供者套用至叢集:
取得叢集的 admin
認證。例如:
tanzu cluster kubeconfig get my-cluster --admin
將 kubectl
的內容設定為叢集。例如:
kubectl config use-context my-cluster-admin@my-cluster
將 CNI 提供者套用至叢集:
kubectl apply -f PATH-TO-YOUR-CNI-CONFIGURATION/example.yaml
tanzu cluster list
命令監控叢集的狀態。叢集建立完成後,叢集狀態將從 creating
變更為 running
。如需有關如何檢查叢集的詳細資訊,請參閱連線到並檢查工作負載叢集。若要在由主管或獨立管理叢集部署為單節點工作負載叢集的以類別為基礎的叢集上安裝 calico
而不是 antrea
,首先需要自訂叢集的 ClusterBootstrap
物件,如下所示:
建立 YAML 檔案,且其包含下列 Kubernetes 物件:
apiVersion: cni.tanzu.vmware.com/v1alpha1
kind: CalicoConfig
metadata:
name: CLUSTER-NAME
namespace: CLUSTER-NAMESPACE
spec:
calico:
config:
vethMTU: 0
---
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: ClusterBootstrap
metadata:
annotations:
tkg.tanzu.vmware.com/add-missing-fields-from-tkr: TKR-VERSION
name: CLUSTER-NAME
namespace: CLUSTER-NAMESPACE
spec:
additionalPackages: # Customize additional packages
- refName: metrics-server*
- refName: secretgen-controller*
- refName: pinniped*
cni:
refName: calico*
valuesFrom:
providerRef:
apiGroup: cni.tanzu.vmware.com
kind: CalicoConfig
name: CLUSTER-NAME
其中:
CLUSTER-NAME
是您想建立的工作負載叢集的名稱。CLUSTER-NAMESPACE
是工作負載叢集的命名空間。TKR-VERSION
是您想用於工作負載叢集的 Tanzu Kubernetes 版本 (TKr)。例如:
v1.23.5+vmware.1-tkg.1
(適用於主管部署的叢集) 或v1.24.10---vmware.1-tiny.1-tkg.1
(適用於單節點叢集),如 vSphere 上的單節點叢集 (技術預覽) 中所述對於單節點叢集,請從 ClusterBootstrap
定義中刪除 spec.additionalPackages
區塊。單節點叢集沒有額外的 metrics-server
、secretgen-controller
和 pinniped
套件。
透過對管理叢集 (無論是主管叢集還是獨立管理叢集) 執行 kubectl apply -f
命令來套用該檔案。
為包含以下組態的 Cluster
物件建立 YAML 檔案:
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
name: CLUSTER-NAME
namespace: CLUSTER-NAMESPACE
spec:
clusterNetwork:
services:
cidrBlocks: ["SERVICES-CIDR"]
pods:
cidrBlocks: ["PODS-CIDR"]
serviceDomain: "SERVICE-DOMAIN"
topology:
class: tanzukubernetescluster
version: TKR-VERSION
controlPlane:
replicas: 1
workers:
machineDeployments:
- class: node-pool
name: NODE-POOL-NAME
replicas: 1
variables:
- name: vmClass
value: VM-CLASS
# Default storageClass for control plane and node pool
- name: storageClass
value: STORAGE-CLASS-NAME
其中:
CLUSTER-NAME
是您想建立的工作負載叢集的名稱。CLUSTER-NAMESPACE
是工作負載叢集的命名空間。SERVICES-CIDR
是服務的 CIDR 區塊。例如,198.51.100.0/12
。PODS-CIDR
是網繭的 CIDR 區塊。例如,192.0.2.0/16
。SERVICE-DOMAIN
是服務網域名稱。例如,cluster.local
。TKR-VERSION
是您想用於工作負載叢集的 TKr 版本。例如,v1.23.5+vmware.1-tkg.1
。NODE-POOL-NAME
是 machineDeployments
的節點集區名稱。VM-CLASS
是您想用於叢集的虛擬機器類別的名稱。例如,best-effort-small
。STORAGE-CLASS-NAME
是您想用於叢集的儲存區類別的名稱。例如,wcpglobal-storage-profile
。例如:
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
name: my-workload-cluster
namespace: my-workload-cluster-namespace
spec:
clusterNetwork:
services:
cidrBlocks: ["198.51.100.0/12"]
pods:
cidrBlocks: ["192.0.2.0/16"]
serviceDomain: "cluster.local"
topology:
class: tanzukubernetescluster
version: v1.23.5+vmware.1-tkg.1
controlPlane:
replicas: 1
workers:
machineDeployments:
- class: node-pool
name: my-node-pool
replicas: 1
variables:
- name: vmClass
value: best-effort-small
# Default storageClass for control plane and node pool
- name: storageClass
value: wcpglobal-storage-profile
透過將您在上方步驟中建立的 Cluster
物件定義檔案傳遞至 tanzu cluster create
命令的 -f
選項,建立工作負載叢集。
若要在主管部署的 TanzuKubernetesCluster
類型的工作負載叢集上安裝 calico
而不是 antrea
,請在計劃用於建立工作負載叢集的叢集組態檔中設定 CNI
組態變數,然後將該檔案傳遞至 tanzu cluster create
命令的 -f
選項。例如,CNI: calico
。
若要在工作負載叢集上啟用多個 CNI 提供者 (例如 macvlan、ipvlan、SR-IOV 或 DPDK),請將 Multus 套件安裝到已執行 Antrea 或 Calico CNI 的叢集上,並為 CNI 建立其他 NetworkAttachmentDefinition
資源。之後,您可以在叢集中建立新網繭,以便針對不同的位址範圍使用不同的網路介面。
如需相關指示,請參閱在工作負載叢集上部署 Multus。
在具有 NSX 網路和 Antrea 容器網路介面 (CNI) 的 vSphere 上,您可以設定工作負載叢集,使其使用其工作網繭的可路由 IP 位址,而略過網路位址轉譯 (NAT),讓網繭傳送及接收外部要求。
網繭上的可路由 IP 位址可讓您:
若要將 NSX 設定為支援工作網繭的可路由 IP 位址,請執行以下命令:
瀏覽至 NSX 伺服器,然後開啟網路 (Networking) 索引標籤。
在連線 (Connectivity) > 第 1 層閘道 (Tier-1 Gateways) 下,按一下新增第 1 層閘道 (Add Tier-1 Gateways),然後設定供可路由的 IP 網繭專用的新第 1 層閘道:
按一下儲存 (Save),以儲存閘道。
在連線 (Connectivity) > 區段 (Segments) 下,按一下新增區段 (Add Segment),並為含有可路由網繭的工作負載叢集節點,設定新的 NSX 區段 (邏輯交換器):
tz-overlay
。195.115.4.1/24
。此範圍不應與 DHCP 設定檔的伺服器 IP 位址 (Server IP Address) 值重疊。按一下儲存 (Save),以儲存閘道。
有關如何部署具有可路由、無 NAT IP 位址的 TKC 叢集,請參閱 v1beta1 範例:。具有可路由 Pod 網路的叢集。
若要使用獨立管理叢集部署具有可路由的無 NAT IP 位址的工作網繭的工作負載叢集,請執行以下動作。叢集的 CLUSTER_CIDR
設定可設定其可公開路由 IP 位址的範圍。
依照建立工作負載叢集組態檔中所述,來建立工作負載叢集組態檔,如下所示:
CLUSTER_CIDR
,或者tanzu cluster create
命令前面新增 CLUSTER_CIDR=
設定,如以下步驟中所示。NSXT_POD_ROUTING_ENABLED
設定為 "true"
。NSXT_MANAGER_HOST
設定為 NSX Manager IP 位址。NSXT_ROUTER_PATH
設定為剛為可路由 IP 所新增的第 1 層閘道的詳細目錄路徑。從 [NSX Manager] > 連線 (Connectivity) > 第 1 層閘道 (Tier-1 Gateways) 中取得此路徑,作法是按一下閘道名稱左側的功能表圖示 (),然後按一下將路徑複製到剪貼簿 (Copy Path to Clipboard)。名稱的開頭是 "/infra/tier-1s/
NSXT_
字串變數,請遵循〈組態檔變數參考〉中的 NSX Pod 路由資料表進行。網繭可以用下列四種方式之一對 NSX 進行驗證,其中最後列出的,安全性最低:
NSXT_CLIENT_CERT_KEY_DATA
、NSXT_CLIENT_CERT_KEY_DATA
,並針對 CA 核發的憑證,設定 NSXT_ROOT_CA_DATA_B64
。NSXT_VMC_AUTH_HOST
和 NSXT_VMC_ACCESS_TOKEN
。NSXT_SECRET_NAMESPACE
、NSXT_SECRET_NAME
、NSXT_USERNAME
和 NSXT_PASSWORD
。NSXT_USERNAME
和 NSXT_PASSWORD
。依照建立工作負載叢集中所述執行 tanzu cluster create
。例如:
$ CLUSTER_CIDR=100.96.0.0/11 tanzu cluster create my-routable-work-cluster -f my-routable-work-cluster-config.yaml
Validating configuration...
Creating workload cluster 'my-routable-work-cluster'...
Waiting for cluster to be initialized...
Waiting for cluster nodes to be available...
若要測試工作負載網繭的可路由 IP 位址,請執行下列動作:
將 Web 伺服器部署至可路由的工作負載叢集。
執行 kubectl get pods --o wide
,以擷取可路由網繭的 NAME
、INTERNAL-IP
和 EXTERNAL-IP
值,並驗證列出的 IP 位址是相同的,且在可路由的 CLUSTER_CIDR
範圍內。
執行 kubectl get nodes --o wide
,以擷取可路由的 IP 網繭的工作負載叢集節點的 NAME
、INTERNAL-IP
和EXTERNAL-IP
值。
登入其他工作負載叢集的控制平面節點:
kubectl config use-context CLUSTER-CONTEXT
,將內容變更為不同的叢集。kubectl get nodes
,以擷取目前叢集的控制平面節點的 IP 位址。ssh capv@CONTROLPLANE-IP
。ping
,並將 curl
要求傳送至 Web 伺服器部署所在的可路由 IP 位址,並確認其回應。
ping
輸出應將 Web 伺服器的可路由的網繭 IP 列出為來源位址。在瀏覽器中,登入 NSX,然後導覽至您為可路由的 IP 網繭所建立的第 1 層閘道。
按一下靜態路由 (Static Routes),並確認已在可路由 CLUSTER_CIDR
範圍內建立以下路由:
在您刪除包含可路由的 IP 網繭的工作負載叢集後,您可能需要從 T1 路由器中刪除它們,以釋放這些可路由 IP 位址:
從 [NSX Manager] > 連線 (Connectivity) > 第 1 層閘道 (Tier-1 Gateways) 中,選取可路由 IP 閘道。
在靜態路由 (Static Routes) 之下按一下路由數,以開啟清單。
搜尋含有已刪除叢集名稱的路由,然後從路由名稱左側的功能表圖示 () 中,刪除每個路由。
curl -i -k -u 'NSXT_USERNAME:NSXT_PASSWORD' -H 'Content-Type: application/json' -H 'X-Allow-Overwrite: true' -X DELETE https://NSXT_MANAGER_HOST/policy/api/v1/STATIC-ROUTE-PATH
,其中:
NSXT_MANAGER_HOST
、NSXT_USERNAME
和 NSXT_PASSWORD
是您的 NSX Manager IP 位址和認證STATIC_ROUTE_PATH
是您剛複製到剪貼簿的路徑。名稱的開頭是 /infra/tier-1s/
,且包含 /static-routes/
。若要限制工作負載叢集存取 VMware vCenter Server 管理介面,請在 Antrea 和 Calico CNI 上設定適當的網路原則。當您設定這些原則時,只會篩選來自容器網路的流量。這些原則會封鎖來自所有網繭的流量,除了來自容器儲存區介面 (CSI) 和雲端提供者介面 (CPI) 網繭的流量。
透過工作負載叢集中的 antrea-policy-csi-cpi.yaml
檔案為 Antrea 設定叢集網路原則。為此,請執行以下操作:
在 Tanzu CLI 中,切換到工作負載叢集內容:
kubectl config use-context WORKLOAD-CLUSTER-CONTEXT
建立 antrea-policy-csi-cpi.yaml
檔案,如以下範例所示:
apiVersion: crd.antrea.tanzu.vmware.com/v1alpha1
kind: TierEntitlement
metadata:
name: edit-system-tiers
spec:
permission: edit
tiers:
- emergency
- securityops
- networkops
- platform
# application and baseline Tiers are not restricted
---
apiVersion: crd.antrea.tanzu.vmware.com/v1alpha1
kind: TierEntitlementBinding
metadata:
name: admin-edit-system-tiers
spec:
# Allow only admin to attach Antrea ClusterNetworkPolicy and NetworkPolicy to system Tiers
subjects:
- kind: User
name: admin
tierEntitlement: edit-system-tiers
---
apiVersion: crd.antrea.io/v1alpha3
kind: ClusterGroup
metadata:
name: vc-ip
spec:
ipBlocks:
- cidr: VC_IP_CIDR # Enter the IP CIDR of vCenter Server, for example 192.168.1.1/3.
---
apiVersion: crd.antrea.io/v1alpha3
kind: ClusterGroup
metadata:
name: csi-cpi-pods
spec:
namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
podSelector:
matchExpressions:
- key: k8s-app
operator: In
values: [vsphere-cloud-controller-manager]
---
apiVersion: crd.antrea.io/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: allow-csi-cpi-egress-vc
spec:
priority: 5
tier: emergency
appliedTo:
- group: csi-cpi-pods
egress:
- action: Pass
to:
- group: vc-ip
---
apiVersion: crd.antrea.io/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: drop-egress-vc
spec:
priority: 10
tier: emergency
appliedTo:
- namespaceSelector: {} # Selects all Namespaces in the cluster
egress:
- action: Drop
to:
- group: vc-ip
附註在
cidr:
欄位中,輸入 vCenter Server 的 IP CIDR,例如192.168.1.1/32
。
套用檔案:
kubectl apply -f antrea-policy-csi-cpi.yaml
透過工作負載叢集中的 gnp.yaml
檔案設定 Calico 的叢集網路原則。為此,請執行以下操作:
從 Github 位置下載適用於您的作業系統的 calicoctl
公用程式二進位檔。
在您的系統上安裝公用程式。例如,若要在 Linux 系統上下載並安裝公用程式,請執行以下動作:
wget https://github.com/projectcalico/calico/releases/download/CALICO-VERSION/calicoctl-linux-amd64
mv calicoctl-linux-amd64 calicoctl
chmod +x calicoctl
在 Tanzu CLI 中,切換到工作負載叢集內容:
kubectl config use-context WORKLOAD-CLUSTER-CONTEXT
建立 gnp.yaml
檔案,如以下範例所示:
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: vcenter-egress-deny-all
spec:
order: 1000
types:
- Egress
egress:
- action: Allow
destination:
notNets:
- VC_IP_CIDR # Enter the IP CIDR of vCenter Server, for example 192.168.1.1/32.
---
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: vcenter-egress-allow-csi-cpi
spec:
order: 0
types:
- Egress
egress:
- action: Allow
source:
selector: app == 'vsphere-csi-node' || app == 'vsphere-csi-controller' || k8s-app == 'vsphere-cloud-controller-manager'
destination:
nets:
- VC_IP_CIDR # Enter the IP CIDR of vCenter Server, for example 192.168.1.1/32.
附註在
notNets:
和nets:
欄位下,輸入 vCenter Server 的 IP CIDR,例如192.168.1.1/32
。
套用檔案:
./calicoctl apply -f gnp.yaml
若要瞭解有關 Calico 中選取器選項的詳細資訊,請參閱 Calico 說明文件中的 EntityRule。
對於執行 Kubernetes v1.23 及更新版本的叢集內的命名空間,TKG 支援透過「Pod 安全性許可 (PSA)」控制器來套用 privileged
、baseline
或 restricted
類型的 Pod 安全性原則,如 Kubernetes 說明文件中的 Pod 安全性標準中所述。
附註此功能處於不受支援的技術預覽狀態;請參閱 TKG 功能狀態。
節點的「網繭安全性原則 (PSP)」在 TKG v2.1 中已棄用,以反映它們在 Kubernetes 中的棄用情況;如需瞭解如何將網繭從 PSP 移轉至 PSA 控制器,請參閱從 PodSecurityPolicy 移轉至內建 PodSecurity 許可控制器。
依預設,Kubernetes v1.24 叢集命名空間會將其 Pod 安全性 warn
和 audit
模式設定為 baseline
,這是非強制性設定。這表示移轉至 PSA 控制器時,可能會產生有關 Pod 違反原則的警告,但 Pod 將繼續執行。
這是已知問題,亦即,某些 TKG 套件和元件不符合 baseline
模式;對於這些問題,最快的因應措施是在受影響的命名空間中設定 audit=privileged
和 warn=privileged
標籤,以抑制違規稽核訊息和警告:
kubectl label --overwrite ns NAMESPACE pod-security.kubernetes.io/audit=privileged
kubectl label --overwrite ns NAMESPACE pod-security.kubernetes.io/warn=privileged
其中,NAMESPACE
是以下列出的任何已安裝套件或其他元件的命名空間:
命名空間 | 套件或元件 |
---|---|
avi-system |
AKO (load-balancer-and-ingress-service ) |
cert-manager |
Cert Manager |
pinniped-concierge |
Pinniped |
sonobuoy |
Sonobuoy |
tanzu-auth |
驗證服務 (適用於獨立管理叢集) |
tanzu-system-ingress |
Contour、Envoy |
tanzu-system-logging |
Fluent Bit |
tanzu-system-monitoring |
Prometheus |
velero |
Restic、Velero |
vmware-system-auth |
驗證服務 (適用於主管) |
這些命名空間包含了套件元件,不同於使用者選擇的命名空間或 default
,套件本身是在這裡安裝的。