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

 

具有 ytt 的旧版集群配置

本主题介绍如何使用 ytt 覆盖网络来配置由 Tanzu Kubernetes Grid (TKG) 部署的旧版 TKC 和基于计划的工作负载集群，以设置集群配置文件中的配置变量无法设置的集群和底层对象属性，如使用配置文件配置主管部署的集群（对于 TKC 集群）或配置文件变量参考（对于基于计划的集群）所列。

基于类的集群不需要也不支持 ytt 覆盖网络，因为所有可配置属性都可以在简化的 Cluster 对象本身的高级别设置。如果 Tanzu CLI 在对基于类的集群执行 tanzu cluster create 时检测到计算机上的 ytt，则会输出 It seems like you have done some customizations to the template overlays. 错误

概览

对于 TKC 和基于计划的工作负载集群的高级配置，要设置集群配置变量无法设置的对象属性，您可以自定义任何引导计算机的本地 ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere 目录中的 TKC、基于计划的集群和集群计划配置文件。

您可以直接添加或修改配置文件或使用 ytt 覆盖来自定义这些配置。

直接自定义配置文件更简单，但如果熟悉 ytt 覆盖网络，它们允许您在不同的范围内自定义配置并管理多个模块化配置文件，而不会对上游和继承的配置值进行破坏性编辑。ytt 覆盖网络仅适用于使用 Tanzu CLI 创建的新 TKC 和基于计划的工作叜集群。

有关各种形式的集群配置的工作原理和优先级的详细信息，请参见关于 Tanzu Kubernetes Grid 中的关于旧版 TKC 和基于计划的集群配置。

ytt 行为和约定

ytt 处理的行为和约定包括：

优先级：ytt 按文件名字母顺序深度优先遍历目录，并在继续时覆盖重复的设置。存在重复定义时，ytt 最后处理的定义优先。

覆盖类型：不同的 ytt 覆盖类型会更改或设置不同的内容：

  • 数据值文件设置或修改配置值而不修改对象的结构。其中包括物料清单 (BoM) 文件以及（按照约定）文件名中包含 data 的文件。

  • 覆盖文件更改对象结构定义。按约定，这些文件的文件名中有 overlay。

有关 ytt（包括覆盖示例和交互式验证器工具）的详细信息，请参见：

集群和集群计划

对于 TKC 和基于计划的集群，引导计算机的 ~/.config/tanzu/tkg/providers/ 目录包括 ytt 目录和不同级别的 overlay.yaml 文件，允许您确定每个级别的配置设置范围。

  • 提供程序和版本特定的 ytt 目录。例如，~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/v1.1.0。
    • 提供程序 API 版本的特定配置。
    • base-template.yaml 文件包含全大写占位符，如 "${CLUSTER_NAME}"，不应进行编辑。
    • overlay.yaml 文件量身定制为将值覆盖到 base-template.yaml 中。
  • 提供程序围的 ytt 目录。例如，~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/ytt。
    • 适用于所有版本的提供程序范围的配置。
  • 顶级 ytt 目录，~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/ytt。
    • 跨提供程序配置。
    • 组织到编号目录中，并按编号顺序进行处理。
    • 您可以为优先于编号较低的任何 ytt 子目录的配置创建 /04_user_customizations 子目录。

ytt 覆盖网络

本节包含用于自定义由独立管理集群部署的基于计划的工作负载集群以及创建新集群计划的覆盖网络。

限制：

  • 您只能使用 ytt 覆盖网络修改工作负载集群。不支持使用 ytt 覆盖网络修改独立管理集群。
  • 工作负载集群覆盖仅在创建集群时应用，而不修改现有集群。有关如何修改现有集群的信息，请参见修改现有集群中的资源。

以下示例说明了如何使用配置覆盖文件自定义工作负载集群和创建新的集群计划。

对于在集群中自定义受信任证书的覆盖文件，请参见管理集群密钥和证书主题中的配置具有多个受信任注册表的集群。

vSphere 上的名称服务器

此示例将一个或多个自定义名称服务器添加到 vSphere 上的 legac7 Tanzu Kubernetes Grid 集群中的工作节点和控制平面节点。它停用从 DHCP 进行 DNS 解析，以便优先使用自定义名称服务器。

要在基于类的集群中配置自定义名称服务器，请使用配置变量 CONTROL_PLANE_NODE_NAMESERVERS 和 WORKER_NODE_NAMESERVERS。

两个覆盖文件适用于控制平面节点，其他两个适用于工作节点。您可以将所有四个文件添加到 ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/ 目录中。

覆盖网络文件因节点基于 Ubuntu 还是 Photon 计算机映像而异，并且 Ubuntu 不需要 DHCP 覆盖网络文件。

每个 overlay-dns 文件中的一行设置名称服务器地址。以下代码显示单个名称服务器，但您可以将多个名称服务器指定为列表，例如 nameservers: ["1.2.3.4","5.6.7.8"]。

文件 vsphere-overlay-dns-control-plane.yaml：

  • Ubuntu：

    #@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-control-plane"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]
          #@overlay/match missing_ok=True
          dhcp4Overrides:
            useDNS: false

  • Photon：

    #@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-control-plane"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]

文件 vsphere-overlay-dns-workers.yaml：

  • Ubuntu：

    #@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-worker"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]
          #@overlay/match missing_ok=True
          dhcp4Overrides:
            useDNS: false

  • Photon：

    #@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-worker"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]

文件 vsphere-overlay-dhcp-control-plane.yaml（仅限 Photon）：

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"})
---
spec:
  kubeadmConfigSpec:
    preKubeadmCommands:
    #! disable dns from being emitted by dhcp client
    #@overlay/append
    - echo '[DHCPv4]' >> /etc/systemd/network/10-cloud-init-eth0.network
    #@overlay/append
    - echo 'UseDNS=false' >> /etc/systemd/network/10-cloud-init-eth0.network
    #@overlay/append
    - '/usr/bin/systemctl restart systemd-networkd 2>/dev/null'

文件 vsphere-overlay-dhcp-workers.yaml（仅限 Photon）：

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}),expects="1+"
---
spec:
  template:
    spec:
      #@overlay/match missing_ok=True
      preKubeadmCommands:
      #! disable dns from being emitted by dhcp client
      #@overlay/append
      - echo '[DHCPv4]' >> /etc/systemd/network/10-cloud-init-eth0.network
      #@overlay/append
      - echo 'UseDNS=false' >> /etc/systemd/network/10-cloud-init-eth0.network
      #@overlay/append
      - '/usr/bin/systemctl restart systemd-networkd 2>/dev/null'

具有 NSX ALB 的 FQDN 控制平面端点

要在 vSphere with NSX Advanced Load Balancer 上创建工作负载集群并将 VSPHERE_CONTROL_PLANE_ENDPOINT 设置为 FQDN 而非 IP 地址，请在 .config/tanzu/tkg/providers/infrastructure-vsphere/ytt/ 目录（如 fqdn-cert-api.yaml）中创建覆盖网络文件，其内容如下：

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")
#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"}), expects="1+"
#@overlay/match-child-defaults missing_ok=True
---

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
metadata:
  name: #@ "{}-control-plane".format(data.values.CLUSTER_NAME)
spec:
  kubeadmConfigSpec:
    clusterConfiguration:
      apiServer:
        certSANs:
        - CONTROLPLANE-FQDN

其中，CONTROLPLANE-FQDN 是工作负载集群控制平面的 FQDN。

在覆盖网络就位后，创建集群。

创建集群后，请按照配置节点 DHCP 预留和端点 DNS 记录（仅限 vSphere）过程创建 DNS 记录。

在创建具有 FQDN 端点的其他每个集群之前，请根据需要在覆盖网络中修改 CONTROLPLANE-FQDN 设置。

解析 .local 域

在现代 Linux 系统中，尝试解析域后缀以 .local 结尾的主机名可能会失败。出现此问题的原因是 systemd-networkd（大多数 Linux 分发包中的 DNS 解析程序）尝试通过多播 DNS (mDNS) 来解析 .local 域，而不是通过标准 DNS 服务器。

要在基于类的集群中配置 .local 域解析，请使用配置变量 CONTROL_PLANE_NODE_SEARCH_DOMAINS 和 WORKER_NODE_SEARCH_DOMAINS。

要解决旧版集群中的这个已知问题，请在 searchDomainsvsphere-overlay-dns-control-plane.yaml 和~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/ 目录中的 vsphere-overlay-dns-workers.yaml 文件的末尾添加本地域后缀。

vsphere-overlay-dns-control-plane.yaml 文件的示例：

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-control-plane"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]
          searchDomains: ["corp.local"]

vsphere-overlay-dns-workers.yaml 文件的示例：

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-worker"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]
          searchDomains: ["corp.local"]

在没有 DHCP 选项 42 的情况下配置 NTP (vSphere)

Tanzu Kubernetes Grid 集群中的 TLS 身份验证需要精确的时间同步。在大多数基于 DHCP 的环境中，您可以使用 DHCP 选项 42 配置同步。

如果要在缺少 DHCP 选项 42 的 vSphere 环境中部署旧版集群，请按如下所示使用覆盖代码，使 Tanzu Kubernetes Grid 使用保持同步的 NTP 服务器创建集群

要在基于类的集群中配置 NTP，请使用配置变量 NTP_SERVERS。

  • 在 ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/ 目录中，创建一个新的 .yaml 文件或使用以下代码扩充现有覆盖文件，将示例 time.google.com 更改为所需的 NTP 服务器：

    #@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"})
---
spec:
  kubeadmConfigSpec:
    #@overlay/match missing_ok=True
    ntp:
      #@overlay/match missing_ok=True
      enabled: true
      #@overlay/match missing_ok=True
      servers:
        - time.google.com

#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}),expects="1+"
---
spec:
  template:
    spec:
      #@overlay/match missing_ok=True
      ntp:
        #@overlay/match missing_ok=True
        enabled: true
        #@overlay/match missing_ok=True
        servers:
          - time.google.com

自定义节点标签

创建旧版集群时，此覆盖会将持久性标签分配给集群节点。这非常有用，因为通过 kubectl 手动应用的标签不会通过节点替换来保留。

请参见 ytt 覆盖中的额外变量。

要为基于类的集群中的控制平面节点配置自定义节点标签，请使用配置变量 CONTROL_PLANE_NODE_LABELS。

  1. 在 ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/ 目录中，创建一个新的 .yaml 文件或使用以下代码扩充现有的覆盖文件。

    对于控制平面节点标签，请配置 initConfiguration 和 joinConfiguration 部分，以便将标签应用于创建的第一个节点以及之后加入的所有节点：

    #@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"})
---
spec:
  kubeadmConfigSpec:
    initConfiguration:
      nodeRegistration:
        kubeletExtraArgs:
          #@overlay/match missing_ok=True
          node-labels: NODE-LABELS
    joinConfiguration:
      nodeRegistration:
        kubeletExtraArgs:
          #@overlay/match missing_ok=True
          node-labels: NODE-LABELS

    其中，NODE-LABELS 是一个以逗号分隔的标签键/值字符串列表，其中包括node-type=control-plane（例如 "examplekey1=labelvalue1,examplekey2=labelvalue2"）。

    对于工作节点标签：

    #@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}),expects="1+"
---
spec:
  template:
    spec:
      joinConfiguration:
        nodeRegistration:
          kubeletExtraArgs:
            #@overlay/match missing_ok=True
            node-labels: NODE-LABELS

    其中，NODE-LABELS 是一个以逗号分隔的标签键/值字符串列表，其中包括node-type=worker（例如 "examplekey1=labelvalue1,examplekey2=labelvalue2"）。

在 AWS 上停用 Bastion 主机

有关停用 AWS 上工作负载集群的 Bastion 主机的覆盖示例，请参见 TKG Lab 存储库中的在 AWS 上停用 Bastion 服务器。

新计划 nginx

此示例将添加并配置一个新的工作负载集群计划 nginx，该计划将运行 nginx 服务器。该计划使用集群资源集 (CRS) 将 nginx 服务器部署到使用 vSphere 集群 API 提供程序版本 v0.7.6 创建的 vSphere 集群。

  1. 在 .tkg/providers/infrastructure-vsphere/v0.7.6/ 中，添加一个新文件 cluster-template-definition-nginx.yaml,内容与 cluster-template-definition-dev.yaml 和 cluster-template-definition-prod.yaml 文件相同：

    apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TemplateDefinition
spec:
  paths:
    - path: providers/infrastructure-vsphere/v0.7.6/ytt
    - path: providers/infrastructure-vsphere/ytt
    - path: providers/ytt
    - path: bom
      filemark: text-plain
    - path: providers/config_default.yaml

    存在此文件时将创建一个新计划，并且 tanzu CLI 会解析其文件名，以创建传递到 tanzu cluster create --plan 的选项nginx。

  2. 在 ~/.config/tanzu/tkg/providers/ytt/04_user_customizations/ 中，创建一个新文件 deploy_service.yaml，包含：

    #@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")
#@ load("@ytt:yaml", "yaml")

#@ def nginx_deployment():
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
#@ end

#@ if data.values.TKG_CLUSTER_ROLE == "workload" and data.values.CLUSTER_PLAN == "nginx":

---
apiVersion: addons.cluster.x-k8s.io/v1beta1
kind: ClusterResourceSet
metadata:
  name: #@ "{}-nginx-deployment".format(data.values.CLUSTER_NAME)
  labels:
    cluster.x-k8s.io/cluster-name: #@ data.values.CLUSTER_NAME
spec:
  strategy: "ApplyOnce"
  clusterSelector:
    matchLabels:
      tkg.tanzu.vmware.com/cluster-name: #@ data.values.CLUSTER_NAME
  resources:
  - name: #@ "{}-nginx-deployment".format(data.values.CLUSTER_NAME)
    kind: ConfigMap
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: #@ "{}-nginx-deployment".format(data.values.CLUSTER_NAME)
type: addons.cluster.x-k8s.io/resource-set
stringData:
  value: #@ yaml.encode(nginx_deployment())

#@ end

    在此文件中，条件 #@ if data.values.TKG_CLUSTER_ROLE == "workload" and data.values.CLUSTER_PLAN == "nginx": 会将下面的覆盖应用于计划 nginx 的工作负载集群。

    如果顶层 ytt 目录下不存在 04_user_customizations 目录，请创建该目录。

ytt 覆盖中的额外变量

覆盖将其配置应用于所有新创建的集群。要使用不同的覆盖设置单独自定义集群，可以将覆盖与添加到集群配置中的自定义变量进行组合。

此示例显示如何使用额外的集群配置变量为不同的集群设置自定义节点标签。

注意

升级 Tanzu CLI 后，您需要将这些更改重新应用于新的 ~/.config/tanzu/tkg/providers 目录。以前的版本将作为时间戳备份进行重命名。

通过配置变量的节点标签

将 WORKER_NODE_LABELS 变量添加到默认配置和集群配置文件中，可以创建具有不同工作节点标签的新集群。

  1. 编辑 ~/.config/tanzu/tkg/providers/config_default.yaml 并在底部添加自定义变量默认值：

    #! ---------------------------------------------------------------------
#! Custom variables
#! ---------------------------------------------------------------------

WORKER_NODE_LABELS: ""

    如果集群的配置文件缺少此变量，则设置此默认值可防止将不需要的标签添加到集群。

  2. 在 ~/.config/tanzu/tkg/providers/ytt/lib/config_variable_association.star 末尾处添加一行（最后一个右括号上方），将新变量与提供程序类型相关联。

    "WORKER_NODE_LABELS": ["vsphere", "aws", "azure"],
}

end

  3. 在 ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/ 目录中，创建一个新的 .yaml 文件或使用以下代码扩充现有覆盖文件，该代码会将 WORKER_NODE_LABELS 变量添加为数据值：

    #@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}),expects="1+"
---
spec:
  template:
    spec:
      joinConfiguration:
        nodeRegistration:
          kubeletExtraArgs:
            #@overlay/match missing_ok=True
            node-labels: #@ data.values.WORKER_NODE_LABELS

  4. 对于任何新的工作负载集群，现在可以在其集群配置变量文件中设置 WORKER_NODE_LABEL，以将其值作为标签应用于每个集群节点。

    WORKER_NODE_LABELS: "workload-classification=production"

修改现有集群中的资源

ytt 覆盖仅适用于使用登录到独立管理集群的 Tanzu CLI 部署的基于计划的新工作负载集群。要修改已存在的集群的资源，您需要在独立管理集群中对其进行修改，并将其推送到工作负载集群，如下所述。

修改不带 DHCP 选项 42 的 NTP (vSphere)

此过程为现有集群提供了在没有 DHCP 选项 42 (vSphere) 的情况下配置 NTP 覆盖适用于新集群的修改。

修改现有集群上的 NTP 设置需要：

  • 创建新 KubeadmConfigTemplate 资源以反映新设置
  • 更新工作节点的 MachineDeployment 以指向新资源
  • 更新 KubeadmControlPlane 资源以更新控制平面节点
    • 在 v1.5 之前的 Tanzu Kubernetes Grid 版本中，无法更新控制平面节点上的 NTP。

要修改现有集群上的 NTP 设置，请从管理集群以及包含要修改的集群的命名空间中运行以下命令（在本示例中名为 cluster1）：

  1. 为每个 KubeadmConfigTemplate/MachineDeployment 对创建新的 KubeadmConfigTemplate 资源并更新 MachineDeployment。对于 prod 计划集群，请执行此过程三次：

    1. 为工作节点创建新的 KubeadmConfigTemplate 资源。

      • 找到现有 KubeadmConfigTemplate 并将其导出到 yaml 文件进行编辑。

        kubectl get KubeadmConfigTemplate
kubectl get KubeadmConfigTemplate cluster1-md-0 -o yaml > cluster1-md-0.yaml

      • 编辑导出的文件，方法是将 ntp 部分添加到现有 spec.template.spec 部分下面，并将 -v1 附加到 metadata 下的 name 字段，假设这是第一次更新：

        metadata:
...
  name: cluster1-md-0-v1  # from cluster1-md-0
...
kubeadmConfigSpec:
  ntp:
    enabled: true
    servers:
      - time.google.com

      • 应用更新的 yaml 文件以创建新资源。

        kubectl apply -f cluster1-md-0.yaml

    2. 更新 MachineDeployment 资源以指向新创建的 KubeadmConfigTemplate 资源。

      1. 查找和编辑集群的现有 MachineDeployment 资源。

        kubectl get MachineDeployment
kubectl edit MachineDeployment cluster1-md-0

      2. 编辑 spec.template.spec.bootstrap.configRef.name 值，以设置 KubeadmConfigTemplate 资源的新名称。

        spec:
  template:
      ...
      spec:
        bootstrap:
          configRef:
            apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
            kind: KubeadmConfigTemplate
            name: cluster1-md-0-v1 # from cluster1-md-0

      3. 保存并退出文件，这会触发重新创建工作节点。

  2. 编辑控制平面节点的 KubeadmControlPlane 资源以包含 NTP 服务器。

    1. 查找和编辑集群的现有 KubeadmControlPlane 资源。

      kubectl get KubeadmControlPlane
kubectl edit KubeadmControlPlane cluster1-control-plane

    2. 编辑 spec.kubeadmConfigSpec 部分，方法是添加下面的新 ntp 部分。保存并退出文件。

      kubeadmConfigSpec:
  ntp:
    enabled: true
    servers:
      - time.google.com
check-circle-line exclamation-circle-line close-line
Scroll to top icon