Implementación en Kubernetes

  • Artículo
  • Tiempo de lectura: 2 minutos

Azure Pipelines

Azure Pipelines se puede usar para implementar en clústeres de Kubernetes ofrecidos por varios proveedores de nube. Este documento contiene los conceptos asociados a la configuración de implementaciones para cualquier clúster de Kubernetes.

Aunque es posible usar el script para cargar archivos kubeconfig en el agente desde una ubicación remota o archivos seguros y, a continuación, usar kubectl para realizar las implementaciones, la tarea KubernetesManifest y la conexión de servicio de Kubernetes se pueden usar para hacerlo de una manera más sencilla y segura.

Tarea KubernetesManifest

La tarea KubernetesManifest tiene las ventajas adicionales de poder comprobar la estabilidad de los objetos antes de marcar una tarea como correcta o con errores, realizar la sustitución de artefactos, agregar anotaciones relacionadas con la rastreabilidad de canalizaciones en objetos implementados, simplificar la creación y la referencia de imagePullSecrets, realizar manifiestos de elaboración mediante helm o kustomization.yaml o archivos de Docker Compose y ayudar en los lanzamientos de la estrategia de implementación.

Recurso de Kubernetes en entornos

El recurso de Kubernetes en entornos proporciona una manera segura de especificar la credencial necesaria para conectarse a un clúster de Kubernetes para realizar implementaciones.

Creación de recursos

En la opción proveedor de Azure Kubernetes Service, una vez que se proporcionan las entradas de suscripción, clúster y espacio de nombres, además de capturar y almacenar de forma segura las credenciales necesarias, para los objetos ServiceAccount y RoleBinding habilitados para RBAC, se crean objetos ServiceAccount y RoleBinding para que ServiceAccount solo pueda realizar acciones en el espacio de nombres elegido.

La opción Proveedor genérico (volver a usar ServiceAccount existente) se puede usar para configurar una conexión con el clúster de cualquier proveedor de nube (AKS/EKS/GKE/OpenShift/etc.).

Ejemplo


jobs:
- deployment:
  displayName: Deploy to AKS
  pool:
    vmImage: ubuntu-latest
  environment: contoso.aksnamespace
  strategy:
    runOnce:
      deploy:
        steps:
        - checkout: self
        - task: KubernetesManifest@0
          displayName: Create secret
          inputs: 
            action: createSecret
            namespace: aksnamespace
            secretType: dockerRegistry
            secretName: foo-acr-secret
            dockerRegistryEndpoint: fooACR
            
        - task: KubernetesManifest@0
          displayName: Create secret
          inputs: 
            action: createSecret
            namespace: aksnamespace
            secretType: dockerRegistry
            secretName: bar-acr-secret
            dockerRegistryEndpoint: barACR
            
        - task: KubernetesManifest@0
          displayName: Deploy
          inputs:
            action: deploy
            namespace: aksnamespace
            manifests: manifests/deployment.yml|manifests/service.yml
            containers: |
              foo.azurecr.io/demo:$(tagVariable1)
              bar.azurecr.io/demo:$(tagVariable2)
            imagePullSecrets: |
              foo-acr-secret
              bar-acr-secret

Tenga en cuenta que para permitir la extracción de imágenes de registros privados, antes de la acción, la acción se usa junto con las instancias de conexión del servicio del registro de Docker para crear deploycreateSecret imagePullSecrets deploy a los que posteriormente se hace referencia en el paso correspondiente a la deploy acción.

Sugerencia

  • Si configura una canalización de CI-CD de un extremo a otro para un repositorio que contiene un Dockerfile, consulte la plantilla Deploy to Azure Kubernetes (Implementar en Azure Kubernetes),que crea una canalización DE YAML de un extremo a otro junto con la creación de un entorno y un recurso de Kubernetes para ayudar a visualizar estas implementaciones.
  • Aunque la canalización basada en YAML admite actualmente desencadenadores en un único repositorio git, si se requieren desencadenadores para los archivos de manifiesto almacenados en otro repositorio de Git o si se requieren desencadenadores para Azure Container Registry o Docker Hub, se recomienda el uso de canalizaciones de versión en lugar de una canalización basada en YAML para realizar las implementaciones de Kubernetes.

Alternativas

En lugar de usar la tarea KubernetesManifest para la implementación, también se pueden usar las siguientes alternativas:

  • Tarea Kubectl
  • Invocación de kubectl en el script. Por ejemplo: script: kubectl apply -f manifest.yml