Delen via


Omgeving - Kubernetes-resource

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

In de Kubernetes-resourceweergave ziet u de status van objecten in de naamruimte die aan de resource zijn toegewezen. In de resourceweergave wordt ook de tracering van pijplijnen overlays, zodat u terug kunt traceren vanuit een Kubernetes-object naar de pijplijn en vervolgens terug kunt gaan naar de doorvoer.

Gebruik Kubernetes-resources om Kubernetes-clusters in een omgeving te richten voor implementatie. Gebruik pijplijnen om te implementeren in Azure Kubernetes Service (AKS) en clusters van een andere cloudprovider.

U kunt Kubernetes-resources gebruiken met openbare of privéclusters. Zie resources in YAML en beveiliging met resources voor meer informatie over de werking van resources.

Overzicht

Bekijk de volgende voordelen van het gebruik van Kubernetes-resourceweergaven in omgevingen:

  • Pijplijntraceerbaarheid : de Kubernetes-manifesttaak, die wordt gebruikt voor implementaties, voegt meer aantekeningen toe om de tracering van pijplijnen in resourceweergaven weer te geven. Traceerbaarheid van pijplijnen helpt bij het identificeren van de oorspronkelijke Azure DevOps-organisatie, het project en de pijplijn die verantwoordelijk is voor updates die zijn aangebracht in een object binnen de naamruimte.

    Traceerbaarheid van pijplijnen

  • Resourcestatus diagnosticeren: workloadstatus kan nuttig zijn voor het snel opsporen van fouten of regressies die zijn geïntroduceerd door een nieuwe implementatie. Voor niet-geconfigureerde imagePullSecrets die resulteren in ImagePullBackOff-fouten, kan informatie over de podstatus u helpen bij het identificeren van de hoofdoorzaak van het probleem.

    ImagePullBackOff

  • App controleren: controleer de app werkt door elke pull-aanvraag vanuit uw Git-opslagplaats te implementeren in een dynamische Kubernetes-resource onder de omgeving. Revisoren kunnen zien hoe deze wijzigingen eruitzien en werken met andere afhankelijke services voordat ze worden samengevoegd in de doelvertakking en worden geïmplementeerd in productie.

Azure Kubernetes Service gebruiken

Er wordt een ServiceAccount gemaakt in uw gekozen cluster en naamruimte wanneer u Azure Kubernetes Service (AKS) gebruikt. Voor een Kubernetes RBAC-cluster wordt RoleBinding ook gemaakt om het bereik van het gemaakte serviceaccount te beperken tot de gekozen naamruimte. Voor een Kubernetes RBAC-uitgeschakeld cluster heeft het gemaakte ServiceAccount clusterbrede bevoegdheden (tussen naamruimten).

Een AKS Kubernetes-resource toevoegen

  1. Selecteer op de pagina met omgevingsgegevens de optie Resource toevoegen en kies Kubernetes.

  2. Selecteer Azure Kubernetes Service in de vervolgkeuzelijst Provider.

  3. Kies het Azure-abonnement, het cluster en de naamruimte (nieuw/bestaand).

  4. Selecteer Valideren en maken om de Kubernetes-resource te maken.

  5. Controleer of u een cluster voor uw omgeving ziet. U ziet de tekst 'Nooit geïmplementeerd' als u nog geen code in uw cluster hebt geïmplementeerd.

    Voeg een Kubernetes-cluster toe.

Een bestaand serviceaccount gebruiken

De Azure Kubernetes Service wijst een Kubernetes-resource in uw omgeving toe aan een naamruimte.

Zie de sectie Kubernetes-serviceverbinding in Serviceverbindingen voor meer informatie over het instellen van een Kubernetes-serviceverbinding buiten een omgeving.

Tip

Gebruik de algemene provider (bestaand serviceaccount) om een Kubernetes-resource toe te wijzen aan een naamruimte vanuit een niet-AKS-cluster.

Een niet-AKS Kubernetes-resource toevoegen

  1. Selecteer op de pagina met omgevingsgegevens de optie Resource toevoegen en kies Kubernetes.

  2. Selecteer Algemene provider (bestaand serviceaccount) voor uw provider.

  3. Voeg de clusternaam en naamruimtewaarden toe.

  4. Voeg de server-URL toe. U kunt de URL ophalen met de volgende opdracht:

    kubectl config view --minify -o 'jsonpath={.clusters[0].cluster.server}'
    
  5. Het geheime object ophalen.

    Kubernetes 1.22+

    Vervang door service-account-name uw accountnaam.

    kubectl get secret -n <namespace>  -o jsonpath='{.items[?(@.metadata.annotations.kubernetes\.io/service-account\.name==\"service-account-name\")]}'
    

    Als u niets krijgt, raadpleegt u Handmatig een API-token met een lange levensduur maken voor een ServiceAccount.

    Kubernetes 1.22 en hieronder:

    1. De geheime naam van het serviceaccount zoeken
    kubectl get serviceAccounts <service-account-name> -n <namespace> -o 'jsonpath={.secrets[*].name}'
    
    1. vervangen door <service-account-secret-name> de waarde in de vorige opdracht in deze opdracht
    kubectl get secret <service-account-secret-name> -n <namespace> -o json
    
  6. Haal het geheime object op met behulp van de uitvoer van de vorige stap.

    kubectl get secret <service-account-secret-name> -n <namespace> -o json
    
  7. Kopieer en plak het geheimobject dat is opgehaald in het JSON-formulier in het veld Geheim.

  8. Selecteer Valideren en maken om de Kubernetes-resource te maken.

Verwijzen naar uw Kubernetes-resources in een pijplijn

Als u Azure Kubernetes Service gebruikt en een YAML-pijplijn bouwt, kunt u de pijplijn het eenvoudigst configureren door een sjabloon te gebruiken. Maak verbinding met uw opslagplaats en selecteer een van de volgende twee Kubernetes Service-opties:

Met de sjablonen kunt u De app controleren instellen zonder dat u helemaal zelf YAML-code hoeft te schrijven of handmatig expliciete rolbindingen hoeft te maken.

Opties voor Kubernetes-sjablonen.

Beoordelings-app instellen

In het volgende voorbeeld wordt de eerste implementatietaak uitgevoerd voor niet-PR-vertakkingen en worden implementaties uitgevoerd op basis van een reguliere Kubernetes-resource onder omgevingen. De tweede taak wordt alleen uitgevoerd voor PULL-vertakkingen en wordt geïmplementeerd op basis van App-resources controleren (naamruimten in Kubernetes-cluster) die op aanvraag zijn gegenereerd. Resources worden gelabeld met 'Controleren' in de resourceweergave van de omgeving. Definieer variabelen die in de pijplijn moeten worden gebruikt. Als u de sjabloon Implementeren in Azure Kubernetes Services gebruikt, worden deze variabelen voor u gedefinieerd.

# Build and push image to Azure Container Registry; Deploy to Azure Kubernetes Service
trigger:
- main

resources:
- repo: self

variables:

  # Container registry service connection established during pipeline creation
  dockerRegistryServiceConnection: '12345' # Docker service connection identifier
  envName: 'myEnv' # name of your environment
  imageRepository: 'name-of-image-repository' # name of image repository
  containerRegistry: 'mycontainer.azurecr.io' # path to container registry
  dockerfilePath: '**/Dockerfile'
  tag: '$(Build.BuildId)'
  imagePullSecret: 'my-app-secret' # image pull secret

  # Agent VM image name
  vmImageName: 'ubuntu-latest'

  # Name of the new namespace being created to deploy the PR changes.
  k8sNamespaceForPR: 'review-app-$(System.PullRequest.PullRequestId)'

stages:
- stage: Build
  displayName: Build stage
  jobs:
  - job: Build
    displayName: Build
    pool:
      vmImage: $(vmImageName)
    steps:
    - task: Docker@2
      displayName: Build and push an image to container registry
      inputs:
        command: buildAndPush
        repository: $(imageRepository)
        dockerfile: $(dockerfilePath)
        containerRegistry: $(dockerRegistryServiceConnection)
        tags: |
          $(tag)

    - upload: manifests
      artifact: manifests

- stage: Production
  displayName: Deploy stage
  dependsOn: Build

  jobs:
  - deployment: Production
    condition: and(succeeded(), not(startsWith(variables['Build.SourceBranch'], 'refs/pull/')))
    displayName: Production
    pool:
      vmImage: $(vmImageName)
    environment: 
      name: $(envName).$(resourceName)
      resourceType: Kubernetes 
    strategy:
      runOnce:
        deploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create imagePullSecret
            inputs:
              action: createSecret
              secretName: $(imagePullSecret)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)

          - task: KubernetesManifest@0
            displayName: Deploy to Kubernetes cluster
            inputs:
              action: deploy
              manifests: |
                $(Pipeline.Workspace)/manifests/deployment.yml
                $(Pipeline.Workspace)/manifests/service.yml
              imagePullSecrets: |
                $(imagePullSecret)
              containers: |
                $(containerRegistry)/$(imageRepository):$(tag)

  - deployment: DeployPullRequest
    displayName: Deploy Pull request
    condition: and(succeeded(), startsWith(variables['Build.SourceBranch'], 'refs/pull/'))
    pool:
      vmImage: $(vmImageName)

    environment: 
      name: $(envName).$(resourceName)
      resourceType: Kubernetes
    strategy:
      runOnce:
        deploy:
          steps:
          - reviewApp: default

          - task: Kubernetes@1
            displayName: 'Create a new namespace for the pull request'
            inputs:
              command: apply
              useConfigurationFile: true
              inline: '{ "kind": "Namespace", "apiVersion": "v1", "metadata": { "name": "$(k8sNamespaceForPR)" }}'

          - task: KubernetesManifest@0
            displayName: Create imagePullSecret
            inputs:
              action: createSecret
              secretName: $(imagePullSecret)
              namespace: $(k8sNamespaceForPR)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)

          - task: KubernetesManifest@0
            displayName: Deploy to the new namespace in the Kubernetes cluster
            inputs:
              action: deploy
              namespace: $(k8sNamespaceForPR)
              manifests: |
                $(Pipeline.Workspace)/manifests/deployment.yml
                $(Pipeline.Workspace)/manifests/service.yml
              imagePullSecrets: |
                $(imagePullSecret)
              containers: |
                $(containerRegistry)/$(imageRepository):$(tag)

          - task: Kubernetes@1
            name: get
            displayName: 'Get services in the new namespace'
            continueOnError: true
            inputs:
              command: get
              namespace: $(k8sNamespaceForPR)
              arguments: svc
              outputFormat: jsonpath='http://{.items[0].status.loadBalancer.ingress[0].ip}:{.items[0].spec.ports[0].port}'

          # Getting the IP of the deployed service and writing it to a variable for posting comment
          - script: |
              url="$(get.KubectlOutput)"
              message="Your review app has been deployed"
              if [ ! -z "$url" -a "$url" != "http://:" ]
              then
                message="${message} and is available at $url.<br><br>[Learn More](https://aka.ms/testwithreviewapps) about how to test and provide feedback for the app."
              fi
              echo "##vso[task.setvariable variable=GITHUB_COMMENT]$message"

Als u deze taak in een bestaande pijplijn wilt gebruiken, moet de serviceverbinding die de reguliere Kubernetes-omgevingsresource back-up biedt, worden gewijzigd in 'Clusterbeheerdersreferenties gebruiken'. Anders moeten rolbindingen worden gemaakt voor het onderliggende serviceaccount in de naamruimte App controleren.

Volgende stappen