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

 

Pod 和容器网络连接

本主题介绍如何为工作负载集群自定义 Pod 和容器网络连接，包括使用默认 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. 创建一个包含以下 Kubernetes 对象的 YAML 文件：

    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 是 pod 的 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 提供程序

要在工作负载集群（如 macvlan、ipvlan、SR-IOV 或 DPDK）上启用多个 CNI 提供程序，请将 Multus 软件包安装到已运行 Antrea 或 Calico CNI 的集群上，并为 CNI 创建其他 NetworkAttachmentDefinition 资源。然后，您可以在集群中创建新 pod，以便对不同的地址范围使用不同的网络接口。

有关说明，请参见在工作负载集群上部署 Multus。

部署具有可路由、无 NAT IP 地址的 Pod (NSX)

在使用 NSX 网络连接和 Antrea 容器网络接口 (CNI) 的 vSphere 上，您可以为工作负载集群配置其工作 pod 的可路由 IP 地址，绕过网络地址转换 (NAT) 以便 pod 发出和接收外部请求。

Pod 上的可路由 IP 地址允许您：

  • 跟踪对通用共享服务的出站请求，因为其源 IP 地址是可路由的 pod IP 地址，而不是 NAT 地址。
  • 支持绕过 NAT 直接从外部 Internet 发送到 pod 的经身份验证的入站请求。

为可路由 IP pod 配置 NSX

要将 NSX 配置为支持工作线程 Pod 的可路由 IP 地址，请运行以下命令：

  1. 浏览到 NSX 服务器，然后打开网络连接 (Networking)选项卡。

  2. 在连接 (Connectivity) > Tier-1 网关(Tier-1 Gateways)下，单击添加 Tier-1 网关(Add Tier-1 Gateway)，然后配置专用于可路由 IP Pod 的新 Tier-1 网关：

    • 名称 (Name)：为可路由的 Pod T1 网关创建名称。
    • 链接的 Tier-0 网关 (Linked Tier-0 Gateway)：选择 Tanzu Kubernetes Grid 的其他 Tier-1 网关使用的 Tier-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)并为包含可路由 pod 的工作负载集群节点配置新的 NSX 分段（逻辑交换机）：

    • 名称 (Name)：为工作负载集群节点的网络分段创建名称。
    • 连接 (Connectivity)：选择刚创建的 Tier-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 Pod

有关如何部署具有可路由、无 NAT IP 地址的工作线程 Pod 的 TKC 集群，请参见 v1beta1 示例：具有可路由 Pod 网络的集群。

具有可路由 IP 地址的独立管理集群部署的 Pod

要使用独立管理集群部署具有可路由的无 NAT IP 地址的工作线程 Pod 的工作负载集群，请执行以下操作。集群的 CLUSTER_CIDR 设置配置其可公开路由 IP 地址的范围。

  1. 按照创建工作负载集群配置文件中所述创建工作负载集群配置文件，如下所示：

    • 要设置分配给工作节点 Pod 的可路由 IP 地址块，您可以：
      • 在工作负载集群配置文件中设置 CLUSTER_CIDR，或者
      • 在 tanzu cluster create 命令前面添加 CLUSTER_CIDR= 设置，如以下步骤中所示。
    • 将 NSXT_POD_ROUTING_ENABLED 设置为 "true"。
    • 将 NSXT_MANAGER_HOST 设置为 NSX 管理器 IP 地址。
    • 将 NSXT_ROUTER_PATH 设置为新添加的 Tier-1 网关的可路由 IP 的清单路径。在 NSX Manager > 连接 (Connectivity) > Tier-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 令牌：设置 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

要测试工作负载 Pod 的可路由 IP 地址，请执行以下操作：

  1. 将 Web 服务器部署到可路由工作负载集群。

  2. 运行 kubectl get pods --o wide 以检索可路由 Pod 的 NAME、INTERNAL-IP 和EXTERNAL-IP 值，并验证列出的 IP 地址是否相同且在可路由 CLUSTER_CIDR 范围内。

  3. 运行 kubectl get nodes --o wide 以检索工作负载集群节点（包含可路由 IP Pod）的 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 服务器的可路由 Pod IP 列为源地址。

  5. 在浏览器中，登录到 NSX，然后导航到为可路由 IP pod 创建的 Tier-1 网关。

  6. 单击静态路由 (Static Routes)并确认已在可路由 CLUSTER_CIDR 范围内创建以下路由：

    1. 工作负载集群控制平面节点中 pod 的路由，下一个跃点 (Next Hops)显示为控制平面节点本身的地址。
    2. 工作负载集群的工作线程节点中 pod 的路由，下一个跃点 (Next Hops)显示为工作节点本身的地址。

删除可路由 IP

删除包含可路由 IP pod 的工作负载集群后，您可能需要从 T1 路由器中删除它们以释放这些可路由 IP 地址：

  1. 在 NSX manager > 连接 (Connectivity) > Tier-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 管理器 IP 地址和凭据
        • STATIC_ROUTE_PATH 是刚复制到剪贴板的路径。该名称以 /infra/tier-1s/ 开头，并且包含 /static-routes/。

为 CNI 设置网络策略

要限制工作负载集群访问 VMware vCenter Server 管理界面，请在 Antrea 和 Calico CNI 上设置相应的网络策略。配置这些策略时，仅筛选来自容器网络的流量。这些策略会阻止来自所有 Pod 的流量，但来自容器存储接口 (CSI) 和云提供程序接口 (CPI) Pod 的 Pod 除外。

为 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 功能状态。

节点的 Pod 安全策略 (PSP) 在 TKG v2.1 中已弃用，以反映它们在 Kubernetes 中的弃用情况；有关如何将 Pod 从 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 证书管理器
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