Nell'ultima sezione abbiamo terminato il file di configurazione della distribuzione del client e ora siamo pronti a
buttare via la cosa per mantenere Seitel e vederla in esecuzione sul nostro cluster locale.
Ora, prima di farlo, voglio darti un promemoria molto veloce se passi al tuo terminale e fai
un cubo Seitel ottieni i pod.
Ricorderai che abbiamo ancora il pod originale che abbiamo creato con il file di configurazione YAML del
nostro pod client.
Penso che sarebbe davvero bello se ci liberassimo di questo POD o in qualche modo lo eliminassimo prima
di spedire il nostro deployment in questo modo che quando avremo i nostri pod in futuro vedremo solo il pod
creato da quella distribuzione al contrario a un pod dalla distribuzione.
E questo pod dal file di configurazione del pod client originale che avevamo creato.
Quindi voglio capire come possiamo eliminare questo pod esistente per rimuovere un oggetto esistente.
Utilizzeremo il file di configurazione che è stato utilizzato per crearlo.
Quindi, per rimuovere un oggetto esistente, eseguiremo Kube Seitel, elimineremo il trattino F e
passeremo nel file di configurazione che è stato usato per creare quell'oggetto quando abbiamo passato quel file di configurazione.
Seitel esaminerà il file.
Quindi, ecco il file pade del client.
Guarderà questo file.
Sta andando a guardare la proprietà gentile proprio qui e il nome specificato pure.
Cube DTL cercherà quindi di trovare un oggetto con lo stesso tipo con lo stesso nome.
E quando quando lo trova lo cancellerà.
Ora una cosa che voglio menzionare molto rapidamente qui è che questo comando di cancellazione sembra un po
'terribile come un aggiornamento imperativo al nostro cluster.
E infatti è davvero un aggiornamento imperativo.
Stiamo emettendo un comando molto diretto che dice hey Nettie, voglio che tu faccia questo cambiamento molto
discreto allo stato del nostro cluster.
Ora sfortunatamente questo è qualcosa che in realtà non possiamo proprio ignorare quando vogliamo eliminare
creare una risorsa o modificare una risorsa esistente che passiamo in un file di configurazione aggiornato.
E quindi lasciamo alle aziende il compito di apportare le modifiche appropriate.
Ma quando vogliamo eliminare una risorsa Sfortunatamente se volessimo cancellare qualche oggetto all'interno
del nostro cluster avremmo una specie di prendere l'intero stato del nostro intero cluster e poi
come sottrarre quell'unico oggetto.
In altre parole è solo un po 'difficile immaginare un modo per fare un aggiornamento dichiarativo che
cancellerà un oggetto esistente.
E così questo sarà l'unico tipo di luogo in cui ricorreremo all'idea di un aggiornamento
imperativo allo stato del nostro cluster.
OK, facciamo un tentativo.
Quindi torna alla riga di comando o Kube CTO cancella il trattino F e poi specificheremo il pod del client sul file
YAML e poi vedremo che il pod con il nome del client è stato cancellato.
Ora sembra che questo comando appaia appena si risolverà alla fine dopo circa 10 secondi
circa quando il pod viene eliminato sta attraversando lo stesso processo in background che di solito viene
applicato all'eliminazione di un contenitore con i Dockers Seelye.
Ricorda quando cancelli un container o fermi un container, dovrei dire che i contenitori hanno 10 secondi per
essere risolto e poi alla fine viene ucciso.
Questo è ciò che accade nel mondo docker.
E la stessa cosa è cosa succede quando cancelliamo un pod in esecuzione.
Richiede 10 secondi per risolversi e alla fine si spegne e poi dopo quei 10
secondi la cosa viene automaticamente rimossa completamente.
Se ora facciamo un cubo Seitel ottiene Pod, vedremo che non abbiamo più nessun Pott in esecuzione.
OK, così ora abbiamo ripulito un po 'le cose proviamo ad applicare il nostro file di configurazione della posta elettronica di
distribuzione del client al nostro cluster.
Dopo aver applicato questa cosa dovremmo vedere un nuovo pod in esecuzione singolo utilizzando l'immagine multi client.
Così lancio al mio terminale e farò un cubo per vedere T. L. applichiamo dash f distribuzione di dash di Wyant
che verrà visualizzata e quindi vedremo molto rapidamente che la distribuzione è stata creata in modo da poter
stampare lo stato di tutti i nostri pod con cubetti DTL ottenere i pod e vedremo che c'è esattamente un
pod in esecuzione al momento e ha un nome generato a caso molto chiaramente legato alla distribuzione client che abbiamo appena creato.
Possiamo anche stampare lo stato di tale distribuzione utilizzando i cubi di comando DTL per ottenere le distribuzioni.
Quindi stiamo ancora usando il comando Get lo stesso che stavamo usando prima, ma stiamo cambiando il
tipo di oggetto che stiamo cercando.
Quindi ora invece di cercare i pod stiamo cercando implementazioni.
Quindi lo eseguirò e vedremo che abbiamo una distribuzione chiamata Distribuzione client. Noterai anche un paio
di colonne interessanti qui.
Ne abbiamo uno su tutta la linea per la corrente desiderata aggiornata e disponibile desiderato
è un riferimento al numero di repliche o al numero di pod che questa distribuzione vuole eventualmente avere.
Quindi al momento all'interno del nostro file di configurazione abbiamo detto che vogliamo esattamente 1 replica in
esecuzione e quindi ne abbiamo desiderata una.
Vediamo quindi set correnti il numero di pod attivi e in esecuzione.
Abbiamo aggiornato che è anche uno.
Pertanto, in qualsiasi momento in cui si apporta una modifica alla configurazione alla propria implementazione, in particolare una
configurazione modifica il modello qui sotto, la distribuzione contrassegna automaticamente tutti i pod esistenti come
non aggiornati.
E così potremmo vedere aggiornato scendere a zero.
Quindi, man mano che i pod esistenti vengono aggiornati o ricreati con i nuovi stati di
configurazione, alla fine ripristinano questo campo aggiornato.
E poi finalmente disponibile proprio qui è il numero di pod controllati da questa
distribuzione che sono pronti e disponibili per accettare il traffico del cliente in arrivo o essenzialmente solo
con successo i loro contenitori con la configurazione appropriata per ciascuno OK.
Quindi è così.
Quindi ora stiamo vedendo come possiamo usare la distribuzione per creare un set di pod o, in questo caso,
un solo pod.
Ora l'ultima cosa che voglio fare è ANCORA assicurarci che siamo in grado di visitare la nostra applicazione
in esecuzione all'interno del browser.
Quindi vogliamo essere sicuri che questo pod qui sia effettivamente in esecuzione con successo l'immagine multi client.
E voglio assicurarmi che possiamo ancora accedere ai nostri file di progetto di reazione.
Facciamo una pausa veloce proprio qui.
Torneremo alla prossima sezione e ci assicureremo di poter accedere a questo POD o a questo contenitore nel
nostro browser nella prossima sezione.