Tarea de manifiesto de Kubernetes

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

Información general

En la lista siguiente se muestran las principales ventajas de esta tarea:

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

• Estabilidad delmanifiesto: 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 anotaciones siguientes:

  • 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 acción createSecret permite crear secretos del Registro de Docker mediante conexiones de 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 entrada de secretos junto con la acción de implementación para aumentar los archivos de manifiesto de entrada con el valor imagePullSecrets adecuado.

• Manifiesto de "bake":la acción de "bake" de la tarea permite la cocción de plantillas en archivos de manifiesto de Kubernetes. La acción usa herramientas como Helm, Compose y kustomize. Con la cocción, 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 estrategia de valor canario con la acción de implementación conduce a la creación de cargas de trabajo con nombres con el sufijo "-baseline" y "-canary". La tarea admite dos métodos de división de tráfico:

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

    Las implementaciones de tipo "canary" que se basan en una malla de servicio y usan esta tarea son más precisas. Esta precisión se debe a que los proveedores de mallas de servicio habilitan la división de tráfico basada en porcentajes pormenorizados. La malla de servicio usa el registro de servicio y los contenedores sidecar que se insertan en pods. Esta inserción se produce junto con los contenedores de aplicaciones para lograr la división granular del tráfico.

  • Kubernetes sinmalla de servicio: en ausencia de una malla de servicio, es posible que no obtenga la división de porcentaje exacta que desea en el nivel de solicitud. Pero es posible que se puedan realizar implementaciones de valores canarios mediante variantes de línea base y de valor canario 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 selector-label. El manifiesto de Kubernetes respeta estas solicitudes al crear variantes de línea base y de valor canario. Este comportamiento de enrutamiento logra el efecto previsto de enrutar solo una parte del total de solicitudes al valor canario.

  Compare las cargas de trabajo de línea base y de valor canario mediante una tarea de intervención manual en canalizaciones de versión o una tarea Retraso en canalizaciones YAML. Realice la comparación antes de usar la acción promover o rechazar de la tarea.

Acción de implementación

El siguiente código YAML 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 y en los foo/demo campos de imagen de los archivos de bar/demo manifiesto. Para cada coincidencia encontrada, el valor de o se anexa tagVariable1 como una etiqueta al nombre de la tagVariable2 imagen. También puede especificar resúmenes en la entrada de contenedores para la sustitución de artefactos.

Acciones de promoción y rechazo

Creación de una acción secreta

El siguiente código YAML muestra un ejemplo de creación de secretos del Registro de Docker mediante la conexión del servicio Docker Registry:

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 de "bake"

El siguiente código YAML es un ejemplo de cómo crear archivos de manifiesto de los gráficos de Helm. Observe el uso de la entrada de nombre en la primera tarea. Más adelante se hace referencia a este nombre desde el paso de implementación para especificar la ruta de acceso a los manifiestos generados por el paso de elaboración.

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

Acción de escalado

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

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

Acción de revisión

El código YAML siguiente muestra un ejemplo de aplicación de revisiones de 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 objeto 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ódigo Abierto

Esta tarea es de código abierto en GitHub. Los comentarios y las contribuciones son bienvenidos.