Bereitstellen in Kubernetes

Azure DevOps Services | Azure DevOps Server 2022

Sie können Azure Pipelines für die Bereitstellung in Azure Kubernetes Service- und Kubernetes-Clustern verwenden, die von anderen Cloudanbietern angeboten werden. Azure Pipelines verfügt über zwei Aufgaben für die Arbeit mit Kubernetes:

• KubernetesManifest-Aufgabe: Baking und Bereitstellung von Manifesten in Kubernetes-Clustern mit Helm, Kompose oder Kustomize
• Kubectl-Aufgabe: Bereitstellen, Konfigurieren und Aktualisieren eines Kubernetes-Clusters in Azure Container Service durch Ausführen von kubectl-Befehlen.

Wenn Sie Azure Kubernetes Service mit einer der beiden Aufgaben verwenden, ist der Azure Resource Manager-Dienstverbindungstyp die beste Möglichkeit, eine Verbindung mit einem privaten Cluster oder einem Cluster mit deaktivierten lokalen Konten herzustellen.

Wenn Sie die Nachverfolgbarkeit der Bereitstellung verbessern möchten, verwenden Sie eine Kubernetes-Ressource in Umgebungen mit einer Kubernetes-Aufgabe.

Informationen zu den ersten Schritten mit Azure Pipelines und Azure Kubernetes Service finden Sie unter Erstellen und Bereitstellen in Azure Kubernetes Service mit Azure Pipelines. Informationen zu den ersten Schritten mit Azure Pipelines, Kubernetes und insbesondere mit der Canary-Bereitstellungsstrategie finden Sie unter Verwenden einer Canary-Bereitstellungsstrategie für Kubernetes-Bereitstellungen mit Azure Pipelines.

KubernetesManifest-Aufgabe

Von der KubernetesManifest-Aufgabe wird die Objektstabilität überprüft, bevor eine Aufgabe als Erfolg/Fehler markiert wird. Die Aufgabe ermöglicht es auch, Artefaktersetzungen durchzuführen, Anmerkungen im Zusammenhang mit der Nachverfolgbarkeit der Pipeline hinzuzufügen, das Erstellen und Verweisen auf imagePullSecrets zu vereinfachen, Baking von Manifesten auszuführen und Rollouts von Bereitstellungsstrategien zu unterstützen.

Hinweis

Eine YAML-basierte Pipeline unterstützt zwar Trigger für ein einzelnes Git-Repository, wenn Sie aber einen Trigger für eine in einem anderen Git-Repository gespeicherte Manifestdatei benötigen oder Trigger für Azure Container Registry oder Docker Hub erforderlich sind, sollten Sie anstelle einer YAML-basierten Pipeline eine klassische Pipeline verwenden.

Sie können die Baking-Aktion in der Kubernetes-Manifestaufgabe verwenden, um ein Baking von Vorlagen in Kubernetes-Manifestdateien auszuführen. Mit der Aktion können Sie Tools wie Helm, Kustomize und Kompose verwenden. Die Baking-Aktion der Kubernetes-Manifestaufgabe bietet Einblick in die Transformation zwischen Eingabevorlagen und den Endmanifestdateien, die in Bereitstellungen verwendet werden. Sie können nachgeschaltete Manifestdateien (in Aufgaben) als Eingaben für die Bereitstellungsaktion der Kubernetes-Manifestaufgabe verwenden.

Sie können Kubernetes-Ressourcen, die Teil von Umgebungen sind, mit Bereitstellungsaufträgen als Ziel verwenden. Mithilfe der Bereitstellung von Umgebungen und Ressourcen erhalten Sie Zugriff auf eine bessere Nachverfolgbarkeit von Pipelines, sodass Sie Bereitstellungsprobleme diagnostizieren können. Sie können Bereitstellungen auch in Kubernetes-Clustern mit regulären Aufträgen ohne dieselben Integritätsfeatures durchführen.

Der folgende YAML-Code ist ein Beispiel für das Baking von Manifestdateien aus Helm-Charts.

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-Aufgabe

Alternativ zur KubernetesManifest-Aufgabe können Sie die Kubectl-Aufgabe verwenden, um einen Kubernetes-Cluster in Azure Container Service bereitzustellen, zu konfigurieren und zu aktualisieren, indem Sie kubectl-Befehle ausführen.

Das folgende Beispiel zeigt, wie eine Dienstverbindung verwendet wird, um auf den Kubernetes-Cluster zu verweisen.

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

Skripttask

Sie können auch kubectl mit einer Skriptaufgabe verwenden.

Im folgenden Beispiel wird ein Skript verwendet, um kubectl auszuführen.

- script: |
    kubectl apply -f manifest.yml

Kubernetes-Bereitstellungsstrategien

Die Kubernetes-Manifestaufgabe bietet derzeit Unterstützung für die Canary-Bereitstellungsstrategie. Verwenden Sie die Canary-Bereitstellungsstrategie, um teilweise neue Änderungen bereitzustellen, sodass die neuen Änderungen vor einem vollständigen Rollout mit den aktuellen Bereitstellungen koexistieren.

Weitere Informationen zu Canary-Bereitstellungen mit Pipelines finden Sie unter Verwenden einer Canary-Bereitstellungsstrategie für Kubernetes-Bereitstellungen mit Azure Pipelines.

Kubernetes-Bereitstellungen in mehreren Clouds

Kubernetes wird bei allen Cloudanbietern auf die gleiche Weise ausgeführt. Azure Pipelines kann für die Bereitstellung in Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) oder Clustern von anderen Cloudanbietern verwendet werden.

Erstellen Sie zum Einrichten der Multi-Cloud-Bereitstellung eine Umgebung, und fügen Sie dann Ihre Kubernetes-Ressourcen hinzu, die Namespaces von Kubernetes-Clustern zugeordnet sind.

• Azure Kubernetes Service
• Generischer Anbieter, der ein vorhandenes Dienstkonto verwendet

Der generische Anbieteransatz, der auf einem vorhandenen Dienstkonto basiert, funktioniert mit Clustern von jedem Cloudanbieter, einschließlich Azure. Der Vorteil der Verwendung der Option Azure Kubernetes Service ist, dass neue ServiceAccount- und RoleBinding-Objekte erstellt werden (anstatt ein vorhandenes ServiceAccount wiederzuverwenden), sodass das neu erstellte RoleBinding-Objekt die Vorgänge des ServiceAccount nur auf den ausgewählten Namespace beschränken kann.

Wenn Sie den generischen Anbieteransatz verwenden, vergewissern Sie sich, dass eine RoleBinding vorhanden ist, die dem gewünschten Dienstkonto Berechtigungen in der edit-ClusterRole gewährt. Sie müssen dem richtigen Dienstkonto Berechtigungen erteilen, damit das Dienstkonto von Azure Pipelines zum Erstellen von Objekten im ausgewählten Namespace verwendet werden kann.

Parallele Bereitstellungen in mehreren Clouds

Das folgende Beispiel zeigt, wie Sie parallele Bereitstellungen in Clustern in mehreren Clouds durchführen. In diesem Beispiel gibt es Bereitstellungen für die AKS-, GKE-, EKS- und OpenShift-Cluster. Diese vier Namespaces sind Kubernetes-Ressourcen in der contoso-Umgebung zugeordnet.

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/*