1
00:00:00,580 --> 00:00:05,220
Nell'ultima sezione abbiamo terminato il file di configurazione della distribuzione del client e ora siamo pronti a

2
00:00:05,220 --> 00:00:09,680
buttare via la cosa per mantenere Seitel e vederla in esecuzione sul nostro cluster locale.

3
00:00:09,690 --> 00:00:14,550
Ora, prima di farlo, voglio darti un promemoria molto veloce se passi al tuo terminale e fai

4
00:00:14,550 --> 00:00:16,500
un cubo Seitel ottieni i pod.

5
00:00:16,500 --> 00:00:22,200
Ricorderai che abbiamo ancora il pod originale che abbiamo creato con il file di configurazione YAML del

6
00:00:22,200 --> 00:00:23,260
nostro pod client.

7
00:00:23,310 --> 00:00:29,100
Penso che sarebbe davvero bello se ci liberassimo di questo POD o in qualche modo lo eliminassimo prima

8
00:00:29,100 --> 00:00:35,160
di spedire il nostro deployment in questo modo che quando avremo i nostri pod in futuro vedremo solo il pod

9
00:00:35,160 --> 00:00:38,740
creato da quella distribuzione al contrario a un pod dalla distribuzione.

10
00:00:38,790 --> 00:00:43,760
E questo pod dal file di configurazione del pod client originale che avevamo creato.

11
00:00:43,800 --> 00:00:49,400
Quindi voglio capire come possiamo eliminare questo pod esistente per rimuovere un oggetto esistente.

12
00:00:49,470 --> 00:00:53,860
Utilizzeremo il file di configurazione che è stato utilizzato per crearlo.

13
00:00:53,880 --> 00:01:00,030
Quindi, per rimuovere un oggetto esistente, eseguiremo Kube Seitel, elimineremo il trattino F e

14
00:01:00,030 --> 00:01:07,820
passeremo nel file di configurazione che è stato usato per creare quell'oggetto quando abbiamo passato quel file di configurazione.

15
00:01:07,900 --> 00:01:11,050
Seitel esaminerà il file.

16
00:01:11,060 --> 00:01:12,500
Quindi, ecco il file pade del client.

17
00:01:12,530 --> 00:01:13,780
Guarderà questo file.

18
00:01:13,910 --> 00:01:18,600
Sta andando a guardare la proprietà gentile proprio qui e il nome specificato pure.

19
00:01:18,740 --> 00:01:24,020
Cube DTL cercherà quindi di trovare un oggetto con lo stesso tipo con lo stesso nome.

20
00:01:24,110 --> 00:01:27,350
E quando quando lo trova lo cancellerà.

21
00:01:27,350 --> 00:01:32,840
Ora una cosa che voglio menzionare molto rapidamente qui è che questo comando di cancellazione sembra un po

22
00:01:32,930 --> 00:01:35,510
'terribile come un aggiornamento imperativo al nostro cluster.

23
00:01:35,630 --> 00:01:39,210
E infatti è davvero un aggiornamento imperativo.

24
00:01:39,260 --> 00:01:45,470
Stiamo emettendo un comando molto diretto che dice hey Nettie, voglio che tu faccia questo cambiamento molto

25
00:01:45,530 --> 00:01:48,040
discreto allo stato del nostro cluster.

26
00:01:48,110 --> 00:01:52,970
Ora sfortunatamente questo è qualcosa che in realtà non possiamo proprio ignorare quando vogliamo eliminare

27
00:01:53,000 --> 00:01:58,160
creare una risorsa o modificare una risorsa esistente che passiamo in un file di configurazione aggiornato.

28
00:01:58,220 --> 00:02:01,910
E quindi lasciamo alle aziende il compito di apportare le modifiche appropriate.

29
00:02:02,210 --> 00:02:07,190
Ma quando vogliamo eliminare una risorsa Sfortunatamente se volessimo cancellare qualche oggetto all'interno

30
00:02:07,190 --> 00:02:12,950
del nostro cluster avremmo una specie di prendere l'intero stato del nostro intero cluster e poi

31
00:02:12,950 --> 00:02:14,630
come sottrarre quell'unico oggetto.

32
00:02:14,630 --> 00:02:19,850
In altre parole è solo un po 'difficile immaginare un modo per fare un aggiornamento dichiarativo che

33
00:02:19,880 --> 00:02:21,260
cancellerà un oggetto esistente.

34
00:02:21,290 --> 00:02:26,410
E così questo sarà l'unico tipo di luogo in cui ricorreremo all'idea di un aggiornamento

35
00:02:26,450 --> 00:02:28,510
imperativo allo stato del nostro cluster.

36
00:02:28,570 --> 00:02:29,750
OK, facciamo un tentativo.

37
00:02:30,740 --> 00:02:38,660
Quindi torna alla riga di comando o Kube CTO cancella il trattino F e poi specificheremo il pod del client sul file

38
00:02:38,800 --> 00:02:44,690
YAML e poi vedremo che il pod con il nome del client è stato cancellato.

39
00:02:45,490 --> 00:02:50,830
Ora sembra che questo comando appaia appena si risolverà alla fine dopo circa 10 secondi

40
00:02:50,830 --> 00:02:56,710
circa quando il pod viene eliminato sta attraversando lo stesso processo in background che di solito viene

41
00:02:56,710 --> 00:03:00,220
applicato all'eliminazione di un contenitore con i Dockers Seelye.

42
00:03:00,400 --> 00:03:05,560
Ricorda quando cancelli un container o fermi un container, dovrei dire che i contenitori hanno 10 secondi per

43
00:03:05,560 --> 00:03:08,000
essere risolto e poi alla fine viene ucciso.

44
00:03:08,050 --> 00:03:09,860
Questo è ciò che accade nel mondo docker.

45
00:03:10,000 --> 00:03:13,090
E la stessa cosa è cosa succede quando cancelliamo un pod in esecuzione.

46
00:03:13,230 --> 00:03:18,220
Richiede 10 secondi per risolversi e alla fine si spegne e poi dopo quei 10

47
00:03:18,310 --> 00:03:20,670
secondi la cosa viene automaticamente rimossa completamente.

48
00:03:21,580 --> 00:03:28,300
Se ora facciamo un cubo Seitel ottiene Pod, vedremo che non abbiamo più nessun Pott in esecuzione.

49
00:03:28,460 --> 00:03:34,260
OK, così ora abbiamo ripulito un po 'le cose proviamo ad applicare il nostro file di configurazione della posta elettronica di

50
00:03:34,430 --> 00:03:36,320
distribuzione del client al nostro cluster.

51
00:03:36,320 --> 00:03:43,040
Dopo aver applicato questa cosa dovremmo vedere un nuovo pod in esecuzione singolo utilizzando l'immagine multi client.

52
00:03:43,040 --> 00:03:51,530
Così lancio al mio terminale e farò un cubo per vedere T. L. applichiamo dash f distribuzione di dash di Wyant

53
00:03:53,810 --> 00:03:59,210
che verrà visualizzata e quindi vedremo molto rapidamente che la distribuzione è stata creata in modo da poter

54
00:03:59,210 --> 00:04:05,270
stampare lo stato di tutti i nostri pod con cubetti DTL ottenere i pod e vedremo che c'è esattamente un

55
00:04:05,320 --> 00:04:11,960
pod in esecuzione al momento e ha un nome generato a caso molto chiaramente legato alla distribuzione client che abbiamo appena creato.

56
00:04:11,960 --> 00:04:19,100
Possiamo anche stampare lo stato di tale distribuzione utilizzando i cubi di comando DTL per ottenere le distribuzioni.

57
00:04:19,100 --> 00:04:23,990
Quindi stiamo ancora usando il comando Get lo stesso che stavamo usando prima, ma stiamo cambiando il

58
00:04:24,050 --> 00:04:26,000
tipo di oggetto che stiamo cercando.

59
00:04:26,000 --> 00:04:30,180
Quindi ora invece di cercare i pod stiamo cercando implementazioni.

60
00:04:30,580 --> 00:04:38,030
Quindi lo eseguirò e vedremo che abbiamo una distribuzione chiamata Distribuzione client. Noterai anche un paio

61
00:04:38,030 --> 00:04:40,270
di colonne interessanti qui.

62
00:04:40,310 --> 00:04:46,340
Ne abbiamo uno su tutta la linea per la corrente desiderata aggiornata e disponibile desiderato

63
00:04:46,340 --> 00:04:52,920
è un riferimento al numero di repliche o al numero di pod che questa distribuzione vuole eventualmente avere.

64
00:04:52,920 --> 00:04:58,370
Quindi al momento all'interno del nostro file di configurazione abbiamo detto che vogliamo esattamente 1 replica in

65
00:04:58,370 --> 00:05:01,050
esecuzione e quindi ne abbiamo desiderata una.

66
00:05:01,160 --> 00:05:04,480
Vediamo quindi set correnti il numero di pod attivi e in esecuzione.

67
00:05:04,820 --> 00:05:07,290
Abbiamo aggiornato che è anche uno.

68
00:05:07,310 --> 00:05:14,210
Pertanto, in qualsiasi momento in cui si apporta una modifica alla configurazione alla propria implementazione, in particolare una

69
00:05:14,210 --> 00:05:20,300
configurazione modifica il modello qui sotto, la distribuzione contrassegna automaticamente tutti i pod esistenti come

70
00:05:20,510 --> 00:05:21,630
non aggiornati.

71
00:05:21,800 --> 00:05:24,430
E così potremmo vedere aggiornato scendere a zero.

72
00:05:24,500 --> 00:05:30,290
Quindi, man mano che i pod esistenti vengono aggiornati o ricreati con i nuovi stati di

73
00:05:30,380 --> 00:05:32,960
configurazione, alla fine ripristinano questo campo aggiornato.

74
00:05:33,200 --> 00:05:37,850
E poi finalmente disponibile proprio qui è il numero di pod controllati da questa

75
00:05:37,880 --> 00:05:43,220
distribuzione che sono pronti e disponibili per accettare il traffico del cliente in arrivo o essenzialmente solo

76
00:05:43,370 --> 00:05:47,600
con successo i loro contenitori con la configurazione appropriata per ciascuno OK.

77
00:05:47,610 --> 00:05:48,810
Quindi è così.

78
00:05:48,810 --> 00:05:54,780
Quindi ora stiamo vedendo come possiamo usare la distribuzione per creare un set di pod o, in questo caso,

79
00:05:54,780 --> 00:05:55,800
un solo pod.

80
00:05:55,830 --> 00:06:00,990
Ora l'ultima cosa che voglio fare è ANCORA assicurarci che siamo in grado di visitare la nostra applicazione

81
00:06:01,020 --> 00:06:02,550
in esecuzione all'interno del browser.

82
00:06:02,850 --> 00:06:09,250
Quindi vogliamo essere sicuri che questo pod qui sia effettivamente in esecuzione con successo l'immagine multi client.

83
00:06:09,310 --> 00:06:13,100
E voglio assicurarmi che possiamo ancora accedere ai nostri file di progetto di reazione.

84
00:06:13,340 --> 00:06:14,660
Facciamo una pausa veloce proprio qui.

85
00:06:14,670 --> 00:06:19,380
Torneremo alla prossima sezione e ci assicureremo di poter accedere a questo POD o a questo contenitore nel

86
00:06:19,530 --> 00:06:21,000
nostro browser nella prossima sezione.