‫Lascia che ti parli di piste asciutte e diff, che
‫sono cose nuove.
‫Le ultime versioni di Kubernetes che iniziano con 1. 13 hanno
‫questa nuova opzione che ci consente di
‫vedere cosa cambieremo prima di cambiarlo.
‫L'abbiamo visto prima.
‫Ti ho mostrato un paio di esempi all'inizio del corso.
‫Ma questo metodo di utilizzo con
‫il comando apply è nuovo
‫e migliore. Quello che avevamo in
‫passato era che avevamo una corsa a secco, ma era
‫solo sul client. Il client non ha effettivamente
‫parlato con il server per dire ehi, queste risorse sono già lì?
‫Devo ricrearli o verranno aggiornati o cosa
‫accadrà? Giusto.
‫Non è successo prima.
‫Ora c'è un'opzione di funzionamento a secco
‫del server che invierà il nostro YAML al server
‫e lo confronterà, scoprirà cosa deve realmente accadere
‫e quindi riporterà alla riga di comando
‫cosa cambierà. Vediamolo in azione.
‫Sono nella directory YAML di K8 come ho discusso in precedenza
‫in una lezione, se sei nel repository di Docker Mastery e non
‫hai questa directory, allora devi
‫fare un git-pull per ottenere gli ultimi aggiornamenti.
‫Questo è un file che abbiamo visto in
‫una lezione precedente, app. yml. Questo è un servizio,
‫oltre a una distribuzione, in un file.
‫Tecnicamente sono state create due risorse con
‫un comando apply e sono correlate.
‫Il servizio utilizza un selettore, di cui
‫non abbiamo ancora parlato. I selettori indicano come un
‫oggetto trova le risorse con cui vuole parlare o
‫fare qualcosa.
‫Un servizio deve parlare con i pod, quindi deve trovare
‫un modo per raggiungerli.
‫Utilizza i selettori come essenzialmente pattern matching
‫per abbinare le etichette le chiavi e
‫i valori lì. Se eseguissi la tradizionale
‫corsa a secco qui, tutto ciò che farebbe sarebbe che il client
‫guardasse l'applicazione e dicesse, sì, creerò questi oggetti.
‫Tutto ok. Tornerà sempre e dirà creato.
‫Questo perché l'applicazione non è
‫molto specifica. Se stavi utilizzando un aggiornamento, un
‫comando create o un comando di eliminazione, che di nuovo
‫non mi sembra un flusso di lavoro basato su DevOps.
‫Quei comandi farebbero solo un giro secco e sai
‫che l'aggiornamento uno direbbe sì,
‫entrambi verranno aggiornati. Ma non lo sa davvero sul
‫tuo cluster, giusto. Non ha parlato con il server per capirlo.
‫Vogliamo provare il funzionamento a secco del server che è abilitato
‫di default su qualsiasi cosa 1. 13 e più recenti.
‫Quando lo faccio, andrà a parlare con il server e mi
‫darà una risposta adeguata.
‫Andiamo avanti e creiamo questo.
‫Ho intenzione di togliere il funzionamento a secco del server.
‫Ciò creerà le due risorse, la distribuzione e
‫il servizio.
‫Ora, se premo la freccia su e torno al server
‫dry run, vedrai che dice invariato per entrambi.
‫Non mi sta dicendo cosa è cambiato o se
‫c'era qualcosa che avrebbe cambiato quello
‫che sarebbe stato. Mi sta solo dicendo che
‫una risorsa verrà cambiata o non cambiata. È una specie di interruttore, sì o no.
‫Che ne dici di ottenere la differenza effettiva tra ciò che
‫vogliamo dare al server e quale sia lo
‫stato attuale delle nostre risorse.
‫Questo è il comando diff kubectl.
‫Se gli do semplicemente un diff invece
‫di applicare, confronterò lo YAML che ho
‫con le specifiche che sono nei server attualmente
‫in esecuzione. quello stato ritorna e farà una
‫differenza su quello. Facciamolo.
‫Non dirà nulla perché non c'è differenza.
‫Ma cosa succede se andiamo a cambiare lo YAML?
‫Cosa succede se cambio le repliche in due?
‫Quindi aggiungo un'etichetta nei metadati e gli darò qualcosa
‫come ... qualcosa di simile a.
‫Server dmz.
‫L'ho inventato. Non importa davvero.
‫Quindi abbiamo le repliche di due.
‫Se faccio lo stesso diff, torna con i vantaggi e
‫gli svantaggi.
‫Se sei abituato a leggere le differenze, questo
‫ha perfettamente senso per te. Se non sei abituato a diff, il
‫segno negativo significa che la linea andrebbe via.
‫Quindi verranno aggiunte queste righe.
‫Poi quaggiù, ti mostra quale linea e quale
‫personaggio nella linea che viene
‫rimosso.
‫Questo è stato aggiunto.
‫Mantiene la formattazione YAML, il che è carino.
‫Ci sta facendo sapere che stanno avvenendo molteplici cambiamenti.
‫Grande. Ovviamente, questo non sta realmente facendo
‫qualcosa come un canarino, o test di distribuzione o altro.
‫Non sta cercando di fare la cosa e poi vedere
‫qual è il risultato. Sta davvero solo guardando le
‫specifiche che ha registrato e le specifiche che abbiamo sul
‫nostro disco. Controlla maggiori
‫informazioni a riguardo sui link delle risorse.
‫È un articolo di blog del team Kubernetes
‫sul futuro di questi e su come giocheranno quando
‫usciranno dalla beta. Ricorda, queste funzioni in questo momento sono
‫beta, almeno in 1. 15 lo sono.
‫Speriamo che con questo, puoi creare il tuo flusso
‫di lavoro per creare YAML da
‫zero, Gestire le specifiche in tali YAML e quindi utilizzare ripetutamente
‫il comando apply per apportare le modifiche.
‫È un'infrastruttura molto più compatibile con DevOps come tipo
‫di codice per farlo.
‫Tutto ciò che fai è documentato, si spera in Git.
‫Quindi, si spera che stiate eseguendo un commit git per ogni modifica
‫apportata nel vostro YAML prima di distribuirlo sul server.
‫Quindi hai quella bella documentazione in Git, così come la
‫documentazione quando fai qualcosa come un diff per vedere cosa
‫hai contro ciò che è effettivamente in esecuzione.