Wdrażanie na platformie Kubernetes

Azure DevOps Services | Azure DevOps Server 2022

Usługi Azure Pipelines można użyć do wdrożenia w klastrach Azure Kubernetes Service i Kubernetes oferowanych przez innych dostawców chmury. Usługa Azure Pipelines ma dwa zadania do pracy z platformą Kubernetes:

• Zadanie KubernetesManifest: bake and deploy manifests to Kubernetes clusters with Helm, Kompose lub Kustomize
• Zadanie Kubectl: wdrażanie, konfigurowanie i aktualizowanie klastra Kubernetes w usłudze Azure Container Service przez uruchomienie poleceń kubectl

Jeśli używasz usługi Azure Kubernetes Service z jednym z zadań, typ połączenia usługi Azure Resource Manager jest najlepszym sposobem nawiązywania połączenia z klastrem prywatnym lub klastrem z wyłączonymi kontami lokalnymi.

Aby uzyskać dodatkową możliwość śledzenia wdrożenia, użyj zasobu Kubernetes w środowiskach z zadaniem Kubernetes.

Aby rozpocząć pracę z usługami Azure Pipelines i Azure Kubernetes Service, zobacz Build and deploy to Azure Kubernetes Service with Azure Pipelines (Tworzenie i wdrażanie w usłudze Azure Kubernetes Service za pomocą usługi Azure Pipelines). Aby rozpocząć pracę z usługą Azure Pipelines, platformą Kubernetes i strategią wdrażania kanarowego, zobacz Używanie strategii wdrażania kanary dla wdrożeń kubernetes za pomocą usługi Azure Pipelines.

KubernetesManifest, zadanie

Zadanie KubernetesManifest sprawdza stabilność obiektu przed oznaczeniem zadania jako powodzenia/niepowodzenia. Zadanie może również wykonywać podstawianie artefaktów, dodawać adnotacje związane z śledzeniem potoku, upraszczać tworzenie i odwoływanie się do obrazówPullSecrets, manifesty pieczenia i pomoc w wdrażaniu strategii wdrażania.

Uwaga

Chociaż wyzwalacze obsługi potoku opartego na języku YAML są wyzwalane w jednym repozytorium Git, jeśli potrzebujesz wyzwalacza dla pliku manifestu przechowywanego w innym repozytorium Git lub jeśli wyzwalacze są wymagane dla usługi Azure Container Registry lub Docker Hub, należy użyć potoku klasycznego zamiast potoku opartego na języku YAML.

Możesz użyć akcji bake w zadaniu manifestu Kubernetes do pieczenia szablonów w plikach manifestu Kubernetes. Akcja umożliwia korzystanie z narzędzi, takich jak Helm, Kustomize i Kompose. Akcja bake zadania manifestu Kubernetes zapewnia wgląd w transformację między szablonami wejściowymi a końcowymi plikami manifestu, które są używane we wdrożeniach. Pliki manifestu upieczonego (w zadaniach) można używać jako danych wejściowych dla akcji wdrażania zadania manifestu kubernetes.

Możesz kierować zasoby kubernetes, które są częścią środowisk z zadaniami wdrażania. Użycie środowisk i wdrożeń zasobów zapewnia dostęp do lepszej możliwości śledzenia potoku, dzięki czemu można zdiagnozować problemy z wdrażaniem. Można również wdrażać w klastrach Kubernetes z regularnymi zadaniami bez tych samych funkcji kondycji.

Poniższy kod YAML jest przykładem pieczenia plików manifestu z wykresów helm

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

Zadanie Kubectl

Alternatywą dla zadania KubernetesManifest KubernetesManifest jest użycie zadania Kubectl do wdrażania, konfigurowania i aktualizowania klastra Kubernetes w usłudze Azure Container Service, uruchamiając polecenia kubectl.

W poniższym przykładzie pokazano, jak jest używane połączenie usługi do odwoływania się do klastra Kubernetes.

- task: Kubernetes@1
  displayName: kubectl apply
  inputs:
    connectionType: Kubernetes Service Connection
    kubernetesServiceEndpoint: Contoso

Zadanie skryptu

Można również użyć kubectl z zadaniem skryptu.

W poniższym przykładzie użyto skryptu do uruchomienia kubectlpolecenia .

- script: |
    kubectl apply -f manifest.yml

Strategie wdrażania na platformie Kubernetes

Zadanie manifestu platformy Kubernetes obsługuje obecnie strategię wdrażania kanarowego. Użyj strategii wdrażania kanary, aby częściowo wdrożyć nowe zmiany, aby nowe zmiany współistnieły z bieżącymi wdrożeniami przed pełnym wdrożeniem.

Aby uzyskać więcej informacji na temat wdrożeń kanarowych z potokami, zobacz Use a canary deployment strategy for Kubernetes deployments with Azure Pipelines (Używanie strategii wdrażania kanarowego dla wdrożeń platformy Kubernetes za pomocą usługi Azure Pipelines).

Wdrożenia platformy Kubernetes z wieloma chmurami

Platforma Kubernetes działa w ten sam sposób dla wszystkich dostawców usług w chmurze. Usługa Azure Pipelines może służyć do wdrażania w usłudze Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) lub klastrach od dowolnego innego dostawcy chmury.

Aby skonfigurować wdrożenie wielochmurowe, utwórz środowisko, a następnie dodaj zasoby kubernetes skojarzone z przestrzeniami nazw klastrów Kubernetes.

• Azure Kubernetes Service
• Dostawca ogólny korzystający z istniejącego konta usługi

Ogólne podejście dostawcy oparte na istniejącym koncie usługi współpracuje z klastrami od dowolnego dostawcy chmury, w tym z platformą Azure. Zaletą korzystania z opcji usługi Azure Kubernetes Service jest utworzenie nowych obiektów ServiceAccount i RoleBinding (zamiast ponownego użycia istniejącego konta usługi ServiceAccount), dzięki czemu nowo utworzony obiekt RoleBinding może ograniczyć operacje usługi ServiceAccount tylko do wybranej przestrzeni nazw.

W przypadku korzystania z podejścia ogólnego dostawcy upewnij się, że istnieje powiązanie ról, które przyznaje uprawnienia edit ClusterRole do żądanego konta usługi. Musisz udzielić uprawnień do odpowiedniego konta usług, aby konto usługi było używane przez usługę Azure Pipelines do tworzenia obiektów w wybranej przestrzeni nazw.

Wdrożenia równoległe w wielu chmurach

W poniższym przykładzie pokazano, jak wykonywać wdrożenia równoległe w klastrach w wielu chmurach. W tym przykładzie istnieją wdrożenia w klastrach AKS, GKE, EKS i OpenShift. Te cztery przestrzenie nazw są skojarzone z zasobami kubernetes w contoso środowisku.

trigger:
- main

jobs:
- deployment:
  displayName: Deploy to AKS
  pool:
    vmImage: ubuntu-latest
  environment: contoso.aksnamespace
  strategy:
    runOnce:
      deploy:
        steps:
        - checkout: self
        - task: KubernetesManifest@0
          displayName: Deploy to Kubernetes cluster
          inputs:
            action: deploy
            kubernetesServiceConnection: serviceConnection #replace with your service connection
            namespace: aksnamespace
            manifests: manifests/*
- deployment:
  displayName: Deploy to GKE
  pool:
    vmImage: ubuntu-latest
  environment: contoso.gkenamespace
  strategy:
    runOnce:
      deploy:
        steps:
        - checkout: self
        - task: KubernetesManifest@0
          displayName: Deploy to Kubernetes cluster
          inputs:
            action: deploy
            kubernetesServiceConnection: serviceConnection #replace with your service connection
            namespace: gkenamespace
            manifests: manifests/*
- deployment:
  displayName: Deploy to EKS
  pool:
    vmImage: ubuntu-latest
  environment: contoso.eksnamespace
  strategy:
    runOnce:
      deploy:
        steps:
        - checkout: self
        - task: KubernetesManifest@0
          displayName: Deploy to Kubernetes cluster
          inputs:
            action: deploy
            kubernetesServiceConnection: serviceConnection #replace with your service connection
            namespace: eksnamespace
            manifests: manifests/*
- deployment:
  displayName: Deploy to OpenShift
  pool:
    vmImage: ubuntu-latest
  environment: contoso.openshiftnamespace
  strategy:
    runOnce:
      deploy:
        steps:
        - checkout: self
        - task: KubernetesManifest@0
          displayName: Deploy to Kubernetes cluster
          inputs:
            action: deploy
            kubernetesServiceConnection: serviceConnection #replace with your service connection
            namespace: openshiftnamespace
            manifests: manifests/*
- deployment:
  displayName: Deploy to DigitalOcean
  pool:
    vmImage: ubuntu-latest
  environment: contoso.digitaloceannamespace
  strategy:
    runOnce:
      deploy:
        steps:
        - checkout: self
        - task: KubernetesManifest@0
          displayName: Deploy to Kubernetes cluster
          inputs:
            action: deploy
            kubernetesServiceConnection: serviceConnection #replace with your service connection
            namespace: digitaloceannamespace
            manifests: manifests/*