Il libro «Kubernetes per DevOps»

Ciao, Habrozhiteli! Kubernetes è uno degli elementi chiave dell'ecosistema cloud moderno. Questa tecnologia garantisce l'affidabilità, la scalabilità e la resilienza della virtualizzazione dei container. John Arundel e Justin Domingus discutono dell'ecosistema Kubernetes e presentano soluzioni comprovate per problemi quotidiani. Passo dopo passo, costruirete la vostra applicazione basata sul cloud e creerete l'infrastruttura per supportarla, configurando l'ambiente di sviluppo e un pipeline di distribuzione continua, che sarà utile mentre lavorate alle prossime applicazioni.

• Inizierete a lavorare con container e Kubernetes dalle basi: non è necessaria alcuna esperienza speciale per studiare l'argomento. • Avviate i vostri cluster o scegliete un servizio Kubernetes gestito da Amazon, Google, ecc. • Applicate Kubernetes per gestire il ciclo di vita del container e il consumo delle risorse. • Ottimizzate i cluster in base a costi, prestazioni, resilienza, potenza e scalabilità. • Scoprite i migliori strumenti per lo sviluppo, il test e la distribuzione delle vostre applicazioni. • Utilizzate le pratiche attuali del settore per garantire sicurezza e controllo. • Implementate i principi DevOps all'interno dell'azienda, affinché i team di sviluppo possano agire in modo più agile, rapido ed efficiente.

A chi è destinato il libro

Il libro è particolarmente pertinente per i membri dei reparti di gestione che sono responsabili dei server, delle applicazioni e dei servizi, nonché per gli sviluppatori che stanno creando nuovi servizi cloud o migrando applicazioni esistenti in Kubernetes e nel cloud. Non preoccupatevi, non è necessario saper lavorare con Kubernetes e container: vi insegneremo tutto.

Anche gli utenti esperti di Kubernetes troveranno molte informazioni preziose: qui vengono trattati approfonditamente argomenti come RBAC, distribuzione continua, gestione dei dati sensibili e osservabilità. Speriamo che tra le pagine del libro ci sia qualcosa di interessante anche per voi, indipendentemente dalle vostre abilità ed esperienze.

A quali domande risponde il libro

Durante la pianificazione e la scrittura del libro, abbiamo discusso delle tecnologie cloud e di Kubernetes con centinaia di persone, parlando sia con leader ed esperti del settore che con assoluti principianti. Di seguito sono riportate alcune domande alle quali vorrebbero vedere risposte in questa edizione.

• «Mi interessa sapere perché dovrei perdere tempo con questa tecnologia. Quali problemi può aiutare a risolvere a me e al mio team?»
• «Kubernetes sembra interessante, ma ha una barriera d'ingresso piuttosto alta. Creare un semplice esempio non è difficile, ma la gestione e il debug successivi spaventano. Vorremmo ricevere consigli affidabili su come le persone gestiscono i cluster Kubernetes in condizioni reali e quali problemi ci aspettiamo di incontrare.»
• «Un consiglio soggettivo sarebbe utile. L'ecosistema Kubernetes offre troppe opzioni ai team principianti. Quando la stessa cosa può essere fatta in più modi, come si fa a capire quale sia il migliore? Come si fa a scegliere?»

E, probabilmente, la domanda più importante di tutte:

• «Come utilizzare Kubernetes senza compromettere l'operatività 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 potrebbe cambiare nel tempo) è molto utile. I valori di configurazione di solito includono parametri destinati a un ambiente specifico, indirizzi DNS di servizi esterni e credenziali per l'autenticazione.

Certo, tutto questo potrebbe essere inserito direttamente nel codice, ma questo approccio non è abbastanza flessibile. Ad esempio, per modificare un valore di configurazione, dovresti ricompilare e ridistribuire il tuo codice. Una soluzione migliore sarebbe separare la configurazione dal codice e leggerla da un file o da variabili di ambiente.

Kubernetes offre diversi modi per gestire la configurazione. In primo luogo, puoi passare i valori all'applicazione tramite variabili di ambiente specificate nella definizione della pod (vedi la sezione 'Variabili di ambiente' a pagina 192). In secondo luogo, i dati di configurazione possono essere memorizzati direttamente in Kubernetes utilizzando gli oggetti ConfigMap e Secret.

In questo capitolo esploreremo in dettaglio questi oggetti e esamineremo alcuni approcci pratici per la gestione della configurazione e dei dati sensibili, utilizzando un'applicazione dimostrativa come esempio.

Aggiornamento delle pod shell quando viene modificata la configurazione

Immaginate di avere un deployment nel vostro cluster e di voler modificare alcuni valori nel suo ConfigMap. Se usate un chart Helm (vedere la sezione "Helm: gestore dei pacchetti per Kubernetes" a pagina 102), potete rilevare le modifiche nella configurazione e riavviare automaticamente le vostre pod shell con un semplice trucco. Aggiungete la seguente annotazione nella specifica del vostro deployment:

checksum/config: {{ include (print $.Template.BasePath "\/configmap.yaml") .
       | sha256sum }}

Ora il modello del deployment contiene un checksum dei parametri di configurazione: quando questi ultimi vengono modificati, il checksum si aggiornerà. Se eseguite il comando helm upgrade, Helm rileverà che la specifica del deployment è stata modificata e riavvierà tutte le pod shell.

Dati sensibili in Kubernetes

Già sappiamo che l'oggetto ConfigMap fornisce un meccanismo flessibile per memorizzare e accedere ai dati di configurazione nel cluster. Tuttavia, la maggior parte delle applicazioni ha informazioni che sono segrete e riservate: ad esempio, password o chiavi API. Queste possono essere memorizzate anche in ConfigMap, ma questa soluzione non è ideale.

Invece, Kubernetes offre un oggetto di tipo speciale progettato per memorizzare dati sensibili: il Secret. Vediamo come utilizzare questo oggetto nella nostra applicazione dimostrativa.

Per iniziare, date un'occhiata al manifesto Kubernetes per l'oggetto Secret (vedere hello-secret-env/k8s/secret.yaml):

apiVersion: v1
kind: Secret
metadata:
    name: demo-secret
stringData:
    magicWord: xyzzy

In questo esempio, la chiave segreta magicWord ha il valore xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). La parola xyzzy è in effetti molto utile nel mondo dei computer. Analogamente a ConfigMap, nell'oggetto Secret si possono memorizzare numerose chiavi e valori. Qui, per semplicità, utilizziamo solo una coppia "chiave - valore".

Utilizzo degli oggetti Secret come variabili d'ambiente

Come per ConfigMap, è possibile rendere l'oggetto Secret accessibile nel contenitore come variabili d'ambiente o come file sul suo disco. Nel seguente esempio, assegneremo una variabile d'ambiente a un valore del Secret:

spec:
   contenitori:
       - nome: demo
          immagine: cloudnatived/demo:hello-secret-env
          porte:
             - containerPort: 8888
          ambiente:
             - nome: GREETING
               valueFrom:
               secretKeyRef:
                  nome: demo-secret
                  chiave: magicWord

Esegui il seguente comando nel repository demo per applicare i manifesti:

kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configurato
secret "demo-secret" creato

Come prima, reindirizza la porta locale al deployment per vedere il risultato nel tuo browser:

kubectl port-forward deploy/demo 9999:8888
Reindirizzando da 127.0.0.1:9999 -> 8888
Reindirizzando da [::1]:9999 -> 8888

Aprendo l'indirizzo localhost:9999/ dovresti vedere quanto segue:

La parola magica è "xyzzy"

Scrittura di oggetti Secret in file

In questo esempio collegheremo l'oggetto Secret al 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:
   contenitori:
       - nome: demo
          immagine: cloudnatived/demo:hello-secret-file
          porte:
              - containerPort: 8888
          volumeMounts:
              - nome: demo-secret-volume
                mountPath: "/secrets/"
                readOnly: true
   volumi:
      - nome: demo-secret-volume
        secret:
           secretName: demo-secret

Come nel sottosezione "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. Il campo mountPath è impostato su /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" con nome magicWord, quindi il manifesto creerà nel contenitore un file /secrets/magicWord con dati riservati, accessibile solo in lettura.

Se applichi questo manifesto nello stesso modo del precedente esempio, dovrebbe risultare lo stesso:

La parola magica è "xyzzy"

Lettura di oggetti Secret

Nella sezione precedente abbiamo utilizzato il comando kubectl describe per visualizzare il contenuto di ConfigMap. È possibile fare lo stesso con Secret?

kubectl describe secret/demo-secret
Nome:          demo-secret

Namespace:      default
Etichette:             
Annotazioni:
Tipo:               Opaque

Dati
====
magicWord: 5   byte

Nota che i dati stessi non vengono visualizzati. Gli oggetti Secret in Kubernetes hanno tipo Opaque: ciò significa che il loro contenuto non viene mostrato nell'output di kubectl describe, nei log e nel terminale, impedendo la divulgazione accidentale di informazioni riservate.

Per visualizzare la versione codificata dei dati riservati in formato YAML, utilizzare il comando kubectl get:

kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
   magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaque

base64

Cos'è eHl6enk=, che non assomiglia affatto al nostro valore originale? In realtà, si tratta di 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= è la versione della nostra parola segreta xyzzy, codificata in base64. Si può verificare eseguendo il comando base64 —decode nel terminale:

echo "eHl6enk=" | base64 --decode
xyzzy

Pertanto, anche se Kubernetes ti protegge dall'output accidentale di dati riservati nel terminale o nei file di log, se hai i diritti di lettura sugli oggetti Secret in un determinato namespace, puoi accedere a questi dati in formato base64 e poi decodificarli.

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
eHl6enkK

Accesso agli oggetti Secret

Chi può leggere e modificare gli oggetti Secret? Questo è determinato da RBAC — un 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 disattivato, tutti i tuoi oggetti Secret sono accessibili a qualsiasi utente e contenitore (spiegheremo in seguito che non dovresti avere alcun cluster di produzione senza RBAC).

Crittografia passiva dei dati

E per quanto riguarda coloro che hanno accesso al database etcd, in cui Kubernetes memorizza tutte le sue informazioni? Possono leggere i dati riservati senza avere diritti di lettura sugli oggetti Secret attraverso l'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 chi ha accesso diretto al database. Per la sua decrittazione è necessaria una chiave, disponibile solo per il server API di Kubernetes. In un cluster correttamente configurato, la crittografia passiva dovrebbe essere abilitata.

Puoi verificare se la crittografia passiva è attiva nel tuo cluster nel seguente 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. Se utilizzi Google Kubernetes Engine o altri servizi di gestione di Kubernetes, i tuoi dati vengono crittografati tramite un meccanismo diverso, pertanto il flag sarà assente. Contatta il tuo fornitore di Kubernetes per sapere 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 una risorsa dall'eliminazione utilizzando un'annotazione fornita dal gestore Helm:

kind: Secret
metadata:
    annotations:
        "helm.sh/resource-policy": keep

Strategie di gestione degli oggetti Secret

Nell'esempio della sezione precedente, i dati riservati erano protetti da accessi non autorizzati subito dopo essere stati salvati nel cluster. Tuttavia, nei file di manifestazione, erano memorizzati come testo normale.

Non dovresti mai inserire informazioni riservate in file che si trovano nel sistema di controllo versioni. Come amministrare e memorizzare tali informazioni in modo sicuro prima di applicarle al cluster Kubernetes?

Puoi scegliere qualsiasi strumento o strategia per lavorare con i dati riservati nelle tue applicazioni, ma dovrai comunque rispondere ad almeno alle seguenti domande.

• Dove memorizzare i dati riservati affinché siano altamente disponibili?
• Come rendere i dati riservati accessibili alle tue applicazioni attive?
• Cosa dovrebbe accadere alle tue applicazioni quando sostituisci o modifichi i dati riservati?

A proposito degli autori

John Arundell è un consulente con 30 anni di esperienza nell'industria informatica. Ha scritto diversi libri e collabora con molte aziende di diversi paesi, fornendo consulenza su infrastrutture cloud e Kubernetes. Nel tempo libero si dedica al surf, è un buon tiratore e suona il pianoforte per hobby. Vive in un incantevole cottage a Cornovaglia, Inghilterra.

Justin Domingus è un ingegnere di sistemi informatici che lavora in un ambiente DevOps con Kubernetes e tecnologie cloud. Ama trascorrere tempo all'aperto, bere caffè, pescare granchi e stare al computer. Vive a Seattle, Washington, con un meraviglioso gatto e una moglie ancora più straordinaria, nonché migliore amica, Adrienne.

» Maggiori dettagli sul libro sono disponibili su sito dell'editore
» Indice
» Estratto

Per gli utenti di Habr sconto del 25% con il coupon — Kubernetes

Una volta effettuato il pagamento della versione cartacea del libro, riceverai un'email con il libro elettronico.

Fonte: habr.com