KubernetesManifest@1 – Bereitstellen in Kubernetes v1-Aufgabe

Verwenden Sie Kubernetes-Manifestdateien, um sie in Clustern bereitzustellen oder sogar die Manifestdateien zu backen, die für Bereitstellungen mit Helm-Diagrammen verwendet werden sollen.

Syntax

# Deploy to Kubernetes v1
# Use Kubernetes manifest files to deploy to clusters or even bake the manifest files to be used for deployments using Helm charts.
- task: KubernetesManifest@1
  inputs:
    #action: 'deploy' # 'bake' | 'createSecret' | 'delete' | 'deploy' | 'patch' | 'promote' | 'scale' | 'reject'. Action. Default: deploy.
    #connectionType: 'kubernetesServiceConnection' # 'azureResourceManager' | 'kubernetesServiceConnection'. Required when action != bake. Service connection type. Default: kubernetesServiceConnection.
    #kubernetesServiceConnection: # string. Alias: kubernetesServiceEndpoint. Required when action != bake && connectionType = kubernetesServiceConnection. Kubernetes service connection. 
    #azureSubscriptionConnection: # string. Alias: azureSubscriptionEndpoint. Required when action != bake && connectionType = azureResourceManager. Azure subscription. 
    #azureResourceGroup: # string. Required when action != bake && connectionType = azureResourceManager. Resource group. 
    #kubernetesCluster: # string. Required when action != bake && connectionType = azureResourceManager. Kubernetes cluster. 
    #useClusterAdmin: false # boolean. Optional. Use when connectionType = azureResourceManager. Use cluster admin credentials. Default: false.
    #namespace: # string. Namespace. 
    #strategy: 'none' # 'canary' | 'none'. Optional. Use when action = deploy || action = promote || action = reject. Strategy. Default: none.
    #trafficSplitMethod: 'pod' # 'pod' | 'smi'. Optional. Use when strategy = canary. Traffic split method. Default: pod.
    #percentage: '0' # string. Required when strategy = Canary && action = deploy. Percentage. Default: 0.
    #baselineAndCanaryReplicas: '1' # string. Required when strategy = Canary && action = deploy && trafficSplitMethod = SMI. Baseline and canary replicas. Default: 1.
    #manifests: # string. Required when action = deploy || action = promote || action = reject. Manifests. 
    #containers: # string. Optional. Use when action = deploy || action = promote || action = bake. Containers. 
    #imagePullSecrets: # string. Optional. Use when action = deploy || action = promote. ImagePullSecrets. 
    #renderType: 'helm' # 'helm' | 'kompose' | 'kustomize'. Optional. Use when action = bake. Render Engine. Default: helm.
    #dockerComposeFile: # string. Required when action = bake && renderType = kompose. Path to docker compose file. 
    #helmChart: # string. Required when action = bake && renderType = helm. Helm Chart. 
    #releaseName: # string. Optional. Use when action = bake && renderType = helm. Helm Release Name. 
    #overrideFiles: # string. Optional. Use when action = bake && renderType = helm. Override Files. 
    #overrides: # string. Optional. Use when action = bake && renderType = helm. Overrides. 
    #kustomizationPath: # string. Optional. Use when action = bake && renderType = kustomize. Kustomization Path. 
    #resourceToPatch: 'file' # 'file' | 'name'. Required when action = patch. Resource to patch. Default: file.
    #resourceFileToPatch: # string. Required when action = patch && resourceToPatch = file. File path. 
    #kind: # 'deployment' | 'replicaset' | 'statefulset'. Required when action = scale || resourceToPatch = name. Kind. 
    #name: # string. Required when action = scale || resourceToPatch = name. Name. 
    #replicas: # string. Required when action = scale. Replica count. 
    #mergeStrategy: 'strategic' # 'json' | 'merge' | 'strategic'. Required when action = patch. Merge Strategy. Default: strategic.
    #arguments: # string. Optional. Use when action = delete. Arguments. 
    #patch: # string. Required when action = patch. Patch. 
    #secretType: 'dockerRegistry' # 'dockerRegistry' | 'generic'. Required when action = createSecret. Type of secret. Default: dockerRegistry.
    #secretName: # string. Optional. Use when action = createSecret. Secret name. 
    #secretArguments: # string. Optional. Use when action = createSecret && secretType = generic. Arguments. 
    #dockerRegistryEndpoint: # string. Optional. Use when action = createSecret && secretType = dockerRegistry. Docker registry service connection. 
    #rolloutStatusTimeout: '0' # string. Optional. Use when action = deploy || action = patch || action = scale || action = promote. Timeout for rollout status. Default: 0.
    #resourceType: 'Microsoft.ContainerService/managedClusters' # string. Optional. Use when action = deploy. Resource type. Default: Microsoft.ContainerService/managedClusters.

Eingänge

action - Aktion
string. Zulässige Werte: bake, createSecret (geheim erstellen), delete, deploy, patch, promote, scale, reject. Standardwert: deploy.

Gibt die auszuführende Aktion an.

connectionType - Dienstverbindungstyp
string. Erforderlich, wenn action != bake. Zulässige Werte: azureResourceManager (Azure Resource Manager), kubernetesServiceConnection (Kubernetes Service Connection). Standardwert: kubernetesServiceConnection.

Wählen Sie einen Verbindungstyp für den Kubernetes-Dienst aus.

• kubernetesServiceConnection (Kubernetes Service-Verbindung): Ermöglicht das Bereitstellen einer KubeConfig-Datei, das Angeben eines Dienstkontos oder das Importieren einer AKS-Instanz mit der Option Azure-Abonnement . Für das Importieren einer AKS-Instanz mit der Option Azure-Abonnement ist der Kubernetes-Clusterzugriff zur Dienstverbindungskonfiguration erforderlich.
• azureResourceManager (Azure Resource Manager): Ermöglicht die Auswahl einer AKS-Instanz. Greift nicht auf Kubernetes-Cluster zur Dienstverbindungskonfiguration zu.

Weitere Informationen finden Sie unter Anmerkungen.

kubernetesServiceConnection - Kubernetes-Dienstverbindung
Eingabealias: kubernetesServiceEndpoint. string. Erforderlich, wenn action != bake && connectionType = kubernetesServiceConnection.

Gibt eine Kubernetes-Dienstverbindungan.

azureSubscriptionConnection - Azure-Abonnement
Eingabealias: azureSubscriptionEndpoint. string. Erforderlich, wenn action != bake && connectionType = azureResourceManager.

Wählen Sie das Azure Resource Manager-Abonnement aus, das Azure Container Registry enthält.Hinweis: Um eine neue Dienstverbindung zu konfigurieren, wählen Sie das Azure-Abonnement aus der Liste aus, und klicken Sie auf "Autorisieren". Wenn Ihr Abonnement nicht aufgeführt ist oder Sie einen vorhandenen Dienstprinzipal verwenden möchten, können Sie über die Schaltfläche "Hinzufügen" oder "Verwalten" eine Azure-Dienstverbindung einrichten.

azureResourceGroup - Ressourcengruppe
string. Erforderlich, wenn action != bake && connectionType = azureResourceManager.

Wählen Sie eine Azure-Ressourcengruppe aus.

kubernetesCluster - Kubernetes-Cluster
string. Erforderlich, wenn action != bake && connectionType = azureResourceManager.

Wählen Sie einen von Azure verwalteten Cluster aus.

useClusterAdmin - Verwenden von Clusteradministratoranmeldeinformationen
boolean. Wahlfrei. Wird verwendet, wenn connectionType = azureResourceManager. Standardwert: false.

Verwenden Sie Clusteradministratoranmeldeinformationen anstelle von Standardbenutzeranmeldeinformationen für Clusterbenutzer.

namespace - Namespace-
string.

Gibt den Namespace für die Befehle mithilfe des –namespace-Flags an. Wenn der Namespace nicht angegeben wird, werden die Befehle im Standardnamespace ausgeführt.

strategy - Strategie
string. Wahlfrei. Wird verwendet, wenn action = deploy || action = promote || action = reject. Zulässige Werte: canary, none. Standardwert: none.

Gibt die Bereitstellungsstrategie an, die in der deploy-Aktion vor einer promote Aktion oder reject Aktion verwendet wird. Derzeit ist canary die einzige akzeptable Bereitstellungsstrategie.

trafficSplitMethod - Geteilte Datenverkehrsmethode
string. Wahlfrei. Wird verwendet, wenn strategy = canary. Zulässige Werte: pod, smi. Standardwert: pod.

Für den Wert smiwird die prozentuale Datenverkehrsteilung auf Anforderungsebene mithilfe eines Dienstgitters durchgeführt. Ein Dienstgitter muss von einem Clusteradministrator eingerichtet werden. Diese Aufgabe behandelt die Orchestrierung von SMI-TrafficSplit--Objekten.

Für den Wert podist die prozentuale Aufteilung auf Anforderungsebene nicht möglich, wenn kein Dienstgitter vorhanden ist. Stattdessen wird die Prozentuale Eingabe verwendet, um die Replikate für Basisplan und Canary zu berechnen. Die Berechnung ist ein Prozentsatz der Replikate, die in den Eingabemanifesten für die stabile Variante angegeben sind.

percentage - Prozentsatz
string. Erforderlich, wenn strategy = Canary && action = deploy. Standardwert: 0.

Der Prozentsatz, der zum Berechnen der Anzahl der Basisplanvarianten- und Canary-Variant-Replikate der Workloads verwendet wird, die in Manifestdateien enthalten sind.

Berechnen Sie für die angegebene Prozenteingabe Folgendes:

(Prozentsatz × Anzahl der Replikate) / 100

Wenn das Ergebnis keine ganze Zahl ist, wird der mathematische Boden des Ergebnisses verwendet, wenn Basisplan- und Canaryvarianten erstellt werden.

Gehen Sie beispielsweise davon aus, dass sich die Bereitstellung hello-world in der Eingabemanifestdatei befindet und dass sich die folgenden Zeilen in der Aufgabeneingabe befinden:

replicas: 4
strategy: canary
percentage: 25

In diesem Fall werden die Bereitstellungen hello-world-baseline und hello-world-canary mit jeweils einem Replikat erstellt. Die Basisplanvariante wird mit demselben Image und Tag wie die stabile Version erstellt, bei der es sich um die Variante mit vier Replikaten vor der Bereitstellung handelt. Die Canaryvariante wird mit dem Image und tag erstellt, das den neu bereitgestellten Änderungen entspricht.

baselineAndCanaryReplicas - Baseline- und Canary-Replikate
string. Erforderlich, wenn strategy = Canary && action = deploy && trafficSplitMethod = SMI. Standardwert: 1.

Wenn Sie trafficSplitMethod auf smifestlegen, wird die prozentuale Datenverkehrsteilung in der Dienstgitterebene gesteuert. Sie können die tatsächliche Anzahl der Replikate für Canary- und Basisplanvarianten unabhängig von der Datenverkehrsteilung steuern.

Angenommen, das Eingabebereitstellungsmanifest gibt 30 Replikate für die stabile Variante an. Gehen Sie außerdem davon aus, dass Sie die folgende Eingabe für den Vorgang angeben:

strategy: canary
trafficSplitMethod: smi
percentage: 20
baselineAndCanaryReplicas: 1

In diesem Fall empfängt die stabile Variante 80% des Datenverkehrs, während die Basis- und Canaryvarianten jeweils die Hälfte der angegebenen 20%erhalten. Basisplan- und Canaryvarianten erhalten nicht jeweils drei Replikate. Sie erhalten stattdessen die angegebene Anzahl von Replikaten, was bedeutet, dass sie jeweils ein Replikat erhalten.

manifests - Manifeste
string. Erforderlich, wenn action = deploy || action = promote || action = reject.

Gibt den Pfad zu den Manifestdateien an, die für die Bereitstellung verwendet werden sollen. Jede Zeile stellt einen einzelnen Pfad dar. Ein Dateiabgleichsmuster ist ein akzeptabler Wert für jede Zeile.

containers - Container
string. Wahlfrei. Wird verwendet, wenn action = deploy || action = promote || action = bake.

Gibt die vollqualifizierte Ressourcen-URL des Bilds an, das für Ersetzungen in den Manifestdateien verwendet werden soll. Die URL contosodemo.azurecr.io/helloworld:test ist ein Beispiel.

imagePullSecrets - ImagePullSecrets
string. Wahlfrei. Wird verwendet, wenn action = deploy || action = promote.

Gibt eine mehrzeilige Eingabe an, in der jede Zeile den Namen eines Docker-Registrierungsschlüssels enthält, der bereits im Cluster eingerichtet wurde. Jeder geheime Name wird unter imagePullSecrets für die Workloads hinzugefügt, die in den Eingabemanifestdateien enthalten sind.

renderType - Rendermodul-
string. Wahlfrei. Wird verwendet, wenn action = bake. Zulässige Werte: helm, kompose, kustomize. Standardwert: helm.

Gibt den Rendertyp an, der zum Erstellen der Manifestdateien verwendet wird.

dockerComposeFile - Pfad zur Docker-Erstelldatei
string. Erforderlich, wenn action = bake && renderType = kompose.

Gibt einen Docker-Compose-Dateipfad an.

helmChart - Helmdiagramm
string. Erforderlich, wenn action = bake && renderType = helm.

Gibt den Helm-Diagrammpfad zum Backen an.

releaseName - Name der Helm-Version
string. Wahlfrei. Wird verwendet, wenn action = bake && renderType = helm.

Gibt den zu verwendenden Helm-Versionsnamen an.

overrideFiles - Außerkraftsetzen von Dateien
string. Wahlfrei. Wird verwendet, wenn action = bake && renderType = helm.

Gibt eine mehrzeile Eingabe an, die den Pfad zu den Außerkraftsetzungsdateien akzeptiert. Die Dateien werden verwendet, wenn Manifestdateien aus Helm-Diagrammen gebacken werden.

overrides - Außerkraftsetzungen
string. Wahlfrei. Wird verwendet, wenn action = bake && renderType = helm.

Gibt die festzulegenden Außerkraftsetzungswerte an.

kustomizationPath - Kustomisierungspfad
string. Wahlfrei. Wird verwendet, wenn action = bake && renderType = kustomize.

Gibt das Argument an, das der Pfad zum Verzeichnis sein muss, das die Datei enthält, oder eine Git-Repository-URL mit einem Pfadsuffix, das same im Hinblick auf den Repositorystamm angibt.

resourceToPatch - Ressource zum Patchen von
string. Erforderlich, wenn action = patch. Zulässige Werte: file, name. Standardwert: file.

Gibt eine der folgenden Patchmethoden an:

• Eine Manifestdatei identifiziert die objekte, die gepatcht werden sollen.
• Ein einzelnes Objekt wird nach Art und Name als Patchziel identifiziert.

Zulässige Werte sind Datei- und Namen.

resourceFileToPatch - Dateipfad
string. Erforderlich, wenn action = patch && resourceToPatch = file.

Gibt den Pfad zu der Datei an, die für einen Patch verwendet wird.

kind - Kind-
string. Erforderlich, wenn action = scale || resourceToPatch = name. Zulässige Werte: deployment, replicaset, statefulset.

Gibt die Art des K8s-Objekts an, z. B. deployment, replicaSet und mehr.

name - Name
string. Erforderlich, wenn action = scale || resourceToPatch = name.

Gibt den Namen des K8s-Objekts an.

replicas - Replikatanzahl
string. Erforderlich, wenn action = scale.

Gibt die Anzahl der Replikate an, auf die skaliert werden soll.

mergeStrategy - zusammenführen
string. Erforderlich, wenn action = patch. Zulässige Werte: json, merge, strategic. Standardwert: strategic.

Gibt den Typ des bereitgestellten Patches an.

arguments - Argumente
string. Wahlfrei. Wird verwendet, wenn action = delete.

Gibt die Argumente für den Befehl kubectl delete an. Beispiel: arguments: deployment hello-world foo-bar

patch - Patch-
string. Erforderlich, wenn action = patch.

Gibt den Inhalt des Patches an.

secretType - Geheimschlüsseltyp
string. Erforderlich, wenn action = createSecret. Zulässige Werte: dockerRegistry, generic. Standardwert: dockerRegistry.

Erstellt oder aktualisiert ein generisches oder Docker-imagepullsecret. Geben Sie dockerRegistry an, um die imagepullsecret der ausgewählten Registrierung zu erstellen oder zu aktualisieren. Ein imagePullSecret ist eine Möglichkeit, einen geheimen Schlüssel zu übergeben, der ein Containerregistrierungskennwort an das Kubelet enthält, damit es ein privates Image im Namen Ihres Pods abrufen kann.

secretName - Geheimer Name
string. Wahlfrei. Wird verwendet, wenn action = createSecret.

Gibt den Namen des geheimen Schlüssels an. Sie können diesen geheimen Namen in der YaML-Konfigurationsdatei Kubernetes verwenden.

secretArguments - Argumente
string. Wahlfrei. Wird verwendet, wenn action = createSecret && secretType = generic.

Gibt Schlüssel und Literalwerte an, die in einen geheimen Schlüssel eingefügt werden sollen. Beispiel: --from-literal=key1=value1--from-literal=key2="top secret".

dockerRegistryEndpoint - Docker-Registrierungsdienstverbindung
string. Wahlfrei. Wird verwendet, wenn action = createSecret && secretType = dockerRegistry.

Gibt die Anmeldeinformationen der angegebenen Dienstverbindung an, die zum Erstellen eines Docker-Registrierungsschlüssels innerhalb des Clusters verwendet werden. Manifestdateien unter dem Feld imagePullSecrets können dann auf den Namen dieses geheimen Schlüssels verweisen.

rolloutStatusTimeout - Timeout für den Rolloutstatus
string. Wahlfrei. Wird verwendet, wenn action = deploy || action = patch || action = scale || action = promote. Standardwert: 0.

Gibt die Zeitdauer (in Sekunden) an, die gewartet werden soll, bevor watch on rollout Status beendet wird.

resourceType - Ressourcentyp-
string. Wahlfrei. Wird verwendet, wenn action = deploy. Standardwert: Microsoft.ContainerService/managedClusters.

Der Typ der Ressource (Flotte, verwalteter Cluster).

Aufgabensteuerungsoptionen

Alle Aufgaben verfügen zusätzlich zu ihren Aufgabeneingaben über Steuerungsoptionen. Weitere Informationen finden Sie unter Steuerelementoptionen und allgemeinen Aufgabeneigenschaften.

Ausgabevariablen

Mit dieser Aufgabe werden die folgenden Ausgabevariablendefiniert, die Sie in nachgeschalteten Schritten, Aufträgen und Phasen verwenden können.

manifestsBundle
Der Speicherort der Manifestpakete, die von der Bake-Aktion erstellt wurden

Bemerkungen

Überlegungen zur Kubernetes-Dienstverbindung beim Zugriff auf AKS

Sie können eine Kubernetes-Dienstverbindung mit einer der folgenden Optionen erstellen.

• KubeConfig
• Dienstkonto
• Azure-Abonnement

Wenn Sie die Option Azure-Abonnement auswählen, muss Kubernetes zur Dienstverbindungskonfiguration auf Azure DevOps zugreifen können. Es kann verschiedene Gründe geben, warum eine Dienstverbindung nicht erstellt werden kann, z. B. sie einen privaten Cluster erstellt haben oder der Cluster lokalen Kontendeaktiviert hat. In diesen Fällen kann Azure DevOps zur Dienstverbindungskonfiguration keine Verbindung mit Ihrem Cluster herstellen, und Es wird ein hängen gebliebener Laden von Namespaces Bildschirm angezeigt.

Ab Kubernetes 1.24 werden langlebige Token standardmäßig nicht mehrerstellt. Kubernetes empfiehlt, keine langlebigen Token zu verwenden. Daher haben Aufgaben, die eine Kubernetes-Dienstverbindung verwenden, die mit der Option Azure-Abonnement erstellt wurde, keinen Zugriff auf das permanente Token, das für die Authentifizierung erforderlich ist und nicht auf Ihren Kubernetes-Cluster zugreifen kann. Dies führt auch zum fixierten Laden von Namespaces Dialogfeld.

Verwenden der Azure Resource Manager-Dienstverbindung für den Zugriff auf AKS

Für AKS-Kunden bietet der Azure Resource Manager-Dienstverbindungstyp die beste Methode zum Herstellen einer Verbindung mit einem privaten Cluster oder einem Cluster mit deaktivierten lokalen Konten. Diese Methode hängt nicht von der Clusterkonnektivität zum Zeitpunkt der Erstellung einer Dienstverbindung ab. Der Zugriff auf AKS wird an die Pipelinelaufzeit verzögert, was die folgenden Vorteile bietet:

• Der Zugriff auf einen (privaten) AKS-Cluster kann von einem selbst gehosteten oder Skalensatz-Agent mit Blick auf den Cluster ausgeführt werden.
• Für jede Aufgabe, die eine Azure Resource Manager-Dienstverbindung verwendet, wird ein Token erstellt. Dadurch wird sichergestellt, dass Sie eine Verbindung mit Kubernetes mit einem kurzlebigen Token herstellen, bei dem es sich um die Kubernetes-Empfehlunghandelt.
• Auf AKS kann auch zugegriffen werden, wenn lokale Konten deaktiviert sind.

Häufig gestellte Fragen zur Dienstverbindung

Ich erhalte die folgende Fehlermeldung: Es wurde kein geheimer Schlüssel gefunden, der dem Dienstkonto zugeordnet ist. Was passiert?

Sie verwenden die Kubernetes-Dienstverbindung mit der Azure-Abonnementoption. Wir aktualisieren diese Methode, um langlebige Token zu erstellen. Dies wird voraussichtlich Mitte Mai verfügbar sein. Es wird jedoch empfohlen, mit der Verwendung des Azure-Dienstverbindungstyps zu beginnen und keine langlebigen Token gemäß Kubernetes-Leitfadenzu verwenden.

Ich verwende AKS und möchte nichts ändern, kann ich weiterhin Aufgaben mit der Kubernetes-Dienstverbindung verwenden?

Wir aktualisieren diese Methode, um langlebige Token zu erstellen. Dies wird voraussichtlich Mitte Mai verfügbar sein. Bitte beachten Sie jedoch, dass dieser Ansatz gegen Kubernetes-Anleitung.

Ich verwende die Kubernetes-Aufgaben und kubernetes-Dienstverbindung, aber keine AKS. Sollte ich besorgt sein?

Aufgaben funktionieren weiterhin wie zuvor.

Wird der Dienstverbindungstyp Kubernetes entfernt?

Unsere Kubernetes-Aufgaben arbeiten mit jedem Kubernetes-Cluster, unabhängig davon, wo sie ausgeführt werden. Die Kubernetes-Dienstverbindung ist weiterhin vorhanden.

Ich bin ein AKS-Kunde und alles läuft gut, sollte ich handeln?

Es ist nicht erforderlich, etwas zu ändern. Wenn Sie die Kubernetes-Dienstverbindung verwenden und während der Erstellung das Azure-Abonnement ausgewählt haben, sollten Sie sich den Kubernetes-Anleitungen zur Verwendung von langlebigen Tokenbewusst sein.

Ich erschaffe eine Kubernetes-Umgebung und habe keine Möglichkeit, Dienstverbindungen zu verwenden.

Falls Sie während der Erstellungszeit der Umgebung nicht auf Ihre AKS zugreifen können, können Sie eine leere Umgebung verwenden und die connectionType Eingabe auf eine Azure Resource Manager-Dienstverbindung festlegen.

Ich habe AKS mit Azure Active Directory RBAC konfiguriert, und meine Pipeline funktioniert nicht. Werden diese Updates dies beheben?

Der Zugriff auf Kubernetes, wenn AAD RBAC aktiviert ist, ist nicht mit der Tokenerstellung verknüpft. Um eine interaktive Eingabeaufforderung zu verhindern, werden wir kubelogin in einem zukünftigen Update unterstützen.

Verwenden Sie eine Kubernetes-Manifestaufgabe in einer Build- oder Releasepipeline, um Manifeste in Kubernetes-Clustern zu backen und bereitzustellen.

Diese Aufgabe unterstützt Folgendes:

• Artefaktersetzung: Die Bereitstellungsaktion führt als Eingabe einer Liste von Containerimages aus, die Sie zusammen mit ihren Tags und Digests angeben können. Die gleiche Eingabe wird in die Nichttemplatisierten Manifestdateien vor der Anwendung auf den Cluster ersetzt. Durch diese Ersetzung wird sichergestellt, dass die Clusterknoten die richtige Version des Bilds ziehen.

• Manifeststabilität: Der Rolloutstatus der bereitgestellten Kubernetes-Objekte wird überprüft. Die Stabilitätsprüfungen werden integriert, um festzustellen, ob der Vorgangsstatus ein Erfolg oder ein Fehler ist.

• Rückverfolgbarkeitsanmerkungen: Anmerkungen werden den bereitgestellten Kubernetes-Objekten hinzugefügt, um Informationen zur Rückverfolgbarkeit zu überlagern. Die folgenden Anmerkungen werden unterstützt:

  • azure-pipelines/org
  • azure-pipelines/projekt
  • Azure-Pipelines/Pipeline
  • azure-pipelines/pipelineId
  • Azure-Pipelines/Ausführung
  • azure-pipelines/executionuri
  • azure-pipelines/jobName

• Geheime Behandlung: Mit der aktion createSecret können Docker-Registrierungsschlüssel mithilfe von Docker-Registrierungsdienstverbindungen erstellt werden. Außerdem können generische geheime Schlüssel mithilfe von Nur-Text-Variablen oder geheimen Variablen erstellt werden. Vor der Bereitstellung im Cluster können Sie die secrets Eingabe zusammen mit der aktion deploy verwenden, um die Eingabemanifestdateien mit dem entsprechenden imagePullSecrets Wert zu erweitern.

• Bake-Manifest: Die bake Aktion der Aufgabe ermöglicht das Backen von Vorlagen in Kubernetes-Manifestdateien. Die Aktion verwendet Tools wie Helm, Verfassen und Kustomize. Beim Backen können diese Kubernetes-Manifestdateien für Bereitstellungen im Cluster verwendet werden.

• Bereitstellungsstrategie: Die Auswahl der canary Strategie mit der deploy Aktion führt zur Erstellung von Arbeitslastnamen, die mit -baseline und -canarysuffixiert sind. Die Aufgabe unterstützt zwei Methoden für die Aufteilung des Datenverkehrs:

  • Service Mesh Interface: Service Mesh Interface (SMI) Abstraktion ermöglicht die Konfiguration mit Dienstanbietern wie Linkerd und Istio. Die Kubernetes-Manifestaufgabe ordnet SMI-TrafficSplit Objekte während des Lebenszyklus der Bereitstellungsstrategie den stabilen, Basisplan- und Canarydiensten zu.

    Canary-Bereitstellungen, die auf einem Dienstgitter basieren und diese Aufgabe verwenden, sind genauer. Diese Genauigkeit ist darauf zurückzuführen, wie Service-Gitteranbieter die granulare prozentbasierte Aufteilung des Datenverkehrs ermöglichen. Das Dienstgitter verwendet die Dienstregistrierungs- und Sidecar-Container, die in Pods eingefügt werden. Diese Einfügung erfolgt zusammen mit Anwendungscontainern, um die differenzierte Datenverkehrsteilung zu erzielen.

  • Kubernetes ohne Dienstgitter: Wenn kein Dienstgitter vorhanden ist, erhalten Sie möglicherweise nicht die genaue prozentuale Aufteilung auf Anforderungsebene. Sie können canary-Bereitstellungen jedoch mithilfe von Basisplan- und Canaryvarianten neben der stabilen Variante durchführen.

    Der Dienst sendet Anforderungen an Pods aller drei Workloadvarianten, da die Einschränkungen für die Auswahlbezeichnung erfüllt sind. Kubernetes Manifest berücksichtigt diese Anforderungen beim Erstellen von Basis- und Canaryvarianten. Dieses Routingverhalten erreicht den beabsichtigten Effekt des Routings nur für einen Teil der Gesamtanforderungen an das Canary.

  Vergleichen Sie die basisplan- und canary-Arbeitslasten, indem Sie entweder einen manuellen Interventionsvorgang in Releasepipelinen oder einen Verzögerungsvorgang in YAML-Pipelines verwenden. Führen Sie den Vergleich aus, bevor Sie die Aktion zum Heraufstufen oder Ablehnen der Aufgabe verwenden.

Bereitstellen einer Aktion

Der folgende YAML-Code ist ein Beispiel für die Bereitstellung in einem Kubernetes-Namespace mithilfe von Manifestdateien:

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

Im obigen Beispiel versucht die Aufgabe, Übereinstimmungen für die Bilder foo/demo und bar/demo in den Bildfeldern von Manifestdateien zu finden. Für jede gefundene Übereinstimmung wird der Wert von tagVariable1 oder tagVariable2 als Tag an den Bildnamen angefügt. Sie können auch Digests in der Containereingabe für die Artefaktersetzung angeben.

Hinweis

Sie können zwar deploy, promoteund reject Aktionen mit YAML-Eingaben im Zusammenhang mit der Bereitstellungsstrategie erstellen, die Unterstützung für eine Manuelle Intervention-Aufgabe ist derzeit jedoch für Buildpipelines nicht verfügbar.

Für Releasepipelines empfehlen wir Ihnen, Aktionen und Eingaben im Zusammenhang mit der Bereitstellungsstrategie in der folgenden Reihenfolge zu verwenden:

1. Eine mit strategy: canary und percentage: $(someValue)angegebene Bereitstellungsaktion.
2. Ein Manueller Eingriffsvorgang, damit Sie die Pipeline anhalten und die Basisplanvariante mit der Canaryvariante vergleichen können.
3. Eine Höherstufenaktion, die ausgeführt wird, wenn ein manueller Eingriffsvorgang fortgesetzt wird, und eine Ablehnungsaktion, die ausgeführt wird, wenn eine manuelle Intervention-Aufgabe abgelehnt wird.

Geheime Aktion erstellen

Der folgende YAML-Code zeigt eine Beispielerstellung von Docker-Registrierungsschlüsseln mithilfe Docker Registry Service-Verbindung:

steps:
- task: KubernetesManifest@0
  displayName: Create secret
  inputs: 
    action: createSecret
    secretType: dockerRegistry
    secretName: foobar
    dockerRegistryEndpoint: demoACR
    kubernetesServiceConnection: someK8sSC
    namespace: default

Dieser YAML-Code zeigt eine Beispielerstellung allgemeiner geheimer Schlüssel:

steps:
- task: KubernetesManifest@0
  displayName: Create secret
  inputs: 
    action: createSecret
    secretType: generic
    secretName: some-secret
    secretArguments: --from-literal=key1=value1
    kubernetesServiceConnection: someK8sSC
    namespace: default

Backen-Aktion

Der folgende YAML-Code ist ein Beispiel für das Backen von Manifestdateien aus Helm-Diagrammen. Beachten Sie die Verwendung einer Namenseingabe in der ersten Aufgabe. Auf diesen Namen wird später aus dem Bereitstellungsschritt verwiesen, um den Pfad zu den Manifesten anzugeben, die vom Backschritt erstellt wurden.

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

Hinweis

Informationen zur direkten Verwendung von Helm zum Verwalten von Versionen und Rollbacks finden Sie unter Packen und Bereitstellen von Helm-Diagrammen.

Kustomize-Beispiel

Der folgende YAML-Code ist ein Beispiel für baking manifest files generated with Kustomize that contain a kustomization.yaml file.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from kustomization path
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Kompose-Beispiel

Der folgende YAML-Code ist ein Beispiel für Backmanifestdateien, die mit Kompose generiert werden, einem Konvertierungstool für Docker Compose.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Docker Compose
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Skalierungsaktion

Der folgende YAML-Code zeigt ein Beispiel für Skalierungsobjekte:

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

Patchaktion

Der folgende YAML-Code zeigt ein Beispiel für Objektpatching:

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

Löschen-Aktion

Dieser YAML-Code zeigt ein Beispielobjektlöschen:

steps:
- task: KubernetesManifest@0
  displayName: Delete
  inputs:
    action: delete
    arguments: deployment expressapp
    kubernetesServiceConnection: someK8sSC
    namespace: default

Problembehandlung

Mein Kubernetes-Cluster liegt hinter einer Firewall und ich verwende gehostete Agents. Wie kann ich in diesem Cluster bereitstellen?

Sie können gehosteten Agents Zugriff über Ihre Firewall gewähren, indem Sie die IP-Adressen für die gehosteten Agents zulassen. Ausführlichere Informationen finden Sie im Artikel mit den IP-Adressbereichen für Agents.

Wie funktionieren Anforderungen an stabile und variantenreiche Dienstrouten bei Canary-Bereitstellungen?

Die Bezeichnungsauswahlbeziehung zwischen Pods und Diensten in Kubernetes ermöglicht es, Bereitstellungen so festzulegen, dass ein einzelner Dienst Anforderungen sowohl an die stabilen als auch an die Canary-Varianten weiterleitet. Die Kubernetes-Manifestaufgabe verwendet dies für Canarybereitstellungen.

Wenn die Aufgabe die Eingaben von action: deploy und strategy: canaryenthält, werden für jede Workload (Bereitstellung, ReplicaSet, Pod, ...) definiert in den Eingabemanifestdateien eine -baseline und -canary Variante der Bereitstellung erstellt. In diesem Beispiel gibt es eine Bereitstellung sampleapp in der Eingabemanifestdatei und dass nach Abschluss der Ausführung 22 der Pipeline die stabile Variante dieser Bereitstellung namens sampleapp im Cluster bereitgestellt wird. In der nachfolgenden Ausführung (in diesem Fall "Run Number 23") führt Kubernetes-Manifestaufgabe mit action: deploy und strategy: canary zum Erstellen von SampleApp-Baseline- und Sampleapp-Canary-Bereitstellungen, deren Anzahl der Replikate durch das Produkt der percentage Aufgabeneingabe mit dem Wert der gewünschten Anzahl von Replikaten für die endgültige stabile Variante von sampleapp gemäß den Eingabemanifestdateien bestimmt wird.

Mit Ausnahme der Anzahl der Replikate weist die Basisplanversion die gleiche Konfiguration wie die stabile Variante auf, während die Canaryversion die neuen Änderungen aufweist, die von der aktuellen Ausführung eingeführt werden (in diesem Fall run number 23). Wenn ein manueller Eingriff in die Pipeline nach dem oben genannten Schritt eingerichtet wird, würde es die Möglichkeit bieten, die Pipeline anzuhalten, damit der Pipelineadministrator wichtige Metriken für die Basis- und Canaryversionen auswerten und die Entscheidung treffen kann, ob die Canaryänderungen sicher und gut genug für ein vollständiges Rollout sind.

Dieaction: promote und strategy: canary oder action: reject und strategy: canary Eingaben der Kubernetes-Manifestaufgaben können verwendet werden, um die Canaryänderungen zu fördern bzw. abzulehnen. Beachten Sie, dass am Ende dieses Schritts nur die stabile Variante der in den Eingabemanifestdateien deklarierten Workloads im Cluster bereitgestellt wird, während die ephemeren Basispläne und Canaryversionen bereinigt werden.

Anforderungen

Anforderung	BESCHREIBUNG
Pipelinetypen	YAML, Classic Build, Classic Release
Läuft auf	Agent, DeploymentGroup
Anforderungen	Nichts
Funktionen	Dieser Vorgang erfüllt keine Anforderungen für nachfolgende Vorgänge im Auftrag.
Befehlseinschränkungen	Beliebig
Settable-Variablen	Beliebig
Agentversion	Alle unterstützten Agentversionen.
Vorgangskategorie	Einsetzen