KubernetesManifest@0: Aufgabe "Bereitstellen in Kubernetes v0"

Verwenden Sie einen Kubernetes-Manifesttask in einer Build- oder Releasepipeline, um Manifeste mithilfe von Helm-Diagrammen in Kubernetes-Clustern zu backen und bereitzustellen.

Syntax

# Deploy to Kubernetes v0
# Use Kubernetes manifest files to deploy to clusters or even bake the manifest files to be used for deployments using Helm charts.
- task: KubernetesManifest@0
  inputs:
    #action: 'deploy' # 'bake' | 'createSecret' | 'delete' | 'deploy' | 'patch' | 'promote' | 'scale' | 'reject'. Action. Default: deploy.
    #kubernetesServiceConnection: # string. Required when action != bake. Kubernetes service connection. 
    #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.

kubernetesServiceConnection - Kubernetes-Dienstverbindung
string. Erforderlich, wenn action != bake.

Gibt eine Kubernetes-Dienstverbindung an.

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 Dienstgitter muss von einem Clusteradministrator eingerichtet werden. Diese Aufgabe verarbeitet 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 Baseline und Canary zu berechnen. Die Berechnung ist ein Prozentsatz der Replikate, die in den Eingabemanifesten für die stabile Variante angegeben werden.

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

Der Prozentsatz, der verwendet wird, um die Anzahl der Replikate von Baselinevarianten und Canary-Varianten der Workloads zu berechnen, die in Manifestdateien enthalten sind.

Berechnen Sie für die angegebene Prozentuale Eingabe Folgendes:

(Prozentsatz × Anzahl von Replikaten) / 100

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

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 Baselinevariante wird mit demselben Image und Tag wie die stabile Version erstellt, d. h. die Variante mit vier Replikaten vor der Bereitstellung. Die canary-Variante 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 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 stabile Variante an. Gehen Sie außerdem davon aus, dass Sie die folgende Eingabe für die Aufgabe angeben:

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

In diesem Fall empfängt die stabile Variante 80 % des Datenverkehrs, während die Baseline- und Canary-Variante jeweils die Hälfte der angegebenen 20 % erhalten. Baseline- und Canary-Varianten erhalten keine 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. 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-Diagrammen erstellt 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.

Gibt eine der folgenden Patchmethoden an:

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

Zulässige Werte sind Datei 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 es ein privates Image im Namen Ihres Pods pullen 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 .

Aufgabensteuerungsoptionen

Alle Aufgaben verfügen zusätzlich zu ihren Aufgabeneingaben ü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
Gibt den Speicherort der Manifestbündel an, die von der Bake-Aktion erstellt wurden.

Hinweise

Hinweis

Es ist eine neuere Version dieser Aufgabe verfügbar, die zusätzliche Unterstützung für das Ziel eines Kubernetes-Clusters auf unterschiedliche Weise mit der connectionType -Eigenschaft bietet. Weitere Informationen finden Sie in KubernetesManifest@1- und KubernetesManifest@1-Dienstverbindungsbemerkungen.

Verwenden Sie einen Kubernetes-Manifesttask in einer Build- oder Releasepipeline, um Manifeste zu baken und in Kubernetes-Clustern bereitzustellen.

Diese Aufgabe unterstützt Folgendes:

• Artefaktersetzung: Die Bereitstellungsaktion verwendet als Eingabe eine Liste von Containerimages, die Sie zusammen mit ihren Tags und Digests angeben können. Die gleiche Eingabe wird vor der Anwendung im Cluster in die nicht durchtemplatisierten Manifestdateien ersetzt. Durch diese Ersetzung wird sichergestellt, dass die Clusterknoten die richtige Version des Images pullen.

• Manifeststabilität: Die Rollout-status der bereitgestellten Kubernetes-Objekte wird überprüft. Die Stabilitätsüberprüfungen werden integriert, um zu bestimmen, ob die aufgabe status ein Erfolg oder ein Fehler ist.

• Anmerkungen zur Rückverfolgbarkeit: Anmerkungen werden den bereitgestellten Kubernetes-Objekten hinzugefügt, um Informationen zur Nachverfolgbarkeit 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 Nur-Text-Variablen oder Geheimnisvariablen 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 Baken 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. Der Task 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 Dienstnetz 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 Dienstnetz verwendet die Dienstregistrierung und Sidecar-Container, die in Pods eingefügt werden. Diese Einschleusung erfolgt zusammen mit Anwendungscontainern, um die differenzierte Datenverkehrsaufteilung zu erreichen.

  • Kubernetes ohne Dienstgitter: Wenn kein Dienstgitter 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, wenn die Selektorbezeichnungseinschränkungen erfüllt sind. Kubernetes Manifest berücksichtigt diese Anforderungen beim Erstellen von Baseline- und Canary-Varianten. Dieses Routingverhalten erzielt den beabsichtigten Effekt, dass nur ein Teil der Gesamtanforderungen an den Canary weitergeleitet wird.

  Vergleichen Sie die Baseline- und Canary-Workloads, indem Sie entweder einen Manuellen Eingriffstask in Releasepipelines oder einen Verzögerungstask in YAML-Pipelines verwenden. Führen Sie den Vergleich aus, bevor Sie die Aktion "Höherstufen" 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 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 empfehlen wir Ihnen, Aktionen und Eingaben im Zusammenhang mit der Bereitstellungsstrategie in der folgenden Reihenfolge zu verwenden:

1. Eine bereitstellungsaktion, die mit strategy: canary und percentage: $(someValue)angegeben ist.
2. Ein Manueller Eingriffstask, damit Sie die Pipeline anhalten und die Baselinevariante mit der Canary-Variante vergleichen können.
3. Eine Höherstaufst-Aktion, die ausgeführt wird, wenn ein Manueller Eingriffstask fortgesetzt wird, und eine Ablehnungsaktion, die ausgeführt wird, wenn ein Manueller Eingriffstask abgelehnt wird.

Erstellen einer Geheimaktion

Der folgende YAML-Code zeigt ein Beispiel für die Erstellung von Docker-Registrierungsgeheimnissen mithilfe der Docker-Registrierungsdienstverbindung:

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

Bake-Aktion

Der folgende YAML-Code ist ein Beispiel für das Baken 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 Bake-Schritt 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 Releases und Rollbacks finden Sie unter der Aufgabe Paketieren und Bereitstellen von Helm-Diagrammen.

Kustomize-Beispiel

Der folgende YAML-Code ist ein Beispiel für das Baking 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 Baken 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 Objektpatches:

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 eines Objekts:

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 die Aufgabe die Eingaben von action: deploy und strategy: canaryenthält, werden für jede In den Eingabemanifestdateien definierte Workload (Bereitstellung, ReplicaSet, Pod, ...) eine - und -canary --baselineVariante 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 anschließenden Ausführung (in diesem Fall Ausführungsnummer 23) führt der Kubernetes-Manifesttask mit action: deploy und strategy: canary zur Erstellung von bereitstellungen sampleapp-baseline und sampleapp-canary, deren Anzahl der Replikate durch das Produkt der percentage Taskeingabe 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 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 eingeführt werden (in diesem Fall Ausführungsnummer 23). Wenn nach dem oben genannten Schritt ein manueller Eingriff in der Pipeline eingerichtet wird, bietet dies die Möglichkeit, die Pipeline anzuhalten, damit der Pipelineadministrator wichtige Metriken für die Baseline- und Canaryversionen auswerten und entscheiden kann, ob die Canary-Änderungen sicher und ausreichend für einen vollständigen Rollout sind.

Dieaction: promote Eingaben und oder strategy: canaryaction: reject und strategy: canary der Kubernetes-Manifesttasks können verwendet werden, um die Canary-Änderungen bzw. 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 kurzlebigen Baseline- und Canary-Versionen bereinigt werden.

Anforderungen

Anforderung	BESCHREIBUNG
Pipelinetypen	YAML, Klassischer Build, klassisches Release
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