Alauda DevOps Tekton v3 迁移到 Alauda DevOps Pipelines

NOTE
  • 本指南专门针对从 Alauda DevOps Tekton v3 迁移到 Alauda DevOps Pipelines 若需升级 Alauda DevOps Pipelines 各版本之间,请参考 Pipelines 升级文档。

本指南提供了从 Alauda DevOps Tekton v3 平滑迁移到 Alauda DevOps Pipelines 的详细步骤。升级过程设计为无缝迁移,确保您现有的 CI/CD 流水线不受影响。

迁移步骤

1. 卸载现有 Tekton Pipeline 实例及 Alauda DevOps Tekton v3

开始升级前,需卸载现有 Tekton 组件。请按以下步骤操作:

重要提示: 卸载过程不会影响您现有的 Task、TaskRun、Pipeline 和 PipelineRun 资源。这些资源在升级完成后将保持不变。

  1. 删除 Pipeline 实例

    $ kubectl delete tektonpipelines.operator.tekton.dev pipeline
  2. 确认 Pipeline 实例已删除

    $ kubectl get tektonpipelines.operator.tekton.dev pipeline

    确认命令无资源返回,表示删除成功。

  3. 卸载 Tekton Operator

    $ kubectl delete subscriptions.operators.coreos.com tekton-operator -n tekton-operator
  4. 确认 Operator 已卸载

    $ kubectl get subscriptions.operators.coreos.com -A | grep tekton

    确认命令无结果返回,表示卸载成功。

2. 部署 Alauda DevOps Pipelines

  1. 进入集群的 Administrator -> Application Market Management -> OperatorHub 页面
  2. 搜索并选择 Alauda DevOps Pipelines
  3. 选择合适的 Channel :::warning[关键:Channel 选择] 部署 Alauda DevOps Pipelines 时,必须选择 pipelines-4.0 频道。不要选择 latest 频道。
  • 频道:必须为 pipelines-4.0(保证与 Katanomi pipeline 兼容)
  • 版本:可选择 pipelines-4.0 频道内任意版本

选择 latest 频道可能导致未来自动升级到 v4.x 或更高版本,可能引发与 Katanomi pipeline 不可逆的兼容性问题。 ::: 4. 按照页面提示完成部署 5. 等待 Alauda DevOps Pipelines Operator 就绪

Alauda DevOps Pipelines Operator 部署完成后,会自动部署相关组件如 Pipelines。可通过以下命令检查组件状态:

$ kubectl get tektonconfigs.operator.tekton.dev config

$ kubectl get tektonpipelines.operator.tekton.dev pipeline

等待两个资源均显示 Ready 状态后,方可进行下一步。

3. (可选)调整 Operator 资源以支持大规模迁移

如果环境中存在大量现有的 TaskRunPipelineRun 资源,Tekton Operator 在一次性数据迁移过程中可能会遇到内存不足(OOM)错误。由于 Operator 平时不需要如此大量资源,默认资源限制可能不足。

[何时应用此配置]

仅当您拥有大量现有 Tekton 资源时才需执行此步骤。大多数安装可跳过,直接进行步骤 4。

调整 Operator 资源

您可以通过以下任一方式临时增加 Operator 的资源限制:

方法一:使用平台 UI

  1. 进入 Alauda DevOps Pipelines Operator 页面
  2. 切换到 Subscription 标签页
  3. 点击 Edit Subscription 按钮
  4. 添加如下资源配置

方法二:使用 kubectl CLI

kubectl edit subscriptions.operators.coreos.com -n tekton-operator tektoncd-operator

spec 下添加以下 config 部分:

NOTE

resources 数值可根据实际环境需求调整。以下示例为大多数场景提供了均衡配置。

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: tektoncd-operator
  namespace: tekton-operator
spec:
  channel: pipelines-4.0
  installPlanApproval: Manual
  name: tektoncd-operator
  source: platform
  sourceNamespace: cpaas-system
  config:
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limits:
        cpu: "2"
        memory: "2Gi"

此配置调整了 tekton-operator Pod 的资源配额。

NOTE

Operator 部署后会自动开始迁移现有 Tekton 资源。您可通过 Operator 日志或步骤 5 中描述的 TektonConfig 状态监控迁移进度。迁移完成后,可移除该 config 配置以恢复默认设置。

NOTE
  • 如果您之前仅在 Alauda Container Platform Builds 中使用过 Tekton,可跳过以下步骤,直接使用 Alauda DevOps Pipelines 的默认配置。

4. 配置 TektonConfig

NOTE
  • 如果您之前仅在 Alauda Container Platform Builds 中使用过 Tekton,可跳过以下步骤,直接使用 Alauda DevOps Pipelines 的默认配置。

Alauda DevOps Pipelines Operator 部署完成后,需配置 TektonConfig 资源以确保与现有系统兼容:

最佳实践: 建议仅修改 spec.pipeline 部分配置,以保持系统稳定。

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    await-sidecar-readiness: true
    disable-creds-init: false
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-custom-tasks: true
    enable-git-resolver: true
    enable-hub-resolver: true
    enable-provenance-in-status: true
    enable-step-actions: true
    enforce-nonfalsifiability: none
    keep-pod-on-cancel: false
    metrics.count.enable-reason: false
    metrics.pipelinerun.duration-type: histogram
    metrics.pipelinerun.level: pipeline
    metrics.taskrun.duration-type: histogram
    metrics.taskrun.level: task

    performance:
      disable-ha: false
    require-git-ssh-secret-known-hosts: false
    running-in-environment-with-injected-sidecars: true
    send-cloudevents-for-runs: false
    set-security-context: false
    trusted-resources-verification-no-match-policy: ignore

    # Tekton Operator 兼容性配置
    coschedule: workspaces
    disable-affinity-assistant: true
    enable-api-fields: alpha
    enable-cel-in-whenexpression: true
    enable-param-enum: true
    max-result-size: 8192
    results-from: sidecar-logs

    options:
      disabled: false
      configMaps:
        # 修改默认配置:init 容器配额、runAsUser、镜像拉取超时
        config-defaults:
          data:
            # 容器配置
            default-imagepullbackoff-timeout: 5m
            default-pod-template: |
              securityContext:
                runAsUser: 0

  addon: {}
  chain:
    artifacts.oci.format: simplesigning
    artifacts.oci.storage: oci
    artifacts.pipelinerun.format: in-toto
    artifacts.pipelinerun.storage: oci
    artifacts.taskrun.format: in-toto
    artifacts.taskrun.storage: oci
    disabled: false
    options: {}
  config: {}
  dashboard:
    options: {}
    readonly: false
  hub:
    options: {}

  platforms:
    openshift: {}
  profile: all
  pruner:
    disabled: false
    keep: 100
    resources:
    - pipelinerun
    schedule: 0 8 * * *
  targetNamespace: tekton-pipelines
  trigger:
    enable-api-fields: stable
    options: {}
[重要:确保旧版与新版 Pipeline 均可正常运行]

上述配置在全局 default-pod-template 中设置了 runAsUser: 0,以保证与您现有 Pipeline 及容器镜像的向后兼容性。

但此配置会导致使用 Tekton 目录中 Task 的新 Pipeline 失败,因为这些目录 Task 需要 runAsUser: 65532fsGroup: 65532 以保证安全性和正确的文件权限。

解决方案:为确保旧版 Pipeline 和使用官方 Task 的新版 Pipeline 均能正常运行,您需要在使用官方 Task 的 PipelineRun 级别覆盖 Pod 模板配置。

关于如何针对不同场景配置 Pod 模板的详细指导,包括:

  • 如何为特定 PipelineRun 覆盖 Pod 模板
  • 在混合使用官方与自定义 Task 时使用 TaskRunSpecs 进行细粒度控制
  • 安全最佳实践及配置示例(参见示例 5:使用官方 Task 与旧版全局配置)

请参阅 Pod 模板配置指南

5. (可选)监控并验证迁移进度

Alauda DevOps Pipelines Operator 部署完成(步骤 2)后,会自动开始迁移现有 Tekton 资源。您可在配置过程中或完成后随时监控迁移进度并验证完成情况。

方法一:通过 Operator 日志监控

可实时查看 tekton-operator-webhook 日志,观察迁移进度:

kubectl logs -f -n tekton-operator tekton-operator-webhook-<suffix>

迁移过程中,您会看到如下日志条目:

  • migrating %d group resources —— 表示待迁移的资源类型总数
  • migrating group resource —— 表示某个资源类型开始迁移
  • migration completed —— 表示某个资源类型迁移完成

方法二:检查 TektonConfig 状态

通过查看 TektonConfig 资源状态,确认迁移是否完成:

kubectl get tektonconfigs.operator.tekton.dev config -o yaml

查看输出中的版本注释:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
status:
  annotations:
    operator.tekton.dev/post-upgrade-version: v0.74.1-a07f82b
    operator.tekton.dev/pre-upgrade-version: v0.74.1-a07f82b
  version: v0.74.1-a07f82b

pre-upgrade-versionpost-upgrade-version 与当前 version 一致时,表示迁移完成。

[提醒]

如果您在步骤 3 调整过 Operator 资源,现在可以移除 Subscription 中的 config 部分,恢复默认资源配置。

6. 配置日志访问权限

NOTE
  • 如果您之前仅在 Alauda Container Platform Builds 中使用过 Tekton,可跳过以下步骤,直接使用 Alauda DevOps Pipelines 的默认配置。

由于启用了 results-from: sidecar-logs 功能,需为控制器配置日志访问权限:

技术说明: 该配置允许控制器从 Pod 日志中获取结果信息。详情请参阅 Tekton 官方文档

kubectl apply -f - <<EOF
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tekton-pipelines-controller-pod-log-access
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: default
    app.kubernetes.io/part-of: tekton-pipelines
rules:
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tekton-pipelines-controller-pod-log-access
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: default
    app.kubernetes.io/part-of: tekton-pipelines
subjects:
  - kind: ServiceAccount
    name: tekton-pipelines-controller
    namespace: tekton-pipelines
roleRef:
  kind: ClusterRole
  name: tekton-pipelines-controller-pod-log-access
  apiGroup: rbac.authorization.k8s.io
EOF

迁移完成

完成以上步骤后,您已成功从 Alauda DevOps Tekton v3 迁移到 Alauda DevOps Pipelines。新版本提供了:

  • 更稳定的系统
  • 更丰富的功能集
  • 更优的性能表现
  • 更灵活的配置选项

建议您查阅 Alauda DevOps Pipelines 文档,全面了解新版本功能,充分发挥其能力。