Che cos'è Kubernetes Server-Side Apply (SSA)?

0
60

Server-Side Apply (SSA) è generalmente disponibile in Kubernetes dal rilascio v1.22 nell'agosto 2021. È una strategia per la gestione dichiarativa delle risorse che migliora i calcoli diff e avvisa in caso di unione conflitti spostando la logica del comando kubectl apply sul server.

Questo articolo spiegherà come funziona SSA e perché è preferibile al precedente approccio CSA (client-side apply). Imparerai anche come abilitare SSA quando apporti modifiche agli oggetti nel tuo cluster.

Comprensione degli aggiornamenti dichiarativi

Il comando kubectl apply esegue aggiornamenti dichiarativi degli oggetti. Invece di istruire Kubernetes a modificare campi specifici, fornisci una rappresentazione completa dell'oggetto così come desideri che appaia. Il sistema calcola automaticamente le differenze rispetto allo stato esistente del tuo cluster. Eseguirà quindi le azioni che trasformano lo stato nello stato desiderato espresso dal file manifest.

Ecco un semplice manifest del pod:

apiVersion: v1 kind: Podmetadata: name: nginx spec: contenitori: – nome: nginx immagine: nginx:latest

L'esecuzione di kubectl apply con questo manifest avvierà un nuovo pod che esegue l'immagine nginx:latest. La differenza tra lo stato esistente del cluster e quello desiderato è evidente: è stato creato un pod, dove prima non ce n'era nessuno con il nome nginx.

Potresti quindi modificare il manifest cambiandone uno delle proprietà del pod:

apiVersion: v1 kind< /strong>: metadatipod: nome: nginx specifiche: contenitori: – nome: nginx immagine : nginx:1.23

Questa volta la differenza tra lo stato esistente e quello desiderato è meno sostanziale. Il comando kubectl apply rileverà il campo immagine rivisto e aggiornerà la configurazione del tuo pod di conseguenza.

I problemi con l'applicazione lato client

La differenziazione delle modifiche e la risoluzione di eventuali conflitti è la parte più importante degli aggiornamenti dichiarativi. Questo processo viene eseguito all'interno di Kubectl per impostazione predefinita. Il client è responsabile dell'identificazione dell'oggetto esistente sul server e del confronto delle sue modifiche.

Il comando kubectl apply scrive un'annotazione dell'ultima configurazione applicata sugli oggetti per facilitare questo processo. Consente l'identificazione dei campi che esistono sull'oggetto attivo ma che sono stati rimossi dal manifesto in entrata. Il client sa quindi che devono essere cancellati dall'oggetto per ottenere il nuovo stato.

Questo approccio è problematico quando ci sono più agenti che aggiornano lo stesso oggetto. Ad esempio, un singolo oggetto potrebbe essere modificato sia da Kubectl che da un controller dedicato nel tuo cluster. L'applicazione lato client non può tenere traccia di quale agente ha modificato un campo, né può capire quando si verifica un conflitto. Confronta semplicemente il tuo manifest locale con l'ultima configurazione applicata dell'oggetto esistente e unisce tutte le modifiche.

Anche l'applicazione lato client è intrinsecamente legata a Kubectl. Gli strumenti di terze parti che desiderano effettuare i propri aggiornamenti dichiarativi devono chiamare Kubectl o ricreare la logica di applicazione da zero. Nessuna di queste due opzioni è particolarmente ideale.

Come funziona l'applicazione lato server

Il problema fondamentale con CSA è che i manifest locali obsoleti non vengono mai rilevati. Se un altro applicatore modifica un oggetto prima di eseguire kubectl apply, le tue vecchie revisioni locali potrebbero sovrascrivere quelle nuove corrette. Con SSA abilitato, il conflitto verrà rilevato e l'aggiornamento verrà bloccato. È un sistema centralizzato che impone che il tuo stato locale sia mantenuto aggiornato.

SSA funziona aggiungendo un meccanismo del piano di controllo che memorizza le informazioni su ciascun campo nei tuoi oggetti. Sostituisce l'annotazione dell'ultima configurazione applicata con un nuovo campo metadata.managedFields. Ogni campo nel tuo oggetto viene tracciato all'interno dei ManagedFields.

Ai campi viene assegnato un “field manager” che identifica il cliente che li possiede. Se applichi un manifest con Kubectl, Kubectl sarà il gestore designato. Il gestore di un campo potrebbe anche essere un controller o un'integrazione esterna che aggiorna i tuoi oggetti.

Ai gestori è vietato aggiornare i rispettivi campi. Ti verrà impedito di modificare un campo con kubectl apply se è attualmente di proprietà di un controller diverso. Sono disponibili tre strategie per risolvere questi conflitti di unione:

  • Forza la sovrascrittura del valore – In alcune situazioni potresti voler forzare l'aggiornamento. Ciò ne modificherà il valore e trasferirà la proprietà al nuovo Field Manager. È destinato principalmente ai controllori che devono mantenere la gestione dei campi che hanno popolato. Puoi forzare manualmente un aggiornamento impostando il flag –force-conflicts in Kubectl.
  • Non sovrascrivere il valore– L'applicatore può rimuovere il campo dalla sua configurazione locale e quindi ripetere la richiesta. Il campo manterrà il suo valore esistente. La rimozione del campo risolve il conflitto cedendo la proprietà al gestore esistente.
  • Condividi la gestione– L'applicatore può aggiornare il suo valore locale in modo che corrisponda al valore esistente sul server. Se ripete la richiesta pur continuando a rivendicare la proprietà, SSA consentirà di condividere la gestione con il gestore esistente. Questo perché l'applicatore accetta lo stato attuale del campo ma ha indicato che potrebbe volerlo gestire in futuro.

Questo approccio è molto più potente della tradizionale applicazione kubectl. Previene le sovrascritture accidentali, consente ai controllori di rivendicare in modo affidabile la proprietà dei campi che controllano ed è completamente dichiarativo. SSA tiene traccia di come diversi utenti hanno modificato i singoli campi, invece di registrare solo l'intero ultimo stato dell'oggetto. Significa anche che ora puoi utilizzare apply all'interno di qualsiasi strumento, indipendentemente dalla lingua o dalla disponibilità del binario kubectl. Otterrai gli stessi risultati coerenti comunque avvii l'operazione.

Utilizzo di SSA oggi

Puoi attivare SSA impostando – -server-side flag ogni volta che esegui Kubectl apply:

$ kubectl apply -f nginx.yaml –server-side pod/nginx serverside-applied

L'output del comando cambia per evidenziare che SSA è stato utilizzato.

L'ispezione del manifest YAML dell'oggetto rivelerà i campi gestiti:

$ kubectl get pod nginx -o yaml apiVersion: v1 kind: Pod metadata: creationTimestamp: “2022-11-24T16:02:29Z” managedFields: – apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:spec: f:containers: k: {“name”:”nginx”}: .: {} f:image: {} f:name: {} manager: kubectl operation: Apply time: “2022-11-24T16:02:29Z” – apiVersion: v1 fieldsType : FieldsV1 fieldsV1: f:status: f:conditions: k:{“type”:”ContainersReady”}: .: {} f:lastProbeTime: {} f:lastTransitionTime: {} f:status: {} f:type: {} k:{“type”:”Initialized”}: .: {} f:lastProbeTime: {} f:lastTransitionTime: {} f:status: {} f:type: {} k:{“type”:” Pronto”}: .: {} f:lastProbeTime: {} f:lastTransitionTime: {} f:status: {} f:type: {} f:containerStatuses: {} f:hostIP: {} f:phase: {} f:podIP: {} f:podIPs: .: {} k:{“ip”:”10.244.0.186″}: .: {} f:ip: {} f:startTime: {} manager: operazione kubelet: aggiornamento sottorisorsa: ora stato: “2022-11-24T16:02:31Z” …

I campi sono raggruppati dal gestore che li possiede. In questo esempio, la specifica è gestita da Kubectl perché è così che è stato creato il pod. Il campo stato è gestito da Kubelet, tuttavia, perché il nodo che esegue il pod modifica il valore di quel campo durante il ciclo di vita del pod.

SSA è anche pronto per l'uso nei controller. Consente una semantica più potente e nuovi tipi di controller, compresi quelli che ricostruiscono gli oggetti. Questo modello gestisce le modifiche ricostruendo da zero i campi di un oggetto in modo soddisfacente per il controller, quindi applicando nuovamente il risultato al server. È un metodo più naturale rispetto allo stabilire manualmente la sequenza di operazioni che produrranno la modifica desiderata.

Controllare se un oggetto è gestito con SSA

Puoi verificare se un oggetto utilizza CSA o SSA recuperando il suo manifest YAML in Kubectl:

$ kubectl get pod nginx -o yaml

Se vedi un'annotazione dell'ultima configurazione applicata, il tuo oggetto è gestito da CSA:

apiVersion: v1 kind: Pod metadati: annotazioni: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"Pod","metadata":{"annotazioni":{},"name":"nginx","namespace": "default"},"spec":{"containers":[{"image":"nginx:latest","name":"nginx"}]}} creazioneTimestamp: "2022-11-24T14:20:07Z" nome: nginx spazio dei nomi: predefinito

SSA è stato utilizzato per l'oggetto se invece viene visualizzato metadata.managedFields:

apiVersion: v1 kind: Pod metadata: creationTimestamp< strong class="sy2">: "2022-11-24T16:02:29Z" ManagedFields: – apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:spec: f:containers: k:{"name":"nginx"}: .: { } f:image: {} f:name: {} gestore: kubectl operazione: Applica tempo: "2022-11-24T16:02:29Z"

Puoi spostare un oggetto tra CSA e SSA semplicemente aggiungendo o omettendo il flag –server-side la prossima volta che esegui kubectl si applica. Kubernetes gestisce la conversione dell'ultima configurazione applicata in ManagedFields e viceversa.

Gli aggiornamenti a SSA possono presentare conflitti se il manifest locale è diverso dall'oggetto sul server. Ciò si verifica quando hai eseguito un comando imperativo come kubectl scale o kubectl label dall'ultima operazione di applicazione sull'oggetto. Dovresti controllare che il tuo manifest locale corrisponda accuratamente all'oggetto live prima di convertirlo in SSA.

Riepilogo

L'applicazione lato server è un approccio alla gestione dichiarativa degli oggetti in cui i campi sono monitorato dal piano di controllo Kubernetes. Ciò facilita un robusto rilevamento dei conflitti e strategie di risoluzione flessibili. SSA risolve i limiti dell'applicazione lato client che consente la sovrascrittura involontaria dei campi senza alcun preavviso.

Sebbene SSA sia ora generalmente disponibile, devi comunque specificarlo manualmente ogni volta che esegui kubectl apply. Vale la pena ricordare che SSA è più utile in situazioni in cui gli oggetti vengono gestiti da diversi processi diversi, come operatori umani con Kubectl e un loop di controller. Non trarrai molti vantaggi da SSA se utilizzi esclusivamente kubectl apply per creare e aggiornare oggetti.

Si prevede che una futura versione di Kubernetes rimuoverà CSA, rendendo SSA l'unica opzione predefinita . Il flag –server-side diventerà quindi ridondante.

READ NEXT

  • › Amazon Luna sta riducendo la sua libreria di giochi
  • › Come spostare una tabella in Google Documenti
  • › Come utilizzare un filtro avanzato in Microsoft Excel
  • › Vivreste in una nuova capanna lunare stampata in 3D?
  • › Linux su Apple Silicon Mac ora è abbastanza buono per i giochi
  • › I nuovi Tiny PC di Zotac sono eccellenti alternative a Mac Mini