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

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: