#Миграция с Alauda DevOps Tekton v3 на Alauda DevOps 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)
• Версия: можно выбрать любую версию из канала pipelines-4.0

Выбор канала latest может привести к автоматическим обновлениям до версий v4.x и выше в будущем, что может вызвать необратимые проблемы совместимости с конвейерами Katanomi. ::: 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) во время одноразового процесса миграции данных. Поскольку оператор обычно не требует таких больших ресурсов, стандартные лимиты могут быть недостаточны.

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

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

Метод 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:

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.

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

После завершения развертывания оператора 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: {}

#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.

#6. Настройка разрешений доступа к логам

Поскольку функция 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, чтобы узнать обо всех возможностях новой версии и максимально эффективно использовать её функционал.