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.
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.
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
Selecteer op de pagina met omgevingsgegevens de optie Resource toevoegen en kies Kubernetes.
Selecteer Azure Kubernetes Service in de vervolgkeuzelijst Provider.
Kies het Azure-abonnement, het cluster en de naamruimte (nieuw/bestaand).
Selecteer Valideren en maken om de Kubernetes-resource te maken.
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.
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
Selecteer op de pagina met omgevingsgegevens de optie Resource toevoegen en kies Kubernetes.
Selecteer Algemene provider (bestaand serviceaccount) voor uw provider.
Voeg de clusternaam en naamruimtewaarden toe.
Voeg de server-URL toe. U kunt de URL ophalen met de volgende opdracht:
kubectl config view --minify -o 'jsonpath={.clusters[0].cluster.server}'
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:
- De geheime naam van het serviceaccount zoeken
kubectl get serviceAccounts <service-account-name> -n <namespace> -o 'jsonpath={.secrets[*].name}'
- 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
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
Kopieer en plak het geheimobject dat is opgehaald in het JSON-formulier in het veld Geheim.
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:
- Implementeren in Azure Kubernetes Services-sjabloon
- Implementeren in Kubernetes - App beoordelen met Azure DevSpaces
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.
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.