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

 

查看和更新自动管理的软件包配置

本主题介绍了如何查看和自定义从 tanzu-core 存储库安装的自动管理软件包的配置以及对其进行故障排除。此外，还列出了您可以自定义的 Antrea、Pinniped、Calico、vSphere CPI 和 vSphere CSI 配置设置。

查看软件包配置

自动管理的软件包位于 tanzu-core 存储库中，其中包含支持基本集群功能的组件，例如 Antrea 或 Calico 容器网络接口以及 Pinniped 身份验证组件。在某些情况下，内部 Tanzu Kubernetes Grid 和 Kubernetes 资源将这些组件称为 addons。

要查看自动管理的软件包及其包含的附加模块组件的配置，您可以：

  • 通过对管理集群运行 kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE 命令，检索已安装附加模块组件的 Kubernetes 密钥。其中：

    • CLUSTER-NAME 是目标集群的名称。如果要检索工作负载集群中安装的附加模块组件的密钥，CLUSTER-NAME 是工作负载集群的名称。
    • PACKAGE-NAME 是软件包的名称。
    • CLUSTER-NAMESPACE 是目标集群的命名空间。

  • 从 projects.registry.vmware.com/tkg/packages/core 下载软件包配置文件。

例如，要查看 Antrea 的配置，请执行以下操作：

  • 通过对管理集群运行以下命令来检索 Antrea 密钥：

    kubectl get secret CLUSTER-NAME-antrea-addon -n CLUSTER-NAMESPACE

  • 下载 Antrea 软件包配置文件：

    1. 在用于创建集群的 Tanzu Kubernetes 版本 (TKr) 中找到 antrea 的版本标记。您可以通过对管理集群运行 kubectl get tkr 命令来检索 TKr。

      1. 运行 kubectl get clusters CLUSTER-NAME -n CLUSTER-NAMESPACE --show-labels。

      2. 在输出中，找到 tanzuKubernetesRelease 的值。例如，tanzuKubernetesRelease=v1.23.10---vmware.1-tkg.1。

      3. 运行 kubectl get tkr TKR-VERSION，其中 TKR-VERSION 是上面检索的值。例如：

        kubectl get tkr v1.23.10---vmware.1-tkg.1 -o yaml

      4. 在输出中，在 packages/core/antrea 下找到版本标记。

        或者，也可以通过在 ~/.config/tanzu/tkg/bom/YOUR-TKR-BOM-FILE 中查看 TKr 找到版本标记。

    2. 下载软件包配置文件。例如：

      imgpkg pull -b projects.registry.vmware.com/tkg/packages/core/antrea:v1.2.3_vmware.4-tkg.1-advanced -o antrea

    3. 导航到 antrea 并查看文件。

要了解有关 Antrea 容器网络连接功能的更多信息，请参见 VMware Container Networking with Antrea 1.4.0 发行说明。要了解有关将 Antrea 容器集群与 VMware NSX 集成的更多信息，请参见Antrea 容器集群的集群。

自定义软件包配置

由于自动管理的软件包由 Tanzu Kubernetes Grid 管理，因此通常不需要自定义工作负载集群中自动管理的软件包的配置。

但如果需要，可以自定义这些设置。如何自定义自动管理的软件包设置取决于集群的类型。

对于基于计划或 TKC 的集群，可以修改和修补组件密钥的 values.yaml 部分，以单独自定义现有集群，如自定义 values.yaml 设置中所述。

在某些情况下，对于基于计划或 TKC 的集群，可以将覆盖添加到管理集群中的软件包配置密钥，以便在创建集群之前对其进行自定义，如使用覆盖网络自定义中所述。

对于基于类的集群，可以在创建集群之前对其自定义，方法是按照创建基于类的集群中所述的两步过程的步骤 1 创建集群清单，然后将自定义对象定义添加到清单中，然后再在步骤 2 中创建集群。有关示例，请参见自定义基于类的清单。

自动管理的软件包 values.yaml 设置

您可以在自动管理的软件包中自定义以下配置设置。这些值在软件包组件密钥的 values.yaml 部分中设置：

软件包 设置 描述
Antrea antrea.config.defaultMTU 默认为 null。
Antrea antrea.config.tlsCipherSuites 默认情况下，包括启用了 FIPS 的密码套件。要切换到其他密码套件，请更新 tlsCipherSuites 字段下的值。
Calico calico.config.vethMTU 默认为 “0”，从而使 Calico 自动检测其最大传输大小 (MTU) 设置。设置此参数以字符串形式指定最大数据包大小（以字节为单位）。
Calico calico.config.skipCNIBinaries 默认值为 true，这会限制 Calico 在集群创建期间覆盖现有 CNI 插件的设置。升级集群时，为避免覆盖，请设置 calico.config.skipCNIBinaries=true。
Pinniped pinniped.supervisor_svc_external_dns 与 Pinniped 主管关联的 FQDN，用作 OIDC IDP 客户端中的回调 URL。根据 Pinniped 的服务类型，可能还需要包含端口号：
  • 对于 LoadBalancer，在具有 NSX ALB、AWS 或 Azure 的 vSphere 上，请不要不包含端口号：https://hr.tkg.example.com。
  • 对于 NodePort，如在没有 NSX ALB 的 vSphere 上一样，请包含端口号：https://hr.tkg.example.com:31234。
Pinniped pinniped.upstream_oidc_client_id OIDC 提供程序的客户端 ID。
Pinniped pinniped.upstream_oidc_client_secret OIDC 提供程序的客户端密码。
Pinniped pinniped.upstream_oidc_issuer_url OIDC 提供程序的 URL。
Pinniped pinniped.upstream_oidc_tls_ca_data 用于验证与 OIDC 提供程序的 TLS 连接的 base64 编码 CA 包数据。
Pinniped pinniped.upstream_oidc_additional_scopes 令牌响应中要请求的其他范围的列表。
Pinniped pinniped.upstream_oidc_claims OIDC 声明映射。
Pinniped dex.config.ldap.host* LDAP 服务器的 IP 或 DNS 地址。如果要将默认端口 636 更改为其他端口，请指定 “host:port”。
Pinniped dex.config.ldap.bindDN* 和 dex.config.ldap.BIND_PW_ENV_VAR* 应用程序服务帐户的 DN 和密码。
Pinniped dex.config.ldap.userSearch* 用户的搜索属性。有关结构定义，请参见 Dex 文档。
Pinniped dex.config.ldap.groupSearch* 组的搜索属性。有关结构定义，请参见 Dex 文档。
vSphere CSI vsphereCSI.provisionTimeout 默认为 300s。
vSphere CSI vsphereCSI.attachTimeout 默认为 300s。
vSphere CSI vsphereCSI.netPermissions 默认为 null。

* 如果要更新以 dex. 开头的 Pinniped 设置，请参见部署管理集群后更新 Dex 设置。

自定义 values.yaml 设置

要在已运行的基于计划或 TKC 的集群中自定义附加模块组件密钥的 values.yaml 部分，请执行以下操作：

  1. 通过对管理集群运行 kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE 命令来检索密钥。例如：

    kubectl get secret example-workload-cluster-antrea-addon -n example-workload-cluster-namespace -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml

  2. 更新 values.yaml 部分。您可以更新上表中列出的任何值。

  3. 通过对编辑的 values.yaml 文件进行 base64 编码应用更新，并在集群密钥中替换该文件。此命令因环境的操作系统而异：例如：

    Linux：

    kubectl patch secret/example-workload-cluster-antrea-addon -n example-workload-cluster-namespace -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=merge

    MacOS：

    kubectl patch secret/example-workload-cluster-antrea-addon -n example-workload-cluster-namespace -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge

  4. 更新秘钥后，通过运行 kubectl get packageinstall 命令检查软件包的状态。例如：

    $ kubectl get packageinstall antrea -n tkg-system
NAMESPACE    NAME                   PACKAGE NAME                      PACKAGE VERSION                 DESCRIPTION                  AGE
tkg-system   antrea                 antrea.tanzu.vmware.com           0.13.3+vmware.1-tkg.1           Reconcile succeeded          7d14h

    如果返回的状态为 Reconcile failed，请运行以下命令以获取有关失败的详细信息：

    kubectl get packageinstall antrea -n tkg-system -o yaml

  5. 运行 kubectl get app 命令。例如：

    $ kubectl get app antrea -n tkg-system
NAME           DESCRIPTION             SINCE-DEPLOY    AGE
antrea         Reconcile succeeded     3m23s           7h50m

    如果返回的状态为 Reconcile failed，请运行以下命令以获取有关失败的详细信息：

    kubectl get app antrea -n tkg-system -o yaml

以下示例更新了 Antrea 的默认最大传输单元 (MTU)。

stringData:
  values.yaml: |
    #@data/values
    #@overlay/match-child-defaults missing_ok=True
    ---
    infraProvider: vsphere
    antrea:
      config:
        defaultMTU: 8900
注意

确保为集群中的所有节点配置相同的 MTU 设置。防火墙设置必须允许配置 MTU 大小的数据包。要解决由集群中节点上的不同 MTU 设置引起的任何问题，请参见MTU 不匹配导致集群工作节点处于 NotReady 状态。

使用覆盖网络进行自定义

在某些情况下，您可以向附加模块组件密钥添加覆盖网络，以便在创建基于计划或 TKC 的集群之前自定义这些集群的自动管理软件包配置。

以下示例指示 Pinniped 使用 LoadBalancer 服务类型，而不是 NodePort，当 NSX Advanced Load Balancer (ALB) 未用作控制平面端点时，这是 vSphere 上的默认值：

...
stringData:
 overlays.yaml: |
   #@ load("@ytt:overlay", "overlay")
   #@overlay/match by=overlay.subset({"kind": "Service", "metadata": {"name": "pinniped-supervisor", "namespace": "pinniped-supervisor"}})
   ---
   #@overlay/replace
   spec:
     type: LoadBalancer
     selector:
       app: pinniped-supervisor
     ports:
       - name: https
         protocol: TCP
         port: 443
         targetPort: 8443
 values.yaml: |
   #@data/values
   #@overlay/match-child-defaults missing_ok=True
   ---
   infrastructure_provider: vsphere
   tkg_cluster_role: management

要添加覆盖网络，请执行以下操作：

  1. 通过对管理集群运行 kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE 命令来检索密钥。例如：

    kubectl get secret example-workload-cluster-pinniped-addon -n example-workload-cluster-namespace -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml

  2. 在 stringData 下添加 overlays.yaml 部分。

  3. 通过对编辑的 values.yaml 文件进行 base64 编码应用更新，并在集群密钥中替换该文件。此命令因环境的操作系统而异：例如：

    Linux：

    kubectl patch secret/example-workload-cluster-pinniped-addon -n example-workload-cluster-namespace -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=merge

    MacOS：

    kubectl patch secret/example-workload-cluster-pinniped-addon -n example-workload-cluster-namespace -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge

  4. 更新密钥后，通过运行 kubectl get packageinstall 和 kubectl get app 命令来检查软件包的状态，如自动管理的软件包 values.yaml 设置中所述。

自定义基于类的清单

对于基于类的集群，可以在创建集群之前对其自定义，方法是按照创建基于类的集群中所述的两步过程的步骤 1 创建集群清单，然后将自定义对象定义添加到清单中，然后再在步骤 2 中创建集群。

例如，要自定义 vSphere CSI 的 netPermissions 值，请修改使用 tanzu cluster create --dry-run 生成的清单，方法是在 VSphereCSIConfig 对象的 spec.vsphereCSI 定义块中添加类似以下内容的 netPermissions 块：

apiVersion: csi.tanzu.vmware.com/v1alpha1
kind: VSphereCSIConfig
[...]
spec:
  vsphereCSI:
    mode: vsphereCSI
    config:
      [...]
      provisionTimeout: 33s
      attachTimeout: 77s
      resizerTimeout: 99s
      netPermissions:
        PERM-1:
          ips: "*"
          permissions: READ_WRITE
          rootsquash: false
        PERM-2:
          ips: "10.20.20.0/24"
          permissions: READ_ONLY
          rootsquash: true
        PERM-3:
          ips: "10.30.30.0/24"
          permissions: NO_ACCESS

其中：

  • PERM-* 是您为权限设置的该部分指定的名称，可转换为 vSphere 配置密钥中的 [NetPermissions "PERM-1"] 等。
  • ips: 值是该部分为其设置权限的文件卷的地址范围。
  • permissions: 值是为该部分设置的权限。

修改清单后，可以按照创建基于类的集群中的步骤 2 创建集群。

排除软件包配置故障

要对集群中的自动管理的软件包配置进行故障排除，请查看并修改软件包的 PackageInstall 自定义资源 (CR) 和组件 Secret。

要对软件包配置应用临时更改，可能需要暂停协调 PackageInstall 和 Secret 对象，如下文自动管理软件包的暂停生命周期管理所述。此过程将停用软件包的生命周期管理，应谨慎使用。

主要术语

Tanzu Kubernetes Grid 使用以下资源来管理自动管理软件包的生命周期。

管理集群中安装的组件：

  • kapp-controller，本地软件包管理器：部署管理集群时，Tanzu CLI 会在集群中安装 kapp-controller。kapp-controller 将安装 tanzu-addons-manager 和其他自动管理的软件包。它还会在从管理集群部署的每个工作负载集群中安装和管理 kapp-controller。
  • tanzu-addons-manager：管理集群和从管理集群部署的工作负载集群中作为自动管理的软件包安装的附加模块组件。
  • tkr-controller：在管理集群中创建 TKrs 和 BoM ConfigMaps。

工作负载集群中安装的组件：

kapp-controller 会在运行它的工作负载集群中安装自动管理的软件包。

对象:

  • Secret：Tanzu CLI 为每个集群的每个附加模块组件创建一个 Secret。这些密钥定义了附加模块组件的配置。tanzu-addons-manager 读取密钥，并使用密钥包含的配置信息来配置附加模块组件。所有密钥都在管理集群中创建。
  • PackageRepository CR：tanzu-addons-manager创建PackageRepository CR，该 CR 引用所有附加模块组件Package CR（见下文）。
  • Package CR：对于 PackageRepository kapp-controller 中的每个附加模块组件都会在目标集群中创建一个 Package CR。
  • PackageInstall CR：对于附加模块组件 Package，tanzu-addons-manager 会在目标集群中创建一个 PackageInstall CR，以通知 kapp-controller 需要安装哪些自动管理的软件包。
  • App CR：对于每个 PackageInstall，kapp-controller 会在目标集群中创建一个 App CR。然后，kapp-controller 协调 CR 并安装软件包。
  • BoM ConfigMap：向 tanzu-addons-manager 提供有关附加模块组件（如映像位置）的元数据信息。

您可以使用以下命令监控这些资源的状态：

命令 描述
kubectl get packageinstall PACKAGE-NAME -n tkg-system -o yaml 检查目标集群中的 PackageInstall CR。例如，kubectl get packageinstall antrea -n tkg-system -o yaml。
kubectl get app PACKAGE-NAME -n tkg-system -o yaml 检查目标集群中的 App CR。例如，kubectl get app antrea -n tkg-system -o yaml。
kubectl get cluster CLUSTER-NAME -n CLUSTER-NAMESPACE -o jsonpath={.metadata.labels.tanzuKubernetesRelease} 在管理集群中，检查目标集群的 TKr 标签是否指向正确的 TKr。
kubectl get tanzukubernetesrelease TKR-NAME 检查 TKr 是否位于管理集群中。
kubectl get configmaps -n tkr-system -l ‘tanzuKubernetesRelease=TKR-NAME’ 检查管理集群中是否存在与您的 TKr 对应的 BoM ConfigMap。
kubectl get app CLUSTER-NAME-kapp-controller -n CLUSTER-NAMESPACE 对于工作负载集群，请检查管理集群中是否存在 kapp-controller App CR。
kubectl logs deployment/tanzu-addons-controller-manager -n tkg-system 检查管理集群中的 tanzu-addons-manager 日志。
kubectl get configmap -n tkg-system | grep ADD-ON-NAME-ctrl 检查是否已应用对附加模块密钥的更新。同步时间为 5 分钟。

暂停自动管理的软件包的生命周期管理

重要

本节中的命令会停用软件包生命周期管理。如果可能，请改用上述更新软件包配置中所述的过程。

如果需要临时暂停自动管理的软件包的生命周期管理，可以使用以下命令：

  • 要暂停密钥协调，请对管理集群运行以下命令：

    kubectl patch secret/CLUSTER-NAME-ADD-ON-NAME-addon -n CLUSTER-NAMESPACE -p '{"metadata":{"annotations":{"tkg.tanzu.vmware.com/addon-paused": ""}}}' --type=merge

    运行此命令后，tanzu-addons-manager 会停滞协调密钥。

  • 要暂停 PackageInstall CR 协调，请针对目标集群运行以下命令：

    kubectl patch packageinstall/PACKAGE-NAME -n tkg-system -p '{"spec":{"paused":true}}' --type=merge

    运行此命令后，kapp-controller 会停止协调 PackageInstall 和相应的 App CR。

如果要临时修改附加模块组件的资源，请先暂停密钥协调，然后再暂停 PackageInstall CR 协调。取消暂停生命周期管理后，tanzu-addons-manager 和 kapp-controller 会恢复密钥及 PackageInstall CR 协调：

  • 要取消暂停密钥协调，请从密钥注释中移除 tkg.tanzu.vmware.com/addon-paused。

  • 要取消暂停 PackageInstall CR 协调，请将 PackageInstall CR 更新为 {"spec":{"paused":false}} 或移除变量。

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