本主题介绍如何为 Tanzu Kubernetes Grid (TKG) 独立管理集群创建自定义 ClusterClass
资源,如何使用它创建基于类的工作负载集群,以及使用基于自定义 ClusterClass 的集群。
要使集群基于自定义 ClusterClass,请将其 spec.topology.class
设置为自定义 ClusterClass 名称。
这些过程不适用于具有 vSphere with Tanzu 主管的 TKG。
注意根据上游集群 API 文档,自定义 ClusterClass 是一种实验性 Kubernetes 功能。由于自定义 ClusterClass 可用的自定义范围,VMware无法测试或验证所有可能的自定义。客户负责测试、验证其自定义 ClusterClass 集群以及进行故障排除。客户可以提交有关其自定义 ClusterClass 集群的支持请求,VMware 技术支持团队会尽最大努力提供帮助,但无法保证解决针对自定义 ClusterClass 集群提出的每个问题。在生产环境中部署自定义 ClusterClass 集群之前,客户应了解这些风险。要使用默认
ClusterClass
资源创建工作负载集群,请按照集群部署步骤中的过程操作。
要创建自定义 ClusterClass,您需要在本地安装 ytt
、imgpkg
、Tanzu CLI 和 kubectl
。有关如何下载和安装 ytt
和 imgpkg
的信息,请参见安装 Carvel Tools。
要创建自定义 ClusterClass,VMware 建议从现有的默认 ClusterClass 清单或 YTT 模板开始,如创建基本 ClusterClass 清单所述。发布新版本的默认 ClusterClass 对象(例如,使用新版本的 TKG)时,您可以将覆盖应用于新版本,以便实施相同的自定义。此主题中的过程介绍了这种创建自定义 ClusterClass 对象的方法。
要在不使用现有模板的情况下编写全新的 ClusterClass 对象,请按照集群 API 文档中的写入 ClusterClass中的过程进行操作。
您可以根据默认 ClusterClass 清单或 Tanzu Kubernetes Grid 提供的 YTT 模板创建基本 ClusterClass 清单。您创建的任何自定义集群都应基于此基本 ClusterClass 清单。该过程有 3 个步骤:
有三种方法可用于为集群创建基本 ClusterClass 清单。
重要方法 2 和 3 适用于需要满足以下用例的高级用户:
- 您希望为 CI 系统生成自定义 ClusterClass 定义,而无需部署独立的管理集群。
- 您希望工作负载集群使用与管理集群不同的基础架构。
在 Tanzu Kubernetes Grid 2.3.0 及更高版本中,部署管理集群后,可以在 ~/.config/tanzu/tkg/clusterclassconfigs
文件夹中找到默认 ClusterClass 清单。
要查看部署了管理集群的目标平台的清单,请运行以下命令:
tree ~/.config/tanzu/tkg/clusterclassconfigs/
例如,如果您部署了管理集群到 vSphere,您将看到以下 YAML 文件。
.config/tanzu/tkg/clusterclassconfigs/
└── tkg-vsphere-default-v1.1.1.yaml
1 directory, 1 file
生成的清单包含有关已从管理集群部署中提取的目标平台的信息。您可以直接将其用作自定义 ClusterClass 创建的基本清单。有关后续步骤,请参见自定义基本 ClusterClass 清单。
安装 Tanzu CLI v0.90.1 或更高版本后,但在部署管理集群之前,可以在 ~/.config/tanzu/tkg/providers/infrastructure-<provider name>/<provider version>/cconly
文件夹中找到默认 ClusterClass 的 YTT 模板。您可以使用这些模板创建用于创建自定义 ClusterClass 的基本清单。
要查找模板,请根据您的目标平台运行相应的命令。
tree ~/.config/tanzu/tkg/providers/infrastructure-vsphere/v1.7.0/cconly
您将看到以下 YAML 文件。
.config/tanzu/tkg/providers/infrastructure-vsphere/v1.7.0/cconly
├── base.yaml
├── overlay-kube-apiserver-admission.yaml
└── overlay.yaml
1 directory, 3 files
tree ~/.config/tanzu/tkg/providers/infrastructure-aws/v2.1.3/cconly
您将看到以下 YAML 文件。
.config/tanzu/tkg/providers/infrastructure-aws/v2.1.3/cconly
├── base.yaml
├── overlay-kube-apiserver-admission.yaml
└── overlay.yaml
tree ~/.config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly/
您将看到以下 YAML 文件。
.config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly/
├── base.yaml
├── overlay-kube-apiserver-admission.yaml
└── overlay.yaml
创建一个名为 user_input.yaml
的 YTT 数据值文件,其中包含以下内容。
#@data/values
#@overlay/match-child-defaults missing_ok=True
---
将适用于目标平台的配置值添加至 user_input.yaml
。
您可以使用部署管理集群部署时使用的配置值。例如,vSphere的 user_input.yaml
文件将类似于以下内容:
#@data/values
#@overlay/match-child-defaults missing_ok=True
---
ENABLE_MHC: true
ENABLE_MHC_CONTROL_PLANE: true
ENABLE_MHC_WORKER_NODE: true
MHC_UNKNOWN_STATUS_TIMEOUT: 5m
MHC_FALSE_STATUS_TIMEOUT: 12m
MHC_MAX_UNHEALTHY_CONTROL_PLANE: 100%
MHC_MAX_UNHEALTHY_WORKER_NODE: 100%
NODE_STARTUP_TIMEOUT: 20m
VSPHERE_TLS_THUMBPRINT: 0A:B4:8F:2E:E4:34:82:90:D5:6A:F8:77:8C:8C:51:24:D2:49:3B:E8
VSPHERE_DATACENTER: /dc0
VSPHERE_DATASTORE: /dc0/datastore/sharedVmfs-0
VSPHERE_FOLDER: /dc0/vm
VSPHERE_NETWORK: /dc0/network/VM Network
VSPHERE_RESOURCE_POOL: /dc0/host/cluster0/Resources
VSPHERE_SERVER: xxx.xxx.xxx.xxx
VSPHERE_USERNAME: [email protected]
VSPHERE_CONTROL_PLANE_DISK_GIB: "20"
VSPHERE_CONTROL_PLANE_MEM_MIB: "8192"
VSPHERE_CONTROL_PLANE_NUM_CPUS: "4" VSPHERE_WORKER_DISK_GIB: "20"
VSPHERE_WORKER_MEM_MIB: "8192"
VSPHERE_WORKER_NUM_CPUS: "4"
VSPHERE_CLUSTER_CLASS_VERSION: "v1.1.1" # change it to the version in TKG BOM
NAMESPACE: "tkg-system" # DO NOT change it
使用 ytt
为您的目标平台生成基本 ClusterClass 清单。
ytt -f ~/.config/tanzu/tkg/providers/infrastructure-vsphere/v1.7.0/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml
ytt -f ~/.config/tanzu/tkg/providers/infrastructure-aws/v2.1.3/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml
ytt -f ~/.config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml
现在,您已为基础架构生成基本清单,有关后续步骤,请参见自定义基本 ClusterClass 清单。
默认 ClusterClass 的 YTT 模板也可以从 TKG 映像存储库下载。您可以使用这些模板创建用于创建自定义 ClusterClass 的基本清单。
从官方 TKG 注册表中的 providerTemplate
映像中提取 YTT 模板。
对于 TKG v2.4.0,providerTemplate
映象标记为 v0.31.0
。您可以通过搜索 providerTemplateImage
在 TKG BOM 文件中查找标记版本。
imgpkg pull -i projects.registry.vmware.com/tkg/tanzu_core/provider/provider-templates:v0.31.0 -o providers
您将看到类似以下内容的输出:
Pulling image 'projects.registry.vmware.com/tkg/tanzu_core/provider/provider-templates@sha256:b210d26c610800f5da4b3aa55bfbc8ffae9275fa2c4073a2b1332e2045a6e1da'
Extracting layer 'sha256:3ba336232c0e616b2b6c8f263593497c5a059a645f4c6137ea0eb658f4a8538a' (1/1)
Succeeded
YAML 模板文件将下载到 providers
文件夹中。
创建一个名为 user_input.yaml
的 YTT 数据值文件,其中包含以下内容。
#@data/values
#@overlay/match-child-defaults missing_ok=True
---
将适用于目标平台的配置值添加至 user_input.yaml
。
您可以使用部署管理集群部署时使用的配置值。例如,vSphere的 user_input.yaml
文件将类似于以下内容:
#@data/values
#@overlay/match-child-defaults missing_ok=True
---
ENABLE_MHC: true
ENABLE_MHC_CONTROL_PLANE: true
ENABLE_MHC_WORKER_NODE: true
MHC_UNKNOWN_STATUS_TIMEOUT: 5m
MHC_FALSE_STATUS_TIMEOUT: 12m
MHC_MAX_UNHEALTHY_CONTROL_PLANE: 100%
MHC_MAX_UNHEALTHY_WORKER_NODE: 100%
NODE_STARTUP_TIMEOUT: 20m
VSPHERE_TLS_THUMBPRINT: 0A:B4:8F:2E:E4:34:82:90:D5:6A:F8:77:8C:8C:51:24:D2:49:3B:E8
VSPHERE_DATACENTER: /dc0
VSPHERE_DATASTORE: /dc0/datastore/sharedVmfs-0
VSPHERE_FOLDER: /dc0/vm
VSPHERE_NETWORK: /dc0/network/VM Network
VSPHERE_RESOURCE_POOL: /dc0/host/cluster0/Resources
VSPHERE_SERVER: xxx.xxx.xxx.xxx
VSPHERE_USERNAME: [email protected]
VSPHERE_CONTROL_PLANE_DISK_GIB: "20"
VSPHERE_CONTROL_PLANE_MEM_MIB: "8192"
VSPHERE_CONTROL_PLANE_NUM_CPUS: "4" VSPHERE_WORKER_DISK_GIB: "20"
VSPHERE_WORKER_MEM_MIB: "8192"
VSPHERE_WORKER_NUM_CPUS: "4"
VSPHERE_CLUSTER_CLASS_VERSION: "v1.1.1" # change it to the version in TKG BOM
NAMESPACE: "tkg-system" # DO NOT change it
使用 ytt
为您的目标平台生成基本 ClusterClass 清单。
ytt -f providers/infrastructure-vsphere/v1.7.0/cconly -f providers/config_default.yaml -f user_input.yaml
ytt -f providers/infrastructure-aws/v2.1.3/cconly -f providers/config_default.yaml -f user_input.yaml
ytt -f ~/.config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml
现在,您已为基础架构生成基本清单,有关后续步骤,请参见自定义基本 ClusterClass 清单。
要自定义 ClusterClass 清单,请创建该清单旁边的 ytt
覆盖文件。以下示例显示了如何在 ClusterClass 定义中修改 Linux 内核参数。
创建 custom
文件夹,结构如下所示:
tree custom
custom
|-- overlays
|-- filter.yaml
|-- kernels.yaml
编辑 custom/overlays/kernels.yaml
。
例如,添加 nfConntrackMax
为变量,然后为其定义一个修补程序,该修补程序将其值添加到控制平面节点的内核参数 net.netfilter.nf_conntrack_max
。
此覆盖网络在 preKubeadmCommands
字段附加一个命令,以将配置写入到 sysctl.conf
。要使设置生效,可以附加命令 sysctl -p
以应用此更改。默认 ClusterClass 定义不可变,因此此覆盖网络还会通过添加 -extended
来更改自定义 ClusterClass 及其所有模板的名称。
cat custom/overlays/kernels.yaml
#@ load("@ytt:overlay", "overlay")
#@overlay/match by=overlay.subset({"kind":"ClusterClass"})
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: ClusterClass
metadata:
name: tkg-vsphere-default-v1.1.1-extended
spec:
variables:
- name: nfConntrackMax
required: false
schema:
openAPIV3Schema:
type: string
patches:
- name: nfConntrackMax
enabledIf: '{{ not (empty .nfConntrackMax) }}'
definitions:
- selector:
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlaneTemplate
matchResources:
controlPlane: true
jsonPatches:
- op: add
path: /spec/template/spec/preKubeadmCommands/-
valueFrom:
template: echo "net.netfilter.nf_conntrack_max={{ .nfConntrackMax }}" >> /etc/sysctl.conf
- op: add
path: /spec/template/spec/preKubeadmCommands/-
value: sysctl -p
移除不希望更改的资源。
在此示例中,所有模板都将在自定义和默认 ClusterClass 之间共享,以便全部移除。您也可以以同样的方式基于默认模板创建自定义模板,在这种情况下,请确保不排除 kind
。
cat custom/overlays/filter.yaml
#@ load("@ytt:overlay", "overlay")
#@overlay/match by=overlay.not_op(overlay.subset({"kind": "ClusterClass"})),expects="0+"
---
#@overlay/remove
使用默认 ClusterClass 清单生成基本 ClusterClass。
ytt -f tkg-vsphere-default-v1.1.1.yaml -f custom/overlays/filter.yaml > default_cc.yaml
生成自定义 ClusterClass。
ytt -f tkg-vsphere-default-v1.1.1.yaml -f custom/ > custom_cc.yaml
(可选)检查默认 ClusterClass 与自定义 ClusterClass 之间的差异,以确认更改已应用。
diff default_cc.yaml custom_cc.yaml
您应看到类似如下的输出内容:
4c4
< name: tkg-vsphere-default-v1.1.1
---
> name: tkg-vsphere-default-v1.1.1-extended
638a639,643
> - name: nfConntrackMax
> required: false
> schema:
> openAPIV3Schema:
> type: string
2607a2613,2628
> - name: nfConntrackMax
> enabledIf: '{{ not (empty .nfConntrackMax) }}'
> definitions:
> - selector:
> apiVersion: controlplane.cluster.x-k8s.io/v1beta1
> kind: KubeadmControlPlaneTemplate
> matchResources:
> controlPlane: true
> jsonPatches:
> - op: add
> path: /spec/template/spec/preKubeadmCommands/-
> valueFrom:
> template: echo "net.netfilter.nf_conntrack_max={{ .nfConntrackMax }}" >> /etc/sysctl.conf
> - op: add
> path: /spec/template/spec/preKubeadmCommands/-
> value: sysctl -p
在此示例中,您可以看到已将 -extended
添加到集群名称中。
要使管理集群能够使用自定义 ClusterClass,请通过应用新清单来安装它。
应用 ClusterClass 清单。
kubectl apply -f custom_cc.yaml
您会看到以下输出。
clusterclass.cluster.x-k8s.io/tkg-vsphere-default-v1.1.1-extended created
检查自定义 ClusterClass 是否已传播到默认命名空间,例如:
kubectl get clusterclass
您会看到以下输出。
NAME AGE
tkg-vsphere-default-v1.1.1 2d23h
tkg-vsphere-default-v1.1.1-extended 11s
创建自定义 ClusterClass 后,您可以使用它创建包含自定义的新工作负载集群。
使用 --dry-run
选项运行 tanzu cluster create
,以从标准集群配置文件生成集群清单。
tanzu cluster create --file workload-1.yaml --dry-run > default_cluster.yaml
创建 ytt
覆盖网络或直接编辑集群清单。
建议的选项是创建 ytt
覆盖网络(例如,cluster_overlay.yaml
)以执行以下操作:
topology.class
值替换为自定义 ClusterClass 的名称variables
块与修改 ClusterClass 对象规范一样,只要存在新的上游集群版本,按如下方式使用覆盖网络,即可自动将更改应用于新对象。
#@ load("@ytt:overlay", "overlay")
#@overlay/match by=overlay.subset({"kind":"Cluster"})
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
spec:
topology:
class: tkg-vsphere-default-v1.1.1-extended
variables:
- name: nfConntrackMax
value: "1048576
生成 custom_cluster.yaml
清单:
ytt -f default_cluster.yaml -f cluster_overlay.yaml > custom_cluster.yaml
(可选)与上面的 ClusterClass 一样,可以运行 diff
以将自定义类集群清单与基于默认类的集群进行比较,例如:
diff custom_cluster.yaml default_cluster.yaml
您应看到类似如下的输出内容:
< class: tkg-vsphere-default-v1.1.1
---
> class: tkg-vsphere-default-v1.1.1-extended
142a143,144
> - name: nfConntrackMax
> value: "1048576"
根据上面生成的自定义清单创建自定义工作负载集群,如下所示。
创建集群。
tanzu cluster create -f custom_cluster.yaml
检查创建的对象属性。
例如,对于上述内核修改,请检索 KubeadmControlPlane
对象并确认已设置内核配置:
kubectl get kcp workload-1-jgwd9 -o yaml
您应看到类似如下的输出内容:
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
...
preKubeadmCommands:
- hostname "{{ ds.meta_data.hostname }}"
- echo "::1 ipv6-localhost ipv6-loopback" >/etc/hosts
- echo "127.0.0.1 localhost" >>/etc/hosts
- echo "127.0.0.1 {{ ds.meta_data.hostname }}" >>/etc/hosts
- echo "{{ ds.meta_data.hostname }}" >/etc/hostname
- echo "net.netfilter.nf_conntrack_max=1048576" >> /etc/sysctl.conf
- sysctl -p
...
登录到控制平面节点并确认其 sysctl.conf
已修改:
capv@workload-1-jgwd9:~$ sudo cat /etc/sysctl.conf
...
net.ipv6.neigh.default.gc_thresh3=16384
fs.file-max=9223372036854775807
net.netfilter.nf_conntrack_max=1048576
如果使用先前版本创建了自定义集群,则可以将其升级到最新的 TKG 版本。
升级集群之前,需要执行一些准备步骤。
在升级管理集群之前,请使用为上一版本创建的自定义清单版本创建测试集群。
例如,创建一个名为 test-upgrade
的自定义集群。
获取 TKG 2.2 管理集群提供的 ClusterClass 版本的相关信息。
kubectl get clusterclass
如果使用 TKG v2.2.0 创建自定义集群,ClusterClass 版本应为 1.0.0。例如:
NAME AGE
tkg-vsphere-default-extended-v1.0.0 21m
tkg-vsphere-default-v1.0.0 10d
获取有关在 test-upgrade
集群中运行的 ClusterClass 版本的信息。
kubectl get cluster test-upgrade -o jsonpath='{.spec.topology.class}'
输出应为 tkg-vsphere-default-extended-v1.0.0
。
按照升级独立管理集群中的说明操作,将管理集群升级到 TKG 2.4。
获取将管理集群升级到 v.2.4 后可用的 ClusterClass 版本的相关信息。
kubectl get cluster mgmt-cluster-name -n tkg-system -o jsonpath='{.spec.topology.class}'
如果管理集群在 vSphere 上运行,输出应为 tkg-vsphere-default-v1.1.1
。
tkg-vsphere-default-v1.1.1-extended
并与旧版 tkg-vsphere-default-extended-v1.0.0
包含相同的自定义变量。custom_cc.yaml
。在管理集群中安装新的自定义 ClusterClass。
kubectl apply -f custom_cc.yaml
获取管理集群现在可用的 ClusterClass 版本的相关信息。
kubectl get clusterclass
应同时显示旧版本和较新版本。
NAME AGE
tkg-vsphere-default-extended-v1.0.0 61m
tkg-vsphere-default-v1.0.0 10d
tkg-vsphere-default-v1.1.1 25m
tkg-vsphere-default-v1.1.1-extended 15s
在执行准备步骤后,可以在升级生产集群之前在测试集群上测试升级。
将集群 test-upgrade
从旧版本的自定义 ClusterClass 调整为新版本。
kubectl patch cluster test-upgrade --type merge -p '{"spec": {"topology": {"class": "tkg-vsphere-default-v1.1.1-extended"}}}'
输出应为 cluster.cluster.x-k8s.io/test-upgrade patched
。
获取有关当前在 test-upgrade
集群中运行的 ClusterClass 版本的信息。
kubectl get cluster test-upgrade -o jsonpath='{.spec.topology.class}'
输出应为 tkg-vsphere-default-v1.1.1-extended
。以前其为 tkg-vsphere-default-extended-v1.0.0
。
等待几分钟,然后运行 kubectl get cluster
,直到看到 UpdatesAvailable
已更新为 true
。
kubectl get cluster test-upgrade -o yaml
准备就绪后,输出中应显示类似于以下内容的消息:
...
status:
conditions:
...
- lastTransitionTime: "2023-06-19T09:59:21Z"
message: '[v1.25.9+vmware.1-tkg.1-20230609 v1.26.4+vmware.1-tkg.1-20230609]'
status: "True"
type: UpdatesAvailable
controlPlaneReady: true
infrastructureReady: true
observedGeneration: 5
phase: Provisioned
升级 test-upgrade
集群。
tanzu cluster upgrade test-upgrade
检查创建的对象属性。
例如,对于上述示例中所述的内核修改,请检索 KubeadmControlPlane
对象并确认已设置内核配置:
kubectl get kcp test-upgrade-nsc6d -o yaml
您应看到类似如下的输出内容:
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
...
preKubeadmCommands:
- hostname "{{ ds.meta_data.hostname }}"
- echo "::1 ipv6-localhost ipv6-loopback" >/etc/hosts
- echo "127.0.0.1 localhost" >>/etc/hosts
- echo "127.0.0.1 {{ ds.meta_data.hostname }}" >>/etc/hosts
- echo "{{ ds.meta_data.hostname }}" >/etc/hostname
- sed -i 's|".*/pause|"projects-stg.registry.vmware.com/tkg/pause|' /etc/containerd/config.toml
- systemctl restart containerd
- echo "net.netfilter.nf_conntrack_max=1048576" >> /etc/sysctl.conf
- sysctl -p
如果测试升级成功,请在生产集群上重复执行升级中的步骤。
注意如果在升级过程中遇到任何错误,可以通过将集群从新版本的自定义 ClusterClass 重新设置为旧版本来回滚。
如果已创建具有默认 ClusterClass 的集群,并且希望将其更新为使用自定义 ClusterClass,请使用 kubectl
编辑集群对象:
spec.topology.class
更改为自定义 ClassClass 清单的名称。spec.topology.variables
以附加自定义变量。如果要恢复为新版本的默认 ClusterClass:
spec.topology.class
更改为新版本的默认 ClusterClass。spec.topology.variables
以移除自定义变量。您可能需要添加在新版本的默认 ClusterClass 中定义的新变量。