Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Azure Kubernetes Service (AKS) spiegato: piano di controllo, nodi, rete, sicurezza e costi (Doppiaggio IA)

Transcript

Azure Kubernetes Service (AKS) spiegato: piano di controllo, nodi, rete, sicurezza e costi (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Speaker 2: Avrei sentito parlare di Kubernetes e HS nelle conversazioni sul cloud.
0:03
Speaker 2: Forse è annuito, ma onestamente cosa significano davvero per chi
0:06
Speaker 2: esegue applicazioni nel cloud? I container hanno cambiato il modo
0:10
Speaker 2: in cui creiamo software perché sono leggeri, portatili e coerenti.
0:13
Speaker 2: Il problema è che gestire manualmente diventa presto un caos.
0:16
Speaker 2: Gestire una manciata di container è semplice, ma con decine
0:19
Speaker 2: o centinaia passi tutto il tempo a scalare, aggiornare e
0:21
Speaker 2: risolvere guasti invece di sviluppare il tuo prodotto. Alla fine
0:25
Speaker 2: di questo episodio capirai i quattro aspetti principali gestiti da
0:28
Speaker 2: Azure Kubernetes Service, il piano di controllo, i nodi, la rete,
0:31
Speaker 2: la sicurezza. Analizzeremo anche quanto costa realmente. Nessun linguaggio di marketing,
0:36
Speaker 2: solo concetti chiari. Il problema dei container, perché abbiamo bisogno
0:39
Speaker 2: di account. I container si sono diffusi perché risolvono un
0:41
Speaker 2: problema reale. Un pacchetto che raggruppa il codice dell'applicazione, le
0:44
Speaker 2: librerie di runtime e la configurazione. Funziona allo stesso modo
0:47
Speaker 2: sul tuo laptop, su un server di test o in produzione?
0:50
Speaker 2: Addio ai problemi del sul mio computer funziona. Eseguire pochi
0:53
Speaker 2: container funziona bene. Li avvii manualmente, controlli i log, li
0:57
Speaker 2: riavvii quando vanno in crash. Ma quando ne hai decine
1:00
Speaker 2: o centinaia distribuiti su più server incontri una serie di
1:03
Speaker 2: nuovi problemi. Devi decidere dove va ogni container, quale server
1:06
Speaker 2: riceve quale container e come si trovano sulla rete. Cosa
1:10
Speaker 2: succede quando uno si blocca alle 3 del mattino? E
1:12
Speaker 2: come gestire un picco di traffico che richiede 50 copie
1:14
Speaker 2: in più della tua app in 30 secondi? Kubernetes è
1:17
Speaker 2: una piattaforma open source progettata esattamente per questi problemi. Pianifica
1:21
Speaker 2: i container sui server, li scala e ne verifica lo
1:23
Speaker 2: stato e in strada il traffico tra loro È lo
1:26
Speaker 2: standard del settore per l'orchestrazione dei container. Ma Kubernetes risolve
1:29
Speaker 2: un problema e ne crea un altro. Gestirlo da soli
1:32
Speaker 2: è complesso. Devi configurare e mantenere il piano di controllo,
1:35
Speaker 2: il cervello del cluster, gestire i nodi worker, applicare patch
1:37
Speaker 2: di sicurezza, aggiornare le versioni e salvare i dati di
1:39
Speaker 2: configurazione e salvare i dati di configurazione. È un lavoro
1:42
Speaker 2: a tempo pieno per chi sa il fatto suo. I
1:44
Speaker 2: servizi gestiti come Azure Kubernetes Service ti tolgono questo peso
1:47
Speaker 2: operativo dalle spalle. Microsoft gestisce il piano di controllo per
1:51
Speaker 2: te e si occupa di aggiornamenti, patch e backup. Tu
1:52
Speaker 2: ti concentri sulle tue applicazioni. Quindi cosa fa esattamente AKS
1:56
Speaker 2: per te? Iniziamo dalla parte più importante, il piano di controllo.
1:59
Speaker 2: Cos'è Azure Kubernetes Service? AKS è la versione gestita di
2:03
Speaker 2: Kubernetes offerta da Microsoft, semplice e chiaro. Ottieni un cluster
2:06
Speaker 2: Kubernetes pienamente funzionale senza dover configurare o mantenere l'infrastruttura sottostante.
2:11
Speaker 2: Microsoft gestisce il piano di controllo per te così puoi
2:13
Speaker 2: concentrarti sul deploy e sull'esecuzione delle tue applicazioni. Immaginalo come
2:16
Speaker 2: affittare un appartamento invece di costruire una casa. Quando costruisci
2:19
Speaker 2: una casa sei responsabile di tutto, fondamenta, idraulica, impianto elettrico, tetto.
2:22
Speaker 2: Quando sei in affitto, il proprietario si occupa di tutto questo.
2:24
Speaker 2: Tu devi solo trasferirti e arredare. AHS è il proprietario
2:26
Speaker 2: di casa. Microsoft gestisce le fondamenta, il piano di controllo,
2:29
Speaker 2: la rete, le patch di sicurezza e gli aggiornamenti. Tu
2:32
Speaker 2: porti l'arredamento, le tue applicazioni containerizzate, le configurazioni e le
2:34
Speaker 2: pipeline di deployment. Tuttavia, AHS non è solo un cluster
2:37
Speaker 2: Kubernetes isolato. Lavora in stretta integrazione con il resto delle piattaforme.
2:41
Speaker 2: N3D gestisce l'autenticazione degli utenti e il controllo degli accessi.
2:44
Speaker 2: Azure Monitor raccoglie log e metriche dal tuo cluster e
2:46
Speaker 2: dalle tue applicazioni. Azure Policy ti consente di imporre regole
2:49
Speaker 2: su tutti i tuoi cluster, come vietare container eseguiti come
2:52
Speaker 2: root o richiedere che le immagini provengano da un registro approvato.
2:55
Speaker 2: È questo che rende HS qualcosa di più di un
2:57
Speaker 2: semplice Kubernetes su macchine virtuali e Azure. Ovviamente devi comunque
3:01
Speaker 2: conoscere i concetti basi di Kubernetes, pod, deployment e servizi.
3:05
Speaker 2: Questa è la competenza che porti lui. HS non sostituisce
3:07
Speaker 2: questo aspetto, ma ciò che elimina è il carico operativo
3:09
Speaker 2: necessario per mantenere il cluster in salute. Non devi preoccuparti
3:12
Speaker 2: che il piano di controllo vada offline. Non devi aggiornare
3:14
Speaker 2: malmente le versioni di Kubernetes. Non devi eseguire il backup
3:16
Speaker 2: di etcd in database di configurazione del cluster. Microsoft gestisce tutto.
3:20
Speaker 2: Quindi solleviamo il sipare su quel cervello il piano di controllo.
3:23
Speaker 2: Il piano di controllo è il cervello gestito da Microsoft.
3:25
Speaker 2: Cosa c'è esattamente all'interno di questo piano di controllo? Quattro
3:27
Speaker 2: componenti principali. L'API server è la porta d'ingresso. Ogni comando
3:31
Speaker 2: richiesta interazione con il tuo cluster passa da lì. Lo
3:34
Speaker 2: scheduler decide su quale nodo eseguire ogni nuovo pod. Il
3:37
Speaker 2: controller manager monitora lo stato del cluster e assicura che
3:39
Speaker 2: la realtà corrisponda a ciò che è richiesto. Ed etcd
3:42
Speaker 2: memorizza tutti i dati di configurazione. Immaginalo come la memoria
3:44
Speaker 2: del tuo cluster. Se etcd viene danneggiato o perso, hai
3:47
Speaker 2: perso il cluster. Se configuri Kubernetes da solo, sei responsabile
3:51
Speaker 2: di tutto questo. Devi applicare patch all'API server quando appaiono vulnerabili.
3:54
Speaker 2: Devi eseguire regolarmente il backup di etcd. Devi gestire i
3:56
Speaker 2: guasti ADU sulle macchine che eseguono questi componenti. È un
3:58
Speaker 2: lavoro impegnativo. Con HS, Microsoft ti solleva da quest'one. Gestiscono
4:02
Speaker 2: il piano di controllo sulla propria infrastruttura. Lo aggiornano, fanno
4:05
Speaker 2: il backup e lo monitorano. Non vedrai mai le macchine sottostanti.
4:07
Speaker 2: Interagisci solo con l'endpoint dell'API server e tutto il resto
4:10
Speaker 2: avviene dietro le quinte. Tuttavia, non tutti i piani di
4:13
Speaker 2: controllo sono vulnerabili. HS offre tre livelli, free, standard e premium.
4:17
Speaker 2: Il livello gratuito ti offre il piano di controllo senza
4:19
Speaker 2: costi aggiuntivi, senza SLA sul server API. Va bene per l'apprendimento,
4:23
Speaker 2: lo sviluppo o ambienti di test dove pochi minuti di
4:25
Speaker 2: inattività non creano problemi, ma per i carichi di lavoro
4:27
Speaker 2: in produzione probabilmente vorrà di più. Il livello standard costa
4:30
Speaker 2: circa 72 dollari al mese per cluster. Ti offre un
4:33
Speaker 2: SLA del 99,95% sul server API quando utilizzi le zone
4:36
Speaker 2: di disponibilità. Se il piano di controllo si interrompe, Microsoft
4:40
Speaker 2: riconosce un credito. È la scelta predefinita per la maggior
4:42
Speaker 2: parte di cluster. Il livello premium costa circa 432 dollari
4:46
Speaker 2: al mese. Ottieni tutto ciò che è incluso nello standard
4:48
Speaker 2: più il supporto a lungo termine per le versioni. Se
4:50
Speaker 2: esegui un carico di lavoro regolamentato, che deve rimanere su
4:53
Speaker 2: una versione specifica per mesi o anni, ecco dove il
4:55
Speaker 2: premium ha senso. Ecco il punto chiave però. In realtà
4:58
Speaker 2: non paghi per il piano di controllo stesso. Il livello
5:01
Speaker 2: gratuito è veramente gratuito. Standard e premium sono tariffe per
5:04
Speaker 2: l'SLA e il supporto a lungo termine, non per le
5:05
Speaker 2: risorse del piano di controllo. Ciò per cui paghi sono
5:08
Speaker 2: i nodi di lavoro, le VM che eseguono i tuoi contenuti.
5:10
Speaker 2: Questi vengono fatturati separatamente alle tariffe standard delle vie mediate.
5:13
Speaker 2: Pesare in questo modo. Il piano di controllo è il cervello.
5:16
Speaker 2: Microsoft lo gestisce per te. Tu scegli il livello di
5:18
Speaker 2: servizio in base alle tue esigenze di affidabilità. Al vero
5:20
Speaker 2: lavoro di esecuzione delle tue applicazioni avviene sui nodi di lavoro.
5:23
Speaker 2: Quei nodi di lavoro sono dove le tue applicazioni vengono
5:25
Speaker 2: effettivamente eseguite. Parliamo di loro. I nodi lavoratori per cui paghi.
5:29
Speaker 2: I nodi sono macchine virtuali Azure, semplice e chiaro. VM
5:32
Speaker 2: Azure standard che ospitano i tuoi pod, che sono l'unità
5:34
Speaker 2: più piccola in Kubernetes che esegue uno o più container.
5:37
Speaker 2: Tu scegli la dimensione e il numero. Quindi se vuoi
5:39
Speaker 2: una D2SM3VO3 con 2 VCPU e 8GB di RAM puoi farlo.
5:44
Speaker 2: Ti serve una i32 ottimizzata per la memoria con 32
5:46
Speaker 2: VCPU e 256GB che questo funziona. Ora non metti semplicemente
5:50
Speaker 2: insieme VM a caso. HES li organizza in pool di nodi.
5:54
Speaker 2: Un pool di nodi è un gruppo di VM identiche
5:56
Speaker 2: con la stessa dimensione e configurazione. Puoi avere più pool
5:59
Speaker 2: di nodi in un singolo cluster. Un pool con VM
6:01
Speaker 2: di serie D per uso generico per il tuo front- end web,
6:03
Speaker 2: un altro con VM di serie E ottimizzate per la
6:05
Speaker 2: memoria per il tuo database e un terzo con VM
6:07
Speaker 2: abilitate per GPU per carichi di lavoro di machine learning.
6:09
Speaker 2: Ogni pool viene ridimensionato in modo indipendente. Tale dimensionamento è automatico.
6:12
Speaker 2: L'autoscaler del cluster monitora i tuoi podi. Quando hanno bisogno
6:15
Speaker 2: di più risorse di quelle che i nodi attuali possono fornire,
6:17
Speaker 2: aggiunge nuovi nodi. E quando il traffico diminuisce e i
6:20
Speaker 2: carichi rimangono per il più inattivi, li rimuove. Tu imposti
6:22
Speaker 2: la dimensione minima e massima per ogni pool e AKS
6:24
Speaker 2: gestisce il resto. È qui che si risparmiano soldi veri.
6:27
Speaker 2: Non paghi per la capacità inutilizzata nelle ore di bassa
6:29
Speaker 2: attività Gli aggiornamenti dei nodi sono un'altra cosa gestita da HSE.
6:33
Speaker 2: Quando esce una nuova patch di sicurezza per il sistema operativo,
6:35
Speaker 2: HSE può applicarla ai tuoi nodi e quando viene rilasciata
6:38
Speaker 2: una nuova versione di Kubernetes, HSE può aggiornare il tuo cluster.
6:40
Speaker 2: Tu controlli la pianificazione. Decidi tu quando avvengono gli aggiornamenti,
6:43
Speaker 2: non Microsoft. Il lavoro effettivo di drenaggio dei pod, aggiornamento
6:46
Speaker 2: dei nodi e ripristino online è gestito per te. Vorrei costi.
6:50
Speaker 2: Paghi le tariffe standard delle VM azzure per i tuoi nodi.
6:53
Speaker 2: Una D2SW3 negli Stati Uniti Orientali costa circa 70$ al mese,
6:56
Speaker 2: una VM più grande costa di poco. Tuttavia ci sono
6:59
Speaker 2: modi per ridurre significativamente tale spesa. Le istanze riservate ti
7:02
Speaker 2: permettono di impegnarti per 1-3 anni in cambio di uno sconto,
7:04
Speaker 2: risparmiando fino al 72% rispetto al pay as you go.
7:07
Speaker 2: Se conosci la tua capacità di base, ovvero i nodi
7:09
Speaker 2: che devono essere sempre attivi, riservarli ha molto senso. Le
7:12
Speaker 2: VM spots sono ancora più economiche, fino al 90% o
7:14
Speaker 2: meno rispetto alle tariffe pay as you go, ma c'è
7:16
Speaker 2: un limite. Azure può reclamare tale capacità in qualsiasi momento,
7:20
Speaker 2: dando ai tuoi nodi 30 secondi di preavviso prima dell'edizione.
7:23
Speaker 2: Va bene per lavori batch, pipeline CICD o carichi di
7:25
Speaker 2: lavoro stateless che tollerano interruzioni, ma non per le tue
7:28
Speaker 2: epi di produzione rivolte ai clienti. Quindi paghi per i worker,
7:32
Speaker 2: scegli dimensione, numero e modello di prezzo, mentre Aks gestisce pool,
7:35
Speaker 2: scalabilità e aggiornamenti. I tuoi nodi e pod devono comunicare
7:39
Speaker 2: tra loro. Ed è qui che entra in gioco il networking. Networking,
7:42
Speaker 2: ovvero come comunicano i pod. Ogni pod nel tuo cluster
7:45
Speaker 2: necessita di un indirizzo IP, ma i pod vanno e
7:47
Speaker 2: vengono costantemente. Si arrestano, scalano, vengono sostituiti. Quindi serve un
7:51
Speaker 2: sistema che assegni IP dinamicamente e garantisca che i pod
7:53
Speaker 2: possano raggiungersi. Esattamente ciò che fa la container network interface.
7:57
Speaker 2: Azure CNI e l'implementazione di Microsoft gestisce come i pod
8:00
Speaker 2: ottengono gli indirizzi e come il traffico fluisce tra loro.
8:03
Speaker 2: Esistono due modelli di networking principali tra cui scegliere. Il
8:05
Speaker 2: networking overlay assegna i pod IP da un intervallo separato
8:08
Speaker 2: a non parte della tua rete virtuale. Questa è l'opzione
8:11
Speaker 2: più scalabile. Puoi avere fino a 5.000 nodi e un
8:14
Speaker 2: quarto di milione di pod in un singolo cluster. Poiché
8:16
Speaker 2: gli IP dei pod sono isolati dalla VNet, puoi riutilizzare
8:19
Speaker 2: lo stesso spazio di indirizzi su più cluster senza conflitti.
8:22
Speaker 2: Il compromesso è che i pod non sono accessibili direttamente
8:25
Speaker 2: dall'esterno del cluster. Il traffico in uscita da un pod
8:27
Speaker 2: viene tradotto nell'indirizzo IP del nodo. Altra opzione è Networking Flat,
8:31
Speaker 2: in cui i pod ottengono IP direttamente dall'intervallo della tua VNet.
8:34
Speaker 2: I sistemi esterni possono raggiungere direttamente i pod, se necessario,
8:37
Speaker 2: ma lo svantaggio è che si consumano indirizzi IP della
8:39
Speaker 2: propria VNet che possono esaurirsi rapidamente se si hanno molti pod.
8:43
Speaker 2: È necessario pianificare con attenzione i della subnet? Ora parliamo
8:45
Speaker 2: del traffico in uscita dal cluster. Quando un pod deve
8:48
Speaker 2: raggiungere qualcosa su internet, un'API esterno, un database o un
8:51
Speaker 2: servizio di terze parti, quel traffico deve passare da qualche parte.
8:54
Speaker 2: Per impostazione predefinita, KS utilizza un bilanciatore di carico ZOO
8:57
Speaker 2: per le connessioni in uscita, che funziona bene per la
8:58
Speaker 2: maggior parte dei carichi di load. Tuttavia, se le tue
9:00
Speaker 2: applicazioni effettuano molte connessioni in uscita, potresti riscontrare il cosiddetto
9:03
Speaker 2: esaurimento delle porte SNAT. Ogni nodo riceve un numero fisso
9:06
Speaker 2: di parte di traduzione degli indirizzi di rete di origine,
9:09
Speaker 2: e quando si esauriscono, le nuove connessioni falliscono. La soluzione
9:12
Speaker 2: è Azure NAT Gateway, che gestisce molto meglio un numero
9:14
Speaker 2: elevato di connessioni. Per esporre le applicazioni a Internet esistono
9:18
Speaker 2: due approcci principali. Per le applicazioni che comunicano tramite TCP
9:21
Speaker 2: o UDP come server di gioco, database o protocolli personalizzati,
9:24
Speaker 2: si utilizza un servizio di bilanciamento del carico, fornisce alla
9:27
Speaker 2: tua app un IP pubblico e inoltre il traffico a
9:29
Speaker 2: livello 4. Per le applicazioni web che utilizzano HTTPS o
9:32
Speaker 2: HTTPS è preferibile un controller ingresso. Questo lavora a livello 7,
9:36
Speaker 2: comprende URL, percorsi e nomi host. Puoi instradare il traffico
9:39
Speaker 2: verso diversi servizi in base al nome di dominio o
9:41
Speaker 2: al percorso URL e un singolo IP pubblico può servire
9:44
Speaker 2: decine di applicazioni. AKS supporta opzioni di ingresso gestite come
9:48
Speaker 2: l'application Gateway per container oppure puoi gestire una tua come Nginx.
9:52
Speaker 2: Un errore comune che si commette spesso è creare un
9:53
Speaker 2: cluster AKS con una subnet troppo piccola, magari una subnet 0.108
9:57
Speaker 2: per un totale di 16p. Funziona per un piccolo cluster
10:00
Speaker 2: di test ma HHS riserve IP per ogni nodo un
10:02
Speaker 2: cluster a 3 nodi con un AM728 potrebbe andare bene
10:05
Speaker 2: oggi ma al mese prossimo aggiungi un pool di nodi
10:06
Speaker 2: il traffico aumenta e non puoi più scalare e non
10:08
Speaker 2: è possibile modificare il CDR della subnet una volta creato
10:11
Speaker 2: il cluster dovresti ricostruire il cluster o creare un nuovo
10:14
Speaker 2: pool di nodi su una subnet diversa e migrare i
10:16
Speaker 2: tuoi carichi di lavoro pianifica le dimensioni delle subnet per
10:19
Speaker 2: la crescita fino a giorno Una volta che la tua
10:21
Speaker 2: app è attiva e raggiungibile, devi proteggerla. Sicurezza. Chi può accedere? Quindi,
10:25
Speaker 2: come funziona davvero la sicurezza in Akais? Immaginalo come un
10:28
Speaker 2: edificio con diversi livelli di protezione. Il primo livello è
10:30
Speaker 2: l'identità e l'accesso. Chi può varcare la soglia? Colleghi il
10:33
Speaker 2: tuo cluster a EntryD, che è il servizio di identità
10:36
Speaker 2: di Microsoft. In precedenza era chiamato Azure Active Directory. Il
10:40
Speaker 2: tuo team accede utilizzando le normali credenziali di lavoro, senza
10:43
Speaker 2: bisogno di account separati. Poi, sopra questo, aggiungi l'airbag di Kubernetes,
10:45
Speaker 2: ovvero il controllo degli accessi basato sui ruoli. Questo decide
10:48
Speaker 2: chi può vedere cosa, chi può distribuire i pod e
10:50
Speaker 2: chi può eliminare le risorse. Uno sviluppatore potrebbe avere accesso
10:53
Speaker 2: solo al proprio namespace, mentre un operatore ha accesso in
10:55
Speaker 2: lettura all'intero cluster e un amministratore ha il controllo completo.
10:59
Speaker 2: Puoi mappare i gruppi e entra direttamente sui ruoli Kubernetes,
11:02
Speaker 2: così quando qualcuno entra o esce dal team a giorni
11:03
Speaker 2: il gruppo entra e i permessi si adattano automaticamente. È
11:06
Speaker 2: come la reception che gestisce gli accessi per l'intero edificio.
11:09
Speaker 2: La sicurezza di rete è il secondo livello. Per impostazione predefinita,
11:12
Speaker 2: il server API del tuo cluster AKI- S è accessibile tramite
11:14
Speaker 2: internet pubblico e, sebbene sia possibile limitarlo a specifici intervalli IP,
11:17
Speaker 2: l'endpoint è esposto. Per i carichi di lavoro in produzione
11:20
Speaker 2: ti servirà invece un cluster privato. In questo modo, il
11:23
Speaker 2: server API ottiene un IP interno dalla tua VNet, accessibile
11:25
Speaker 2: solo tramite Azure Private Link, senza alcuna esposizione pubblica. Chiunque
11:29
Speaker 2: gestisca il cluster deve essere connesso alla tua rete tramite VPN,
11:32
Speaker 2: ExpressRoute o una jumpbox all'interno della VNet. Passiamo ora alla
11:35
Speaker 2: sicurezza dei pod, dove si verificano la maggior parte delle
11:37
Speaker 2: vulnerabilità dei container. Regola numero 1. Non eseguire i container
11:40
Speaker 2: come root. Se un container viene eseguito come root, un
11:42
Speaker 2: attaccante riesce a entrare e ottiene l'accesso root sull'host. Lo
11:45
Speaker 2: stesso vale per l'escalation dei privilegi, disabilità. Usa Azure Policy
11:48
Speaker 2: per Kubernetes per imporre queste regole automaticamente. Puoi stabilire che
11:52
Speaker 2: nessun container in questo namespace possa girare come root. La
11:54
Speaker 2: policy bloccherà ogni distribuzione che viola tale regola prima ancora
11:57
Speaker 2: che raggiunga un nodo. I segreti sono il prossimo aspetto cruciale.
12:00
Speaker 2: Non memorizzare mai password, chiavi API o stringhe di connessione
12:02
Speaker 2: nel tuo codice, nel tuo codice o nelle immagini del container.
12:05
Speaker 2: Succede continuamente che la gente inserisce una password del database
12:08
Speaker 2: in un file di configurazione. Crea l'immagine, la invia a
12:10
Speaker 2: un registro e quella password resta lì per sempre. Chiunque
12:14
Speaker 2: abbia accesso al registro può estrarla. Usa invece Azure Key Vault.
12:17
Speaker 2: Memorizza i tuoi segreti lì e consenti ai tuoi pod
12:19
Speaker 2: di accedervi tramite il driver CSI Secret Store. Il pod
12:22
Speaker 2: monta il segreto come volume variabile d'ambiente in fase di
12:24
Speaker 2: esecuzione e il segreto non tocca mai la tua immagine
12:26
Speaker 2: o il codice sorgente. Infine, monitoraggio. Microsoft Defender for Containers
12:31
Speaker 2: analizza le immagini dei tuoi container alla ricerca di vulnerabilità
12:33
Speaker 2: note e monitora i cluster per attività sospette. tentativi di
12:36
Speaker 2: escalation dei privilegi, connessioni di rete insolite o carichi di
12:39
Speaker 2: crypto mining. Non è uno strumento da configurare e dimenticare,
12:42
Speaker 2: ma rileva cose che potresti non notare da solo. Anche
12:44
Speaker 2: con tutto questo le cose possono andare storte. Quindi diamo
12:47
Speaker 2: un'occhiata agli insidi più comuni. Insidi comuni, cosa va storte?
12:50
Speaker 2: Cosa mette più spiegato alle persone? Analizziamo i soliti sospetti.
12:53
Speaker 2: Per prima cosa i limiti di quota di azienda. Il
12:55
Speaker 2: tuo abbonamento a Azure ha dei limiti sul numero di
12:57
Speaker 2: vcpu utilizzabili in una determinata regione. Lo stesso vale per
12:59
Speaker 2: i più pubblici, bilanciatori di carico e altre risorse. Quando
13:03
Speaker 2: cluster HS questo consuma parte di tale quota. Se raggiunge
13:06
Speaker 2: il limite, la creazione del cluster fallisce o la scalabilità
13:08
Speaker 2: smette di funzionare. La soluzione è semplice, richiede un aumento
13:11
Speaker 2: della quota tramite il portale di Azure. Ma fallo prima
13:14
Speaker 2: di averne bisogno, non quando un deployment è bloccato alle
13:16
Speaker 2: 2 metri. Il passo successivo è il dimensionamento della subnet,
13:18
Speaker 2: che è critico perché non può essere corretto in seguito.
13:21
Speaker 2: HS riserva indirizzi IP per nodo e ogni nodo necessita
13:24
Speaker 2: di un certo numero di IP per i pod. Se
13:26
Speaker 2: la tua subnet è troppo piccola finirai gli indirizzi e
13:28
Speaker 2: non potrai espandere la subnet dopo la creazione del cluster.
13:30
Speaker 2: Pianifica la crescita. Se pensi di aver bisogno di 10
13:34
Speaker 2: nodi oggi, predisponi abbastanza IP per 50. Una subnet 3.1.4
13:37
Speaker 2: ti offre 250 nodi più utilizzabili, il che è un
13:39
Speaker 2: buon punto di partenza per la maggior parte dei cluster.
13:41
Speaker 2: Image pullback off è probabilmente l'errore dei pod più comune
13:44
Speaker 2: che vedrai. Il tuo pod prova a scaricare un'immagine container,
13:47
Speaker 2: ma fallisce. Di solito è un problema di autenticazione. Il
13:50
Speaker 2: tuo cluster non riesce ad accedere al registro di contatto.
13:52
Speaker 2: Forse stai usando un registro privato senza credenziali o le
13:54
Speaker 2: credenziali sono scadute. Controlla i tuoi image pull secrets, assicurati
13:57
Speaker 2: che l'account di servizio abbia accesso al registro e verifica
14:00
Speaker 2: che il nome dell'immagine sia corretto. Raramente si tratta di
14:02
Speaker 2: un bug di Kubernetes. Crash loop back off è un
14:04
Speaker 2: altro errore frequente. Il tuo pod si avvia, gira per
14:06
Speaker 2: pochi secondi, va in crash, si riavvia e va di
14:07
Speaker 2: nuovo in crash. L'istinto naturale è dare la colpa a Kubernetes,
14:10
Speaker 2: ma non fa. 9 volte su 10 è colpa della
14:13
Speaker 2: tua applicazione una variabile d'ambiente mal configurata, una dipendenza mancante,
14:16
Speaker 2: una stringa di connessione al database che punta al server sbagliato.
14:19
Speaker 2: Controlla i log del pod con kubectl logs. Il messaggio
14:21
Speaker 2: di errore di solito è proprio lì. E poi c'è
14:23
Speaker 2: l'esaurimento delle connessioni in uscita. Le tue applicazioni effettuano molte
14:26
Speaker 2: connessioni verso servizi esterni, api, database e strumenti di terze parti.
14:30
Speaker 2: Ogni connessione usa una porta SNAT e ogni nodo ha
14:33
Speaker 2: un numero limitato di tali porte. Quando finiscono le nuove
14:36
Speaker 2: connessioni falliscono silenziosamente. La tua app sembra integra ma non
14:39
Speaker 2: riesce a raggiungere nulla al di fuori del cluster. La
14:41
Speaker 2: soluzione è passare ad Azure NAT Gateway che gestisce un
14:43
Speaker 2: elevato numero di connessioni molto meglio del bilanciatore di carico
14:46
Speaker 2: predefinito oppure usare dimensioni dei nodi maggiori che offrono più
14:48
Speaker 2: porte SNAT per node. Tutti questi elementi hanno un prezzo
14:50
Speaker 2: quindi vediamo cosa pagherai effettivamente. Costi e prezzi. Dunque quanto
14:55
Speaker 2: costa realmente HS? Facciamo chiarezza. La parte principale della fattura
14:58
Speaker 2: deriva dalle VM dei nodi worker. Calcolo archiviazione, rete. È
15:02
Speaker 2: lì che finisce la maggior parte del denaro. Un nodo
15:03
Speaker 2: D2SB3 nell'area East US costa circa 70 dollari al mese.
15:06
Speaker 2: 5 nodi, 350 dollari. 10 nodi, 700. I costi delle
15:11
Speaker 2: VM aumentano rapidamente. Il control plane ha tre livelli di prezzo.
15:15
Speaker 2: Il livello free offre il control plane senza costi aggiuntivi,
15:17
Speaker 2: ma senza serve. Standard costa circa 72 dollari al mese
15:21
Speaker 2: per cluster con una SLA del 99,95% sul server API.
15:26
Speaker 2: Premium costa circa 432 dollari al mese e aggiunge supporto
15:29
Speaker 2: a lungo termine per le versioni di Kubernetes. Per la
15:31
Speaker 2: maggior parte dei carichi di lavoro in produzione, standard è l'ideale,
15:34
Speaker 2: ma puoi ridurre i costi delle VM. Le istanze riservate
15:37
Speaker 2: ti permettono di impegnarti per 1 o 3 anni, risparmiando
15:39
Speaker 2: fino al 72% rispetto al PSU Go. Se conosci la
15:42
Speaker 2: tua capacità di base, ovvero i nodi sempre necessari, riservarli
15:45
Speaker 2: è la scelta più ovvia. Piene di risparmio Azure funzionano
15:48
Speaker 2: in modo simile, ma offrono più flessibilità tra diverse famiglie
15:50
Speaker 2: di VM. Ti impegni per una spesa oraria specifica e
15:53
Speaker 2: Azure applica lo sconto automaticamente. I risparmi arrivano fino al 65%.
15:57
Speaker 2: Le VM spots sono l'opzione più economica, fino al 90%
15:59
Speaker 2: di sconto, ma c'è un limite. Puoi recuperare tale capacità
16:01
Speaker 2: in qualsiasi momento. I tuoi nodi vengono rimossi e i
16:04
Speaker 2: pod riprogrammati. Questo va bene per batch job, runner CICD
16:07
Speaker 2: o carichi di lavoro stateless. Non altrettanto per la tua
16:10
Speaker 2: API di produzione. L'ottimizzazione dei costi non riguarda solo gli sconti.
16:13
Speaker 2: Dimensiona correttamente i tuoi nodi. Non eseguire il provisioning di
16:15
Speaker 2: una VM a 16 core quando i tuoi pod ne
16:17
Speaker 2: usano solo. Usa l'autoscaler del cluster per non pagare nodi
16:19
Speaker 2: inattivi durante il traffico scarso. Per carichi di lavoro a
16:22
Speaker 2: basso utilizzo di CPU, considera le VM serie B. Sono
16:24
Speaker 2: di tipo burstable e significativamente più economiche della serie D.
16:27
Speaker 2: Non dimenticare nemmeno l'archiviazione e il trasferimento dati. I volumi
16:29
Speaker 2: persistenti aggiungono costi. Azure Disk è veloce ma costoso. Azure
16:33
Speaker 2: Files è più economico ma più lento. Scegli in base
16:35
Speaker 2: alle esigenze di prestazioni del tuo carico di lavoro. Anche
16:38
Speaker 2: il traffico dato in uscita da Azure ha un costo.
16:41
Speaker 2: Mantieni il traffico all'interno della stessa regione quando possibile. Quindi,
16:44
Speaker 2: quando ha senso usare HKS? Parliamo di consigli pratici. Quando
16:47
Speaker 2: dovresti usare HKS? HKS eccelle con un'architettura a microservizi. hai
16:51
Speaker 2: più servizi indipendenti che devono scalare separatamente. Il front- end potrebbe
16:55
Speaker 2: aver bisogno di 10 repliche nelle ore di punta, mentre
16:57
Speaker 2: il back- end solo 3. HS lo gestisce naturalmente. Ogni servizio
17:01
Speaker 2: scala in modo indipendente, in base al proprio traffico. La
17:04
Speaker 2: tua disponibilità è un altro punto di forza. HS distribuisce
17:07
Speaker 2: i tuoi pod su più nodi. Se un nodo fallisce,
17:09
Speaker 2: i pod vengono riprogrammati su nodi inti. Se utilizzi le
17:12
Speaker 2: zone di disponibilità, il tuo cluster può sopravvivere al guasto
17:14
Speaker 2: di un intero data center. Per le applicazioni che devono
17:16
Speaker 2: restare attive 24-7, questo è prezioso. L'integrazione CI- CD è dove
17:20
Speaker 2: HS dà davvero i suoi frutti. Crea la tua immagine container,
17:22
Speaker 2: la invia a un registro e HS distribuisce la nuova
17:25
Speaker 2: versione con un aggiornamento progressivo. Zero tempi di attività. Se
17:28
Speaker 2: qualcosa va storto esegui il rollback. Nessun SSH manuale sui server,
17:31
Speaker 2: nessun copia e incolla di file. La pipeline gestisce tutto.
17:34
Speaker 2: Ma HS non è sempre la risposta giusta. Se hai
17:36
Speaker 2: una semplice applicazione monolitica su una singola VM, HS aggiunge
17:39
Speaker 2: complessità senza grandi benefici. Gestiresti Kubernetes solo per il gusto
17:43
Speaker 2: di farlo? A volte una VM, un servizio app o
17:46
Speaker 2: persino Azure Functions sono la scelta più semplice ed economica.
17:48
Speaker 2: Se hai appena iniziato, usa il livello gratuito. Crea un cluster,
17:51
Speaker 2: distribuisce un'app di test, rompi le cose, riparale. Impara i
17:54
Speaker 2: concetti senza preoccuparti dei costi. Quando sei pronto per la
17:56
Speaker 2: produzione passa lo standard. Siamo tutti insieme. Quindi ecco cosa
18:00
Speaker 2: devi ricordare. HKS si occupa di quattro aspetti fondamentali. Microsoft
18:03
Speaker 2: gestisce il piano di controllo, ovvero il cervello del cluster.
18:06
Speaker 2: Tu scegli dimensione e numero di nodi, le VM worker,
18:08
Speaker 2: e HKS gestisce i pool e la scalabilità. Per la
18:11
Speaker 2: rete i pod comunicano tra loro e con l'esterno tramite
18:13
Speaker 2: Azure CNI e HKS si integra per far funzionare tutto.
18:17
Speaker 2: Gli strumenti di sicurezza sono integrate. identità isolamento di rete
18:20
Speaker 2: hardlink dei pod paghi solo per calcolo nodi archiviazione rete
18:25
Speaker 2: il piano di controllo è gratuito nel livello free ti
18:27
Speaker 2: serve lo standard o il premium solo se vuoi SLA
18:30
Speaker 2: o supporto a lungo termine il tuo prossimo passo crea
18:33
Speaker 2: un cluster HS gratuito nel portale Azure distribuisci una semplice
18:36
Speaker 2: app di test NGINX o un container Hello World guarda
18:39
Speaker 2: come funziona rompi tutto e ripara quell'esperienza pratica supera qualsiasi
18:42
Speaker 2: tutorial se questo episodio ti è stato utile iscriviti per
18:45
Speaker 2: altre spiegazioni chiare su Azure e condividilo con chi inizia
18:47
Speaker 2: il suo percorso nel cloud ti ringrazieranno in seguito.