KubernetesManifest@0 — wdrażanie w zadaniu kubernetes v0

Zadanie manifestu kubernetes w potoku kompilacji lub wydania służy do pieczenia i wdrażania manifestów w klastrach Kubernetes przy użyciu wykresów helm.

Składnia

# 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.

Dane wejściowe

action - Działania
string. Dozwolone wartości: bake, createSecret (utwórz wpis tajny), delete, deploy, patch, promote, scale, . reject Wartość domyślna: deploy.

Określa akcję do wykonania.

kubernetesServiceConnection - Połączenie usługi Kubernetes
string. Wymagane, gdy action != bake.

Określa połączenie usługi Kubernetes.

namespace - Obszaru nazw
string.

Określa przestrzeń nazw poleceń przy użyciu flagi –namespace . Jeśli przestrzeń nazw nie zostanie podana, polecenia zostaną uruchomione w domyślnej przestrzeni nazw.

strategy - Strategii
string. Opcjonalny. Użyj polecenia , gdy action = deploy || action = promote || action = reject. Dozwolone wartości: canary, none. Wartość domyślna: none.

Określa strategię wdrażania używaną deploy w akcji przed akcją promote lub reject akcją. canary Obecnie jest jedyną akceptowalną strategią wdrażania.

trafficSplitMethod - Metoda podziału ruchu
string. Opcjonalny. Użyj polecenia , gdy strategy = canary. Dozwolone wartości: pod, smi. Wartość domyślna: pod.

W przypadku wartości smiwartość procentowa podziału ruchu jest wykonywana na poziomie żądania przy użyciu siatki usług. Siatka usług musi zostać skonfigurowana przez administratora klastra. To zadanie obsługuje orkiestrację obiektów SMI TrafficSplit .

W przypadku wartości podwartość procentowa podziału nie jest możliwa na poziomie żądania w przypadku braku siatki usług. Zamiast tego wartość procentowa danych wejściowych jest używana do obliczania replik dla punktu odniesienia i kanarnika. Obliczanie jest procentem replik określonych w manifestach wejściowych dla stabilnego wariantu.

percentage - Procent
string. Wymagane, gdy strategy = Canary && action = deploy. Wartość domyślna: 0.

Wartość procentowa używana do obliczania liczby wariantów linii bazowych i wariantów kanarowych obciążeń zawartych w plikach manifestu.

Dla określonego procentu danych wejściowych oblicz:

(procent × liczby replik) / 100

Jeśli wynik nie jest liczbą całkowitą, podłogi matematyczne wyniku jest używane podczas tworzenia wariantów punktów odniesienia i kanarowych.

Załóżmy na przykład, że wdrożenie hello-world znajduje się w pliku manifestu wejściowego i że w danych wejściowych zadania znajdują się następujące wiersze:

replicas: 4
strategy: canary
percentage: 25

W takim przypadku wdrożenia hello-world-baseline i hello-world-canary są tworzone z jedną repliką. Wariant punktu odniesienia jest tworzony z tym samym obrazem i tagiem co stabilna wersja, która jest wariantem z czterema replikami przed wdrożeniem. Wariant kanarowy jest tworzony przy użyciu obrazu i tagu odpowiadającego nowo wdrożonym zmianom.

baselineAndCanaryReplicas - Repliki bazowe i kanary
string. Wymagane, gdy strategy = Canary && action = deploy && trafficSplitMethod = SMI. Wartość domyślna: 1.

Po ustawieniu wartości trafficSplitMethodsmina wartość wartość procentowa podziału ruchu jest kontrolowana na płaszczyźnie siatki usług. Można kontrolować rzeczywistą liczbę replik dla wariantów kanarowych i bazowych niezależnie od podziału ruchu.

Załóżmy na przykład, że manifest wdrożenia wejściowego określa 30 replik dla stabilnego wariantu. Załóżmy również, że dla zadania określono następujące dane wejściowe:

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

W tym przypadku wariant stabilny otrzymuje 80% ruchu, podczas gdy warianty bazowe i kanarkowe otrzymują połowę określonego 20%. Warianty bazowe i kanary nie otrzymują trzech replik. Zamiast tego otrzymują określoną liczbę replik, co oznacza, że każda z nich odbiera jedną replikę.

manifests - Manifesty
string. Wymagane, gdy action = deploy || action = promote || action = reject.

Określa ścieżkę do plików manifestu, które mają być używane do wdrożenia. Każdy wiersz reprezentuje jedną ścieżkę. Wzorzec dopasowywania plików jest akceptowalną wartością dla każdego wiersza.

containers - Pojemniki
string. Opcjonalny. Użyj polecenia , gdy action = deploy || action = promote || action = bake.

Określa w pełni kwalifikowany adres URL zasobu obrazu, który ma być używany do podstawienia w plikach manifestu. Adres URL contosodemo.azurecr.io/helloworld:test jest przykładem.

imagePullSecrets - ImagePullSecrets
string. Opcjonalny. Użyj polecenia , gdy action = deploy || action = promote.

Określa wielowierszowe dane wejściowe, w których każdy wiersz zawiera nazwę wpisu tajnego rejestru platformy Docker, który został już skonfigurowany w klastrze. Każda nazwa wpisu tajnego jest dodawana w obszarze imagePullSecrets dla obciążeń znalezionych w plikach manifestu wejściowego.

renderType - Aparat renderowania
string. Opcjonalny. Użyj polecenia , gdy action = bake. Dozwolone wartości: helm, kompose, kustomize. Wartość domyślna: helm.

Określa typ renderowania używany do tworzenia plików manifestu.

dockerComposeFile - Ścieżka do pliku docker compose
string. Wymagane, gdy action = bake && renderType = kompose.

Określa ścieżkę pliku docker-compose.

helmChart - Pakiet Helm
string. Wymagane, gdy action = bake && renderType = helm.

Określa ścieżkę wykresu Helm do pieczenia.

releaseName - Nazwa wydania programu Helm
string. Opcjonalny. Użyj polecenia , gdy action = bake && renderType = helm.

Określa nazwę wydania programu Helm do użycia.

overrideFiles - Zastępowanie plików
string. Opcjonalny. Użyj polecenia , gdy action = bake && renderType = helm.

Określa wielowierszowe dane wejściowe, które akceptują ścieżkę do przesłonięć plików. Pliki są używane podczas tworzenia plików manifestu z wykresów programu Helm.

overrides - Zastępuje
string. Opcjonalny. Użyj polecenia , gdy action = bake && renderType = helm.

Określa wartości przesłonięcia do ustawienia.

kustomizationPath - Ścieżka kustomyzacji
string. Opcjonalny. Użyj polecenia , gdy action = bake && renderType = kustomize.

Określa argument, który musi być ścieżką do katalogu zawierającego plik lub adres URL repozytorium Git z sufiksem ścieżki określającym same w odniesieniu do katalogu głównego repozytorium.

resourceToPatch - Zasób do stosowania poprawek
string. Wymagane, gdy action = patch. Dozwolone wartości: file, name. Wartość domyślna: file.

Wskazuje jedną z następujących metod poprawek:

• Plik manifestu identyfikuje obiekty do stosowania poprawek.
• Pojedynczy obiekt jest identyfikowany przez rodzaj i nazwę jako obiekt docelowy poprawki.

Dopuszczalne wartości to plik i nazwa.

resourceFileToPatch - Ścieżka pliku
string. Wymagane, gdy action = patch && resourceToPatch = file.

Określa ścieżkę do pliku używanego dla poprawki.

kind - Rodzaju
string. Wymagane, gdy action = scale || resourceToPatch = name. Dozwolone wartości: deployment, replicaset, statefulset.

Określa rodzaj obiektu K8s, na przykład deployment, replicaSet i nie tylko.

name - Nazwa
string. Wymagane, gdy action = scale || resourceToPatch = name.

Określa nazwę obiektu K8s.

replicas - Liczba replik
string. Wymagane, gdy action = scale.

Określa liczbę replik do skalowania do.

mergeStrategy - Strategia scalania
string. Wymagane, gdy action = patch. Dozwolone wartości: json, merge, strategic. Wartość domyślna: strategic.

Określa typ udostępnianej poprawki.

arguments - Argumenty
string. Opcjonalny. Użyj polecenia , gdy action = delete.

Określa argumenty polecenia kubectl delete . Przykład: arguments: deployment hello-world foo-bar

patch - Patch
string. Wymagane, gdy action = patch.

Określa zawartość poprawki.

secretType - Typ wpisu tajnego
string. Wymagane, gdy action = createSecret. Dozwolone wartości: dockerRegistry, generic. Wartość domyślna: dockerRegistry.

Tworzy lub aktualizuje ogólny lub docker imagepullsecret. Określ dockerRegistry , aby utworzyć lub zaktualizować imagepullsecret wybrany rejestr. Element imagePullSecret to sposób przekazania wpisu tajnego zawierającego hasło rejestru kontenerów do rozwiązania Kubelet, dzięki czemu może ściągnąć prywatny obraz w imieniu zasobnika.

secretName - Nazwa wpisu tajnego
string. Opcjonalny. Użyj polecenia , gdy action = createSecret.

Określa nazwę wpisu tajnego. Tej nazwy wpisu tajnego można użyć w pliku konfiguracji YAML kubernetes.

secretArguments - Argumenty
string. Opcjonalny. Użyj polecenia , gdy action = createSecret && secretType = generic.

Określa klucze i wartości literałów do wstawienia w kluczu tajnym. Na przykład --from-literal=key1=value1--from-literal=key2="top secret".

dockerRegistryEndpoint - Połączenie usługi rejestru platformy Docker
string. Opcjonalny. Użyj polecenia , gdy action = createSecret && secretType = dockerRegistry.

Określa poświadczenia określonego połączenia usługi, które są używane do tworzenia wpisu tajnego rejestru platformy Docker w klastrze. Pliki manifestu w imagePullSecrets polu mogą następnie odwoływać się do nazwy tego wpisu tajnego.

rolloutStatusTimeout - Limit czasu dla stanu wdrożenia
string. Opcjonalny. Użyj polecenia , gdy action = deploy || action = patch || action = scale || action = promote. Wartość domyślna: 0.

Określa czas oczekiwania (w sekundach) przed zakończeniem watch on rollout stanu.

Opcje sterowania zadaniami

Wszystkie zadania mają opcje sterowania oprócz danych wejściowych zadań podrzędnych. Aby uzyskać więcej informacji, zobacz Opcje sterowania i typowe właściwości zadań.

Zmienne wyjściowe

To zadanie definiuje następujące zmienne wyjściowe, które można używać w krokach podrzędnych, zadaniach i etapach.

manifestsBundle
Określa lokalizację pakietów manifestu utworzonych przez akcję pieczenia.

Uwagi

Uwaga

Dostępna jest nowsza wersja tego zadania, która zapewnia dodatkową obsługę określania celu klastra Kubernetes na różne sposoby przy użyciu connectionType właściwości . Aby uzyskać więcej informacji , zobaczuwagi dotyczące KubernetesManifest@1 i połączenia z usługą KubernetesManifest@1

Użyj zadania manifestu Kubernetes w potoku kompilacji lub wydania, aby utworzyć i wdrożyć manifesty w klastrach Kubernetes.

To zadanie obsługuje następujące zadania:

• Podstawianie artefaktów: akcja wdrażania przyjmuje jako dane wejściowe listę obrazów kontenerów, które można określić wraz z ich tagami i skrótami. Te same dane wejściowe są zastępowane w niezaplatanych plikach manifestu przed aplikacją do klastra. To podstawianie gwarantuje, że węzły klastra ściągają właściwą wersję obrazu.

• Stabilność manifestu: sprawdzany jest stan wdrożenia wdrożonych obiektów Kubernetes. Kontrole stabilności są uwzględniane w celu określenia, czy stan zadania jest powodzeniem, czy niepowodzeniem.

• Adnotacje dotyczące możliwości śledzenia: adnotacje są dodawane do wdrożonych obiektów Kubernetes w celu nadpisywania informacji dotyczących możliwości śledzenia. Obsługiwane są następujące adnotacje:

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

• Obsługa wpisów tajnych: akcja createSecret umożliwia tworzenie wpisów tajnych rejestru platformy Docker przy użyciu połączeń usługi rejestru platformy Docker. Umożliwia również tworzenie ogólnych wpisów tajnych przy użyciu zmiennych zwykłych lub zmiennych tajnych. Przed wdrożeniem w klastrze można użyć secrets danych wejściowych wraz z deploy akcją w celu rozszerzenia plików manifestu wejściowego o odpowiednią imagePullSecrets wartość.

• Manifest bake: bake akcja zadania umożliwia tworzenie szablonów w plikach manifestu kubernetes. Akcja używa narzędzi, takich jak Helm, Compose i Kustomize. W przypadku pieczenia te pliki manifestu Kubernetes można używać do wdrożeń w klastrze.

• Strategia wdrażania: wybranie canary strategii z deploy akcją prowadzi do utworzenia nazw obciążeń z sufiksem i -canary-baseline . Zadanie obsługuje dwie metody dzielenia ruchu:

  • Interfejs usługi Service Mesh: abstrakcja interfejsu usługi Service Mesh (SMI) umożliwia konfigurację z dostawcami usługi mesh, takimi jak Linkerd i Istio. Zadanie manifestu Kubernetes mapuje obiekty SMI TrafficSplit na stabilne, bazowe i kanary usług w cyklu życia strategii wdrażania.

    Wdrożenia kanaarne, które są oparte na siatce usług i używają tego zadania, są bardziej dokładne. Ta dokładność jest spowodowana tym, jak dostawcy usługi Service Mesh umożliwiają szczegółowy podział ruchu na podstawie procentu. Siatka usługi używa rejestru usług i kontenerów przyczepki, które są wstrzykiwane do zasobników. Wstrzyknięcie odbywa się wraz z kontenerami aplikacji w celu osiągnięcia szczegółowego podziału ruchu.

  • Platforma Kubernetes bez siatki usług: w przypadku braku siatki usług nie można uzyskać dokładnego podziału procentowego żądanego na poziomie żądania. Można jednak wykonać wdrożenia kanary przy użyciu wariantów bazowych i kanarowych obok stabilnego wariantu.

    Usługa wysyła żądania do zasobników wszystkich trzech wariantów obciążenia, ponieważ są spełnione ograniczenia etykiety selektora. Manifest kubernetes honoruje te żądania podczas tworzenia wariantów punktu odniesienia i kanargu. To zachowanie routingu osiąga zamierzony efekt routingu tylko części całkowitych żądań do kanary.

  Porównaj obciążenia punktu odniesienia i kanargu przy użyciu zadania interwencja ręczna w potokach wydania lub zadania Opóźnienie w potokach YAML. Przed użyciem akcji podwyższania poziomu lub odrzucania zadania wykonaj porównanie.

Wdrażanie akcji

Poniższy kod YAML jest przykładem wdrażania w przestrzeni nazw kubernetes przy użyciu plików manifestu:

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

W powyższym przykładzie zadanie próbuje znaleźć dopasowania dla obrazów foo/demo i bar/demo w polach obrazu plików manifestu. Dla każdego znalezionego tagVariable1 dopasowania wartość lub tagVariable2 jest dołączana jako tag do nazwy obrazu. Możesz również określić skróty w kontenerach wejściowych dla podstawianie artefaktów.

Uwaga

Chociaż można tworzyć deployakcje , promotei reject przy użyciu danych wejściowych YAML związanych ze strategią wdrażania, obsługa zadania interwencja ręczna jest obecnie niedostępna dla potoków kompilacji.

W przypadku potoków wydania zalecamy użycie akcji i danych wejściowych związanych ze strategią wdrażania w następującej sekwencji:

1. Akcja wdrażania określona za pomocą polecenia strategy: canary i percentage: $(someValue).
2. Zadanie interwencja ręczna, aby można było wstrzymać potok i porównać wariant punktu odniesienia z wariantem kanarowym.
3. Akcja podwyższania poziomu, która jest uruchamiana, jeśli zadanie interwencja ręczna zostanie wznowione i akcja odrzucenia, która zostanie uruchomiona, jeśli zadanie interwencja ręczna zostanie odrzucone.

Tworzenie akcji wpisu tajnego

Poniższy kod YAML przedstawia przykładowe tworzenie wpisów tajnych rejestru platformy Docker przy użyciu połączenia usługi Rejestru platformy Docker:

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

Ten kod YAML przedstawia przykładowe tworzenie ogólnych wpisów tajnych:

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

Akcja bake

Poniższy kod YAML jest przykładem pieczenia plików manifestu z wykresów helm. Zanotuj użycie nazwy wejściowej w pierwszym zadaniu. Ta nazwa jest później przywoływała się z kroku wdrażania w celu określenia ścieżki do manifestów utworzonych przez krok pieczenia.

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

Uwaga

Aby użyć programu Helm bezpośrednio do zarządzania wydaniami i wycofywaniem, zobacz zadanie Pakiet i wdrażanie wykresów programu Helm.

Przykład kustomize

Poniższy kod YAML jest przykładem pieczenia plików manifestu generowanych za pomocą narzędzia Kustomize zawierającego kustomization.yaml plik.

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)

Przykład komkompose

Poniższy kod YAML jest przykładem pieczenia plików manifestu generowanych za pomocą narzędzia Kompose, narzędzia do konwersji do platformy 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)

Akcja skalowania

Poniższy kod YAML przedstawia przykład skalowania obiektów:

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

Akcja poprawek

Poniższy kod YAML przedstawia przykład stosowania poprawek obiektów:

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

Akcja usuwania

Ten kod YAML przedstawia przykładowe usunięcie obiektu:

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

Rozwiązywanie problemów

Mój klaster Kubernetes jest za zaporą i używam agentów hostowanych. Jak można przeprowadzić wdrożenie w tym klastrze?

Dostępu hostowanym agentom można udzielić przez zaporę, zezwalając na adresy IP agentów hostowanych. Aby uzyskać więcej informacji, zobacz zakresy adresów IP agentów.

Jak działają żądania w przypadku stabilnych i zmiennych tras usług z wdrożeniami kanarkowymi?

Relacja selektora etykiet między zasobnikami i usługami na platformie usłudze Kubernetes umożliwia skonfigurowanie wdrożeń w taki sposób, aby jedna usługa kierowała żądania zarówno do stabilnych, jak i kanarkowych wariantów. Zadanie manifestu platformy Kubernetes używa tego zadania w przypadku wdrożeń kanarkowych.

Jeśli zadanie zawiera dane wejściowe action: deploy i strategy: canary, dla każdego obciążenia (Deployment, ReplicaSet, Pod, ...) zdefiniowanego w plikach -baseline manifestu wejściowego, tworzone są warianty i -canary wdrożenia. W tym przykładzie istnieje wdrożenie sampleapp w pliku manifestu wejściowego i że po zakończeniu przebiegu nr 22 potoku stabilny wariant tego wdrożenia o nazwie sampleapp jest wdrażany w klastrze. W kolejnym uruchomieniu (w tym przypadku uruchom numer 23), zadanie manifestu Platformy Kubernetes z action: deploy programem i strategy: canary spowodowałoby utworzenie wdrożeń sampleapp-baseline i sampleapp-canary, których liczba replik jest określana przez produkt percentage danych wejściowych zadania z wartością żądanej liczby replik dla końcowego stabilnego wariantu jako sampleapp dla plików manifestu wejściowego.

Z wyłączeniem liczby replik wersja punktu odniesienia ma taką samą konfigurację jak stabilny wariant, podczas gdy wersja kanarowa ma nowe zmiany wprowadzone przez bieżący przebieg (w tym przypadku numer 23). Jeśli interwencja ręczna jest skonfigurowana w potoku po powyższym kroku, umożliwiłoby to wstrzymanie potoku w taki sposób, aby administrator potoku mógł ocenić kluczowe metryki dla wersji punktu odniesienia i kanargu oraz podjąć decyzję o tym, czy zmiany kanaarne są bezpieczne i wystarczająco dobre dla kompletnego wdrożenia.

strategy: canary Zadaniaaction: promote manifestu Platformy Kubernetes i lub i action: rejectstrategy: canary mogą służyć do promowania lub odrzucania odpowiednio zmian kanaracji. Należy pamiętać, że w obu przypadkach na końcu tego kroku tylko stabilny wariant obciążeń zadeklarowanych w plikach manifestu wejściowego pozostanie wdrożony w klastrze, podczas gdy efemeryczna linia bazowa i wersje kanary są czyszczone.

Wymagania

Wymaganie	Opis
Typy potoków	YAML, kompilacja klasyczna, wersja klasyczna
Działa na	Agent, DeploymentGroup
Wymagania	Brak
Możliwości	To zadanie nie spełnia żadnych wymagań dotyczących kolejnych zadań w zadaniu.
Ograniczenia poleceń	Dowolne
Zmienne ustawialne	Dowolne
Wersja agenta	Wszystkie obsługiwane wersje agenta.
Kategoria zadania	Wdrażanie