Ambiente - Risorsa di Kubernetes
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020
La visualizzazione risorse Kubernetes mostra lo stato degli oggetti all'interno dello spazio dei nomi di cui è stato eseguito il mapping alla risorsa. La visualizzazione delle risorse sovrappone anche la tracciabilità della pipeline in modo da poter risalire da un oggetto Kubernetes alla pipeline e quindi tornare al commit.
Usare le risorse Kubernetes per definire come destinazione i cluster Kubernetes in un ambiente per la distribuzione. Usare le pipeline per la distribuzione in servizio Azure Kubernetes (servizio Azure Kubernetes) e cluster da qualsiasi altro provider di servizi cloud.
È possibile usare le risorse Kubernetes con cluster pubblici o privati. Per altre informazioni sul funzionamento delle risorse, vedere risorse in YAML e sicurezza con le risorse.
Nota
Se si usa un cluster del servizio Azure Kubernetes privato, assicurarsi di essere connessi alla rete virtuale del cluster perché l'endpoint del server API non viene esposto tramite un indirizzo IP pubblico.
Azure Pipelines consiglia di configurare un agente self-hosted all'interno di una rete virtuale che abbia accesso alla rete virtuale del cluster. Per informazioni dettagliate, vedere Opzioni per la connessione al cluster privato.
Panoramica
Vedere i vantaggi seguenti dell'uso delle viste delle risorse Kubernetes all'interno degli ambienti:
Tracciabilità della pipeline: l'attività manifesto di Kubernetes, usata per le distribuzioni, aggiunge altre annotazioni per mostrare la tracciabilità della pipeline nelle visualizzazioni delle risorse. La tracciabilità delle pipeline consente di identificare l'organizzazione, il progetto e la pipeline di Azure DevOps di origine responsabili degli aggiornamenti apportati a un oggetto all'interno dello spazio dei nomi.
Diagnosticare l'integrità delle risorse: lo stato del carico di lavoro può essere utile per eseguire rapidamente il debug di errori o regressioni introdotti da una nuova distribuzione. Ad esempio, per imagePullSecrets non configurati che generano errori ImagePullBackOff, le informazioni sullo stato del pod consentono di identificare la causa radice del problema.
Esaminare l'app : esaminare il funzionamento dell'app distribuendo ogni richiesta pull dal repository Git a una risorsa Kubernetes dinamica nell'ambiente. I revisori possono vedere l'aspetto e l'uso di tali modifiche con altri servizi dipendenti prima di essere uniti nel ramo di destinazione e distribuiti nell'ambiente di produzione.
Usare il servizio Azure Kubernetes
Un account di servizio viene creato nel cluster e nello spazio dei nomi scelti quando si usa servizio Azure Kubernetes (servizio Azure Kubernetes). Per un cluster abilitato per il controllo degli accessi in base al ruolo di Kubernetes, RoleBinding viene creato anche per limitare l'ambito dell'account del servizio creato allo spazio dei nomi scelto. Per un cluster con controllo degli accessi in base al ruolo di Kubernetes disabilitato, ServiceAccount creato dispone di privilegi a livello di cluster (tra spazi dei nomi).
Aggiungere una risorsa Kubernetes del servizio Azure Kubernetes
Nella pagina dei dettagli dell'ambiente selezionare Aggiungi risorsa e scegliere Kubernetes.
Selezionare servizio Azure Kubernetes nell'elenco a discesa Provider.
Scegliere la sottoscrizione di Azure, il cluster e lo spazio dei nomi (nuovo/esistente).
Selezionare Convalida e crea per creare la risorsa Kubernetes.
Verificare che venga visualizzato un cluster per l'ambiente in uso. Se il codice non è ancora stato distribuito nel cluster, verrà visualizzato il testo "Mai distribuito".
Usare un account di servizio esistente
Il servizio Azure Kubernetes esegue il mapping di una risorsa Kubernetes all'interno dell'ambiente a uno spazio dei nomi.
Per altre informazioni sulla configurazione di una connessione al servizio Kubernetes all'esterno di un ambiente, vedere la sezione Connessione al servizio Kubernetes in Connessioni al servizio.
Suggerimento
Usare il provider generico (account del servizio esistente) per eseguire il mapping di una risorsa Kubernetes a uno spazio dei nomi da un cluster non del servizio Azure Kubernetes.
Aggiungere una risorsa Kubernetes non del servizio Azure Kubernetes
Nella pagina dei dettagli dell'ambiente selezionare Aggiungi risorsa e scegliere Kubernetes.
Selezionare Provider generico (account del servizio esistente) per il provider.
Aggiungere i valori del nome del cluster e dello spazio dei nomi.
Aggiungere l'URL del server. È possibile ottenere l'URL con il comando seguente:
kubectl config view --minify -o 'jsonpath={.clusters[0].cluster.server}'
Per ottenere l'oggetto segreto.
Kubernetes 1.22+
Sostituire
service-account-name
con il nome dell'account.kubectl get secret -n <namespace> -o jsonpath='{.items[?(@.metadata.annotations.kubernetes\.io/service-account\.name==\"service-account-name\")]}'
Se non si ottiene nulla, vedere Creare manualmente un token API di lunga durata per un Account di servizio.
Kubernetes 1.22 e versioni successive:
- Trovare il nome del segreto dell'account del servizio
kubectl get serviceAccounts <service-account-name> -n <namespace> -o 'jsonpath={.secrets[*].name}'
- sostituire
<service-account-secret-name>
con il valore nel comando precedente in questo comando
kubectl get secret <service-account-secret-name> -n <namespace> -o json
Ottenere l'oggetto segreto usando l'output del passaggio precedente.
kubectl get secret <service-account-secret-name> -n <namespace> -o json
Copiare e incollare l'oggetto Segreto recuperato nel modulo JSON nel campo Segreto.
Selezionare Convalida e crea per creare la risorsa Kubernetes.
Fare riferimento alle risorse Kubernetes in una pipeline
Se si usa servizio Azure Kubernetes e si compila una pipeline YAML, il modo più semplice per configurare la pipeline consiste nell'usare un modello. Connettersi al repository e selezionare una delle due opzioni del servizio Kubernetes seguenti:
- Eseguire la distribuzione nel modello di servizio Azure Kubernetes
- Distribuire in Kubernetes - Esaminare l'app con Azure DevSpaces
I modelli consentono di configurare l'app di revisione senza dover scrivere codice YAML da zero o creare manualmente associazioni di ruolo esplicite.
Configurare l'app di revisione
Nell'esempio seguente il primo processo di distribuzione viene eseguito per rami non pr e esegue distribuzioni in una normale risorsa Kubernetes in ambienti. Il secondo processo viene eseguito solo per i rami della richiesta pull e viene distribuito in Esaminare le risorse dell'app (spazi dei nomi all'interno del cluster Kubernetes) generati su richiesta. Le risorse vengono etichettate con "Rivedi" nella visualizzazione elenco risorse dell'ambiente. Definire le variabili da usare nella pipeline. Se si usa il modello Deploy to servizio Azure Kubernetes s, queste variabili vengono definite automaticamente.
# 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"
Per usare questo processo in una pipeline esistente , la connessione al servizio che esegue il backup della normale risorsa dell'ambiente Kubernetes deve essere modificata in "Usare le credenziali di amministratore del cluster". In caso contrario, le associazioni di ruolo devono essere create per l'account del servizio sottostante allo spazio dei nomi Verifica app.