KubernetesManifest@0 — zadanie Wdrażanie na platformie Kubernetes w wersji 0

Użyj zadania manifestu kubernetes w potoku kompilacji lub wydania, aby utworzyć i wdrożyć manifesty w klastrach Kubernetes przy użyciu pakietów Helm.

Ta wersja zadania jest przestarzała; użyj KubernetesManifest@1, aby skorzystać z najnowszych funkcji, takich jak Federacja tożsamości obciążenia.

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 - akcja
string. Dozwolone wartości: bake, createSecret (tworzenie wpisu tajnego), delete, deploy, patch, promote, scale, reject. Wartość domyślna: deploy.

Określa akcję do wykonania.

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

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

przestrzeni nazw namespace -
string.

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

strategii strategy -
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ą w akcji deploy przed akcją promote lub akcją reject. Obecnie canary jest jedyną akceptowalną strategią wdrażania.

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

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

W przypadku wartości podpodział procentowy nie jest możliwy 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 kanargu. Obliczenie jest procentem replik określonych w manifestach wejściowych dla stabilnego wariantu.

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

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

Dla określonego procentu danych wejściowych oblicz:

(procent × liczba replik) / 100

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

Załóżmy na przykład, że hello-world wdrożenia 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 przy użyciu tego samego obrazu i tagu co stabilna wersja, która jest wariantem czterech replik 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 trafficSplitMethod na smiwartość 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 stabilny wariant otrzymuje 80% ruchu, podczas gdy warianty bazowe i kanarne otrzymują połowę określonego 20%. Warianty bazowe i kanarne nie otrzymują trzech replik. Zamiast tego otrzymują określoną liczbę replik, co oznacza, że każda z nich odbiera jedną replikę.

manifestów manifests -
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 - Containers
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 imagePullSecrets dla obciążeń znajdujących się w plikach manifestu wejściowego.

aparatu renderowania renderType -
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 - helm chart
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 - przesłanianie 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, gdy pliki manifestu z wykresów programu Helm są pieczone.

overrides - przesłonięcia
string. Opcjonalny. Użyj polecenia , gdy action = bake && renderType = helm.

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

kustomizationPath - ścieżki kustomizacji
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 według rodzaju i nazwy jako obiektu docelowego poprawki.

Dopuszczalne wartości to plików i nazwa .

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

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

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

Określa rodzaj obiektu K8s, taki jak deployment, replicaSet i nie tylko.

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

Określa nazwę obiektu K8s.

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

Określa liczbę replik do skalowania do.

mergeStrategy - strategii 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 dla polecenia kubectl delete. Przykład: arguments: deployment hello-world foo-bar

poprawki
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 wybranego rejestru. 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. Tę nazwę 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łu do wstawienia w kluczu tajnym. Na przykład --from-literal=key1=value1--from-literal=key2="top secret".

dockerRegistryEndpoint - połączenia 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 polu imagePullSecrets mogą następnie odwoływać się do nazwy tego wpisu tajnego.

limit czasu rolloutStatusTimeout - 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 kontroli 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ę bake.

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 właściwości connectionType. Aby uzyskać więcej informacji, zobacz KubernetesManifest@1 i uwagi dotyczące połączenia z usługą KubernetesManifest@1

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

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

• Podstawienie artefaktu: akcja wdrażania jest wykonywana jako dane wejściowe listy 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 do nieplatyzowanych plików manifestu przed aplikacją w klastrze. Podstawienie to gwarantuje, że węzły klastra ściągają odpowiednią 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 o możliwości śledzenia. Obsługiwane są następujące adnotacje:

  • azure-pipelines/org
  • azure-pipelines/project
  • azure-pipelines/pipeline
  • 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 w postaci zwykłego tekstu lub zmiennych tajnych. Przed wdrożeniem w klastrze można użyć danych wejściowych secrets wraz z akcją deploy, aby rozszerzyć pliki manifestu wejściowego o odpowiednią wartość imagePullSecrets.

• Manifest Bake: akcja bake 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 platformy Kubernetes mogą być używane do wdrożeń w klastrze.

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

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

    Wdrożenia kanary, które są oparte na siatce usług i używają tego zadania, są dokładniejsze. Ta dokładność wynika ze sposobu, w jaki dostawcy siatki usług umożliwiają szczegółowy podział ruchu opartego na procentach. Siatka usług używa rejestru usług i kontenerów przyczepki, które są wstrzykiwane do zasobników. Ta iniekcja występuje obok kontenerów aplikacji w celu osiągnięcia szczegółowego podziału ruchu.

  • kubernetes bezsiatki usług: w przypadku braku siatki usługi możesz nie uzyskać dokładnego podziału procentowego na poziomie żądania. Można jednak wykonać wdrożenia kanary, używając wariantów odniesienia 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 platformy 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 kanargu.

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

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 dopasowania wartość tagVariable1 lub tagVariable2 jest dołączana jako tag do nazwy obrazu. Można również określić skróty w kontenerach wejściowych dla podstawienia artefaktu.

Uwaga

Chociaż można tworzyć akcje deploy, promotei reject z danymi wejściowymi YAML związanymi 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 kolejności:

1. Akcja wdrażania określona przy użyciu 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 jest uruchamiana, 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 Docker Registry:

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 pieca

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, które zostały wygenerowane 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 Package and deploy Helm charts.

Przykład kustomize

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

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 Kompose

Poniższy kod YAML jest przykładem plików manifestu pieczenia generowanych za pomocą narzędzia konwersji Kompose dla narzędzia 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 stosowania 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 usuń

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 znajduje się za zaporą i używam hostowanych agentów. Jak mogę wdrożyć w tym klastrze?

Dostęp hostowanych agentów można udzielić za pośrednictwem zapory, zezwalając na adresy IP dla hostowanych agentów. 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ń kanarowych.

Jeśli zadanie zawiera dane wejściowe action: deploy i strategy: canary, dla każdego obciążenia (Deployment, ReplicaSet, Pod, ...) zdefiniowanego w plikach manifestu wejściowego, tworzone są -baseline i -canary wariant wdrożenia. W tym przykładzie istnieje sampleapp wdrożenia w pliku manifestu wejściowego i że po zakończeniu przebiegu nr 22 potoku w klastrze wdrożono stabilny wariant tego wdrożenia o nazwie sampleapp. W kolejnym uruchomieniu (w tym przypadku jest to numer 23), zadanie manifestu kubernetes z action: deploy i strategy: canary spowodowałoby utworzenie przykładowych wdrożeń bazowych i przykładowych aplikacji kanary, 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 sampleapp zgodnie z plikami manifestu wejściowego.

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

Za pomocąaction: promote i strategy: canary lub action: reject i strategy: canary danych wejściowych zadań manifestu kubernetes można odpowiednio podwyższyć lub odrzucić zmiany kanary. 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 kanarne są czyszczone.

Wymagania

Wymaganie	Opis
Typy potoków	YAML, klasyczna kompilacja, wersja klasyczna
Działa na	Agent, DeploymentGroup
Wymagania	Żaden
możliwości	To zadanie nie spełnia żadnych wymagań dotyczących kolejnych zadań w zadaniu.
ograniczenia poleceń	Jakikolwiek
zmienne ustawiane	Jakikolwiek
Wersja agenta	Wszystkie obsługiwane wersje agentów.
Kategoria zadań	Zastosuj