• Русский
  • Миграция с 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. Проверьте удаление оператора

      $ 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[Критично: Выбор канала] При развертывании Alauda DevOps Pipelines вы ДОЛЖНЫ выбрать канал pipelines-4.0. НЕ выбирайте канал latest.
    • Канал: должен быть pipelines-4.0 (требуется для совместимости с Katanomi pipeline)
    • Версия: можно выбрать любую версию из канала pipelines-4.0

    Выбор канала latest может привести к автоматическим обновлениям до версий v4.x и выше в будущем, что может вызвать необратимые проблемы совместимости с Katanomi pipelines. ::: 4. Следуйте инструкциям на экране для завершения развертывания 5. Дождитесь готовности оператора Alauda DevOps Pipelines

    После завершения развертывания оператора Alauda DevOps Pipelines он автоматически развернет связанные компоненты, такие как Pipelines. Вы можете проверить статус компонентов с помощью следующих команд:

    $ kubectl get tektonconfigs.operator.tekton.dev config
    
    $ kubectl get tektonpipelines.operator.tekton.dev pipeline

    Дождитесь, пока оба ресурса не покажут статус Ready, прежде чем переходить к следующему шагу.

    3. (Опционально) Настройка ресурсов оператора для крупномасштабной миграции

    Если в вашей среде содержится большое количество существующих ресурсов TaskRun и PipelineRun, Tekton Operator может столкнуться с ошибками Out of Memory (OOM) во время одноразового процесса миграции данных. Поскольку оператор обычно не требует таких больших ресурсов, стандартные лимиты ресурсов могут быть недостаточными.

    [Когда применять эту настройку]

    Этот шаг необходим только если у вас большой объем существующих ресурсов Tekton. Для большинства установок вы можете пропустить этот шаг и перейти к шагу 4.

    Настройка ресурсов оператора

    Вы можете временно увеличить лимиты ресурсов оператора одним из следующих способов:

    Метод 1: Через UI платформы

    1. Перейдите на страницу оператора Alauda DevOps Pipelines
    2. Откройте вкладку Subscription
    3. Нажмите кнопку Edit Subscription
    4. Добавьте конфигурацию ресурсов, как показано ниже

    Метод 2: Через kubectl CLI

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

    Добавьте следующий раздел config под spec:

    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"

    Эта конфигурация изменяет квоты ресурсов Pod tekton-operator.

    NOTE

    После развертывания оператор автоматически начнет миграцию существующих ресурсов Tekton. Вы можете отслеживать прогресс миграции через логи оператора или проверять статус TektonConfig, как описано в шаге 5 ниже. После завершения миграции вы можете удалить раздел config, чтобы вернуть настройки по умолчанию.

    NOTE
    • Если вы ранее использовали Tekton только в Alauda Container Platform Builds, вы можете пропустить следующие шаги и использовать стандартную конфигурацию Alauda DevOps Pipelines напрямую.

    4. Настройка TektonConfig

    NOTE
    • Если вы ранее использовали Tekton только в Alauda Container Platform Builds, вы можете пропустить следующие шаги и использовать стандартную конфигурацию Alauda DevOps Pipelines напрямую.

    После завершения развертывания оператора Alauda DevOps Pipelines необходимо настроить ресурс 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, таймаут pull образа
            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]

    Данная конфигурация устанавливает runAsUser: 0 в глобальном default-pod-template для обеспечения обратной совместимости с вашими существующими Pipelines и образами контейнеров.

    Однако такая конфигурация приведет к сбоям новых Pipelines, использующих Tasks из каталога Tekton, поскольку эти Tasks требуют runAsUser: 65532 и fsGroup: 65532 для безопасности и корректных прав доступа к файлам.

    Решение: Чтобы обеспечить корректную работу как устаревших, так и новых Pipelines (использующих официальные Tasks), необходимо переопределить конфигурацию Pod шаблона на уровне PipelineRun для Pipelines с официальными Tasks.

    Для подробных инструкций по настройке Pod шаблонов для различных сценариев, включая:

    • Как переопределять Pod шаблон для конкретных PipelineRun
    • Использование TaskRunSpecs для тонкой настройки при смешивании официальных и пользовательских Tasks
    • Рекомендации по безопасности и примеры конфигураций (см. Пример 5: Использование официальных Tasks с устаревшей глобальной конфигурацией)

    Пожалуйста, обратитесь к Руководству по настройке Pod шаблонов.

    5. (Опционально) Мониторинг и проверка прогресса миграции

    После развертывания оператора Alauda DevOps Pipelines (шаг 2) он автоматически начинает миграцию существующих ресурсов Tekton. Вы можете в любой момент во время или после настройки отслеживать прогресс миграции и проверять её завершение.

    Метод 1: Мониторинг через логи оператора

    Вы можете в реальном времени наблюдать процесс миграции, проверяя логи tekton-operator-webhook:

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

    Во время миграции вы увидите записи в логах, например:

    • migrating %d group resources — указывает общее количество типов ресурсов для миграции
    • migrating group resource — показывает начало миграции конкретного типа ресурса
    • migration completed — подтверждает завершение миграции конкретного типа ресурса

    Метод 2: Проверка статуса 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, теперь вы можете удалить раздел config из Subscription, чтобы вернуть настройки ресурсов по умолчанию.

    6. Настройка прав доступа к логам

    NOTE
    • Если вы ранее использовали Tekton только в Alauda Container Platform Builds, вы можете пропустить следующие шаги и использовать стандартную конфигурацию 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, чтобы узнать обо всех возможностях новой версии и максимально эффективно их использовать.