KubernetesManifest@1– Aufgabe "Bereitstellen in Kubernetes v1"

Verwenden Sie Kubernetes-Manifestdateien zum Bereitstellen in Clustern oder sogar zum Backen der Manifestdateien, die für Bereitstellungen mithilfe von 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.

Eingaben

action - Aktion
string. Zulässige Werte: bake, createSecret (Geheimnis 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 Kubernetes-Dienstverbindungstyp aus.

• kubernetesServiceConnection(Kubernetes-Dienstverbindung): Ermöglicht das Bereitstellen einer KubeConfig-Datei, das Angeben eines Dienstkontos oder das Importieren eines AKS-instance mit der Azure-Abonnementoption. Das Importieren eines AKS-instance mit der Azure-Abonnementoption erfordert den Kubernetes-Clusterzugriff zur Konfigurationszeit der Dienstverbindung.
• azureResourceManager(Azure Resource Manager): Hiermit können Sie eine AKS-instance auswählen. Greift zum Zeitpunkt der Dienstverbindungskonfiguration nicht auf den Kubernetes-Cluster zu.

Weitere Informationen finden Sie unter Hinweise.

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

Gibt eine Kubernetes-Dienstverbindung an.

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 eine Azure-Dienstverbindung über die Schaltfläche „Hinzufügen“ oder „Verwalten“ 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 verwalteten Azure-Cluster aus.

useClusterAdmin - Verwenden von Clusteradministratoranmeldeinformationen
boolean. Optional. Verwenden Sie , wenn connectionType = azureResourceManager. Standardwert. false.

Verwenden Sie die Anmeldeinformationen des Clusteradministrators anstelle der Standardanmeldeinformationen von Clusterbenutzern.

namespace - Namespace
string.

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

strategy - Strategie
string. Optional. Verwenden Sie , 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. canary Derzeit ist die einzige zulässige Bereitstellungsstrategie.

trafficSplitMethod - Methode für die Aufteilung des Datenverkehrs
string. Optional. Verwenden Sie , wenn strategy = canary. Zulässige Werte: pod, smi. Standardwert. pod.

Für den Wert smierfolgt die prozentuale Datenverkehrsaufteilung auf Anforderungsebene mithilfe eines Dienstgitters. Ein Service Mesh muss von Clusteradministrator*innen eingerichtet werden. Diese Aufgabe verarbeitet die Orchestrierung von TrafficSplit-Objekten der SMI.

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 Baseline und Canary zu berechnen. Das Ergebnis der Berechnung ist ein Prozentsatz der Replikate, die in den Eingabemanifesten für die Stable-Variante angegeben sind.

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

Der verwendete Prozentsatz zum Berechnen der Anzahl der Replikate von Baseline- und Canary-Varianten der in Manifestdateien enthaltenen Workloads.

Für die angegebene prozentuale Eingabe wird berechnet:

(Prozentsatz × Anzahl von Replikaten) / 100

Wenn das Ergebnis kein Integer ist, wird beim Erstellen der Baseline- und Canary-Varianten das abgerundete Ergebnis verwendet.

Angenommen, die Bereitstellung hello-world befindet sich in der Eingabemanifestdatei und die folgenden Zeilen befinden sich in der Aufgabeneingabe:

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 Baseline-Variante wird mit demselben Image und demselben Tag wie die Stable-Version erstellt, die Variante mit vier Replikaten vor der Bereitstellung. Die Canary-Variante wird mit dem Image und dem 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 auf smifestlegentrafficSplitMethod, wird die prozentuale Datenverkehrsteilung in der Dienstnetzebene gesteuert. Sie können die tatsächliche Anzahl von Replikaten für Canary- und Baseline-Varianten unabhängig von der Datenverkehrsteilung steuern.

Angenommen, das Eingabebereitstellungsmanifest gibt 30 Replikate für die Stable-Variante an. Außerdem sei angenommen, dass für die Aufgabe die folgende Eingabe vorliegt:

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

In diesem Fall empfängt die Stable-Variante 80 % des Datenverkehrs, während die Baseline- und die Canary-Variante jeweils die Hälfte der angegebenen 20 % erhalten. Baseline- und Canary-Varianten erhalten keine jeweils drei Replikate. Stattdessen erhalten sie die angegebene Anzahl von Replikaten, d. h. jeweils ein Replikat.

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. Optional. Verwenden Sie , 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. Optional. Verwenden Sie , wenn action = deploy || action = promote.

Gibt eine mehrzeilige Eingabe an, bei der jede Zeile den Namen eines Docker-Registrierungsgeheimnisses enthält, das bereits im Cluster eingerichtet wurde. Jeder Geheimname wird unter imagePullSecrets für die Workloads hinzugefügt, die sich in den Eingabemanifestdateien befinden.

renderType - Rendermodul
string. Optional. Verwenden Sie , wenn action = bake. Zulässige Werte: helm, kompose und kustomize. Standardwert. helm.

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

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

Gibt einen docker-compose-Dateipfad an.

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

Gibt den Zubackpfad des Helm-Diagramms an.

releaseName - Helm-Releasename
string. Optional. Verwenden Sie , wenn action = bake && renderType = helm.

Gibt den zu verwendenden Helm-Releasenamen an.

overrideFiles - Überschreiben von Dateien
string. Optional. Verwenden Sie , 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-Charts gebacken werden.

overrides - Überschreibt
string. Optional. Verwenden Sie , wenn action = bake && renderType = helm.

Gibt die festzulegenden Außerkraftsetzungswerte an.

kustomizationPath - Kustomisierungspfad
string. Optional. Verwenden Sie , wenn action = bake && renderType = kustomize.

Gibt das Argument an, das der Pfad zu dem Verzeichnis sein muss, das die Datei enthält, oder eine Git-Repository-URL mit einem Pfadsuffix, das in Bezug auf den Repositorystamm angegeben same ist.

resourceToPatch - Zu patchende Ressource
string. Erforderlich, wenn action = patch. Zulässige Werte: file, name. Standardwert. file.

Weist auf eine der folgenden Patchmethoden hin:

• Eine Manifestdatei identifiziert die zu patchenden Objekte.
• Ein einzelnes Objekt wird nach Art und Name als Patchziel identifiziert.

Zulässige Werte sind file und name.

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

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

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

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

name - Namen
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 - Mergestrategie
string. Erforderlich, wenn action = patch. Zulässige Werte: json, merge und strategic. Standardwert. strategic.

Gibt den Typ des bereitgestellten Patches an.

arguments - Argumente
string. Optional. Verwenden Sie , wenn action = delete.

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

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

Gibt den Inhalt des Patches an.

secretType - Typ des Geheimnisses
string. Erforderlich, wenn action = createSecret. Zulässige Werte: dockerRegistry, generic. Standardwert. dockerRegistry.

Erstellt oder aktualisiert ein generisches oder docker imagepullsecret. Geben Sie an dockerRegistry , um die imagepullsecret der ausgewählten Registrierung zu erstellen oder zu aktualisieren. Ein imagePullSecret ist eine Möglichkeit, ein Geheimnis, das ein Containerregistrierungskennwort enthält, an das Kubelet zu übergeben, damit ein privates Image im Namen Ihres Pods abgerufen werden kann.

secretName - Geheimnisname
string. Optional. Verwenden Sie , wenn action = createSecret.

Gibt den Namen des Geheimnisses an. Sie können diesen Geheimnisnamen in der Kubernetes-YAML-Konfigurationsdatei verwenden.

secretArguments - Argumente
string. Optional. Verwenden Sie , wenn action = createSecret && secretType = generic.

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

dockerRegistryEndpoint - Docker-Registrierungsdienstverbindung
string. Optional. Verwenden Sie , wenn action = createSecret && secretType = dockerRegistry.

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

rolloutStatusTimeout - Timeout für Rollout-status
string. Optional. Verwenden Sie , wenn action = deploy || action = patch || action = scale || action = promote. Standardwert. 0.

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

Optionen für die Vorgangskontrolle

Alle Vorgänge verfügen zusätzlich zu ihren Eingaben über Steuerungsoptionen. Weitere Informationen finden Sie unter Steuerungsoptionen und allgemeine Aufgabeneigenschaften.

Ausgabevariablen

Diese Aufgabe definiert die folgenden Ausgabevariablen, die Sie in Downstreamschritten, Aufträgen und Phasen verwenden können.

manifestsBundle
Der Speicherort der manifesten Bündel, die von der Bake-Aktion erstellt wurden.

Hinweise

Überlegungen zur Kubernetes Service-Verbindung 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 für Azure DevOps zum Zeitpunkt der Dienstverbindungskonfiguration auf Kubernetes zugegriffen werden können. Es kann verschiedene Gründe geben, warum eine Dienstverbindung nicht erstellt werden kann, z. B. haben Sie einen privaten Cluster erstellt oder lokale Konten für den Cluster deaktiviert. In diesen Fällen kann Azure DevOps zum Zeitpunkt der Dienstverbindungskonfiguration keine Verbindung mit Ihrem Cluster herstellen, und Es wird ein Bildschirm zum Laden von Namespaces angezeigt.

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

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

Für AKS-Kunden bietet der Verbindungstyp Azure Resource Manager-Dienst die beste Methode, um eine Verbindung mit einem privaten Cluster oder einem Cluster herzustellen, für den lokale Konten deaktiviert sind. Diese Methode ist nicht von der Clusterkonnektivität abhängig, wenn Sie eine Dienstverbindung erstellen. Der Zugriff auf AKS wird auf die Pipelineruntime zurückgestellt, was die folgenden Vorteile hat:

• Der Zugriff auf einen (privaten) AKS-Cluster kann von einem selbstgehosteten Agent oder einem Skalierungsgruppen-Agent mit Sichtverbindung zum 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. Dies ist die Kubernetes-Empfehlung.
• Auf AKS kann auch dann zugegriffen werden, wenn lokale Konten deaktiviert sind.

Häufig gestellte Fragen zu Dienstverbindungen

Ich erhalte die folgende Fehlermeldung: Es wurde kein Geheimnis gefunden, das mit dem Dienstkonto verknüpft ist. Was passiert?

Sie verwenden die Option Kubernetes-Dienstverbindung mit Azure-Abonnement. 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-Anleitung zu 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 die Kubernetes-Anleitungen steht.

Ich verwende die Kubernetes-Tasks und die Kubernetes-Dienstverbindung, aber nicht AKS. Muss ich mir Sorgen machen?

Ihre Aufgaben funktionieren weiterhin wie zuvor.

Wird der Kubernetes-Dienstverbindungstyp entfernt?

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

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

Es gibt keine Notwendigkeit, etwas zu ändern. Wenn Sie während der Erstellung die Kubernetes-Dienstverbindung und das ausgewählte Azure-Abonnement verwenden, sollten Sie den Kubernetes-Leitfaden zur Verwendung langlebiger Token beachten.

Ich erschaffe eine Kubernetes-Umgebung und habe keine Option, Dienstverbindungen zu verwenden.

Falls Sie während der Erstellung 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, steht in keinem Zusammenhang mit der Tokenerstellung. 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 zu backen und in Kubernetes-Clustern bereitzustellen.

Diese Aufgabe unterstützt Folgendes:

• Artefaktersetzung: Die Bereitstellungsaktion nimmt als Eingabe eine Liste von Containerimages entgegen, die Sie zusammen mit ihren Tags und Digests angeben können. Dieselbe Eingabe wird vor der Anwendung am Cluster in die nicht mit Vorlagen versehenen Manifestdateien ersetzt. Durch diese Ersetzung wird sichergestellt, dass die Clusterknoten die richtige Version des Images abrufen.

• Manifeststabilität: Der Rolloutstatus der bereitgestellten Kubernetes-Objekte wird überprüft. Die Stabilitätsüberprüfungen werden integriert, um zu ermitteln, ob der Aufgabenstatus „erfolgreich“ oder „fehlerhaft“ lautet.

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

  • azure-pipelines/org
  • azure-pipelines/project
  • azure-pipelines/pipeline
  • azure-pipelines/pipelineId
  • azure-pipelines/execution
  • azure-pipelines/executionuri
  • azure-pipelines/jobName

• Geheimnisbehandlung: Mit der createSecret Aktion können Docker-Registrierungsgeheimnisse mithilfe von Docker-Registrierungsdienstverbindungen erstellt werden. Außerdem können generische Geheimnisse mithilfe von Textvariablen oder geheimen Variablen erstellt werden. Vor der Bereitstellung im Cluster können Sie die Eingabe zusammen mit der secretsdeploy Aktion verwenden, um die Eingabemanifestdateien um den entsprechenden imagePullSecrets Wert zu erweitern.

• Bake-Manifest: Die bake Aktion der Aufgabe ermöglicht das Baken von Vorlagen in Kubernetes-Manifestdateien. Die Aktion verwendet Tools wie Helm, Compose 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 Workloadnamen mit -baseline dem Suffix und -canary. Die Aufgabe unterstützt zwei Methoden der Datenverkehrsaufteilung:

  • Service Mesh-Schnittstelle: Die SMI-Abstraktion (Service Mesh Interface ) ermöglicht die Konfiguration mit Service Mesh-Anbietern wie Linkerd und Istio. Der Kubernetes-Manifesttask ordnet SMI-Objekte TrafficSplit den stabilen Diensten, Baselinediensten und Canary-Diensten während des Lebenszyklus der Bereitstellungsstrategie zu.

    Canary-Bereitstellungen, die auf einem Service Mesh basieren und diese Aufgabe verwenden, sind genauer. Diese Genauigkeit ist darauf zurückzuführen, wie Service Mesh-Anbieter die differenzierte prozentuale Aufteilung des Datenverkehrs ermöglichen. Das Service Mesh verwendet die Dienstregistrierung und in Pods eingefügte Sidecar-Container. Diese Einfügung erfolgt zusammen mit Anwendungscontainern und erreicht dadurch die abgestufte Aufteilung des Datenverkehrs.

  • Kubernetes ohne Service Mesh: Wenn kein Service Mesh vorhanden ist, erhalten Sie möglicherweise nicht die genaue prozentuale Aufteilung, die Sie auf Anforderungsebene benötigen. Sie können canary-Bereitstellungen jedoch mithilfe von Baseline- und Canary-Varianten neben der stabilen Variante durchführen.

    Der Dienst sendet Anforderungen an Pods aller drei Workloadvarianten entsprechend den Einschränkungen für die Auswahlbezeichnung. Im Kubernetes-Manifest werden diese Anforderungen beim Erstellen von Baseline- und Canary-Varianten berücksichtigt. Dieses Routingverhalten erzielt den beabsichtigten Effekt, nur einen Teil der Gesamtanforderungen an den Canary weiterzuleiten.

  Vergleichen Sie die Baseline- und Canary-Workloads, indem Sie einenmanuelle Eingriffsaufgabe in Releasepipelines oder eine Verzögerungsaufgabe in YAML-Pipelines verwenden. Führen Sie den Vergleich aus, bevor Sie eine Aktion zum Heraufstufen oder Ablehnen der Aufgabe verwenden.

Bereitstellungsaktion

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 Images foo/demo und bar/demo in den Imagefeldern der Manifestdateien zu finden. Für jede Übereinstimmung wird einer der Werte tagVariable1 oder tagVariable2 als Tag an den Imagenamen angefügt. Sie können auch Digests in der Containereingabe für die Artefaktersetzung angeben.

Hinweis

Sie können zwar Aktionen, promote, und reject mit YAML-Eingaben im Zusammenhang mit der Bereitstellungsstrategie erstellendeploy, aber für Buildpipelines steht derzeit keine Unterstützung für einen Manuellen Eingriffstask zur Verfügung.

Für Releasepipelines wird empfohlen, 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. Eine Aufgabe mit manuellem Eingriff, damit Sie die Pipeline anhalten und die Baseline-Variante mit der Canary-Variante vergleichen können.
3. Eine Heraufstufungsaktion, die bei der Wiederaufnahme einer Aufgabe mit manuellem Eingriff ausgeführt wird, und eine Ablehnungsaktion, die beim Ablehnen einer Aufgabe mit manuellem Eingriff ausgeführt wird.

Erstellen einer Geheimnisaktion

Der folgende YAML-Code zeigt eine Beispielerstellung von Geheimnissen für die Docker-Registrierung mithilfe einer Dienstverbindung für die Docker-Registrierung:

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

Dieser YAML-Code zeigt ein Beispiel für die Erstellung generischer Geheimnisse:

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

Backaktion

Der folgende YAML-Code ist ein Beispiel für das Backen von Manifestdateien aus Helm-Charts. 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 im Bake-Schritt erzeugten Manifesten anzugeben.

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 Releases und Rollbacks finden Sie unter Der Aufgabe Helm-Diagramme packen und bereitstellen.

Kustomize-Beispiel

Der folgende YAML-Code ist ein Beispiel für das Backen von Manifestdateien, die mit Kustomize generiert wurden und eine kustomization.yaml Datei enthalten.

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 das Backen von Manifestdateien, die mit Kompose, einem Konvertierungstool für Docker Compose, generiert wurden.

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 die Skalierung von Objekten:

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 das Patchen von Objekten:

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

Aktion löschen

Dieser YAML-Code zeigt ein Beispiel für das Löschen von Objekten:

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

Problembehandlung

Mein Kubernetes-Cluster befindet sich hinter einer Firewall, und ich verwende gehostete Agents. Wie kann ich die Bereitstellung für diesen Cluster durchführen?

Sie können für gehostete Agents den 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. Der Task „Kubernetes-Manifest“ verwendet dies für Canary-Bereitstellungen.

Wenn der Task die Eingaben von action: deploy und strategy: canaryenthält, werden für jede Workload (Bereitstellung, Replikatset, Pod, ...) in den Eingabemanifestdateien definiert, eine und -canary eine -baseline Variante der Bereitstellung erstellt. In diesem Beispiel gibt es eine Bereitstellung sampleapp in der Eingabemanifestdatei, und nach Abschluss der Ausführungsnummer 22 der Pipeline wird die stabile Variante dieser Bereitstellung namens sampleapp im Cluster bereitgestellt. In der nachfolgenden Ausführung (in diesem Fall Ausführungsnummer 23) führt der Kubernetes-Manifesttask mit action: deploy und strategy: canary zur Erstellung von sampleapp-baseline- und sampleapp-canary-Bereitstellungen, deren Anzahl von Replikaten durch das Produkt der percentage Vorgangseingabe mit dem Wert der gewünschten Anzahl von Replikaten für die endgültige stabile Variante von sampleapp gemäß den Eingabemanifestdateien bestimmt wird.

Abgesehen von der Anzahl der Replikate verfügt die Baselineversion über dieselbe Konfiguration wie die stabile Variante, während die canary-Version die neuen Änderungen aufweist, die durch die aktuelle Ausführung (in diesem Fall Ausführungsnummer 23) eingeführt werden. Wenn nach dem oben genannten Schritt ein manueller Eingriff in die Pipeline vorgenommen wird, kann die Pipeline angehalten werden, damit der*die Pipelineadministrator*in wichtige Metriken für die Baseline- und Canary-Versionen auswerten und die Entscheidung treffen kann, ob die Canary-Änderungen sicher und gut genug für ein vollständiges Rollout sind.

Dieaction: promote Eingaben und oder strategy: canaryaction: reject und strategy: canary der Kubernetes-Manifestaufgaben können verwendet werden, um die Canary-Änderungen zu fördern oder abzulehnen. Beachten Sie, dass in beiden Fällen am Ende dieses Schritts nur die stabile Variante der in den Eingabemanifestdateien deklarierten Workloads im Cluster bereitgestellt wird, während die temporären Baseline- und Canary-Versionen bereinigt werden.

Anforderungen

Anforderung	BESCHREIBUNG
Pipelinetypen	YAML, Klassischer Build, klassische Version
Wird ausgeführt auf	Agent, DeploymentGroup
Forderungen	Keine
Capabilities	Diese Aufgabe erfüllt keine Anforderungen an nachfolgende Aufgaben im Auftrag.
Befehlseinschränkungen	Any
Einstellbare Variablen	Any
Agent-Version	Alle unterstützten Agent-Versionen.
Aufgabenkategorie	Bereitstellen