#启用内置 Tekton Hub

#概述

从 v4.10.2 开始，新的安装不再默认部署内置的 Tekton Hub。Tekton catalog 资源现在由平台独立的 ArtifactHub 组件提供。ArtifactHub 有自己的生命周期，因此 catalog 更新——新工具、Task 修复、版本升级——可以更快地交付，而不受 operator 发布节奏的影响。

operator 仍然完全支持将内置 Tekton Hub 作为一种过渡选项进行部署。本指南说明如何启用它、默认新行为如何在 operator 升级期间保持现有 Tekton Hub 正常工作，以及如何禁用它。

如果你改为部署独立的 ArtifactHub 组件，请参阅 Configuring Tekton to Use ArtifactHub Shim，以将 Tekton Hub resolver 和 DevOps Hub endpoint 连接到它。

本节中的其他指南（例如 Tekton Hub 配置 和 自定义 Catalog）都假定已按照本指南启用了内置 Tekton Hub。

#开关的工作方式

operator 是否部署内置 Tekton Hub 由 operator 级别的开关控制：位于 tekton-operator 命名空间中 tekton-config-defaults ConfigMap 里的 AUTOINSTALL_TEKTONHUB 键。其默认值为 "preserve"。

该开关是三态的：

未设置、为空或无法识别的值都会映射为 "preserve"，因此拼写错误绝不会误进入具有破坏性的 "false" 行为。

#启用内置 Tekton Hub

将开关设置为 "true"。该值会注入 operator 的环境变量，而环境变量不会热重载——在修改 ConfigMap 后必须重启 operator pod。

# 1) Turn the switch on
$ kubectl -n tekton-operator patch configmap tekton-config-defaults \
    --type merge -p '{"data":{"AUTOINSTALL_TEKTONHUB":"true"}}'

# 2) Restart the operator so it re-reads the environment
$ kubectl -n tekton-operator delete pod -l name=tekton-operator

# 3) The operator creates the TektonHub CR for a profile=all TektonConfig shortly
#    after the restart. If the command below reports NotFound, the CR has not been
#    created yet — wait a moment and re-run it.
$ kubectl wait --for=condition=Ready tektonhub/hub --timeout=600s

#升级时的默认行为

在默认值 "preserve" 下，升级一个已经运行内置 Tekton Hub 的环境（例如 v4.10.1 → v4.10.2）无需任何操作：现有 Tekton Hub 会被保留并继续提供其 catalog，因此 Task 和 Pipeline 引用仍然可以正常解析。保留和 catalog 复用都会自动发生：

• TektonHub CR 以及所有内置 Tekton Hub 工作负载都会被保留，operator 会等待 hub 变为 Ready。
• 导入到 kube-public 命名空间中的 catalog ConfigMaps（*-latest tool-image ConfigMaps、overview-template ConfigMaps、tool-image ConfigMaps 以及 mail-template ConfigMaps）会在 operator 的内部升级过程中保持不变，因此升级前提供的 catalog 与升级后提供的 catalog 相同。
• 该环境当前运行的 catalog image 会被自动捕获并固定，因此升级不会将 catalog 切换到你镜像仓库中可能不存在的 tool-image 集合（这对 air-gapped 安装尤其重要）。

只有在你使用 "true" 显式启用内置 Tekton Hub，并希望控制其使用的 catalog image 时，才需要执行下面 将 Catalog 固定到升级前镜像 中的步骤。

#将 Catalog 固定到升级前镜像

operator bundle 不再附带 catalog 所引用的 tool image（例如 buildah、golang、maven 等）。因此，新 catalog 中引用的 tool image 版本可能并不存在于你的环境中。对于 air-gapped 安装尤其如此，因为新版本的镜像同步列表中已不再包含这些 tool image。另一方面，你的升级前 catalog 所引用的 tool image 则可以保证存在，因为它们已随上一版本一起同步。

因此，当你在升级后重新启用内置 Tekton Hub 时，建议将 catalog 固定为升级前的 catalog image，这样升级就不会影响你现有的 pipeline。

步骤 1 — 升级前，记录当前的 catalog image：

$ kubectl -n tekton-pipelines get deployment tekton-hub-api \
    -o jsonpath='{.spec.template.spec.initContainers[?(@.name=="catalog-sidecar")].image}'

步骤 2 — 升级后，按照上述说明启用开关，然后通过 TektonConfig CR 固定记录下来的 image：

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  profile: all
  hub:
    options:
      deployments:
        tekton-hub-api:                   # deployment name, must match exactly
          spec:
            template:
              spec:
                initContainers:
                  - name: catalog-sidecar # init container name, must match exactly
                    image: <catalog-image-recorded-before-the-upgrade>

#禁用内置 Tekton Hub

如果此 Hub 使用了自定义 catalog，并且你要切换到 artifacthub-shim，请先迁移自定义 catalog 源和凭据，并通过 Hub resolver 验证它们。release-4.10 不会自动迁移此配置。

要移除已部署的内置 Tekton Hub，请将开关设为 "false"，然后以相同方式重启 operator：

$ kubectl -n tekton-operator patch configmap tekton-config-defaults \
    --type merge -p '{"data":{"AUTOINSTALL_TEKTONHUB":"false"}}'

$ kubectl -n tekton-operator delete pod -l name=tekton-operator

随后 operator 会移除已部署的内置 Tekton Hub。当开关为 "false" 时：

• TektonHub CR 和所有内置 Tekton Hub 工作负载都会被移除。TektonConfig CR 保持 Ready。
• 随 catalog 一起导入到 kube-public 命名空间中的 overview-template ConfigMaps 会与 Tekton Hub 一起被移除。
• kube-public 命名空间中的 tool-image ConfigMaps（catalog-tool-image-*）和 mail-template ConfigMaps 会被保留。它们会继续指向升级前的 tool image 地址，这些地址在你的镜像仓库中仍然存在。