Attività del manifesto Kubernetes

Azure DevOps Services

Usare un'attività manifesto Kubernetes in una pipeline di compilazione o di rilascio per bake e distribuire manifesti nei cluster Kubernetes.

Panoramica

L'elenco seguente illustra i vantaggi principali di questa attività:

  • Sostituzione dell'artefatto: l'azione di distribuzione accetta come input un elenco di immagini del contenitore che è possibile specificare insieme ai relativi tag e digest. Lo stesso input viene sostituito nei file manifesto non semplificati prima dell'applicazione al cluster. Questa sostituzione garantisce che i nodi del cluster esercitino il pull della versione corretta dell'immagine.

  • Stabilità del manifesto: lo stato di implementazione degli oggetti Kubernetes distribuiti è selezionato. I controlli di stabilità vengono incorporati per determinare se lo stato dell'attività è un esito positivo o negativo.

  • Annotazioni di tracciabilità: le annotazioni vengono aggiunte agli oggetti Kubernetes distribuiti per sovrapporre le informazioni di tracciabilità. Sono supportate le annotazioni seguenti:

    • azure-pipelines/org
    • azure-pipelines/project
    • azure-pipelines/pipeline
    • azure-pipelines/pipelineId
    • azure-pipelines/execution
    • azure-pipelines/executionuri
    • azure-pipelines/jobName
  • Gestione dei segreti: l'azione createSecret consente di creare segreti del Registro di sistema Docker usando connessioni al servizio registro Docker. Consente anche di creare segreti generici usando variabili di testo normale o variabili segrete. Prima della distribuzione nel cluster, è possibile usare l'input dei segreti insieme all'azione deploy per aumentare i file manifesto di input con il valore imagePullSecrets appropriato.

  • Bake manifest(Manifesto bake ): l'azione bake dell'attività consente di aggiungere modelli ai file manifesto di Kubernetes. L'azione usa strumenti come Helm, Compose e kustomize. Con il baking, questi file manifesto Kubernetes sono utilizzabili per le distribuzioni nel cluster.

  • Strategia di distribuzione: la scelta della strategia canary con l'azione di distribuzione comporta la creazione di carichi di lavoro con nomi con suffisso "-baseline" e "-canary". L'attività supporta due metodi di suddivisione del traffico:

    • Interfaccia mesh di servizio: l'astrazione SMI ( Service Mesh Interface ) consente la configurazione con provider di mesh di servizi come Linkerd e Istio. L'attività Manifesto Kubernetes esegue il mapping degli oggetti SMI TrafficSplit ai servizi stabili, di base e canary durante il ciclo di vita della strategia di distribuzione.

      Le distribuzioni canary basate su una mesh di servizio e che usano questa attività sono più accurate. Questa accuratezza è data dal fatto che i provider di mesh di servizi abilitano la suddivisione granulare in base alla percentuale del traffico. La mesh del servizio usa il registro dei servizi e i contenitori sidecar che vengono inseriti nei pod. Questo inserimento viene eseguito insieme ai contenitori dell'applicazione per ottenere la suddivisione granulare del traffico.

    • Kubernetes senza mesh di servizio: in assenza di una mesh di servizio, potrebbe non essere possibile ottenere la suddivisione esatta della percentuale desiderata a livello di richiesta. È tuttavia possibile eseguire distribuzioni canary usando varianti di base e canary accanto alla variante stabile.

      Il servizio invia richieste ai pod di tutte e tre le varianti del carico di lavoro quando vengono soddisfatti i vincoli di etichetta del selettore. Il manifesto kubernetes rispetta queste richieste durante la creazione di varianti di base e canary. Questo comportamento di routing ottiene l'effetto previsto di instradare solo una parte delle richieste totali al canary.

    Confrontare i carichi di lavoro di base e canary usando un'attività Intervento manuale nelle pipeline di versione o un'attività Ritardo nelle pipeline YAML. Eseguire il confronto prima di usare l'azione alza di livello o rifiuta dell'attività.

Azione di distribuzione

Parametro Descrizione
action
Azione
(Obbligatorio)

deploy
kubernetesServiceConnection
Connessione al servizio Kubernetes
(Obbligatorio a meno che l'attività non venga usata in un ambiente Kubernetes)

Nome della connessione al servizio Kubernetes.
Namespace
Spazio dei nomi
(Obbligatorio a meno che l'attività non venga usata in un ambiente Kubernetes)

Spazio dei nomi all'interno del cluster in cui eseguire la distribuzione.
Manifesti
Manifesti
(Obbligatorio)

Percorso dei file manifesto da usare per la distribuzione. Ogni riga rappresenta un singolo percorso. Un criterio di corrispondenza file è un valore accettabile per ogni riga.
Contenitori
Contenitori
Facoltativa

URL completo dell'immagine da usare per le sostituzioni nei file manifesto. Questo input accetta la specifica di più sostituzioni di elementi in formato separato da nuova riga. Ecco un esempio:

containers: |
  contosodemo.azurecr.io/foo:test1
  contosodemo.azurecr.io/bar:test2

In questo esempio tutti i riferimenti a contosodemo.azurecr.io/foo e contosodemo.azurecr.io/bar vengono cercati nel campo image dei file manifesto di input. Per ogni corrispondenza trovata, il tag test1 o test2 sostituisce il riferimento corrispondente.
imagePullSecrets
L'immagine estrae i segreti
Facoltativa

Input su più righe in cui ogni riga contiene il nome di un segreto del Registro di sistema Docker già configurato all'interno del cluster. Ogni nome segreto viene aggiunto in imagePullSecrets per i carichi di lavoro che si trovano nei file manifesto di input.
Strategia
Strategia
Facoltativa

Strategia di distribuzione usata durante l'applicazione dei file manifesto nel cluster. Canary è attualmente l'unica strategia di distribuzione accettabile.
trafficSplitMethod
Metodo di suddivisione del traffico
Facoltativa

I valori accettabili sono pode smi. Il valore predefinito è pod.

Per il valore smi, la suddivisione percentuale del traffico viene eseguita a livello di richiesta usando una mesh di servizio. Una mesh di servizio deve essere impostata da un amministratore del cluster. Questa attività gestisce l'orchestrazione degli oggetti SMI TrafficSplit .

Per il pod di valori, la suddivisione della percentuale non è possibile a livello di richiesta in assenza di una mesh di servizio. L'input percentuale viene invece usato per calcolare le repliche per baseline e canary. Il calcolo è una percentuale di repliche specificate nei manifesti di input per la variante stabile.
Percentuale
Percentuale
(Obbligatorio solo se la strategia è impostata su canary)

Percentuale utilizzata per calcolare il numero di repliche baseline-variant e canary-variant dei carichi di lavoro contenuti nei file manifesto.

Per l'input percentuale specificato, calcolare:

(percentualenumberofreplicas ) / 100

Se il risultato non è un numero intero, il piano matematico del risultato viene usato quando vengono create varianti di base e canary.

Si supponga, ad esempio, che la distribuzione hello-world si trova nel file manifesto di input e che nell'input dell'attività siano presenti le righe seguenti:

replicas: 4
strategy: canary
percentage: 25

In questo caso, le distribuzioni hello-world-baseline e hello-world-canary vengono create con una replica ciascuna. La variante di base viene creata con la stessa immagine e lo stesso tag della versione stabile, ovvero la variante a quattro repliche prima della distribuzione. La variante canary viene creata con l'immagine e il tag corrispondenti alle modifiche appena distribuite.
baselineAndCanaryReplicas
Repliche di base e canary
(Facoltativo e rilevante solo se trafficSplitMethod è impostato su smi)

Quando si imposta trafficSplitMethod su smi, la suddivisione percentuale del traffico viene controllata nel piano della mesh di servizi. È tuttavia possibile controllare il numero effettivo di repliche per le varianti canary e baseline indipendentemente dalla suddivisione del traffico.

Si supponga, ad esempio, che il manifesto della distribuzione di input specifichi 30 repliche per la variante stabile. Si supponga inoltre di specificare l'input seguente per l'attività:

strategy: canary
trafficSplitMethod: smi
percentage: 20
baselineAndCanaryReplicas: 1

In questo caso, la variante stabile riceve l'80% del traffico, mentre le varianti di base e canary ricevono ogni metà del 20% specificato. Tuttavia, le varianti di base e canary non ricevono tre repliche ognuna. Ricevono invece il numero specificato di repliche, ovvero ognuna riceve una replica.
rolloutStatusTimeout
Timeout per lo stato di implementazione
Facoltativa

Tempo di attesa (in secondi) prima di terminare l'esecuzione dell'orologio sullo stato di implementazione. Il valore predefinito è 0 (non attendere).

Il codice YAML seguente è un esempio di distribuzione in uno spazio dei nomi Kubernetes tramite file manifesto:

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

Nell'esempio precedente l'attività tenta di trovare corrispondenze per le foo/demo immagini e bar/demo nei campi immagine dei file manifesto. Per ogni corrispondenza trovata, il valore di tagVariable1 o tagVariable2 viene aggiunto come tag al nome dell'immagine. È anche possibile specificare digest nell'input dei contenitori per la sostituzione degli artefatti.

Nota

Anche se è possibile creare azioni di distribuzione, innalzamento di livello e rifiuto con l'input YAML correlato alla strategia di distribuzione, il supporto per un'attività di intervento manuale non è attualmente disponibile per le pipeline di compilazione.

Per le pipeline di versione, si consiglia di usare azioni e input correlati alla strategia di distribuzione nella sequenza seguente:

  1. Azione di distribuzione specificata con e strategy: canarypercentage: $(someValue).
  2. Un'attività Intervento manuale che consente di sospendere la pipeline e confrontare la variante di base con la variante canary.
  3. Azione di innalzamento di livello che viene eseguita se viene ripresa un'attività di intervento manuale e un'azione di rifiuto che viene eseguita se un'attività di intervento manuale viene rifiutata.

Alzare di livello e rifiutare le azioni

Parametro Descrizione
action
Azione
(Obbligatorio)

alzare di livello o rifiutare
kubernetesServiceConnection
Connessione al servizio Kubernetes
(Obbligatorio)

Nome della connessione al servizio Kubernetes.
Namespace
Spazio dei nomi
(Obbligatorio)

Spazio dei nomi all'interno del cluster in cui eseguire la distribuzione.
Manifesti
Manifesti
(Obbligatorio)

Percorso dei file manifesto da usare per la distribuzione. Ogni riga rappresenta un singolo percorso. Un criterio di corrispondenza file è un valore accettabile per ogni riga.
Contenitori
Contenitori
Facoltativa

URL completo della risorsa dell'immagine da usare per le sostituzioni nei file manifesto. L'URL contosodemo.azurecr.io/helloworld:test è un esempio.
imagePullSecrets
Segreti di pull delle immagini
Facoltativa

Input su più righe in cui ogni riga contiene il nome di un segreto del registro Docker già configurato all'interno del cluster. Ogni nome segreto viene aggiunto nel campo imagePullSecrets per i carichi di lavoro trovati nei file manifesto di input.
Strategia
Strategia
Facoltativa

Strategia di distribuzione usata nell'azione di distribuzione prima di un'azione di innalzamento di livello o di rifiuto. Canary è attualmente l'unica strategia di distribuzione accettabile.

Creare un'azione segreta

Parametro Descrizione
action
Azione
(Obbligatorio)

createSecret
secretType
Tipo di segreto
(Obbligatorio)

I valori accettabili sono dockerRegistry e generici. Il valore predefinito è dockerRegistry.

Se si imposta secretType su dockerRegistry, il campo imagePullSecrets viene creato o aggiornato in un cluster per consentire il pull dell'immagine da un registro contenitori privato.
secretName
Nome segreto
(Obbligatorio)

Nome del segreto da creare o aggiornare.
dockerRegistryEndpoint
Connessione al servizio registro Docker
(Obbligatorio solo se secretType è impostato su dockerRegistry)

Le credenziali della connessione al servizio specificata vengono usate per creare un segreto del registro Docker all'interno del cluster. I file manifesto nel campo imagePullSecrets possono quindi fare riferimento al nome di questo segreto.
secretArguments
Argomenti del segreto
(Obbligatorio solo se secretType è impostato su generico)

Accetta chiavi e valori letterali da usare per la creazione e l'aggiornamento dei segreti. Ecco un esempio:
--from-literal=key1=value1--from-literal=key2="top secret"
kubernetesServiceConnection
Connessione al servizio Kubernetes
(Obbligatorio)

Nome della connessione al servizio Kubernetes.
Namespace
Spazio dei nomi
(Obbligatorio)

Spazio dei nomi del cluster in cui creare un segreto.

Il codice YAML seguente illustra una creazione di esempio di segreti del registro Docker usando la connessione al servizio Registro Docker:

steps:
- task: KubernetesManifest@0
  displayName: Create secret
  inputs: 
    action: createSecret
    secretType: dockerRegistry
    secretName: foobar
    dockerRegistryEndpoint: demoACR
    kubernetesServiceConnection: someK8sSC
    namespace: default

Questo codice YAML mostra un esempio di creazione di segreti generici:

steps:
- task: KubernetesManifest@0
  displayName: Create secret
  inputs: 
    action: createSecret
    secretType: generic
    secretName: some-secret
    secretArguments: --from-literal=key1=value1
    kubernetesServiceConnection: someK8sSC
    namespace: default

Azione bake

Parametro Descrizione
action
Azione
(Obbligatorio)

Cuocere
renderType
Motore di rendering
(Obbligatorio)

Tipo di rendering usato per produrre i file manifesto.

I valori accettabili
,
e kustomize. Il valore predefinito è helm2.
HelmChart
Chart Helm
(Obbligatorio solo se renderType è impostato su helm2)

Percorso del grafico Helm usato per il baking.
overrideFiles
Eseguire l'override dei file
(Facoltativo e rilevante solo se renderType è impostato su helm2)

Input su più righe che accetta il percorso dei file di override. I file vengono usati quando si esegue il bake dei file manifesto dei grafici Helm.
Esegue l' override
Eseguire l'override dei valori
(Facoltativo e rilevante solo se renderType è impostato su helm2)

Valori di override aggiuntivi usati tramite l'opzione della riga di comando --set quando si esegue il bake dei file manifesto che usano Helm.

Specificare i valori di override come coppie chiave-valore nel formato key:value. Se si usano più coppie chiave-valore di override, specificare ogni coppia chiave-valore in una riga separata. Usare un carattere di nuova riga come delimitatore tra coppie chiave-valore diverse.
releaseName
Nome del rilascio
(Facoltativo e rilevante solo se renderType è impostato su helm2)

Nome della versione usata durante il bake dei grafici Helm.
kustomizationPath
Percorso di kustomization
(Facoltativo e rilevante solo se renderType è impostato su kustomize)

Percorso della directory contenente il file kustomization.yaml.
dockerComposeFile
Percorso del file Docker Compose
(Facoltativo e rilevante solo se renderType è impostato su kompose)

Percorso del file Docker Compose.

Il codice YAML seguente è un esempio di bake dei file manifesto dai grafici Helm. Si noti l'utilizzo dell'input del nome nella prima attività. In seguito viene fatto riferimento a questo nome dal passaggio di distribuzione per specificare il percorso dei manifesti prodotti dal passaggio bake.

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

Azione di ridimensionamento

Parametro Descrizione
action
Azione
(Obbligatorio)

scale
gentile
Tipo
(Obbligatorio)

Tipo di oggetto Kubernetes da ridimensionare. Ad esempio, ReplicaSet e StatefulSet.
nome
Nome
(Obbligatorio)

Nome dell'oggetto Kubernetes da ridimensionare.
Repliche
Numero di repliche
(Obbligatorio)

Numero di repliche a cui eseguire la scalabilità.
kubernetesServiceConnection
Connessione al servizio Kubernetes
(Obbligatorio)

Nome della connessione al servizio Kubernetes.
Namespace
Spazio dei nomi
(Obbligatorio)

Spazio dei nomi all'interno del cluster in cui eseguire la distribuzione.
rolloutStatusTimeout
Timeout per lo stato di implementazione
Facoltativa

Tempo di attesa (in secondi) prima di terminare l'esecuzione dell'orologio sullo stato di implementazione. Il valore predefinito è 0 (non attendere).

Il codice YAML seguente mostra un esempio di ridimensionamento degli oggetti:

steps:
- task: KubernetesManifest@0
  displayName: Scale
  inputs: 
    action: scale
    kind: deployment
    name: bootcamp-demo
    replicas: 5
    kubernetesServiceConnection: someK8sSC
    namespace: default

Azione patch

Parametro Descrizione
action
Azione
(Obbligatorio)

benda
resourceToPatch
Risorsa a cui applicare la patch
(Obbligatorio)

Indica uno dei metodi patch seguenti:
  • Un file manifesto identifica gli oggetti a cui applicare la patch.
  • Un singolo oggetto viene identificato in base al tipo e al nome come destinazione della patch.
I valori accettabili sono file e name. Il valore predefinito è file.
resourceFiletoPatch
Percorso del file
(Obbligatorio solo se l'azione è impostata su patche resourceToPatch è impostato su file)

Percorso del file utilizzato per la patch.
gentile
Tipo
(Obbligatorio solo se resourceToPatch è impostato sul nome)

Tipo dell'oggetto Kubernetes. Ad esempio, ReplicaSet e StatefulSet.
nome
Nome
(Obbligatorio solo se resourceToPatch è impostato sul nome)

Nome dell'oggetto Kubernetes a cui applicare la patch.
mergeStrategy
Strategia di unione
(Obbligatorio)

Strategia da usare per l'applicazione della patch.

I valori accettabili
,
e strategici. Il valore predefinito è strategico.
benda
Patch
(Obbligatorio)

Contenuto della patch.
kubernetesServiceConnection
Connessione al servizio Kubernetes
(Obbligatorio)

Nome della connessione al servizio Kubernetes.
Namespace
Spazio dei nomi
(Obbligatorio)

Spazio dei nomi all'interno del cluster in cui eseguire la distribuzione.
rolloutStatusTimeout
Timeout per lo stato di implementazione
Facoltativa

Tempo di attesa (in secondi) prima di terminare l'esecuzione dell'orologio sullo stato di implementazione. Il valore predefinito è 0 (non attendere).

Il codice YAML seguente mostra un esempio di applicazione di patch per gli oggetti:

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

Elimina azione

Parametro Descrizione
action
Azione
(Obbligatorio)

delete
Argomenti
Argomenti
(Obbligatorio)

Argomenti da passare a kubectl per l'eliminazione degli oggetti necessari. Di seguito è riportato un esempio:
arguments: deployment hello-world foo-bar
kubernetesServiceConnection
Connessione al servizio Kubernetes
(Obbligatorio)

Nome della connessione al servizio Kubernetes.
Namespace
Spazio dei nomi
(Obbligatorio)

Spazio dei nomi all'interno del cluster in cui eseguire la distribuzione.

Questo codice YAML mostra un esempio di eliminazione di oggetti:

steps:
- task: KubernetesManifest@0
  displayName: Delete
  inputs:
    action: delete
    arguments: deployment expressapp
    kubernetesServiceConnection: someK8sSC
    namespace: default

Risoluzione dei problemi

Il cluster Kubernetes si trova dietro un firewall e si stanno usando gli agenti ospitati. Come si esegue la distribuzione in questo cluster?

È possibile concedere l'accesso agli agenti ospitati tramite il firewall, consentendo gli indirizzi IP per gli agenti ospitati. Per informazioni dettagliate, vedere Intervalli IP degli agenti

Open source

Questa attività viene open source in GitHub. Commenti e suggerimenti e contributi sono benvenuti.