Alauda DevOps Docs
  • 简体中文

    • 从 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 v32. 部署 Alauda DevOps Pipelines3. （可选）调整 Operator 资源以支持大规模迁移调整 Operator 资源4. 配置 TektonConfig5. （可选）监控并验证迁移进度方法一：通过 Operator 日志监控方法二：检查 TektonConfig 状态6. 配置日志访问权限迁移完成

    迁移步骤

    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 channel。不要选择 latest channel。
    • Channel：必须为 pipelines-4.0（保证与 Katanomi pipeline 兼容）
    • 版本：可选择 pipelines-4.0 channel 内的任意版本

    选择 latest channel 可能导致未来自动升级到 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 资源以支持大规模迁移

    如果您的环境中存在大量的 TaskRun 和 PipelineRun 资源，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: {}
    [重要：确保旧版与新版 Pipelines 均可正常工作]

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

    但该配置会导致使用 Tekton 目录中 Tasks 的新 Pipelines 失败，因为这些目录 Tasks 需要 runAsUser: 65532 和 fsGroup: 65532 以确保安全及正确的文件权限。

    解决方案：为确保旧版 Pipelines 和使用官方 Tasks 的新版 Pipelines 均能正常工作，您需要在使用官方 Tasks 的 PipelineRun 级别覆盖 Pod 模板配置。

    关于如何为不同场景配置 Pod 模板的详细指导，包括：

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

    请参阅 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-version 和 post-upgrade-version 与当前 version 一致时，迁移即完成。

    [温馨提示]

    如果您在第 3 步调整了 Operator 资源，现在可以删除 Subscription 中的 config 部分，恢复默认资源配置。

    6. 配置日志访问权限

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

    由于启用了 results-from: sidecar-logs 功能，您需要为 controller 配置日志访问权限：

    技术说明： 该配置允许 controller 从 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 文档，全面了解新版本的功能，充分发挥其能力。