Compartir vía

KubernetesManifest@1: tarea Implementar en Kubernetes v1

  • Artículo

Use archivos de manifiesto de Kubernetes para implementar en clústeres o incluso hornear los archivos de manifiesto que se usarán para las implementaciones mediante gráficos de Helm.

Syntax

# Deploy to Kubernetes v1
# Use Kubernetes manifest files to deploy to clusters or even bake the manifest files to be used for deployments using Helm charts.
- task: KubernetesManifest@1
  inputs:
    #action: 'deploy' # 'bake' | 'createSecret' | 'delete' | 'deploy' | 'patch' | 'promote' | 'scale' | 'reject'. Action. Default: deploy.
    #connectionType: 'kubernetesServiceConnection' # 'azureResourceManager' | 'kubernetesServiceConnection'. Required when action != bake. Service connection type. Default: kubernetesServiceConnection.
    #kubernetesServiceConnection: # string. Alias: kubernetesServiceEndpoint. Required when action != bake && connectionType = kubernetesServiceConnection. Kubernetes service connection. 
    #azureSubscriptionConnection: # string. Alias: azureSubscriptionEndpoint. Required when action != bake && connectionType = azureResourceManager. Azure subscription. 
    #azureResourceGroup: # string. Required when action != bake && connectionType = azureResourceManager. Resource group. 
    #kubernetesCluster: # string. Required when action != bake && connectionType = azureResourceManager. Kubernetes cluster. 
    #useClusterAdmin: false # boolean. Optional. Use when connectionType = azureResourceManager. Use cluster admin credentials. Default: false.
    #namespace: # string. Namespace. 
    #strategy: 'none' # 'canary' | 'none'. Optional. Use when action = deploy || action = promote || action = reject. Strategy. Default: none.
    #trafficSplitMethod: 'pod' # 'pod' | 'smi'. Optional. Use when strategy = canary. Traffic split method. Default: pod.
    #percentage: '0' # string. Required when strategy = Canary && action = deploy. Percentage. Default: 0.
    #baselineAndCanaryReplicas: '1' # string. Required when strategy = Canary && action = deploy && trafficSplitMethod = SMI. Baseline and canary replicas. Default: 1.
    #manifests: # string. Required when action = deploy || action = promote || action = reject. Manifests. 
    #containers: # string. Optional. Use when action = deploy || action = promote || action = bake. Containers. 
    #imagePullSecrets: # string. Optional. Use when action = deploy || action = promote. ImagePullSecrets. 
    #renderType: 'helm' # 'helm' | 'kompose' | 'kustomize'. Optional. Use when action = bake. Render Engine. Default: helm.
    #dockerComposeFile: # string. Required when action = bake && renderType = kompose. Path to docker compose file. 
    #helmChart: # string. Required when action = bake && renderType = helm. Helm Chart. 
    #releaseName: # string. Optional. Use when action = bake && renderType = helm. Helm Release Name. 
    #overrideFiles: # string. Optional. Use when action = bake && renderType = helm. Override Files. 
    #overrides: # string. Optional. Use when action = bake && renderType = helm. Overrides. 
    #kustomizationPath: # string. Optional. Use when action = bake && renderType = kustomize. Kustomization Path. 
    #resourceToPatch: 'file' # 'file' | 'name'. Required when action = patch. Resource to patch. Default: file.
    #resourceFileToPatch: # string. Required when action = patch && resourceToPatch = file. File path. 
    #kind: # 'deployment' | 'replicaset' | 'statefulset'. Required when action = scale || resourceToPatch = name. Kind. 
    #name: # string. Required when action = scale || resourceToPatch = name. Name. 
    #replicas: # string. Required when action = scale. Replica count. 
    #mergeStrategy: 'strategic' # 'json' | 'merge' | 'strategic'. Required when action = patch. Merge Strategy. Default: strategic.
    #arguments: # string. Optional. Use when action = delete. Arguments. 
    #patch: # string. Required when action = patch. Patch. 
    #secretType: 'dockerRegistry' # 'dockerRegistry' | 'generic'. Required when action = createSecret. Type of secret. Default: dockerRegistry.
    #secretName: # string. Optional. Use when action = createSecret. Secret name. 
    #secretArguments: # string. Optional. Use when action = createSecret && secretType = generic. Arguments. 
    #dockerRegistryEndpoint: # string. Optional. Use when action = createSecret && secretType = dockerRegistry. Docker registry service connection. 
    #rolloutStatusTimeout: '0' # string. Optional. Use when action = deploy || action = patch || action = scale || action = promote. Timeout for rollout status. Default: 0.

Entradas

action - Acción
string. Valores permitidos: bake, createSecret (crear secreto), delete, deploy, promotepatch, , scale, reject. Valor predeterminado: deploy.

Especifica la acción que se va a realizar.


connectionType - Tipo de conexión de servicio
string. Necesario cuando action != bake. Valores permitidos: azureResourceManager (Azure Resource Manager), kubernetesServiceConnection (conexión de Kubernetes Service). Valor predeterminado: kubernetesServiceConnection.

Seleccione un tipo de conexión de servicio de Kubernetes.

  • kubernetesServiceConnection (Conexión de Kubernetes Service): permite proporcionar un archivo KubeConfig, especificar una cuenta de servicio o importar una instancia de AKS con la opción Suscripción de Azure . La importación de una instancia de AKS con la opción Suscripción de Azure requiere acceso al clúster de Kubernetes en el momento de la configuración de conexión de servicio.
  • azureResourceManager(Azure Resource Manager): permite seleccionar una instancia de AKS. No tiene acceso al clúster de Kubernetes en el momento de la configuración de la conexión de servicio.

Para obtener más información, vea Comentarios.


kubernetesServiceConnection - Conexión de servicio de Kubernetes
Alias de entrada: kubernetesServiceEndpoint. string. Necesario cuando action != bake && connectionType = kubernetesServiceConnection.

Especifica una conexión de servicio de Kubernetes.


azureSubscriptionConnection - Suscripción de Azure
Alias de entrada: azureSubscriptionEndpoint. string. Necesario cuando action != bake && connectionType = azureResourceManager.

Seleccione la suscripción de Azure Resource Manager, que contiene Azure Container Registry. Nota: Para configurar una nueva conexión de servicio, seleccione la suscripción de Azure en la lista y haga clic en "Autorizar". Si la suscripción no aparece o si desea usar una entidad de servicio existente, puede configurar una conexión de servicio de Azure mediante el botón "Agregar" o "Administrar".


azureResourceGroup - Grupo de recursos
string. Necesario cuando action != bake && connectionType = azureResourceManager.

Seleccione un grupo de recursos de Azure.


kubernetesCluster - Clúster de Kubernetes
string. Necesario cuando action != bake && connectionType = azureResourceManager.

Seleccione un clúster administrado de Azure.


useClusterAdmin - Uso de credenciales de administrador de clústeres
boolean. Opcional. Use cuando connectionType = azureResourceManager. Valor predeterminado: false.

Use credenciales de administrador de clúster en lugar de credenciales de usuario de clúster predeterminadas.


namespace - Nombres
string.

Especifica el espacio de nombres de los comandos mediante la –namespace marca . Si no se proporciona el espacio de nombres, los comandos se ejecutarán en el espacio de nombres predeterminado.


strategy - Estrategia
string. Opcional. Use cuando action = deploy || action = promote || action = reject. Valores permitidos: canary, none. Valor predeterminado: none.

Especifica la estrategia de implementación usada en la deploy acción antes de una promote acción o reject acción. Actualmente, canary es la única estrategia de implementación aceptable.


trafficSplitMethod - Método de división de tráfico
string. Opcional. Use cuando strategy = canary. Valores permitidos: pod, smi. Valor predeterminado: pod.

Para el valor smi, la división de tráfico porcentual se realiza en el nivel de solicitud mediante una malla de servicio. Un administrador de clústeres debe configurar una malla de servicio. Esta tarea controla la orquestación de objetos SMI TrafficSplit.

Para el valor pod, la división de porcentaje no es posible en el nivel de solicitud en ausencia de una malla de servicio. En su lugar, la entrada percentage se usa para calcular las réplicas de baseline y canary. El cálculo es un porcentaje de réplicas especificadas en los manifiestos de entrada para la variante stable.


percentage - Porcentaje
string. Necesario cuando strategy = Canary && action = deploy. Valor predeterminado: 0.

Porcentaje que se usa para calcular el número de réplicas de las variantes baseline y canary de las cargas de trabajo contenidas en los archivos de manifiesto.

Para la entrada de porcentaje especificada, calcule:

(porcentaje × número de réplicas) / 100

Si el resultado no es un entero, se usará el mínimo matemático del resultado cuando se creen las variantes baseline y canary.

Por ejemplo, supongamos que la implementación hello-world está en el archivo de manifiesto de entrada y que las líneas siguientes están en la entrada de la tarea:

replicas: 4
strategy: canary
percentage: 25

En este caso, las implementaciones hello-world-baseline y hello-world-canary se crean con una réplica cada una. La variante baseline se crea con la misma imagen y etiqueta que la versión stable, que es la variante de cuatro réplicas anterior a la implementación. La variante canary se crea con la imagen y la etiqueta correspondientes a los cambios recién implementados.


baselineAndCanaryReplicas - Réplicas de línea base y controladas
string. Necesario cuando strategy = Canary && action = deploy && trafficSplitMethod = SMI. Valor predeterminado: 1.

Cuando se establece trafficSplitMethodsmien , el porcentaje de división del tráfico se controla en el plano de malla de servicio. Puede controlar el número real de réplicas para variantes controladas y de línea base independientemente de la división del tráfico.

Por ejemplo, supongamos que el manifiesto de implementación de entrada especifica 30 réplicas para la variante stable. Supongamos también que especifica la siguiente entrada para la tarea:

strategy: canary
trafficSplitMethod: smi
percentage: 20
baselineAndCanaryReplicas: 1

En este caso, la variante stable recibe el 80 % del tráfico, mientras que las variantes baseline y canary reciben la mitad del 20 % especificado. Las variantes de línea base y de valor controlado no reciben tres réplicas cada una. En su lugar, reciben el número especificado de réplicas, lo que significa que cada una recibe una.


manifests - Manifiesta
string. Necesario cuando action = deploy || action = promote || action = reject.

Especifica la ruta de acceso a los archivos de manifiesto que se van a usar para la implementación. Cada línea representa una sola ruta de acceso. Un patrón de coincidencia de archivos es un valor aceptable para cada línea.


containers - Contenedores
string. Opcional. Use cuando action = deploy || action = promote || action = bake.

Especifica la dirección URL de recurso completa de la imagen que se va a usar para las sustituciones en los archivos de manifiesto. La dirección URL contosodemo.azurecr.io/helloworld:test es un ejemplo.


imagePullSecrets - ImagePullSecrets
string. Opcional. Use cuando action = deploy || action = promote.

Especifica una entrada de varias líneas en la que cada línea contiene el nombre de un secreto del registro de Docker que ya se ha configurado en el clúster. Cada nombre de secreto se agrega en imagePullSecrets para las cargas de trabajo que se encuentran en los archivos de manifiesto de entrada.


renderType - Motor de representación
string. Opcional. Use cuando action = bake. Valores permitidos: helm, kompose y kustomize. Valor predeterminado: helm.

Especifica el tipo de representación utilizado para generar los archivos de manifiesto.


dockerComposeFile - Ruta de acceso al archivo docker compose
string. Necesario cuando action = bake && renderType = kompose.

Especifica una ruta de acceso de archivo docker-compose.


helmChart - Gráfico de Helm
string. Necesario cuando action = bake && renderType = helm.

Especifica la ruta de acceso del gráfico de Helm que se va a hornear.


releaseName - Nombre de la versión de Helm
string. Opcional. Use cuando action = bake && renderType = helm.

Especifica el nombre de la versión de Helm que se va a usar.


overrideFiles - Invalidar archivos
string. Opcional. Use cuando action = bake && renderType = helm.

Especifica una entrada de varias líneas que acepta la ruta de acceso a los archivos de invalidación. Los archivos se usan cuando se simulan mediante "bake" los archivos de manifiesto de los gráficos de Helm.


overrides - Reemplaza
string. Opcional. Use cuando action = bake && renderType = helm.

Especifica los valores de invalidación que se van a establecer.


kustomizationPath - Ruta de acceso de kustomización
string. Opcional. Use cuando action = bake && renderType = kustomize.

Especifica el argumento que debe ser la ruta de acceso al directorio que contiene el archivo o una dirección URL del repositorio de Git con un sufijo de ruta de acceso que especifica same con respecto a la raíz del repositorio.


resourceToPatch - Recurso para aplicar revisiones
string. Necesario cuando action = patch. Valores permitidos: file, name. Valor predeterminado: file.

Indica uno de los métodos de revisión siguientes:

  • Un archivo de manifiesto identifica los objetos a los que se van a aplicar revisiones.
  • Un objeto individual se identifica por tipo y nombre como destino de revisión.

Los valores aceptables son file y name.


resourceFileToPatch - Ruta de acceso del archivo
string. Necesario cuando action = patch && resourceToPatch = file.

Especifica la ruta de acceso al archivo usado para una revisión.


kind - Tipo
string. Necesario cuando action = scale || resourceToPatch = name. Valores permitidos: deployment, replicaset y statefulset.

Especifica el tipo de objeto K8s, como deployment, replicaSet y mucho más.


name - Nombre
string. Necesario cuando action = scale || resourceToPatch = name.

Especifica el nombre del objeto K8s.


replicas - Número de réplicas
string. Necesario cuando action = scale.

Especifica el número de réplicas a las que se va a escalar.


replicas - Número de réplicas
string. Necesario cuando action = scale.

Especifica el nombre del objeto K8s.


mergeStrategy - Estrategia de combinación
string. Necesario cuando action = patch. Valores permitidos: json, merge y strategic. Valor predeterminado: strategic.

Especifica el tipo de revisión que se proporciona.


arguments - Argumentos
string. Opcional. Use cuando action = delete.

Especifica los argumentos del kubectl delete comando. Un ejemplo es: arguments: deployment hello-world foo-bar


patch - Parche
string. Necesario cuando action = patch.

Especifica el contenido de la revisión.


secretType - Tipo de secreto
string. Necesario cuando action = createSecret. Valores permitidos: dockerRegistry, generic. Valor predeterminado: dockerRegistry.

Crea o actualiza un elemento genérico o docker imagepullsecret. Especifique dockerRegistry para crear o actualizar el imagepullsecret del registro seleccionado. Una imagePullSecret es una manera de pasar un secreto que contiene una contraseña del registro de contenedor a Kubelet, por lo que puede extraer una imagen privada en nombre del pod.


secretName - Nombre del secreto
string. Opcional. Use cuando action = createSecret.

Especifica el nombre del secreto. Puede usar este nombre secreto en el archivo de configuración de YAML de Kubernetes.


secretArguments - Argumentos
string. Opcional. Use cuando action = createSecret && secretType = generic.

Especifica claves y valores literales que se van a insertar en secreto. Por ejemplo, --from-literal=key1=value1--from-literal=key2="top secret".


dockerRegistryEndpoint - Conexión del servicio del registro de Docker
string. Opcional. Use cuando action = createSecret && secretType = dockerRegistry.

Especifica las credenciales de la conexión de servicio especificada que se usan para crear un secreto del registro de Docker dentro del clúster. Los archivos de manifiesto en el imagePullSecrets campo pueden hacer referencia al nombre de este secreto.


rolloutStatusTimeout - Tiempo de espera para el estado de lanzamiento
string. Opcional. Use cuando action = deploy || action = patch || action = scale || action = promote. Valor predeterminado: 0.

Especifica el período de tiempo (en segundos) que se esperará antes de finalizar watch on rollout el estado.


Opciones de control de tareas

Todas las tareas tienen opciones de control además de las entradas de tareas. Para obtener más información, vea Opciones de control y propiedades de tareas comunes.

Variables de salida

Esta tarea define las siguientes variables de salida, que puede consumir en pasos, trabajos y fases de bajada.

manifestsBundle
La ubicación de los conjuntos de manifiestos creados por la acción bake

Comentarios

Consideraciones sobre la conexión de Kubernetes Service al acceder a AKS

Puede crear una conexión de servicio de Kubernetes con cualquiera de las siguientes opciones.

  • KubeConfig
  • Cuenta de servicio
  • Suscripción de Azure

Captura de pantalla de la elección de un método de autenticación de conexión de servicio de Kubernetes.

Al seleccionar la opción Suscripción de Azure , Kubernetes debe ser accesible para Azure DevOps en el momento de la configuración de la conexión del servicio. Puede haber varias razones por las que no se puede crear una conexión de servicio, por ejemplo, ha creado un clúster privado o el clúster tiene deshabilitadas las cuentas locales. En estos casos, Azure DevOps no se puede conectar al clúster en el momento de la configuración de la conexión del servicio y verá una pantalla bloqueada Cargando espacios de nombres .

Captura de pantalla de cómo elegir un cuadro de diálogo de autenticación de conexión de servicio de Kubernetes bloqueado en la carga de espacios de nombres.

A partir de Kubernetes 1.24, los tokens de larga duración ya no se crean de forma predeterminada. Kubernetes recomienda no usar tokens de larga duración. Como resultado, las tareas que usan una conexión de servicio de Kubernetes creada con la opción Suscripción de Azure no tienen acceso al token permanente necesario para autenticarse y no pueden acceder al clúster de Kubernetes. Esto también da como resultado el cuadro de diálogo Cargando espacios de nombres inmovilizados.

Uso de la conexión de servicio de Azure Resource Manager para acceder a AKS

Para los clientes de AKS, el tipo de conexión de servicio de Azure Resource Manager proporciona el mejor método para conectarse a un clúster privado o un clúster que tenga deshabilitadas las cuentas locales. Este método no depende de la conectividad del clúster en el momento en que se crea una conexión de servicio. El acceso a AKS se aplaza al entorno de ejecución de canalización, que tiene las siguientes ventajas:

  • El acceso a un clúster de AKS (privado) se puede realizar desde un agente de conjunto de escalado o autohospedado con línea de visión al clúster.
  • Se crea un token para cada tarea que usa una conexión de servicio de Azure Resource Manager. Esto garantiza que se conecta a Kubernetes con un token de corta duración, que es la recomendación de Kubernetes.
  • Se puede acceder a AKS incluso cuando se deshabilitan las cuentas locales.

Preguntas más frecuentes sobre la conexión de servicio

Recibo el siguiente mensaje de error: No se encontró ningún secreto asociado a la cuenta de servicio. ¿Qué pasa?

Usa la opción conexión de servicio de Kubernetes con la suscripción de Azure. Estamos actualizando este método para crear tokens de larga duración. Se espera que esté disponible a mediados de mayo. Sin embargo, se recomienda empezar a usar el tipo de conexión de servicio de Azure y no usar tokens de larga duración según las instrucciones de Kubernetes.

Uso AKS y no quiero cambiar nada, ¿puedo seguir usando tareas con la conexión del servicio Kubernetes?

Estamos actualizando este método para crear tokens de larga duración. Se espera que esté disponible a mediados de mayo. Sin embargo, tenga en cuenta que este enfoque está en contra de las instrucciones de Kubernetes.

Uso las tareas de Kubernetes y la conexión de servicio de Kubernetes, pero no AKS. ¿Debería preocuparme?

Las tareas seguirán funcionando como antes.

¿Se quitará el tipo de conexión del servicio Kubernetes?

Nuestras tareas de Kubernetes funcionan con cualquier clúster de Kubernetes, independientemente de dónde se ejecuten. La conexión del servicio Kubernetes seguirá existiendo.

Soy un cliente de AKS y todo funciona bien, ¿debo actuar?

No es necesario cambiar nada. Si usa la conexión de servicio de Kubernetes y la suscripción de Azure seleccionada durante la creación, debe tener en cuenta las instrucciones de Kubernetes sobre el uso de tokens de larga duración.

Estoy creando un entorno de Kubernetes y no tengo ninguna opción para usar conexiones de servicio.

En caso de que no pueda acceder a AKS durante el tiempo de creación del entorno, puede usar un entorno vacío y establecer la connectionType entrada en una conexión de servicio de Azure Resource Manager.

Tengo AKS configurado con RBAC de Azure Active Directory y mi canalización no funciona. ¿Resolverán estas actualizaciones?

El acceso a Kubernetes cuando AAD RBAC está habilitado no está relacionado con la creación de tokens. Para evitar un aviso interactivo, se admitirá kubelogin en una actualización futura.

Use una tarea de manifiesto de Kubernetes en una canalización de compilación o de versión para simular mediante "bake" e implementar manifiestos en clústeres de Kubernetes.

Esta tarea admite lo siguiente:

  • Sustitución de artefactos: la acción de implementación toma como entrada una lista de imágenes de contenedor que puede especificar junto con sus etiquetas y resúmenes. La misma entrada se sustituye en los archivos de manifiesto sin plantillas antes de la aplicación en el clúster. Esta sustitución garantiza que los nodos del clúster extraigan la versión correcta de la imagen.

  • Estabilidad del manifiesto: se comprueba el estado de lanzamiento de los objetos de Kubernetes implementados. Las comprobaciones de estabilidad se incorporan para determinar si el estado de la tarea es correcto o no.

  • Anotaciones de rastreabilidad: las anotaciones se agregan a los objetos de Kubernetes implementados para superponer la información de rastreabilidad. Se admiten las siguientes anotaciones:

    • azure-pipelines/org
    • azure-pipelines/project
    • azure-pipelines/pipeline
    • azure-pipelines/pipelineId
    • azure-pipelines/execution
    • azure-pipelines/executionuri
    • azure-pipelines/jobName

  • Control de secretos: la createSecret acción permite crear secretos del registro de Docker mediante conexiones del servicio del registro de Docker. También permite crear secretos genéricos mediante variables de texto sin formato o variables secretas. Antes de la implementación en el clúster, puede usar la secrets entrada junto con la deploy acción para aumentar los archivos de manifiesto de entrada con el valor adecuado imagePullSecrets .

  • Manifiesto de bake: la bake acción de la tarea permite hornear plantillas en archivos de manifiesto de Kubernetes. La acción usa herramientas como Helm, Compose y Kustomize. Con la simulación mediante "bake", estos archivos de manifiesto de Kubernetes se pueden usar para las implementaciones en el clúster.

  • Estrategia de implementación: la elección de la canary estrategia con la deploy acción conduce a la creación de nombres de carga de trabajo con -baseline y -canary. La tarea admite dos métodos de división de tráfico:

    • Service Mesh Interface: la abstracción de Service Mesh Interface (SMI) permite la configuración con proveedores de malla de servicio como Linkerd y Istio. La tarea Manifiesto de Kubernetes asigna objetos SMI TrafficSplit a los servicios estables, de línea base y controlados durante el ciclo de vida de la estrategia de implementación.

      Las implementaciones controladas basadas en una malla de servicio y que usan esta tarea son más precisas. Esta precisión se debe a cómo los proveedores de malla de servicio habilitan la división por porcentaje granular del tráfico. La malla de servicio usa el registro de servicio y los contenedores sidecar que se insertan en pods. Esta inyección se produce junto con los contenedores de aplicaciones para lograr la división de tráfico granular.

    • Kubernetes sin malla de servicio: en ausencia de una malla de servicio, es posible que no obtenga la división exacta del porcentaje que desee a nivel de solicitud. Sin embargo, puede realizar implementaciones controladas mediante variantes de línea base y de valor controlado junto a la variante estable.

      El servicio envía solicitudes a pods de las tres variantes de carga de trabajo a medida que se cumplen las restricciones con la etiqueta selector. El manifiesto de Kubernetes respeta estas solicitudes al crear variantes baseline y canary. Este comportamiento de enrutamiento logra el efecto previsto de enrutar solo una parte de las solicitudes totales a canary.

    Compare las cargas de trabajo de baseline y canary mediante una tarea de intervención manual en las canalizaciones de versión o una tarea de retraso en las canalizaciones YAML. Haga la comparación antes de usar la acción promote o reject de la tarea.

Acción de implementación

El código YAML siguiente es un ejemplo de implementación en un espacio de nombres de Kubernetes mediante archivos de manifiesto:

steps:
- task: KubernetesManifest@0
  displayName: Deploy
  inputs:
    kubernetesServiceConnection: someK8sSC1
    namespace: default
    manifests: |
      manifests/deployment.yml
      manifests/service.yml
    containers: |
      foo/demo:$(tagVariable1)
      bar/demo:$(tagVariable2)
    imagePullSecrets: |
      some-secret
      some-other-secret

En el ejemplo anterior, la tarea intenta buscar coincidencias para las imágenes foo/demo y bar/demo en los campos de imagen de los archivos de manifiesto. Para cada coincidencia encontrada, el valor de tagVariable1 o tagVariable2 se anexa como etiqueta al nombre de la imagen. También puede especificar resúmenes en la entrada containers para la sustitución de artefactos.

Nota:

Aunque puede crear deployacciones , promotey reject con la entrada YAML relacionada con la estrategia de implementación, la compatibilidad con una tarea de intervención manual no está disponible actualmente para canalizaciones de compilación.

En el caso de las canalizaciones de versión, le recomendamos que use acciones y entradas relacionadas con la estrategia de implementación en la siguiente secuencia:

  1. Una acción de implementación especificada con strategy: canary y percentage: $(someValue).
  2. Tarea de intervención manual para poder pausar la canalización y comparar la variante baseline con la variante canary.
  3. Acción promote que se ejecuta si se reanuda una tarea intervención manual y acción reject que se ejecuta si se rechaza una tarea de intervención manual.

Creación de una acción secreta

El código YAML siguiente muestra una creación de ejemplo de secretos del registro de Docker mediante una conexión del servicio del registro de Docker:

steps:
- task: KubernetesManifest@0
  displayName: Create secret
  inputs: 
    action: createSecret
    secretType: dockerRegistry
    secretName: foobar
    dockerRegistryEndpoint: demoACR
    kubernetesServiceConnection: someK8sSC
    namespace: default

Este código YAML muestra una creación de ejemplo de secretos genéricos:

steps:
- task: KubernetesManifest@0
  displayName: Create secret
  inputs: 
    action: createSecret
    secretType: generic
    secretName: some-secret
    secretArguments: --from-literal=key1=value1
    kubernetesServiceConnection: someK8sSC
    namespace: default

Acción bake

El siguiente código YAML es un ejemplo de simulación mediante "bake" de archivos de manifiesto de gráficos de Helm. Anote el uso de una entrada de nombre en la primera tarea. Este nombre se menciona más tarde desde el paso de implementación para especificar la ruta de acceso a los manifiestos producidos por el paso bake.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: someK8sSC
    namespace: default
    manifests: $(bake.manifestsBundle)
    containers: |
      nginx: 1.7.9

Nota

Para usar Helm directamente para administrar versiones y reversiones, consulte la tarea Empaquetar e implementar gráficos de Helm.

Ejemplo de Kustomize

El siguiente código YAML es un ejemplo de archivos de manifiesto de baking generados con Kustomize que contienen un kustomization.yaml archivo.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from kustomization path
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Ejemplo de Kompose

El siguiente código YAML es un ejemplo de archivos de manifiesto de baking generados con Kompose, una herramienta de conversión para Docker Compose.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Docker Compose
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Acción de escalado

El código YAML siguiente muestra un ejemplo de objetos de escalado:

steps:
- task: KubernetesManifest@0
  displayName: Scale
  inputs: 
    action: scale
    kind: deployment
    name: bootcamp-demo
    replicas: 5
    kubernetesServiceConnection: someK8sSC
    namespace: default

Acción Patch

El código YAML siguiente muestra un ejemplo de aplicación de revisiones a objetos:

steps:
- task: KubernetesManifest@0
  displayName: Patch
  inputs: 
    action: patch
    kind: pod
    name: demo-5fbc4d6cd9-pgxn4
    mergeStrategy: strategic
    patch: '{"spec":{"containers":[{"name":"demo","image":"foobar/demo:2239"}]}}'
    kubernetesServiceConnection: someK8sSC
    namespace: default

Eliminar acción

Este código YAML muestra una eliminación de objetos de ejemplo:

steps:
- task: KubernetesManifest@0
  displayName: Delete
  inputs:
    action: delete
    arguments: deployment expressapp
    kubernetesServiceConnection: someK8sSC
    namespace: default

Solución de problemas

Mi clúster de Kubernetes está detrás de un firewall y estoy usando agentes hospedados. ¿Cómo se puede implementar en este clúster?

Puede conceder acceso a los agentes hospedados a través del firewall, permitiendo las direcciones IP de los agentes hospedados. Para más información, consulte el artículo sobre los intervalos IP del agente.

¿Cómo funcionan las solicitudes en rutas de servicio estables y variantes con implementaciones de valor controlado?

La relación del selector de etiquetas entre pods y servicios en Kubernetes permite configurar implementaciones para que un único servicio enrute las solicitudes a las variantes estables y de valor controlado. La tarea de manifiesto de Kubernetes la usa para las implementaciones de valor controlado.

Si la tarea incluye las entradas de y strategy: canary, para cada carga de action: deploy trabajo (Implementación, ReplicaSet, Pod, ...) definida en los archivos de manifiesto de entrada, se crea una -baseline variante y -canary de la implementación. En este ejemplo, hay una implementación sampleapp en el archivo de manifiesto de entrada y que después de finalizar la ejecución número 22 de la canalización, la variante estable de esta implementación denominada sampleapp se implementa en el clúster. En la ejecución posterior (en este caso, número de ejecución 23), la tarea de manifiesto de Kubernetes con action: deploy y strategy: canary daría lugar a la creación de implementaciones sampleapp-baseline y sampleapp-canary cuyo número de réplicas viene determinado por el producto de la entrada de percentage tarea con el valor del número deseado de réplicas para la variante estable final de sampleapp según los archivos de manifiesto de entrada.

Sin incluir el número de réplicas, la versión de línea base tiene la misma configuración que la variante estable, mientras que la versión de valor controlado tiene los nuevos cambios introducidos por la ejecución actual (en este caso, el número de ejecución 23). Si se configura una intervención manual en la canalización después del paso mencionado anteriormente, se podría pausar la canalización para que el administrador de la canalización pueda evaluar las métricas clave de las versiones de la línea de base y de valor controlado y tomar la decisión sobre si los cambios controlados son seguros y lo suficientemente buenos para una implementación completa.

Lasaction: promote entradas y strategy: canary y strategy: canaryaction: reject de las tareas de manifiesto de Kubernetes se pueden usar para promover o rechazar los cambios controlados, respectivamente. Tenga en cuenta que en ambos casos, al final de este paso, solo la variante estable de las cargas de trabajo declaradas en los archivos de manifiesto de entrada permanecerá implementada en el clúster, mientras que las versiones efímeras de línea de base y de valor controlado se limpian.

Requisitos

Requisito Descripción
Tipos de canalización YAML, compilación clásica, versión clásica
Se ejecuta en Agente, DeploymentGroup
Peticiones None
Capabilities Esta tarea no satisface ninguna demanda de tareas posteriores en el trabajo.
Restricciones de comandos Any
Variables que se pueden establecer Any
Versión del agente Todas las versiones de agente compatibles.
Categoría de la tarea: Implementación