KubernetesManifest@0 – Bereitstellen in Kubernetes v0-Aufgabe

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

Diese Version der Aufgabe ist veraltet; verwenden Sie KubernetesManifest@1, um die neuesten Features wie Workload Identity Federationzu nutzen.

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.

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.

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

Gibt eine Kubernetes-Dienstverbindungan.

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 - Helm Release Name
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 - Kustomization Path
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.

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
Gibt den Speicherort der Manifestbundle an, die von bake-Aktion erstellt wurden.

Bemerkungen

Hinweis

Es gibt eine neuere Version dieser Aufgabe, die zusätzliche Unterstützung für das Ausrichten eines Kubernetes-Clusters auf unterschiedliche Weise bietet, indem die connectionType-Eigenschaft verwendet wird. Weitere Informationen finden Sie unter KubernetesManifest@1 und KubernetesManifest@1 Hinweise zur Dienstverbindung

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/project
  • 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	Jegliche
Settable-Variablen	Jegliche
Agentversion	Alle unterstützten Agentversionen.
Vorgangskategorie	Einsetzen