KubernetesManifest@1 — wdrażanie na platformie Kubernetes w wersji 1 — zadanie

Użyj plików manifestu platformy Kubernetes, aby wdrożyć je w klastrach, a nawet przygotować pliki manifestu do użycia na potrzeby wdrożeń przy użyciu wykresów programu Helm.

Składnia

# Deploy to Kubernetes v1
# Use Kubernetes manifest files to deploy to clusters or even bake the manifest files to be used for deployments using Helm charts.
- task: KubernetesManifest@1
  inputs:
    #action: 'deploy' # 'bake' | 'createSecret' | 'delete' | 'deploy' | 'patch' | 'promote' | 'scale' | 'reject'. Action. Default: deploy.
    #connectionType: 'kubernetesServiceConnection' # 'azureResourceManager' | 'kubernetesServiceConnection'. Required when action != bake. Service connection type. Default: kubernetesServiceConnection.
    #kubernetesServiceConnection: # string. Alias: kubernetesServiceEndpoint. Required when action != bake && connectionType = kubernetesServiceConnection. Kubernetes service connection. 
    #azureSubscriptionConnection: # string. Alias: azureSubscriptionEndpoint. Required when action != bake && connectionType = azureResourceManager. Azure subscription. 
    #azureResourceGroup: # string. Required when action != bake && connectionType = azureResourceManager. Resource group. 
    #kubernetesCluster: # string. Required when action != bake && connectionType = azureResourceManager. Kubernetes cluster. 
    #useClusterAdmin: false # boolean. Optional. Use when connectionType = azureResourceManager. Use cluster admin credentials. Default: false.
    #namespace: # string. Namespace. 
    #strategy: 'none' # 'canary' | 'none'. Optional. Use when action = deploy || action = promote || action = reject. Strategy. Default: none.
    #trafficSplitMethod: 'pod' # 'pod' | 'smi'. Optional. Use when strategy = canary. Traffic split method. Default: pod.
    #percentage: '0' # string. Required when strategy = Canary && action = deploy. Percentage. Default: 0.
    #baselineAndCanaryReplicas: '1' # string. Required when strategy = Canary && action = deploy && trafficSplitMethod = SMI. Baseline and canary replicas. Default: 1.
    #manifests: # string. Required when action = deploy || action = promote || action = reject. Manifests. 
    #containers: # string. Optional. Use when action = deploy || action = promote || action = bake. Containers. 
    #imagePullSecrets: # string. Optional. Use when action = deploy || action = promote. ImagePullSecrets. 
    #renderType: 'helm' # 'helm' | 'kompose' | 'kustomize'. Optional. Use when action = bake. Render Engine. Default: helm.
    #dockerComposeFile: # string. Required when action = bake && renderType = kompose. Path to docker compose file. 
    #helmChart: # string. Required when action = bake && renderType = helm. Helm Chart. 
    #releaseName: # string. Optional. Use when action = bake && renderType = helm. Helm Release Name. 
    #overrideFiles: # string. Optional. Use when action = bake && renderType = helm. Override Files. 
    #overrides: # string. Optional. Use when action = bake && renderType = helm. Overrides. 
    #kustomizationPath: # string. Optional. Use when action = bake && renderType = kustomize. Kustomization Path. 
    #resourceToPatch: 'file' # 'file' | 'name'. Required when action = patch. Resource to patch. Default: file.
    #resourceFileToPatch: # string. Required when action = patch && resourceToPatch = file. File path. 
    #kind: # 'deployment' | 'replicaset' | 'statefulset'. Required when action = scale || resourceToPatch = name. Kind. 
    #name: # string. Required when action = scale || resourceToPatch = name. Name. 
    #replicas: # string. Required when action = scale. Replica count. 
    #mergeStrategy: 'strategic' # 'json' | 'merge' | 'strategic'. Required when action = patch. Merge Strategy. Default: strategic.
    #arguments: # string. Optional. Use when action = delete. Arguments. 
    #patch: # string. Required when action = patch. Patch. 
    #secretType: 'dockerRegistry' # 'dockerRegistry' | 'generic'. Required when action = createSecret. Type of secret. Default: dockerRegistry.
    #secretName: # string. Optional. Use when action = createSecret. Secret name. 
    #secretArguments: # string. Optional. Use when action = createSecret && secretType = generic. Arguments. 
    #dockerRegistryEndpoint: # string. Optional. Use when action = createSecret && secretType = dockerRegistry. Docker registry service connection. 
    #rolloutStatusTimeout: '0' # string. Optional. Use when action = deploy || action = patch || action = scale || action = promote. Timeout for rollout status. Default: 0.

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.

connectionType - Typ połączenia z usługą
string. Wymagane, gdy action != bake. Dozwolone wartości: azureResourceManager (Azure Resource Manager), kubernetesServiceConnection (Połączenie usługi Kubernetes). Wartość domyślna: kubernetesServiceConnection.

Wybierz typ połączenia usługi Kubernetes.

• kubernetesServiceConnection (Połączenie usługi Kubernetes) — umożliwia podanie pliku KubeConfig, określenie konta usługi lub zaimportowanie wystąpienia usługi AKS z opcją Subskrypcja platformy Azure . Importowanie wystąpienia usługi AKS z opcją Subskrypcja platformy Azure wymaga dostępu do klastra Kubernetes w czasie konfiguracji połączenia z usługą.
• azureResourceManager(Azure Resource Manager) — umożliwia wybranie wystąpienia usługi AKS. Nie uzyskuje dostępu do klastra Kubernetes w czasie konfiguracji połączenia z usługą.

Aby uzyskać więcej informacji, zobacz Uwagi.

kubernetesServiceConnection - Połączenie usługi Kubernetes
Alias wejściowy: kubernetesServiceEndpoint. string. Wymagane, gdy action != bake && connectionType = kubernetesServiceConnection.

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

azureSubscriptionConnection - Subskrypcja platformy Azure
Alias wejściowy: azureSubscriptionEndpoint. string. Wymagane, gdy action != bake && connectionType = azureResourceManager.

Wybierz subskrypcję usługi Azure Resource Manager zawierającą Azure Container Registry. Uwaga: Aby skonfigurować nowe połączenie z usługą, wybierz subskrypcję platformy Azure z listy i kliknij pozycję "Autoryzuj". Jeśli twoja subskrypcja nie znajduje się na liście lub jeśli chcesz użyć istniejącej jednostki usługi, możesz skonfigurować połączenie usługi platformy Azure przy użyciu przycisku "Dodaj" lub "Zarządzaj".

azureResourceGroup - Grupa zasobów
string. Wymagane, gdy action != bake && connectionType = azureResourceManager.

Wybierz grupę zasobów platformy Azure.

kubernetesCluster - Klaster Kubernetes
string. Wymagane, gdy action != bake && connectionType = azureResourceManager.

Wybierz klaster zarządzany platformy Azure.

useClusterAdmin - Używanie poświadczeń administratora klastra
boolean. Opcjonalny. Użyj polecenia , gdy connectionType = azureResourceManager. Wartość domyślna: false.

Użyj poświadczeń administratora klastra zamiast domyślnych poświadczeń użytkownika klastra.

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, gdy pliki manifestu z wykresów programu Helm są pieczone.

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 zadania

Wszystkie zadania mają opcje sterowania oprócz danych wejściowych zadań. 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
Lokalizacja pakietów manifestu utworzonych przez akcję pieczenia

Uwagi

Zagadnienia dotyczące połączenia z usługą Kubernetes Podczas uzyskiwania dostępu do usługi AKS

Możesz utworzyć połączenie usługi Kubernetes z dowolną z poniższych opcji.

• KubeConfig
• Konto usługi
• Subskrypcja platformy Azure

Podczas wybierania opcji Subskrypcja platformy Azure platforma Kubernetes musi być dostępna dla usługi Azure DevOps w czasie konfiguracji połączenia z usługą. Mogą wystąpić różne przyczyny, dla których nie można utworzyć połączenia z usługą, na przykład utworzono klaster prywatny lub klaster ma wyłączone konta lokalne. W takich przypadkach usługa Azure DevOps nie może nawiązać połączenia z klastrem w czasie konfiguracji połączenia z usługą i zostanie wyświetlony ekran Ładowanie przestrzeni nazw .

Począwszy od platformy Kubernetes 1.24, długotrwałe tokeny nie są już domyślnie tworzone. Platforma Kubernetes zaleca, aby nie używać tokenów długotrwałych. W związku z tym zadania korzystające z połączenia usługi Kubernetes utworzonego z opcją Subskrypcja platformy Azure nie mają dostępu do tokenu trwałego wymaganego do uwierzytelnienia i nie mogą uzyskać dostępu do klastra Kubernetes. Spowoduje to również zablokowanie okna dialogowego Ładowanie przestrzeni nazw .

Uzyskiwanie dostępu do usługi AKS przy użyciu połączenia usługi Azure Resource Manager Service

W przypadku klientów usługi AKS typ połączenia usługi Azure Resource Manager zapewnia najlepszą metodę nawiązywania połączenia z klastrem prywatnym lub klastrem, który ma wyłączone konta lokalne. Ta metoda nie jest zależna od łączności klastra podczas tworzenia połączenia z usługą. Dostęp do usługi AKS jest odroczony do środowiska uruchomieniowego potoku, co ma następujące zalety:

• Dostęp do klastra usługi AKS (prywatnego) można wykonać z własnego agenta lub zestawu skalowania z zasięgiem wzroku do klastra.
• Token jest tworzony dla każdego zadania, które korzysta z połączenia usługi Azure Resource Manager. Gwarantuje to nawiązanie połączenia z platformą Kubernetes przy użyciu krótkotrwałego tokenu, który jest zaleceniem platformy Kubernetes.
• Dostęp do usługi AKS można uzyskać nawet wtedy, gdy konta lokalne są wyłączone.

Często zadawane pytania dotyczące połączenia z usługą

Otrzymuję następujący komunikat o błędzie: Nie można odnaleźć żadnego wpisu tajnego skojarzonego z kontem usługi. Co się dzieje?

Używasz połączenia usługi Kubernetes z opcją Subskrypcja platformy Azure. Aktualizujemy tę metodę w celu utworzenia tokenów długotrwałych. Oczekuje się, że będzie to dostępne w połowie maja. Zaleca się jednak rozpoczęcie korzystania z typu połączenia z usługą platformy Azure, a nie używanie tokenów długotrwałych zgodnie ze wskazówkami dotyczącymi platformy Kubernetes.

Używam usługi AKS i nie chcę nic zmieniać. Czy mogę nadal używać zadań z połączeniem usługi Kubernetes?

Aktualizujemy tę metodę w celu utworzenia tokenów długotrwałych. Oczekuje się, że będzie to dostępne w połowie maja. Należy jednak pamiętać, że takie podejście jest sprzeczne ze wskazówkami dotyczącymi platformy Kubernetes.

Używam zadań platformy Kubernetes i połączenia usługi Kubernetes, ale nie usługi AKS. Czy powinienem się martwić?

Zadania będą nadal działać tak jak poprzednio.

Czy typ połączenia usługi Kubernetes zostanie usunięty?

Nasze zadania kubernetes działają z dowolnym klastrem Kubernetes, niezależnie od tego, gdzie są uruchomione. Połączenie usługi Kubernetes będzie nadal istnieć.

Jestem klientem usługi AKS i wszystko działa prawidłowo, czy powinienem działać?

Nie trzeba nic zmieniać. Jeśli używasz połączenia usługi Kubernetes i wybranej subskrypcji platformy Azure podczas tworzenia, pamiętaj o wskazówkach dotyczących platformy Kubernetes dotyczących korzystania z tokenów długotrwałych.

Tworzysz środowisko Kubernetes i nie mam możliwości korzystania z połączeń z usługami

Jeśli nie możesz uzyskać dostępu do usługi AKS w czasie tworzenia środowiska, możesz użyć pustego środowiska i ustawić connectionType dane wejściowe na połączenie usługi Azure Resource Manager.

Mam skonfigurowaną usługę AKS z kontrolą dostępu opartą na rolach usługi Azure Active Directory, a mój potok nie działa. Czy te aktualizacje rozwiążą ten problem?

Uzyskiwanie dostępu do platformy Kubernetes w przypadku włączenia kontroli dostępu opartej na rolach usługi AAD nie jest związane z tworzeniem tokenów. Aby zapobiec monitowi interaktywnemu, będziemy obsługiwać rozwiązanie kubelogin w przyszłej aktualizacji.

Zadanie manifestu kubernetes w potoku kompilacji lub wydania służy do pieczenia i wdrażania manifestów 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 nieplatyzowanych plikach manifestu przed aplikacją w klastrze. Podstawianie zapewnia, ż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 to powodzenie, czy niepowodzenie.

• Adnotacje ś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ć 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 do plików manifestu kubernetes. Akcja korzysta z narzędzi, takich jak Helm, Compose i Kustomize. W przypadku pieczenia te pliki manifestu platformy Kubernetes mogą być używane w przypadku wdrożeń w klastrze.

• Strategia wdrażania: wybranie canary strategii z deploy akcją prowadzi do utworzenia nazw obciążeń z sufiksem -baseline i -canary. 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 Service Mesh, takimi jak Linkerd i Istio. Zadanie manifestu kubernetes mapuje obiekty SMI TrafficSplit na stabilne, bazowe i kanarkowe usługi podczas cyklu życia strategii wdrażania.

    Wdrożenia kanary, które są oparte na siatce usług i używają tego zadania, są bardziej dokładne. Ta dokładność wynika ze sposobu, w jaki dostawcy siatki usług umożliwiają szczegółowy podział ruchu na podstawie procentu. Siatka usług używa rejestru usług i kontenerów przyczepki, które są wstrzykiwane do zasobników. To 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 możesz nie uzyskać dokładnego podziału procentowego na poziomie żądania. Można jednak wykonać wdrożenia kanarkowe przy użyciu wariantów odniesienia i kanarowych obok stabilnego wariantu.

    Usługa wysyła żądania do zasobników wszystkich trzech wariantów obciążenia w miarę spełnienia ograniczeń etykiety selektora. Manifest kubernetes honoruje te żądania podczas tworzenia wariantów bazowych i kanarowych. To zachowanie routingu osiąga zamierzony efekt rozsyłania tylko części całkowitych żądań do kanarnika.

  Porównaj obciążenia punktu odniesienia i kanargu przy użyciu zadania Interwencja ręczna w potokach wydania lub Zadania opóźnienia 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 wdrożenia 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 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żna również określić skróty w kontenerach wejściowych dla podstawienia artefaktu.

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 kolejności:

1. Akcja wdrażania określona za pomocą parametrów 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 uruchamiana w przypadku wznowienia zadania Interwencja ręczna i akcja odrzucenia 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ład tworzenia 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 pieczenie

Poniższy kod YAML jest przykładem pieczenia plików manifestu z wykresów programu 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 w formie tabeli settable	Dowolne
Wersja agenta	Wszystkie obsługiwane wersje agentów.
Kategoria zadania	Wdrażanie