Implementeren naar Kubernetes

Azure DevOps Services | Azure DevOps Server 2022

U kunt Azure Pipelines gebruiken om te implementeren in Azure Kubernetes Service - en Kubernetes-clusters die worden aangeboden door andere cloudproviders. Azure Pipelines heeft twee taken voor het werken met Kubernetes:

• KubernetesManifest-taak: manifesten bakken en implementeren in Kubernetes-clusters met Helm, Kompose of Kustomize
• Kubectl-taak: een Kubernetes-cluster implementeren, configureren en bijwerken in Azure Container Service door kubectl-opdrachten uit te voeren

Als u Azure Kubernetes Service gebruikt met een van beide taken, is het verbindingstype van de Azure Resource Manager-service de beste manier om verbinding te maken met een privécluster of een cluster waarvoor lokale accounts zijn uitgeschakeld.

Voor extra tracering van implementaties gebruikt u een Kubernetes-resource in omgevingen met een Kubernetes-taak.

Zie Bouwen en implementeren in Azure Kubernetes Service met Azure Pipelines om aan de slag te gaan met Azure Pipelines en de Azure Kubernetes-service. Zie Een canary-implementatiestrategie gebruiken voor Kubernetes-implementaties met Behulp van een canary-implementatiestrategie voor Kubernetes-implementaties met Azure Pipelines om aan de slag te gaan met Azure Pipelines.

KubernetesManifest-taak

De KubernetesManifest-taak controleert op objectstabiliteit voordat een taak als geslaagd/mislukt wordt gemarkeerd. De taak kan ook artefactvervanging uitvoeren, traceringsgerelateerde aantekeningen voor pijplijnen toevoegen, het maken en verwijzen naar imagePullSecrets, bakemanifesten en hulp bij implementatiestrategieimplementaties vereenvoudigen.

Notitie

Hoewel op YAML gebaseerde pijplijn-triggers in één Git-opslagplaats ondersteunen, moet u, als u een trigger nodig hebt voor een manifestbestand dat is opgeslagen in een andere Git-opslagplaats of als triggers nodig zijn voor Azure Container Registry of Docker Hub, een klassieke pijplijn gebruiken in plaats van een OP YAML gebaseerde pijplijn.

U kunt de bake-actie in de Kubernetes-manifesttaak gebruiken om sjablonen in Kubernetes-manifestbestanden te bakenen. Met de actie kunt u hulpprogramma's zoals Helm, Kustomize en Kompose gebruiken. De bake-actie van de Kubernetes-manifesttaak biedt inzicht in de transformatie tussen invoersjablonen en de eindmanifestbestanden die worden gebruikt in implementaties. U kunt gebakken manifestbestanden downstream (in taken) gebruiken als invoer voor de implementatieactie van de Kubernetes-manifesttaak.

U kunt Zich richten op Kubernetes-resources die deel uitmaken van omgevingen met implementatietaken. Het gebruik van omgevingen en resources biedt u toegang tot betere tracering van pijplijnen, zodat u implementatieproblemen kunt diagnosticeren. U kunt ook implementeren in Kubernetes-clusters met reguliere taken zonder dezelfde statusfuncties.

De volgende YAML-code is een voorbeeld van bakmanifestbestanden uit Helm-grafieken

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

Kubectl-taak

Als alternatief voor de KubernetesManifest KubernetesManifest-taak kunt u de Kubectl-taak gebruiken om een Kubernetes-cluster in Azure Container Service te implementeren, configureren en bij te werken door kubectl-opdrachten uit te voeren.

In het volgende voorbeeld ziet u hoe een serviceverbinding wordt gebruikt om te verwijzen naar het Kubernetes-cluster.

- task: Kubernetes@1
  displayName: kubectl apply
  inputs:
    connectionType: Kubernetes Service Connection
    kubernetesServiceEndpoint: Contoso

Scripttaak

U kunt ook gebruiken kubectl met een scripttaak.

In het volgende voorbeeld wordt een script gebruikt om uit te voeren kubectl.

- script: |
    kubectl apply -f manifest.yml

Implementatiestrategieën van Kubernetes

De Kubernetes-manifesttaak ondersteunt momenteel de strategie voor canary-implementatie. Gebruik een canary-implementatiestrategie om gedeeltelijk nieuwe wijzigingen te implementeren, zodat de nieuwe wijzigingen naast de huidige implementaties bestaan vóór een volledige implementatie.

Zie Een canary-implementatiestrategie gebruiken voor Kubernetes-implementaties met Azure Pipelines voor meer informatie over canary-implementaties met pijplijnen.

Kubernetes-implementaties met meerdere clouds

Kubernetes werkt op dezelfde manier op alle cloudproviders. Azure Pipelines kan worden gebruikt voor implementatie in Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) of clusters van andere cloudproviders.

Als u implementatie met meerdere clouds wilt instellen, maakt u een omgeving en voegt u vervolgens uw Kubernetes-resources toe die zijn gekoppeld aan naamruimten van Kubernetes-clusters.

• Azure Kubernetes Service
• Algemene provider die gebruikmaakt van een bestaand serviceaccount

De algemene providerbenadering op basis van een bestaand serviceaccount werkt met clusters van elke cloudprovider, waaronder Azure. Het voordeel van het gebruik van de optie Azure Kubernetes Service is dat er nieuwe ServiceAccount - en RoleBinding-objecten worden gemaakt (in plaats van een bestaand ServiceAccount opnieuw te gebruiken), zodat het zojuist gemaakte RoleBinding-object de bewerkingen van het ServiceAccount alleen kan beperken tot de gekozen naamruimte.

Wanneer u de algemene providerbenadering gebruikt, moet u ervoor zorgen dat er een RoleBinding bestaat, die machtigingen verleent aan het editClusterRole gewenste serviceaccount. U moet machtigingen verlenen aan het juiste servicesaccount, zodat het serviceaccount kan worden gebruikt door Azure Pipelines om objecten te maken in de gekozen naamruimte.

Parallelle implementaties naar meerdere clouds

In het volgende voorbeeld ziet u hoe u parallelle implementaties uitvoert voor clusters in meerdere clouds. In dit voorbeeld zijn er implementaties voor de AKS-, GKE-, EKS- en OpenShift-clusters. Deze vier naamruimten zijn gekoppeld aan Kubernetes-resources onder de contoso omgeving.

trigger:
- main

jobs:
- deployment:
  displayName: Deploy to AKS
  pool:
    vmImage: ubuntu-latest
  environment: contoso.aksnamespace
  strategy:
    runOnce:
      deploy:
        steps:
        - checkout: self
        - task: KubernetesManifest@0
          displayName: Deploy to Kubernetes cluster
          inputs:
            action: deploy
            kubernetesServiceConnection: serviceConnection #replace with your service connection
            namespace: aksnamespace
            manifests: manifests/*
- deployment:
  displayName: Deploy to GKE
  pool:
    vmImage: ubuntu-latest
  environment: contoso.gkenamespace
  strategy:
    runOnce:
      deploy:
        steps:
        - checkout: self
        - task: KubernetesManifest@0
          displayName: Deploy to Kubernetes cluster
          inputs:
            action: deploy
            kubernetesServiceConnection: serviceConnection #replace with your service connection
            namespace: gkenamespace
            manifests: manifests/*
- deployment:
  displayName: Deploy to EKS
  pool:
    vmImage: ubuntu-latest
  environment: contoso.eksnamespace
  strategy:
    runOnce:
      deploy:
        steps:
        - checkout: self
        - task: KubernetesManifest@0
          displayName: Deploy to Kubernetes cluster
          inputs:
            action: deploy
            kubernetesServiceConnection: serviceConnection #replace with your service connection
            namespace: eksnamespace
            manifests: manifests/*
- deployment:
  displayName: Deploy to OpenShift
  pool:
    vmImage: ubuntu-latest
  environment: contoso.openshiftnamespace
  strategy:
    runOnce:
      deploy:
        steps:
        - checkout: self
        - task: KubernetesManifest@0
          displayName: Deploy to Kubernetes cluster
          inputs:
            action: deploy
            kubernetesServiceConnection: serviceConnection #replace with your service connection
            namespace: openshiftnamespace
            manifests: manifests/*
- deployment:
  displayName: Deploy to DigitalOcean
  pool:
    vmImage: ubuntu-latest
  environment: contoso.digitaloceannamespace
  strategy:
    runOnce:
      deploy:
        steps:
        - checkout: self
        - task: KubernetesManifest@0
          displayName: Deploy to Kubernetes cluster
          inputs:
            action: deploy
            kubernetesServiceConnection: serviceConnection #replace with your service connection
            namespace: digitaloceannamespace
            manifests: manifests/*