This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

網繭和容器網路

本主題說明如何為工作負載叢集自訂網繭和容器網路，包括使用預設 Antrea 以外的叢集網路介面 (CNI)，以及在具有 VMware NSX 網路的 vSphere 上，針對工作負載叢集，支援可公開路由的無 NAT IP 位址。

使用非預設 CNI 來建立叢集

當您使用 Tanzu CLI 部署工作負載叢集時，叢集中會自動啟用 Antrea 叢集網路介面 (CNI)。或者，您可以啟用 Calico CNI 或您自己的 CNI 提供者。

由於自動管理的套件由 Tanzu Kubernetes Grid 管理，因此您通常不需要更新其組態。但是，您可能希望建立使用自訂 CNI (如 Calico) 的工作負載叢集。以下幾節提供用來設定自訂 CNI (如 Calico) 的步驟。

獨立管理叢集部署的叢集的自訂 CNI

由獨立管理叢集部署且版本低於 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，請在組態檔中指定以下內容：

CNI: calico

叢集建立程序完成後，您可以依照連線到並檢查工作負載叢集中所述檢查叢集。

自訂 CNI

若要在工作負載叢集中啟用除 Calico 以外的自訂 CNI 提供者，請執行以下步驟：

  1. 建立叢集時，請在組態檔中指定 CNI: none。例如：

    CNI: none

    在將 CNI 套用至叢集之前，叢集建立程序不會成功。您可以在管理叢集上的叢集 API 記錄中，監控叢集建立程序。如需如何存取叢集 API 記錄的指示，請參閱記錄和監控。

  2. 初始化叢集後，將 CNI 提供者套用至叢集：

    1. 取得叢集的 admin 認證。例如：

      tanzu cluster kubeconfig get my-cluster --admin

    2. 將 kubectl 的內容設定為叢集。例如：

      kubectl config use-context my-cluster-admin@my-cluster

    3. 將 CNI 提供者套用至叢集：

      kubectl apply -f PATH-TO-YOUR-CNI-CONFIGURATION/example.yaml
  3. 使用 tanzu cluster list 命令監控叢集的狀態。叢集建立完成後，叢集狀態將從 creating 變更為 running。如需有關如何檢查叢集的詳細資訊，請參閱連線到並檢查工作負載叢集。

適用於主管或以單節點類別為基礎的工作負載叢集的 Calico CNI

若要在由主管或獨立管理叢集部署為單節點工作負載叢集的以類別為基礎的叢集上安裝 calico 而不是 antrea，首先需要自訂叢集的 ClusterBootstrap 物件，如下所示：

  1. 建立 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)。例如：

  2. 對於單節點叢集，請從 ClusterBootstrap 定義中刪除 spec.additionalPackages 區塊。單節點叢集沒有額外的 metrics-server、secretgen-controller 和 pinniped 套件。

  3. 透過對管理叢集 (無論是主管叢集還是獨立管理叢集) 執行 kubectl apply -f 命令來套用該檔案。

  4. 為包含以下組態的 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

  5. 透過將您在上方步驟中建立的 Cluster 物件定義檔案傳遞至 tanzu cluster create 命令的 -f 選項，建立工作負載叢集。

以主管部署的 TKC 為基礎之叢集的 Calico CNI

若要在主管部署的 TanzuKubernetesCluster 類型的工作負載叢集上安裝 calico 而不是 antrea，請在計劃用於建立工作負載叢集的叢集組態檔中設定 CNI 組態變數，然後將該檔案傳遞至 tanzu cluster create 命令的 -f 選項。例如，CNI: calico。

啟用多個 CNI 提供者

若要在工作負載叢集上啟用多個 CNI 提供者 (例如 macvlan、ipvlan、SR-IOV 或 DPDK)，請將 Multus 套件安裝到已執行 Antrea 或 Calico CNI 的叢集上，並為 CNI 建立其他 NetworkAttachmentDefinition 資源。之後，您可以在叢集中建立新網繭，以便針對不同的位址範圍使用不同的網路介面。

如需相關指示，請參閱在工作負載叢集上部署 Multus。

部署具有可路由、無 NAT IP 位址的網繭 (NSX)

在具有 NSX 網路和 Antrea 容器網路介面 (CNI) 的 vSphere 上，您可以設定工作負載叢集，使其使用其工作網繭的可路由 IP 位址，而略過網路位址轉譯 (NAT)，讓網繭傳送及接收外部要求。

網繭上的可路由 IP 位址可讓您：

  • 追蹤送往一般共用服務的傳出要求，因為其來源 IP 位址是可路由的網繭 IP 位址，而不是 NAT 位址。
  • 支援直接從外部網際網路將經驗證的傳入要求傳送到網繭，而略過 NAT。

為可路由的 IP 網繭設定 NSX

若要將 NSX 設定為支援工作網繭的可路由 IP 位址，請執行以下命令：

  1. 瀏覽至 NSX 伺服器，然後開啟網路 (Networking) 索引標籤。

  2. 在連線 (Connectivity) > 第 1 層閘道 (Tier-1 Gateways) 下，按一下新增第 1 層閘道 (Add Tier-1 Gateways)，然後設定供可路由的 IP 網繭專用的新第 1 層閘道：

    • 名稱 (Name)：為可路由的網繭 T1 閘道建立名稱。
    • 連結的第 0 層閘道 (Linked Tier-0 Gateway)：選取供 Tanzu Kubernetes Grid 其他第 1 層閘道使用的第 0 層閘道。
    • Edge 叢集 (Edge Cluster)：選取一個現有的 Edge 叢集。
    • 路由通告 (Route Advertisement)：啟用所有靜態路由 (All Static Routes)、所有 NAT IP (All NAT IP's) 以及所有已連線的區段和服務連接埠 (All Connected Segments & Service Ports)。

    按一下儲存 (Save)，以儲存閘道。

  3. 在連線 (Connectivity) > 區段 (Segments) 下，按一下新增區段 (Add Segment)，並為含有可路由網繭的工作負載叢集節點，設定新的 NSX 區段 (邏輯交換器)：

    • 名稱 (Name)：為工作負載叢集節點的網路區段建立名稱。
    • 連線 (Connectivity)選取您剛建立的第 1 層閘道。
    • 傳輸區域 (Transport Zone)：選取覆疊傳輸區域，例如 tz-overlay。
    • 子網路 (Subnets)：為叢集節點選取一個 IP 位址範圍，例如 195.115.4.1/24。此範圍不應與 DHCP 設定檔的伺服器 IP 位址 (Server IP Address) 值重疊。
    • 路由通告 (Route Advertisement)：啟用所有靜態路由 (All Static Routes)、所有 NAT IP (All NAT IP's) 以及所有已連線的區段和服務連接埠 (All Connected Segments & Service Ports)。

    按一下儲存 (Save)，以儲存閘道。

主管部署的具有可路由 IP 位址的 TKC 網繭

有關如何部署具有可路由、無 NAT IP 位址的 TKC 叢集，請參閱 v1beta1 範例：。具有可路由 Pod 網路的叢集。

具有可路由 IP 位址的獨立管理叢集部署的網繭

若要使用獨立管理叢集部署具有可路由的無 NAT IP 位址的工作網繭的工作負載叢集，請執行以下動作。叢集的 CLUSTER_CIDR 設定可設定其可公開路由 IP 位址的範圍。

  1. 依照建立工作負載叢集組態檔中所述，來建立工作負載叢集組態檔，如下所示：

    • 若要設定指派給工作網繭的可路由 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/
    • 設定用來存取 NSX 的其他 NSXT_ 字串變數，請遵循〈組態檔變數參考〉中的 NSX Pod 路由資料表進行。網繭可以用下列四種方式之一對 NSX 進行驗證，其中最後列出的，安全性最低：
      • 憑證 (Certificate)：設定 NSXT_CLIENT_CERT_KEY_DATA、NSXT_CLIENT_CERT_KEY_DATA，並針對 CA 核發的憑證，設定 NSXT_ROOT_CA_DATA_B64。
      • VMware Cloud (VMC) 上的 VMware Identity Manager Token：設定 NSXT_VMC_AUTH_HOST 和 NSXT_VMC_ACCESS_TOKEN。
      • 儲存在 Kubernetes 秘密金鑰中的使用者名稱/密碼 (Username/password)：設定 NSXT_SECRET_NAMESPACE、NSXT_SECRET_NAME、NSXT_USERNAME 和 NSXT_PASSWORD。
      • 組態檔中純文字形式的使用者名稱/密碼 (Username/password)：設定 NSXT_USERNAME 和 NSXT_PASSWORD。

  2. 依照建立工作負載叢集中所述執行 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

若要測試工作負載網繭的可路由 IP 位址，請執行下列動作：

  1. 將 Web 伺服器部署至可路由的工作負載叢集。

  2. 執行 kubectl get pods --o wide，以擷取可路由網繭的 NAME、INTERNAL-IP 和 EXTERNAL-IP 值，並驗證列出的 IP 位址是相同的，且在可路由的 CLUSTER_CIDR 範圍內。

  3. 執行 kubectl get nodes --o wide，以擷取可路由的 IP 網繭的工作負載叢集節點的 NAME、INTERNAL-IP 和EXTERNAL-IP 值。

  4. 登入其他工作負載叢集的控制平面節點：

    1. 執行 kubectl config use-context CLUSTER-CONTEXT，將內容變更為不同的叢集。
    2. 執行 kubectl get nodes，以擷取目前叢集的控制平面節點的 IP 位址。
    3. 使用您剛擷取的 IP 位址，來執行 ssh capv@CONTROLPLANE-IP。
    4. 執行 ping，並將 curl 要求傳送至 Web 伺服器部署所在的可路由 IP 位址，並確認其回應。
      • ping 輸出應將 Web 伺服器的可路由的網繭 IP 列出為來源位址。

  5. 在瀏覽器中，登入 NSX，然後導覽至您為可路由的 IP 網繭所建立的第 1 層閘道。

  6. 按一下靜態路由 (Static Routes)，並確認已在可路由 CLUSTER_CIDR 範圍內建立以下路由：

    1. 工作負載叢集控制平面節點中的網繭路由，且下一個躍點 (Next Hops) 會顯示為控制平面節點本身的位址。
    2. 工作負載叢集工作節點中的網繭路由，且下一個躍點 (Next Hops) 會顯示為工作節點本身的位址。

刪除可路由 IP

在您刪除包含可路由的 IP 網繭的工作負載叢集後，您可能需要從 T1 路由器中刪除它們，以釋放這些可路由 IP 位址：

  1. 從 [NSX Manager] > 連線 (Connectivity) > 第 1 層閘道 (Tier-1 Gateways) 中，選取可路由 IP 閘道。

  2. 在靜態路由 (Static Routes) 之下按一下路由數，以開啟清單。

  3. 搜尋含有已刪除叢集名稱的路由，然後從路由名稱左側的功能表圖示 (清晰顯示垂直省略符號圖示) 中，刪除每個路由。

    1. 如果因權限錯誤，導致您無法從功能表中刪除路由 (如果路由是由憑證所建立，可能出現此情況)，請透過 API 來刪除路由：
      1. 從路由名稱旁的功能表中，選取將路徑複製到剪貼簿 (Copy Path to Clipboard)。
      2. 執行 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/。

為 CNI 設定網路原則

若要限制工作負載叢集存取 VMware vCenter Server 管理介面，請在 Antrea 和 Calico CNI 上設定適當的網路原則。當您設定這些原則時，只會篩選來自容器網路的流量。這些原則會封鎖來自所有網繭的流量，除了來自容器儲存區介面 (CSI) 和雲端提供者介面 (CPI) 網繭的流量。

為 Antrea 設定叢集網路原則

透過工作負載叢集中的 antrea-policy-csi-cpi.yaml 檔案為 Antrea 設定叢集網路原則。為此，請執行以下操作：

  1. 在 Tanzu CLI 中，切換到工作負載叢集內容：

    kubectl config use-context WORKLOAD-CLUSTER-CONTEXT

  2. 建立 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。

  3. 套用檔案：

    kubectl apply -f antrea-policy-csi-cpi.yaml

為 Calico 設定網路原則

透過工作負載叢集中的 gnp.yaml 檔案設定 Calico 的叢集網路原則。為此，請執行以下操作：

  1. 從 Github 位置下載適用於您的作業系統的 calicoctl 公用程式二進位檔。

  2. 在您的系統上安裝公用程式。例如，若要在 Linux 系統上下載並安裝公用程式，請執行以下動作：

    wget https://github.com/projectcalico/calico/releases/download/CALICO-VERSION/calicoctl-linux-amd64
mv calicoctl-linux-amd64 calicoctl
chmod +x calicoctl

  3. 在 Tanzu CLI 中，切換到工作負載叢集內容：

    kubectl config use-context WORKLOAD-CLUSTER-CONTEXT

  4. 建立 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。

  5. 套用檔案：

    ./calicoctl apply -f gnp.yaml

若要瞭解有關 Calico 中選取器選項的詳細資訊，請參閱 Calico 說明文件中的 EntityRule。

Pod 安全性許可控制器 (技術預覽)

對於執行 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，套件本身是在這裡安裝的。

check-circle-line exclamation-circle-line close-line
Scroll to top icon