Quando si desidera utilizzare Linux per fornire servizi a un'azienda, tali servizi dovranno essere sicuri, resilienti e scalabili. Belle parole, ma cosa intendiamo per loro?
"Sicuro" significa che gli utenti possono accedere ai dati di cui hanno bisogno, sia che si tratti di accesso di sola lettura o di accesso in scrittura. Allo stesso tempo, nessun dato viene esposto a parti non autorizzate a vederlo. La sicurezza è ingannevole: puoi pensare di avere tutto protetto solo per scoprire in seguito che ci sono dei buchi. Progettare in sicurezza dall'inizio di un progetto è molto più semplice che tentare di adattarlo in un secondo momento.
"Resiliente" significa che i tuoi servizi tollerano i guasti all'interno dell'infrastruttura. Un errore potrebbe essere un controller del disco del server che non può più accedere a nessun disco, rendendo i dati irraggiungibili. Oppure l'errore potrebbe essere uno switch di rete che non consente più a due o più sistemi di comunicare. In questo contesto, un "singolo punto di errore" o SPOF è un errore che influisce negativamente sulla disponibilità del servizio. Un'infrastruttura resiliente è senza SPOF.
"Scalabile" descrive la capacità dei sistemi di gestire i picchi di domanda con garbo. Determina anche la facilità con cui possono essere apportate modifiche ai sistemi. Ad esempio, aggiungendo un nuovo utente, aumentando la capacità di archiviazione o spostando un'infrastruttura da Amazon Web Services a Google Cloud, o addirittura spostandola internamente.
Non appena la tua infrastruttura si espande oltre un server, ci sono molte opzioni per aumentare la sicurezza, la resilienza e la scalabilità. Vedremo come questi problemi sono stati risolti tradizionalmente e quale nuova tecnologia è disponibile che cambia il volto del calcolo delle grandi applicazioni.
Ottieni più Linux!
Ti piace quello che stai leggendo? Vuoi più Linux e open source? Possiamo consegnare, letteralmente! Abbonati al formato Linux oggi a un prezzo speciale. Puoi ottenere edizioni cartacee, edizioni digitali o perché no entrambe? Consegniamo a casa tua in tutto il mondo per una semplice tariffa annuale. Quindi rendi la tua vita migliore e più facile, iscriviti ora!
Per capire cosa è possibile oggi, è utile esaminare come i progetti tecnologici sono stati tradizionalmente implementati. Ai vecchi tempi, ovvero più di 10 anni fa, le aziende acquistavano o affittavano hardware per eseguire tutti i componenti delle loro applicazioni. Anche le applicazioni relativamente semplici, come un sito Web WordPress, hanno più componenti. Nel caso di WordPress, è necessario un database MySQL insieme a un server web, come Apache, e un modo di gestire il codice PHP. Quindi, avrebbero costruito un server, impostato Apache, PHP e MySQL, installato WordPress e se ne sarebbero andati.
In generale, ha funzionato. Ha funzionato abbastanza bene che ci sono ancora un numero enorme di server configurati esattamente in questo modo oggi. Ma non era perfetto e due dei problemi maggiori erano la resilienza e la scalabilità.
La mancanza di resilienza significava che qualsiasi problema significativo sul server avrebbe comportato una perdita del servizio. Chiaramente un guasto catastrofico significherebbe nessun sito web, ma non c'era nemmeno spazio per eseguire la manutenzione programmata senza influire sul sito web. Anche l'installazione e l'attivazione di un aggiornamento di sicurezza di routine per Apache richiederebbe un'interruzione di alcuni secondi per il sito Web.
Il problema della resilienza è stato in gran parte risolto creando "cluster ad alta disponibilità". Il principio era quello di avere due server che eseguivano il sito Web, configurati in modo tale che il guasto di uno dei due non comportasse il blocco del sito Web. Il servizio fornito era resistente anche se i singoli server non lo erano.
Nuvole astratteParte del potere di Kubernetes è l'astrazione che offre. Dal punto di vista di uno sviluppatore, sviluppano l'applicazione per l'esecuzione in un contenitore Docker. Docker non si preoccupa se è in esecuzione su Windows, Linux o qualche altro sistema operativo. Lo stesso contenitore Docker può essere preso dal MacBook dello sviluppatore ed eseguito con Kubernetes senza alcuna modifica.
L'installazione di Kubernetes stessa può essere una singola macchina. Naturalmente, molti dei vantaggi di Kubernetes non saranno disponibili: non ci sarà auto-scaling; c'è un ovvio singolo punto di errore e così via. Come prova di concetto in un ambiente di test, però, funziona.
Una volta che sei pronto per la produzione, puoi eseguire internamente o su un provider cloud come AWS o Google Cloud. I fornitori di cloud hanno alcuni servizi integrati che aiutano a eseguire Kubernetes, ma nessuno di questi sono requisiti rigidi. Se vuoi spostarti tra Google, Amazon e la tua infrastruttura, configura Kubernetes e trasferisciti. Nessuna delle tue applicazioni deve cambiare in alcun modo.
E dov'è Linux? Kubernetes funziona su Linux, ma il sistema operativo è invisibile alle applicazioni. Questo è un passo significativo verso la maturità e l'usabilità delle infrastrutture IT.
L'effetto Slashdot
Il problema della scalabilità è un po 'più complicato. Supponiamo che il tuo sito WordPress riceva 1.000 visitatori al mese. Un giorno, la tua attività viene menzionata su Radio 4 o sulla TV della colazione. All'improvviso, ricevi più di un mese di visitatori in 20 minuti. Abbiamo tutti sentito storie di siti web che "si bloccano" e questo è in genere il motivo: mancanza di scalabilità.
I due server che hanno contribuito alla resilienza potevano gestire un carico di lavoro più elevato di quanto potesse fare un solo server, ma è ancora limitato. Pagheresti per due server il 100% delle volte e la maggior parte delle volte funzionavano entrambi perfettamente. È probabile che uno solo possa eseguire il tuo sito. Quindi John Humphrys menziona la tua attività su Today e avresti bisogno di 10 server per gestire il carico, ma solo per poche ore.
La migliore soluzione sia al problema della resilienza che della scalabilità era il cloud computing. Configura una o due istanze del server, i piccoli server che eseguono le tue applicazioni, su Amazon Web Services (AWS) o Google Cloud e, se una delle istanze si guasta per qualche motivo, verrà riavviata automaticamente. Imposta la scalabilità automatica correttamente e quando Mr Humphrys fa aumentare rapidamente il carico di lavoro sulle istanze del tuo server web, vengono avviate automaticamente istanze del server aggiuntive per condividere il carico di lavoro. Successivamente, quando l'interesse si esaurisce, quelle istanze aggiuntive vengono interrotte e paghi solo per ciò che utilizzi. Perfetto … o no?
Sebbene la soluzione cloud sia molto più flessibile del tradizionale server autonomo, ci sono ancora problemi. L'aggiornamento di tutte le istanze cloud in esecuzione non è semplice. Anche lo sviluppo per il cloud presenta delle sfide: il laptop utilizzato dai tuoi sviluppatori potrebbe essere simile all'istanza cloud, ma non è lo stesso. Se ti impegni in AWS, la migrazione a Google Cloud è un'impresa complessa. E supponi, per qualsiasi motivo, di non voler semplicemente cedere i tuoi computer ad Amazon, Google o Microsoft?
I contenitori sono emersi come un mezzo per racchiudere le applicazioni con tutte le loro dipendenze in un unico pacchetto che può essere eseguito ovunque. I container, come Docker, possono essere eseguiti sui laptop degli sviluppatori nello stesso modo in cui vengono eseguiti sulle istanze cloud, ma la gestione di una flotta di container diventa sempre più difficile con l'aumentare del numero di container.
La risposta è l'orchestrazione del contenitore. Si tratta di un significativo spostamento dell'attenzione. In precedenza, ci siamo assicurati di avere un numero sufficiente di server, fisici o virtuali, per assicurarci di poter supportare il carico di lavoro. L'utilizzo della scalabilità automatica dei provider di servizi cloud ha aiutato, ma avevamo ancora a che fare con le istanze. Abbiamo dovuto configurare manualmente i bilanciatori del carico, i firewall, l'archiviazione dei dati e altro ancora. Con l'orchestrazione del contenitore, tutto ciò (e molto altro) è curato. Specifichiamo i risultati di cui abbiamo bisogno e i nostri strumenti di orchestrazione dei container soddisfano i nostri requisiti. Specifichiamo cosa vogliamo che sia fatto, piuttosto che come vogliamo che sia fatto.
Diventa un Kubernete
Kubernetes (ku-ber-net-eez) è oggi il principale strumento di orchestrazione dei container e proviene da Google. Se qualcuno sa come eseguire infrastrutture IT su larga scala, Google lo sa. L'origine di Kubernetes è Borg, un progetto interno di Google che è ancora utilizzato per eseguire la maggior parte delle applicazioni di Google, incluso il suo motore di ricerca, Gmail, Google Maps e altro ancora. Borg era un segreto fino a quando Google non ha pubblicato un articolo al riguardo nel 2015, ma il documento ha reso molto evidente che Borg era l'ispirazione principale dietro Kubernetes.
Borg è un sistema che gestisce le risorse di calcolo nei data center di Google e mantiene le applicazioni di Google, sia di produzione che di altro tipo, in esecuzione nonostante guasti hardware, esaurimento delle risorse o altri problemi che potrebbero altrimenti aver causato un'interruzione. Lo fa monitorando attentamente le migliaia di nodi che compongono una "cella" Borg e i contenitori in esecuzione su di essi, e avviando o arrestando i contenitori come richiesto in risposta a problemi o fluttuazioni di carico.
Lo stesso Kubernetes è nato dall'iniziativa GIFEE ("Google’s Infrastructure For Everyone Else") di Google ed è stato progettato per essere una versione più amichevole di Borg che potrebbe essere utile al di fuori di Google. È stato donato alla Linux Foundation nel 2015 attraverso la formazione della Cloud Native Computing Foundation (CNCF).
Kubernetes fornisce un sistema in base al quale "dichiari" le tue applicazioni e servizi containerizzati e si assicura che le tue applicazioni vengano eseguite in base a tali dichiarazioni. Se i tuoi programmi richiedono risorse esterne, come archiviazione o bilanciatori del carico, Kubernetes può eseguirne il provisioning automaticamente. Può scalare le tue applicazioni verso l'alto o verso il basso per tenere il passo con i cambiamenti di carico e può persino ridimensionare l'intero cluster quando necessario. I componenti del tuo programma non hanno nemmeno bisogno di sapere dove sono in esecuzione: Kubernetes fornisce servizi di denominazione interni alle applicazioni in modo che possano connettersi a "wp_mysql" ed essere collegati automaticamente alla risorsa corretta ".
Il risultato finale è una piattaforma che può essere utilizzata per eseguire le tue applicazioni su qualsiasi infrastruttura, da una singola macchina attraverso un rack di sistemi on-premise a flotte di macchine virtuali basate su cloud in esecuzione su qualsiasi principale provider di cloud, tutte utilizzando gli stessi contenitori e configurazione. Kubernetes è indipendente dal provider: eseguilo dove vuoi.
Kubernetes è uno strumento potente ed è necessariamente complesso. Prima di entrare in una panoramica, dobbiamo introdurre alcuni termini utilizzati in Kubernetes. I contenitori eseguono singole applicazioni, come discusso sopra, e sono raggruppati in pod. Un pod è un gruppo di contenitori strettamente collegati che vengono distribuiti insieme sullo stesso host e condividono alcune risorse. I contenitori all'interno di un pod funzionano come una squadra: eseguiranno funzioni correlate, come un contenitore dell'applicazione e un contenitore di registrazione con impostazioni specifiche per l'applicazione.
Quattro componenti chiave di Kubernetes sono API Server, Scheduler, Controller Manager e un database di configurazione distribuito chiamato etcd. Il server API è il cuore di Kubernetes e funge da endpoint primario per tutte le richieste di gestione. Questi possono essere generati da una varietà di fonti, inclusi altri componenti Kubernetes, come lo scheduler, gli amministratori tramite dashboard da riga di comando o basati sul Web e le stesse applicazioni containerizzate. Convalida le richieste e aggiorna i dati archiviati in etcd.
Lo Scheduler determina su quali nodi verranno eseguiti i vari pod, tenendo conto di vincoli come requisiti di risorse, eventuali vincoli hardware o software, carico di lavoro, scadenze e altro.
Il Controller Manager monitora lo stato del cluster e proverà ad avviare o arrestare i pod come necessario, tramite il server API, per portare il cluster allo stato desiderato. Gestisce anche alcune connessioni interne e funzionalità di sicurezza.
Ogni nodo esegue un processo Kubelet, che comunica con il server API e gestisce i contenitori, generalmente utilizzando Docker, e Kube-Proxy, che gestisce il proxy di rete e il bilanciamento del carico all'interno del cluster.
Il sistema di database distribuito etcd deriva il suo nome da /eccetera cartella sui sistemi Linux, che viene utilizzata per contenere le informazioni sulla configurazione del sistema, più il suffisso "d", spesso utilizzato per denotare un processo daemon. Gli obiettivi di etcd sono archiviare i dati dei valori-chiave in modo distribuito, coerente e tollerante agli errori.
Il server API conserva tutti i dati sullo stato in etcd e può eseguire molte istanze contemporaneamente. Lo scheduler e il gestore del controller possono avere solo un'istanza attiva ma utilizza un sistema di lease per determinare quale istanza in esecuzione è il master. Tutto ciò significa che Kubernetes può essere eseguito come un sistema a disponibilità elevata senza single point of failure.
Mettere tutto insieme
Quindi come utilizziamo questi componenti nella pratica? Quello che segue è un esempio di configurazione di un sito Web WordPress utilizzando Kubernetes. Se vuoi farlo per davvero, allora probabilmente useresti una ricetta predefinita chiamata grafico del timone. Sono disponibili per una serie di applicazioni comuni, ma qui esamineremo alcuni dei passaggi necessari per rendere attivo e funzionante un sito WordPress su Kubernetes.
Il primo compito è definire una password per MySQL:
kubectl crea un mysql-pass generico segreto --from-literal = password = YOUR_PASSWORD
kubectl parlerà con il server API, che convaliderà il comando e quindi memorizzerà la password in etcd. I nostri servizi sono definiti in file YAML e ora abbiamo bisogno di un po 'di memoria persistente per il database MySQL.
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mysql-pv-claim labels: app: wordpress spec: accessModes: - ReadWriteOnce risorse: richieste: archiviazione: 20Gi
La specifica dovrebbe essere per lo più autoesplicativa. I campi del nome e delle etichette vengono utilizzati per fare riferimento a questo spazio di archiviazione da altre parti di Kubernetes, in questo caso il nostro contenitore WordPress.
Una volta definito lo storage, possiamo definire un'istanza MySQL, indirizzandola allo storage predefinito. Segue la definizione del database stesso. Diamo a quel database un nome e un'etichetta per un facile riferimento all'interno di Kubernetes.
Ora abbiamo bisogno di un altro contenitore per eseguire WordPress. Parte della specifica di distribuzione del contenitore è:
tipo: metadati di distribuzione: nome: wordpress etichette: app: wordpress specifiche: strategia: tipo: ricrea
Il tipo di strategia "Ricrea" significa che se uno qualsiasi del codice che comprende l'applicazione cambia, le istanze in esecuzione verranno eliminate e ricreate. Altre opzioni includono la possibilità di eseguire il ciclo di nuove istanze e la rimozione di istanze esistenti, una per una, consentendo al servizio di continuare a funzionare durante la distribuzione di un aggiornamento. Infine, dichiariamo un servizio per WordPress stesso, che comprende il codice PHP e Apache. Parte del file YAML che dichiara questo è:
metadati: nome: wordpress etichette: app: wordpress spec: porte: - porta: 80 selettore: app: wordpress tier: frontend tipo: LoadBalancer
Nota l'ultima riga, che definisce il tipo di servizio come LoadBalancer. Ciò indica a Kubernetes di rendere il servizio disponibile al di fuori di Kubernetes. Senza quella linea, questo sarebbe semplicemente un servizio interno "solo Kubernetes". E questo è tutto. Kubernetes ora utilizzerà quei file YAML come dichiarazione di ciò che è richiesto e configurerà pod, connessioni, archiviazione e così via come richiesto per portare il cluster nello stato "desiderato".
Questa è stata necessariamente solo una panoramica di alto livello di Kubernetes e molti dettagli e funzionalità del sistema sono stati omessi. Abbiamo sorvolato sulla scalabilità automatica (sia pod che i nodi che compongono un cluster), cron job (avvio di container in base a una pianificazione), Ingress (bilanciamento del carico HTTP, riscrittura e offload SSL), RBAC (controlli di accesso basati sui ruoli) , criteri di rete (firewall) e molto altro ancora. Kubernetes è estremamente flessibile ed estremamente potente: per qualsiasi nuova infrastruttura IT, deve essere un serio concorrente.
Risorse
Se non hai familiarità con Docker, inizia da qui: https://docs.docker.com/get-started.
C'è un tutorial interattivo sulla distribuzione e il ridimensionamento di un'app qui: https://kubernetes.io/docs/tutorials/kubernetes-basics.
E vedi https://kubernetes.io/docs/setup/scratch per come creare un cluster.
Puoi giocare con un cluster Kubernetes gratuito su https://tryk8s.com.
Infine, puoi esaminare un lungo documento tecnico con un'eccellente panoramica dell'uso di Borg da parte di Google e di come questo abbia influenzato il design di Kubernetes qui: https://storage.googleapis.com/pub-tools-public-publication-data/ pdf / 43438.pdf.
Scopri di più su Tiger Computing.
- Il miglior cloud storage del 2022-2023 online: opzioni gratuite, a pagamento e aziendali
Ti piace quello che stai leggendo? Vuoi più Linux e open source? Possiamo consegnare, letteralmente! Abbonati al formato Linux oggi a un prezzo speciale. Puoi ottenere edizioni cartacee, edizioni digitali o perché no entrambe? Consegniamo a casa tua in tutto il mondo per una semplice tariffa annuale. Quindi rendi la tua vita migliore e più facile, iscriviti ora!
