本主题介绍如何为工作负载集群自定义 Pod 和容器网络连接,包括使用默认 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
对象,如下所示:
创建一个包含以下 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)。例如:
v1.23.5+vmware.1-tkg.1
(对于主管部署的集群)或v1.25.7---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
是 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
通过将上面步骤中创建的 Cluster
对象定义文件传递到 tanzu cluster create
命令的 -f
选项,创建工作负载集群。
要在主管部署的 TanzuKubernetesCluster
类型的工作负载集群行安装 calico
而不是 antrea
,请在计划用于创建工作负载集群的集群配置文件中设置 CNI
配置,然后将该文件传递到 tanzu cluster create
命令的 -f
选项。例如,CNI: calico
。
要在工作负载集群(如 macvlan、ipvlan、SR-IOV 或 DPDK)上启用多个 CNI 提供程序,请将 Multus 软件包安装到已运行 Antrea 或 Calico CNI 的集群上,并为 CNI 创建其他 NetworkAttachmentDefinition
资源。然后,您可以在集群中创建新 pod,以便对不同的地址范围使用不同的网络接口。
有关说明,请参见在工作负载集群上部署 Multus。
在使用 NSX 网络连接和 Antrea 容器网络接口 (CNI) 的 vSphere 上,您可以为工作负载集群配置其工作 pod 的可路由 IP 地址,绕过网络地址转换 (NAT) 以便 pod 发出和接收外部请求。
Pod 上的可路由 IP 地址允许您:
要将 NSX 配置为支持工作线程 Pod 的可路由 IP 地址,请运行以下命令:
浏览到 NSX 服务器,然后打开网络连接 (Networking)选项卡。
在连接 (Connectivity) > Tier-1 网关(Tier-1 Gateways)下,单击添加 Tier-1 网关(Add Tier-1 Gateway),然后配置专用于可路由 IP Pod 的新 Tier-1 网关:
单击保存 (Save)保存网关。
在连接 (Connectivity) > 分段 (Segments)下,单击添加分段 (Add Segment)并为包含可路由 pod 的工作负载集群节点配置新的 NSX 分段(逻辑交换机):
tz-overlay
。195.115.4.1/24
。此范围不应与 DHCP 配置文件服务器 IP 地址 (Server IP Address)值重叠。单击保存 (Save)保存网关。
有关如何部署具有可路由、无 NAT IP 地址的工作线程 Pod 的 TKC 集群,请参见 v1beta1 示例:具有可路由 Pod 网络的集群。
要使用独立管理集群部署具有可路由的无 NAT IP 地址的工作线程 Pod 的工作负载集群,请执行以下操作。集群的 CLUSTER_CIDR
设置配置其可公开路由 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/
开头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...
要测试工作负载 Pod 的可路由 IP 地址,请执行以下操作:
将 Web 服务器部署到可路由工作负载集群。
运行 kubectl get pods --o wide
以检索可路由 Pod 的 NAME
、INTERNAL-IP
和EXTERNAL-IP
值,并验证列出的 IP 地址是否相同且在可路由 CLUSTER_CIDR
范围内。
运行 kubectl get nodes --o wide
以检索工作负载集群节点(包含可路由 IP Pod)的 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 服务器的可路由 Pod IP 列为源地址。在浏览器中,登录到 NSX,然后导航到为可路由 IP pod 创建的 Tier-1 网关。
单击静态路由 (Static Routes)并确认已在可路由 CLUSTER_CIDR
范围内创建以下路由:
删除包含可路由 IP pod 的工作负载集群后,您可能需要从 T1 路由器中删除它们以释放这些可路由 IP 地址:
在 NSX manager > 连接 (Connectivity) > Tier-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 管理器 IP 地址和凭据STATIC_ROUTE_PATH
是刚复制到剪贴板的路径。该名称以 /infra/tier-1s/
开头,并且包含 /static-routes/
。要限制工作负载集群访问 VMware vCenter Server 管理界面,请在 Antrea 和 Calico CNI 上设置相应的网络策略。配置这些策略时,仅筛选来自容器网络的流量。这些策略会阻止来自所有 Pod 的流量,但来自容器存储接口 (CSI) 和云提供程序接口 (CPI) Pod 的 Pod 除外。
通过工作负载集群中的 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 安全标准中所述。
节点的 Pod 安全策略 (PSP) 在 TKG v2.1 中已弃用,以反映它们在 Kubernetes 中的弃用情况;有关如何将 Pod 从 PSP 迁移到 PSA 控制器,请参见从 PodSecurityPolicy 迁移到内置 PodSecurity 准入控制器。
默认情况下,Kubernetes v1.24 集群命名空间将其 Pod 安全 warn
和 audit
模式设置为 baseline
,这是一个不可强制执行的设置。这意味着,迁移到 PSA 控制器可能会生成有关 Pod 违反策略的警告,但 Pod 将继续运行。