Bereitstellen in Kubernetes

  • 2 Minuten Lesedauer

Azure Pipelines

Azure Pipelines können zur Bereitstellung in Kubernetes-Clustern verwendet werden, die von mehreren cloudanbietern angeboten werden. Dieses Dokument enthält die Konzepte, die dem Einrichten von bereit Stellungen für beliebige Kubernetes-Cluster zugeordnet sind.

Obwohl es möglich ist, Skripts zum Laden von kubeconfig-Dateien auf den Agent von einem Remote Speicherort oder aus sicheren Dateien zu verwenden, und dann kubectl zum Durchführen der bereit Stellungen verwenden, können die kubernetesmanifest-Aufgabe und die Kubernetes-Dienst Verbindung verwendet werden, um dies auf einfachere und sicherere Weise zu erreichen.

Kubernetesmanifest-Aufgabe

Die kubernetesmanifest-Aufgabe hat die zusätzlichen Vorteile, dass Sie die Objekt Stabilität überprüfen können, bevor Sie eine Aufgabe als Erfolg/Fehler markieren, eine Artefakte Ersetzung durchführen, in der Pipeline nach Verfolgungs bezogenen Anmerkungen zu bereitgestellten Objekten hinzufügen, die Erstellung und den Verweis auf imagepullsecrets vereinfachen, Manifeste mithilfe von Helm oder kustomisierung. YAML oder docker Compose

Kubernetes-Ressource in Umgebungen

Kubernetes Resource in Umgebungen bietet eine sichere Möglichkeit zum Angeben der Anmelde Informationen, die erforderlich sind, um eine Verbindung mit einem Kubernetes-Cluster zum Ausführen von bereit Stellungen herzustellen.

Ressourcenerstellung

In der Option Azure Kubernetes Service Provider werden nach dem Bereitstellen der Abonnement-, Cluster-und Namespace Eingaben zusätzlich zum Abrufen und sicheren Speichern der erforderlichen Anmelde Informationen für ein RBAC-fähiges Cluster Dienst Konto und rolebinding -Objekte so erstellt, dass das ServiceAccount nur Aktionen für den ausgewählten Namespace ausführen kann.

Die Option generischer Anbieter (Reusing-Dienst Konto) kann verwendet werden, um eine Verbindung mit dem Cluster eines beliebigen cloudanbieters (AKS/EKS/GKE/openshift/usw.) zu konfigurieren.

Beispiel


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

Beachten Sie, dass deploy die createSecret Aktion zusammen mit Instanzen der docker-Registrierungsdienst Verbindung verwendet wird, um imagepullsecrets zu erstellen, auf die später in dem Schritt verwiesen wird, der der deploy Aktion entspricht.

Tipp

  • Wenn Sie eine End-to-End-CI-CD-Pipeline für ein Repository, das eine dockerfile-Datei enthält, von Grund auf neu einrichten, checken Sie die Vorlage Bereitstellung in Azure Kubernetesein, die eine End-to-End-YAML-Pipeline mit der Erstellung einer Umgebung und einer Kubernetes-Ressource erstellt, um diese bereit Stellungen visuell darzustellen.
  • Obwohl in der YAML-basierten Pipeline derzeit Trigger in einem einzelnen git-Repository unterstützt werden, werden für die Bereitstellung von Kubernetes die Verwendung von releasepipelines anstelle einer YAML-basierten Pipeline empfohlen, wenn Trigger für Manifest-Dateien erforderlich sind, die in einem anderen git-Repository gespeichert sind, oder wenn Trigger für Azure Container Registry oder docker-Hub erforderlich sind.

Alternativen

Anstatt die kubernetesmanifest-Aufgabe für die Bereitstellung zu verwenden, können Sie auch die folgenden Alternativen verwenden:

  • Kubectl-Aufgabe
  • kubectl-Aufruf für Skript. Beispiel: script: kubectl apply -f manifest.yml