Ciao, Habrans! Kubernetes è uno degli elementi chiave dell'ecosistema cloud moderno. Questa tecnologia offre affidabilità, scalabilità e resilienza nella virtualizzazione dei container. John Arundel e Justin Domingus esplorano l'ecosistema di Kubernetes e condividono soluzioni collaudate per problemi quotidiani. Passo dopo passo, creerai la tua applicazione cloud-oriented e costruirai l'infrastruttura necessaria a supportarla, configurando l'ambiente di sviluppo e la pipeline di distribuzione continua, che sarà utile per i tuoi futuri progetti.
• Inizia a lavorare con i container e Kubernetes dalle basi: non è necessaria alcuna esperienza particolare per approfondire l'argomento. • Avvia i tuoi cluster o scegli un servizio Kubernetes gestito da Amazon, Google e altri. • Applica Kubernetes per gestire il ciclo di vita del container e il consumo delle risorse. • Ottimizza i cluster in base a costi, prestazioni, resilienza, potenza e scalabilità. • Scopri i migliori strumenti per sviluppare, testare e distribuire le tue applicazioni. • Sfrutta le best practice del settore per garantire sicurezza e controllo. • Implementa i principi DevOps nella tua azienda per rendere i team di sviluppo più agili, rapidi ed efficienti.
Per chi è destinato il libro
Il libro è particolarmente utile per i membri dei reparti di amministrazione responsabili di server, applicazioni e servizi, nonché per gli sviluppatori coinvolti nella creazione di nuovi servizi cloud o nella migrazione di applicazioni esistenti su Kubernetes e nel cloud. Non preoccuparti, non è necessario sapere lavorare con Kubernetes e i container: ti insegneremo tutto.
Gli utenti esperti di Kubernetes troveranno anche molte informazioni utili: qui vengono approfonditi temi come RBAC, distribuzione continua, gestione dei dati sensibili e monitoraggio. Speriamo che nelle pagine del libro ci sia qualcosa di interessante anche per voi, indipendentemente dalle vostre competenze ed esperienze.
A quali domande risponde il libro
Durante la pianificazione e la scrittura del libro, abbiamo discusso di tecnologie cloud e Kubernetes con centinaia di persone, parlando sia con leader ed esperti del settore che con assoluti principianti. Di seguito sono riportate alcune domande a cui vorrebbero trovare risposta in questa edizione.
- «Mi interessa capire perché dovrei investire tempo in questa tecnologia. Quali problemi può aiutare a risolvere per me e il mio team?»
- «Kubernetes sembra interessante, ma ha una barriera all'ingresso piuttosto elevata. Creare un esempio semplice non è difficile, ma la gestione e il debug successivi spaventano. Vorremmo avere consigli affidabili su come le persone gestiscono i cluster Kubernetes in condizioni reali e quali problemi possiamo aspettarci di affrontare».
- «Un consiglio soggettivo sarebbe utile. L'ecosistema Kubernetes offre troppe opzioni alle squadre principianti. Quando la stessa cosa può essere fatta in più modi, come si fa a capire quale sia il migliore? Come fare una scelta?»
E, probabilmente, la domanda più importante di tutte:
- «Come usare Kubernetes senza interrompere l'attività della mia azienda?»
Estratto. Configurazione e oggetti Secret
La possibilità di separare la logica dell'applicazione Kubernetes dalla sua configurazione (cioè da qualsiasi valore o impostazione che può cambiare nel tempo) è molto utile. I valori di configurazione di solito comprendono parametri destinati a un certo ambiente, indirizzi DNS di servizi di terze parti e credenziali per l'autenticazione.
Certo, tutto questo può essere inserito direttamente nel codice, ma un simile approccio non è abbastanza flessibile. Ad esempio, per cambiare un valore di configurazione, sarebbe necessario ricompilare e distribuire nuovamente il codice. Una soluzione molto migliore sarebbe separare la configurazione dal codice ed estarla da un file o da variabili d'ambiente.
Kubernetes offre diversi modi per gestire la configurazione. In primo luogo, è possibile passare valori all'applicazione tramite variabili d'ambiente specificate nella specifica dei pod (vedi la sezione "Variabili d'ambiente" a pagina 192). In secondo luogo, è possibile memorizzare i dati di configurazione direttamente in Kubernetes utilizzando gli oggetti ConfigMap e Secret.
In questo capitolo esploreremo in dettaglio questi oggetti e considereremo alcuni approcci pratici per gestire la configurazione e i dati riservati utilizzando un'applicazione dimostrativa.
Aggiornamento dei pod quando la configurazione cambia.
Immagina di avere un deployment nel tuo cluster e di voler modificare alcuni valori nel suo ConfigMap. Se utilizzi un chart Helm (vedi la sezione "Helm: gestore di pacchetti per Kubernetes" a pagina 102), puoi rilevare le modifiche nella configurazione e riavviare i tuoi pod automaticamente con un semplice trucco. Aggiungi la seguente annotazione nella specifica del tuo deployment:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
| sha256sum }}Ora il modello di distribuzione include un checksum dei parametri di configurazione: quando i parametri vengono modificati, il checksum verrà aggiornato. Eseguendo il comando helm upgrade, Helm rileverà che la specifica di distribuzione è cambiata e riavvierà tutte le pod-shell.
Dati riservati in Kubernetes
Sappiamo già che l'oggetto ConfigMap fornisce un meccanismo flessibile per memorizzare e accedere ai dati di configurazione nel cluster. Tuttavia, molte applicazioni contengono informazioni che sono segrete e riservate: ad esempio, password o chiavi API. Questi dati possono essere memorizzati anche in ConfigMap, ma questa soluzione non è ideale.
Invece, Kubernetes offre un oggetto di tipo speciale progettato per memorizzare dati riservati: il Secret. Vediamo ora un esempio di come questo oggetto può essere utilizzato nella nostra applicazione dimostrativa.
Iniziamo a guardare il manifesto Kubernetes per l'oggetto Secret (vedi hello-secret-env/k8s/secret.yaml):
apiVersion: v1
kind: Secret
metadata:
name: demo-secret
stringData:
magicWord: xyzzy
In questo esempio, la chiave privata magicWord ha il valore xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). La parola xyzzy è molto utile nel mondo dei computer. Analogamente a ConfigMap, in un oggetto Secret si possono posizionare numerose chiavi e valori. Qui per semplicità, utilizziamo solo una coppia "chiave — valore".
Utilizzo degli oggetti Secret come variabili di ambiente
Come per ConfigMap, è possibile rendere l'oggetto Secret disponibile nel contenitore come variabili di ambiente o file sul suo disco. Nel seguente esempio, assegneremo a una variabile di ambiente un valore proveniente da Secret:
spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-env
ports:
- containerPort: 8888
env:
- name: GREETING
valueFrom:
secretKeyRef:
name: demo-secret
key: magicWordEsegui il seguente comando nel repository demo per applicare i manifest:
kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configurato
secret "demo-secret" creatoCome prima, ridirigi la porta locale al deployment per vedere il risultato nel tuo browser:
kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888Aprendo l'indirizzo :9999/ dovresti vedere quanto segue:
La parola magica è "xyzzy"
Scrivere oggetti Secret in file
In questo esempio collegheremo un oggetto Secret a un contenitore come file. Il codice si trova nella cartella hello-secret-file del repository demo.
Per collegare il Secret come file, utilizzeremo il seguente deployment:
spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-file
ports:
- containerPort: 8888
volumeMounts:
- name: demo-secret-volume
mountPath: "/secrets/"
readOnly: true
volumes:
- name: demo-secret-volume
secret:
secretName: demo-secretCome nella sezione "Creazione di file di configurazione da oggetti ConfigMap" a pagina 240, creiamo un volume (in questo caso demo-secret-volume) e lo colleghiamo al contenitore nella sezione volumeMounts. Nel campo mountPath è indicato "/secrets", quindi Kubernetes creerà in quella cartella un file per ogni coppia "chiave - valore" definita nell'oggetto Secret.
Nel nostro esempio, abbiamo definito solo una coppia "chiave - valore" chiamata magicWord, quindi il manifesto creerà all'interno del contenitore un file "/secrets/magicWord" con dati riservati, accessibile solo in lettura.
Se applichiamo questo manifesto nello stesso modo dell'esempio precedente, dovremmo ottenere lo stesso risultato:
La parola magica è "xyzzy"
Lettura degli oggetti Secret
Nella sezione precedente abbiamo utilizzato il comando kubectl describe per visualizzare il contenuto del ConfigMap. È possibile fare la stessa cosa con il Secret?
kubectl describe secret/demo-secret
Name: demo-secret
Namespace: default
Labels:
Annotations:
Type: Opaque
Data
====
magicWord: 5 bytesNota che i dati stessi non vengono visualizzati. Gli oggetti Secret in Kubernetes hanno il tipo Opaque: ciò significa che il loro contenuto non è mostrato nell'output di kubectl describe, nei log e nel terminale, impedendo di rivelare accidentalmente informazioni riservate.
Per visualizzare la versione codificata dei dati riservati in formato YAML, utilizza il comando kubectl get:
kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaquebase64
Che cos'è eHl6enk=, non sembra affatto il nostro valore di partenza? In realtà, è un oggetto Secret rappresentato in codifica base64. Base64 è uno schema di codifica di dati binari arbitrari in una stringa di caratteri.
Poiché le informazioni riservate possono essere binarie e non accessibili per l'output (come nel caso della chiave di crittografia TLS), gli oggetti Secret sono sempre memorizzati in formato base64.
Il testo beHl6enk= è una versione della nostra parola segreta xyzzy, codificata in base64. Puoi verificarlo eseguendo nel terminale il comando base64 —decode:
echo "eHl6enk=" | base64 --decode
xyzzyQuindi, anche se Kubernetes ti protegge dall'esposizione accidentale di dati riservati nel terminale o nei file di log, se hai diritti di lettura sui segreti in uno specifico namespace, tali dati possono essere recuperati in formato base64 e in seguito decodificati.
Se hai bisogno di codificare un testo in base64 (ad esempio, per inserirlo in un Secret), utilizza il comando base64 senza argomenti:
echo xyzzy | base64
eHl6enkKAccesso agli oggetti Secret
Chi può leggere e modificare gli oggetti Secret? Questo è determinato dal RBAC, il meccanismo di controllo degli accessi (ne discuteremo in dettaglio nella sezione 'Introduzione alla gestione degli accessi basata sui ruoli' a pagina 258). Se utilizzi un cluster in cui il sistema RBAC è assente o disabilitato, tutti i tuoi oggetti Secret sono accessibili a qualunque utente e contenitore (spiegheremo più avanti che non dovresti avere nessun cluster di produzione senza RBAC).
Crittografia passiva dei dati
E per quanto riguarda coloro che hanno accesso al database etcd, dove Kubernetes memorizza tutte le sue informazioni? Possono leggere dati riservati senza avere diritti di lettura sugli oggetti Secret tramite API?
A partire dalla versione 1.7, Kubernetes supporta la crittografia passiva dei dati. Ciò significa che le informazioni riservate all'interno di etcd vengono memorizzate su disco in forma crittografata e non possono essere lette nemmeno da coloro che hanno accesso diretto al database. Per decifrarle è necessaria una chiave, che è disponibile solo al server API di Kubernetes. In un cluster configurato correttamente, la crittografia passiva dovrebbe essere abilitata.
Puoi verificare se la crittografia passiva è attiva nel tuo cluster in questo modo:
kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
--experimental-encryption-provider-config=...Se non vedi il flag experimental-encryption-provider-config, la crittografia passiva non è attiva. Quando utilizzi Google Kubernetes Engine o altri servizi di gestione di Kubernetes, i tuoi dati vengono crittografati tramite un altro meccanismo, quindi il flag sarà assente. Chiedi al tuo fornitore di Kubernetes se il contenuto di etcd è crittografato.
Memorizzazione dei dati riservati
Ci sono risorse Kubernetes che non dovrebbero mai essere eliminate dal cluster: ad esempio, gli oggetti Secret particolarmente importanti. Puoi proteggere la risorsa dall'eliminazione utilizzando un'annotazione fornita dal gestore Helm:
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keepStrategie di gestione degli oggetti Secret
Nell'esempio della sezione precedente, i dati riservati erano protetti da accessi non autorizzati immediatamente dopo il salvataggio nel cluster. Tuttavia, nei file di manifest, erano conservati come testo semplice.
Non dovresti mai posizionare informazioni riservate in file che si trovano nel sistema di controllo versione. Come puoi quindi amministrare e conservare queste informazioni in modo sicuro prima di applicarle al cluster Kubernetes?
Puoi scegliere qualsiasi strumento o strategia per gestire i dati riservati nelle tue applicazioni, ma dovrai comunque rispondere ad almeno le seguenti domande.
- Dove conservare i dati riservati affinché siano altamente disponibili?
- Come rendere i dati riservati accessibili alle tue applicazioni attive?
- Cosa dovrebbe succedere alle tue applicazioni quando sostituisci o modifichi i dati sensibili?
Chi siamo
John Arundel è un consulente con 30 anni di esperienza nel settore informatico. Ha scritto diversi libri e collabora con molte aziende di diversi paesi, fornendo consulenza su infrastrutture cloud-oriented e Kubernetes. Nel tempo libero ama fare surf, ha buone capacità di tiro con la pistola e suona il pianoforte per hobby. Vive in un incantevole cottage in Cornovaglia, Inghilterra.
Justin Domingus è un ingegnere di sistemazione che lavora in un ambiente DevOps con Kubernetes e tecnologie cloud. Gli piace trascorrere tempo all'aperto, bere caffè, pescare granchi e stare al computer. Vive a Seattle, Washington, insieme a un meraviglioso gatto e una moglie altrettanto straordinaria, nonché la sua migliore amica, Adrianne.
» Puoi approfondire con il libro su
»
»
Per gli utenti di Habr, uno sconto del 25% con il coupon — Kubernetes
Dopo il pagamento della versione cartacea del libro, verrà inviato un libro elettronico via email.
Fonte: habr.com
