Introduzione a Kubernetes: dal main frame al container orchestrator

Kubernetes è un prodotto di Google frutto dell’evoluzione del cloud computing e delle necessità che con il passare del
tempo sono state soddisfatte con soluzioni ingegnose ed efficienti.

Inizialmente avevamo macchine fisiche su cui giravano sistemi operativi pesanti con applicativi monoblocco, una
soluzione che aveva molti svantaggi tra cui

- stop per manutenzioni a vari livelli dello stack (hardware, sistema operativo, componenti software proprietarie
e applicativo finale), nonchè alti costi di gestione
- problemi classici di Reliability/Avaiability applicazioni
- gestione delle risorse hardware (cpu, ram...) non ottimizzata e condivisa tra più applicativi, continuo pericolo
che le performance di un componente applicativo potessero influenzare negativamente anche gli altri (lock
risorse condivise etc)
- problemi di scalabilità del sistema

L’avvento delle virtual machines o vm fu il primo passo per risolvere alcuni di questi problemi:

- più sicurezza: avendo più macchine virtuali su una macchina fisica riusciamo a gestire meglio gli accessi al
sistema
- migliore utilizzo risorse: con la virtualizzazione possiamo partizionare le risorse hardware in modo razionale
- maggiore isolamento applicativo: facendo girare applicativi su macchine diverse è meno probabile che le
performance di un applicativo influissero negativamente su quelle di un’altro
- scalabilità e replicabilità: l’immagine di una vm è facilmente replicabile e trasportabile su nuovo hardware
all’occorrenza
- razionalizzazione e riduzione dei costi conseguente

restavano comunque problemi irrisolti come il fatto che ogni vm ha un suo sistema operativo, bisogna pagare le licenze
per ogni server, bisogna gestire la manutenzione e upgrade di ogni vm.

Un miglioramento lo portarono i containers: simili alle vm hanno il vantaggio di condividere il sistema operativo tra
applicazioni: sono leggeri, il sistema operativo è ridotto all’osso, sono indicati per applicazioni cloud-native, sono
scalabili dinamicamente molto più delle virtual machine, garantiscono disaccoppiamento tramite uso api, in ognuno di
essi possiamo definire piccoli microservizi che possono interagire tra loro per erogare un servizio più complesso, sono
portabili, possono girare quasi dovunque, supportano il DevOps deployment e l’Agile Deployment

Tutto l’occorrente per far girare un’applicazione (dipendenze, librerie, codice, tools...) viene impacchettato in una
“container image”, una template immutabile, in sola lettura, che comprende anche il virtual operating enviroment. Se
abbiamo bisogno di una istanza operativa eseguiamo la container image aggiungendo gli argomenti di runtime necessari
a ottenere la modalità di funzionamento ideale e otteniamo un container, ossia un’immagine in esecuzione con un
writable layer sotto (ram, disco etc). Le immagini possono essere versionate e pubblicate su repository pubbliche o
private, Docker è tra le applicazioni/servizi più conosciuti

I vantaggi conseguenti sono:

- build fidelity: è garantita la consistenza della build e la fedeltà rispetto all’immagine iniziale, il modo in cui viene
prodotta una immagine è deterministico e altamente riproducibile e l’immagine gira allo stesso modo ogni volta
- portability: i container possono essere portati e hostati su diverse piattaforme, public clouds, private clouds, on-
premises. A prescindere da dove è deployato il container tutto resta consistente. E’ dunque fatto per essere scalabile
e cloud-native.
- resource segregation: utilizza in modo efficiente le risorse e isola le applicazioni tra di loro. Sono flessibili, è facile fare
rollback, automatizzazione, tutte cose importanti per il mondo devops

Kubernates è di fatto un container orchestrator: permette di gestire in modo dinamico ed efficiente i vantaggi offerti dal
meccanismo dei container (è integrato con docker ma è compatibile con qualsiasi tipo di container che risponda alle
specifiche CRI (container runtime interfaces) su un cluster di macchine fisiche permettendoci di partizionare il cluster in
più cloud (cluster logici) gestire in modo altamente dinamico le risorse (cpu, ram..) e le istanze in esecuzione,
monitorare, bilanciare, scalare in modo efficace e automatizzato i sistemi, gestire in modo sicuro password, chiavi ssh,
oauth tokens senza dover riconfigurare (stop/start) i containers attivi.

Yaml il linguaggio per serializzare i dati

rispetto a xml e json la sintassi yaml è molto più leggibile e snella in quanto la sintassi è molto semplice si basa
sull’indentazione

viene mantenuta la struttura chiave-valore come json, i due punti e uno spazio separano la chiave dal valore (scalars,
valori letterali come numeri, boolean e stringhe) e non vanno usate le virgolette a meno che non sia necessario a evitare
errori di sintassi quando ci troviamo in presenza di caratteri riservati che sono apice, doppio apice (che vanno escapati)
[] {} > | * & ! % # ` @ , e i due punti

uno o più spazi seguiti da un cancelletto indicano una riga di commento

l’indentazione, l’uso cioè di un determinato numero di spazi su ciascuna, permette di definire un oggetto (structure)
complesso di uno o più oggetti senza ricorrere alle graffe che comunque possono essere usate

con l’uso del trattino prima della definizione di una chiave identifichiamo l’inizio di un elemento di un array (sequences)
che può essere una normale coppia chiave-valore o un oggetto più complesso, è possibile ricorrere anche alle parentesi
quadre

con l’uso del triplo trattino o del triplo punto possiamo concatenare più documenti yaml in un unico file

se lo scalare inizia per pipe (“|”) tutto quello che segue compreso accapo e spazio verranno considerati parte del valore

se lo scalare inizia per “>” tutto quello che segue (spazi e accapo compresi) viene considerato parte del valore (come il
pipe) ma spazi e accapo verranno ignorati (come accade in html)

Se con json possiamo esprimere tutto su una riga con yaml non si può (l’accapo fa parte della sintassi), ma è possibile
passare da yamle a json molto facilmente

vedere https://yaml.org/ o https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html per

approfondimenti sulla sintassi

L’installazione di kubernetes su windows e linux

Su windows abbiamo due alternative:

- docker desktop (possiamo abilitare la hyper-v di windows per la virtualizzazione o usare virtualbox o equivalenti
per la gestione delle macchine virtuali), tra le impostazioni di docker desktop abilitare kubernetes per avere
client e server standalone integrati a docker (pro, versione minimale e leggera che va bene per i test in locale,
contro, kubernetes server non è configurabile, ha un cluster con un solo nodo). A questo punto sulla power shell
di windows abbiamo a disposizione il comando “kubectl” per controllare kubernetes .
- minikube utilizzando un container runtime come docker o un vm enviroment come hyper-v nativo di windows o
tipo virtualbox, il metodo più rapido è abilitare hyper-v tra le features di windows e installare minikube con
l’installer o una alternativa proposte sul sito. Dopo l’installazione seguiamo le istruzioni per
 installare/configurare kubectl oppure andiamo nella sezione documentazione del sito, sezione “install kubectl
binary with curl on windows”, troviamo un modo per installare su minikube l’ultima versione dell’eseguibile di
kubectl, che ci servirà per controllare kubernetes. Il nostro primo cluster parte a riga di comando con “minikube
start” e successivamente usiamo “minikube kubectl” o “kubectl” se abbiamo impostato un alias o abbiamo
installato una versione di kubectl apposita.

Su sistemi linux/unix (es. ubuntu) bisogna installare:

- docker (docker-ce, docker-ce-cli, containerd.io) con apt-get dopo aver installato le dipendenze necessarie, la
docker gpg key e aver aggiunto la repository docker alla lista di repo valide per le installazioni e gli update dei
pacchetti software
- kubernetes (kubelet, kubectl, kubeadmin) con apt-get dopo aver disattivato la swap di sistema, aver installato le
dipendenze necessarie, la gpg key google, aver aggiunto la repository kubernetes alla lista di repo valide per le
installazioni e gli update dei pacchetti software e aver installato l’addon per comunicare con i pod (weave-net)

Comandi principali di kubernetes a riga di comando

- kubeadmin usato con l’opzione init facciamo partire il nodo (fisico) master del nostro cluster, mentre con
l’opzione join e gli argomenti tornati in output dalla “kubeadmin init” aggiungiamo un nodo (fisico) al cluster.
- kubectl serve per gestire e controllare lo stato di kubernetes a riga di comando

Due approcci per usare kubernetes: con comandi/configurazioni imperativi (istruzioni che generano singoli task sul
sistema) o con il metodo dichiarativo (set di files che dicono a kubernetes lo stato desiderato che il sistema deve
raggiungere), nello specifico

Approccio imperativo:

- kubectl run per generare un pod e far partire un container

- kubectl expose per esporre oggetti di tipo service
- kubectl scale per modificare la replica di un deployment
- kubectl autoscale per creare un nuovo oggetto di autoscale (scaling orizzontale tramite deployments)
- kubectl create seguito dal tipo di oggetto crea un namespace, un deployment, un servizio etc, in alternativa ai
parametri espliciti si può usare il flag –f e il nome del file yaml che descrive cosa creare
- kubectl delete per eliminare un oggetto di kubernetes (ed eventualmente gli oggetti a lui collegati)
- kubectl replace per aggiornare un oggetto kubernetes, normalmente si usa il flag –f seguito dal nome file con la
descrizione aggiornata dell’oggetto

Approccio dichiarativo: va (vanno) preparato i files manifest yaml con le specifiche desiderate per il sistema e
successivamente

- kubectl apply –f <path> per applicare/aggiornare gli oggetti di Kubernetes a partire dai manifesti yaml (possibile
indicare una cartella piuttosto che un file)
- kubectl diff –f <path> per confrontare (pre/post apply) l’attuale configurazione con i manifesti yaml che descrivono
gli oggetti
- kubectl get –f <path> –o yaml per verificare (pre/post apply) l’attuale configurazione con i manifesti yaml che
descrivono gli oggetti in formato yaml

kubectl api-resources per ottenere l’elenco delle api e gli oggetti conosciuti e l’eventuale sigla utilizzabile quando si
lanciano i comandi di cui sopra.

kubectl describe seguito dal tipo di oggetto torna le info dettagliate relative al tipo di oggetto che ci interessa

kubectl get seguito dal tipo di oggetto torna le info relative al tipo di oggetto che ci interessa

kubectl rollout status per conoscere lo stato di rollout di un deployment (ad esempio selezionandolo per nome)

kubectl exec <nome pod> –n <nome namespace> –it -- /bin/sh ottiene una shell (login) dentro a un pod specifico di un
namespace spec.

Oggetti di kubernetes
Gli oggetti di base di Kubernetes includono:

 Namespace
 Pod
 Service
 Volume

Namespace
Definisce una partizione logica sul cluster fisico. Non possono essere annidati, sono utili nel caso in cui abbiamo molti
utenti suddivisi per team/progetto Quando Kubernetes si avvia sono inizialmente presenti 4 namespaces:

- default: usato per oggetti che non hanno un namespace

- kube-system: usato per oggetti di sistema
- kube-public: accessibile e visibile in lettura da tutti gli utenti, anche quelli non autenticati, riservato per tutte le
risorse pubbliche su tutto il cluster
- kube-node-lease: associato ai componenti di k chiamati “lease” associati ad ogni nodo che si occupano di
monitorare i nodi e di spedire al control plane gli heartbeat in modo da poter stabilire se tutti i nodi sono in
piedi

Possiamo impostare dei limitRange (vedi) alle risorse del namespace

POD
Sono la più piccola unità di scheduling di kubernetes, ci finiscono dentro una o più app containerizzate. Lo use case più
comune è 1 pod=1 container ma nel caso di app accoppiate che ad esempio hanno bisogno di condividere risorse o
usare risorse di storage e rete come un unica unità i pods possono wrappare più container. In questo caso i container
sono co-allocati e co-schedulati.

Considerazioni sui container in un pod:

- set di volumi di storage, tutti i container dentro quel pod possono accedervi e quindi condividere dati, la
presenza dei volumi permette la sopravvivenza dei dati persistenti, anche nel caso in cui i containers in un pod
devono essere riavviati
- networking: ciascun pod ottiene un unico ip, ciascun container di un pod condivide con gli altri il nw namespace
compreso l’indirizzo ip e la porta, i container dentro lo stesso pod usano localhost per comunicare tra di loro,
oppure i canali standard di inter-process comunication. Container su pod diversi non possono usare il
meccanismo di inter-process comunication (a meno che non sia fatta un’apposita configurazione) ma usano l’ip
networking per comunicare con le entità esterne (comunicazione fatta tramite apposita configurazione???)
- privilege mode: i container in un pod possono girare in modalità privilegiata intervenendo sull’apposito flag nel
security context, è importante quando i container hanno bisogno di fare operazioni di amministrazione di
sistema come ad esempio accedere a risorse hardware, operazioni che richiedono particolari privilegi.

Tipi di pod containers wrappati dai pod

- app containers contengono le applicazioni

- init containers eseguiti durante lo startup, prima che parta qualsiasi app container
- ephemeral containers effimeri, che possono servire per scopi di debug

Normalmente i pod sono gestiti da un control plane, ad eccezione di quelli statici gestiti esternamente all’api server,
usati per eseguire un control plane self-hosted usando il demone kubelet su un nodo specifico che ci permette di gestire
i componenti del control plane. I pod statici vengono instanziati da una kubelet su un nodo specifico, possiamo dunque
affermare che kubelet si occupa di supervisionare il pod statico direttamente ed è capace di far ripartire il pod se va in
errore.

Services
E’ una astrazione che definisce (spesso questo pattern è chiamato micro-service)

- un set di pods
 - delle policy policy di accesso a questi

Il set di pods puntati da un servizio è solitamente determinato da un selector sebbene sia possibile creare Service
endpoints senza l’uso di selectors

Per esempio se abbiamo bisogno di un backend con tre repliche per processare una immagine in modo stateless e non
importa al frontend quale delle repliche processi l’immagine. Il numero di pods di backend potrebbero anche cambiare
di numero senza che il il frontend se ne accorga: il service fa questo lavoro di disaccoppiamento.

Se le nostre applicazioni sono capaci di usare le API di kubernetes e il servizio di service discovery è possibile effettuare
delle query all’api-server per ottenere gli endpoint, che non cambiano anche se il numero di pod dietro al servizio
cambia. Se invece abbiamo applicazioni non-native, kubernetes mette a disposizione diverse alternative per accedere ai
pod di backend, come ad esempio una porta di rete o un load balancer etc

Tipi di servizio

- cluster ip: tipo di servizio di default, espone il servizio su un ip interno al cluster, questo servizio è raggiungibile
solo internamente al cluster
- nodePort: espone il servizio su una porta statica sull’ip di ciascun nodo, il nodePort service effettua il routing
delle richieste al servizio di ip del cluster che è creato automaticamente. Il nodePort service è raggiungibile
dall’esterno del cluster usando la combinazione di IP e nodePort
- load Balancer: espone esternamente il servizio usando il load balancer del cloud provider; nodeport e cluster ip
sono creati automaticamente e il loadBalancer esterno redirige le richieste a questi servizi
- external Name: il servizio viene mappato su un valore specificato nel name field esterno, ritornando un CNAME
record e il suo valore; non c’è nessun tipo di proxy configurato, puoi anche usare “ingress” per esporre un
service anche se non è un vero service type

Ogni volta che viene definito un service in un namespace viene creata una entry nel dns come segue

<service-name>.<namespace-name>.svc.cluster.local e una, <service-name>, nel namespace di

appartenenza, così se un container si riferisce al solo <service-name> accederà a quello del namespace dove si trova
(eviteremo di usare services di namespace di staging o produzione se ci troviamo in uno di sviluppo)

esempio di dichiarazione di un service che segue

- con nome my-service

- che identifica e permette l’accesso a quel set di pod che abbiano label app: MyApp
- i pod saranno in ascolto sulla porta 9376 e useranno usano il protocollo tcp (se non specificato è il default)
- il service è accessibile sulla porta 80
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
nota1: se non specificata la target port, si usa per convenzione il valore definito in port

nota2: se tra le spec del container diamo un nome alla porta di ascolto, possiamo usare il medesimo nome nella
definizione del service
apiVersion: v1 apiVersion: v1
kind: Pod kind: Service
... ...
spec: spec:
containers: ...
... ports:
ports: - name: name-of-service-port
 - containerPort: 80 protocol: TCP
name: http-web-svc port: 80
targetPort: http-web-svc

LimitRange
Serve a impostare limiti minimi e massimi di una risorsa per un namespace

Replicaset
Con replicasets kubernetes ci garantisce il numero che vogliamo di pods identici disponibili per i deployments, i
deployments usano i replicasets per l’autodiagnosi e la scalabilità, i deployments wrappano i replicasets, normalmente
si agisce sui deployments e mai sui replicasets

I replicasets vengono definiti con i yaml files come tutti gli altri oggetti

Daemonsets
I daemonset sono i controller che verificano che i pods stiano girando su tutti i nodi, ad esempio il pod di logging.

Quando aggiungiamo nodi al cluster il daemonset fa in modo che i pod replica stiano girando su tutti i nodi aggiunti,
quando li sganciamo dal cluster il daemonset si preoccupa della garbage collection dei pod. Se eliminiamo un
daemonset i pod creati dal daemonset vengono rimossi.

Scenario tipico:

- eseguire un daemone di log collection su ciascun nodo

- eseguire un daemone di cluster storage su ciascun nodo
- eseguire un daemone di monitoraggio su ciascun nodo

normalmente abbiamo un daemonset per ogni tipologia di demone menzionata prima, configurazioni più complesse
prevedono più daemonsets per un tipo di demone ma con flag differenti

Deployment
Il Deployment è usato per aggiornamenti dichiarativi su pods e replicasets, il deployment può essere usato per definire
nuovi replicasets o per rimuovere deployments esistenti e acquisire le risorse che stavano usando. E’ possibille mettere
in pausa un deployment in corso in modo da poter aggiornare le configurazioni senza dover rifare tutto il rollout

Nel manifest, nella sezione spec

- replica definisce il numero di repliche

- template -> spec -> containers definisce il/i containers che dovranno essere usati nei pods

Nodes
Sono i nodi (fisici) su cui si basa il cluster di kubernetes

Ci sono due modi di aggiungere nodi all’api server

1. The kubelet on a node self-registers to the control plane

2. You (or another human user) manually add a Node object, in questo caso bisogna impostare il flag
kubelet --register-node=false

Il nome del nodo deve essere univoco

è possibile rendere un nodo unschedulable, ossia evitare che vengano creati nuovi pod, con il comando kubectl cordon
$NODENAME, il comando può essere preceduto da kubectl drain <node name> per deallocare tutti i pod presenti su
quel nodo. A questo punto il nodo può essere tolto dal cluster, altrimenti, dopo l’opportuna manutenzione, con kubectl
uncordon $NODENAME è possibile dire a kubernetes di ricominciare ad allocare pods sul nodo.
Con il comando kubectl describe node <insert-node-name-here> è possibile ottenere le informazioni relative allo stato
di un nodo:

- addresses: hostname, ip esterno, ip interno (al cluster)

- conditions: lo stato del nodo
o ready: se true, il nodo funziona correttamente, se unknown il controller non ha ricevuto l’heartbeat nel
periodo di tempo impostato (node-monitor-grace-period)
o diskpressure: se true significa che è a corto di disco
o memorypressure: se true significa che è a corto di memoria
o PIDpressure: se true significa che ci sono troppi processi sul nodo
o NetworkUnavailable: se true significa che la connessione di rete non è configurata correttamente
- capacity and allocatable: descrive le risorse disponibili sul nodo: cpu, memoria, e numero max di pod allocabili
- info: informazioni generali tra cui versione del kernel, di kubernetes, dettagli del container runtime e sistema
operativo del nodo

Ci sono due tipi di heartbeats per i nodi:

- aggiornamenti dello .status di un nodo, l’intervallo di default è 5’ che è molto più lungo del timeout di default di
40” per nodi non raggiungibili
- oggetti lease dentro il namespace kube-node-lease: questi oggetti sono più leggeri pertanto è consigliabile
questo approccio nei cluster molto grandi; i lease object vengono aggiornati ogni 10” di default; se
l’aggiornamento fallisce k. riprova con un ritardo esponenziale che parte da 200msec e arriva ai 7”

NODE Controller è un control plane di k. che gestisce diversi aspetti relativi ai nodi:

- assegnare il blocco CIDR quando il nodo viene registrato (se il CIDR assignment è attivo)
- mantenere la lista dei controller interni sui nodi aggiornata con la lista delle macchine disponibili del cloud
- mantenere aggiornato lo stato del nodo, aggiornando il valore Ready (true/unknown) dello stato del nodo in
base alla raggiungibilità del nodo; il controllo per ogni nodo avviene ogni 5”, valore che può essere modificato
intervenendo con l’opzione --node-monitor-period nel kube controller manager
- chiamare l’api initiated eviction se il nodo per tutti i pod del nodo non raggiungibile, di solito aspetta 5’ prima di
chiamare l’api se il nodo non è raggiungibile
Elenco comandi lanciati durante demo/laboratori e rispettivo significato

comandi a kubeadmin significato

init
join 192.168.100.130:6643 --token .... \
--discovery-token-ca-cert-hash sha...
kubeadm token create --print-join-command
inizializza nodo master del cluster restituisce messaggio su
come lanciare sui nodi slave kubeadm join
comando per fare la join a un cluster kubernetes esistente
comando che ci permette di creare un nuovo token e
ottenere il comando da lanciare sui nodi da agganciare al
nostro cluster (visualizza il token per autenticare il nodo
nel cluster)

comandi kubectl get significato

get no torna l’elenco dei nodi di un cluster di kubernetes
get no –o wide torna l’elenco dei nodi di un cluster di kubernetes con info
più dettagliate
get po torna l’elenco dei pod
get pods
get po --show-labels torna l’elenco dei pod corredati delle labels associate a
get pods --show-labels ciascun pod
get po –w torna l’elenco dei pod aggiornandolo con nuovi eventi
get pods –w (cambio di stato)
get po --all-namespaces torna l’elenco dei pod di tutti i namespaces
get pods --all-namespaces
get po –n demo torna l’elenco dei pod nel namespace demo con info
get pods –n demo sintetiche
get po –namespace=demo
get pods –namespace=demo
get po –n demo –o wide torna l’elenco dei pod nel namespace demo con info
get pods –n demo –o wide estese
get po –namespace=demo –o wide
get pods –namespace=demo –o wide
get po –n demo –w torna l’elenco dei pod nel namespace demo, aggiorna
get pods –n demo –w dinamicamente la schermata se ci sono dei cambi stato
get po –namespace=demo –w
get pods –namespace=demo –w
get po demo-pod –n demo –o yaml torna le informazioni dettagliate in formato yaml del pod
get pods demo-pod –n demo –o yaml demo-pod contenuto nel namespace demo
get po –A –l app.kubernetes.io/name=ingress-nginx torna le info dei pods che possiedono la label
get pods –A –l app.kubernetes.io/name=ingress-nginx app.kubernetes.io/name=ingress-nginx
get po --selector="app=webserver" -o wide torna le info dei pods che possiedono la label app:
get pods --selector="app=webserver" -o wide webserver
get po --all-namespaces -o wide --field-selector torna i pod di tutti i namespaces relativi al nodo k8s-
spec.nodeName=k8s-master1 master1
get pods --all-namespaces -o wide --field-selector
spec.nodeName=k8s-master1
get po etcd-k8s-master1 –n kube-system –o=yaml torna le info del pod etcd-k8-master nel namespace kube-
get pods etcd-k8s-master1 –n kube-system –o=yaml system in formato yaml
get svc torna l’elenco dei services
get services
get svc –o wide torna l’elenco con info più dettagliate dei services
get svc –n demo torna l’elenco dei services nel namespace demo
get svc –namespace=demo
get ns torna l’elenco dei namespaces
get namespace
get endpoints torna l’elenco degli endpoints
get rs torna l’elenco dei replicaset
get replicaset
get rs –n demo torna l’elenco dei replicaset nel namespace demo
get replicaset –n demo
get all –n demo torna l’elenco di tutti gli oggetti nel namespace demo
get deploy torna l’elenco dei deployments
get deployments
get deploy –n demo torna l’elenco dei deployments nel namespace demo
get ing simple-ingress –o wide –w torna l’elenco con info estese dell’ingress simple-ingress
get –f ./config/web.yaml –o yaml torna le informazioni in formato yaml degli oggetti
identificati nel file web.yaml

comandi kubectl run significato

run pod1 --image=nginx
run pod2 --image=httpd –l os=alpine
run pod3 --image=nginx --dry-run=client -o yaml >
pod3.yaml
run alpine --rm -ti --image=alpine - - /bin/sh
run alpine --rm -ti –l allow=true --image=alpine - -
/bin/sh
alloca un pod chiamato pod1 con immagine nginx
alloca un pod chiamato pod2 con immagine httpd e label
os=alpine
stampa in formato yaml le informazioni necessarie ad
allocare un pod chiamato pod3 con immagine nginx e le
salva sul file pod3.yaml (utilizzabile dopo per una
create/apply)
esegue un pod chiamato “alpine” con una immagine Alpine
permettendoci di interagire con esso tramite una shell (--
rm rimuove la risorsa appena usciremo dalla shell, --ti per
ottenere in terminale interattivo)
come precedente ma con label allow=true

comandi kubectl create significato

create ns demo
create deploy web –image=nginx –n demo
create deploy web –image=nginx –n demo
create deploy demo-deploy –image=ngix –replicas=3
create deployment intranet --image=httpd --dry-
run=client -o yaml > intranet.yaml
create –f web.yaml
create –f web.yaml –n demo
crea il namespace demo
crea un deployment con nome web usando l’immagine
nginx (scarica da docker)
crea un deployment con nome web usando l’immagine
nginx (scarica da docker) nel namespace demo
crea un deploy con nome demo-deploy usando l’immagine
nginx (scarica da docker) con un fattore di replica (numero
pods) 3
stampa in formato yaml le informazioni necessarie ad
creare un deployment chiamato intranet con immagine
httpd e le salva sul file intranet.yaml (utilizzabile dopo per
una create/apply)
crea gli oggetti descritti nel file web.yaml
crea gli oggetti descritti nel file web.yaml nel namespace
demo

comandi kubectl scale significato

scale –replicas=5 deploy/web –n demo modifica il fattore di replica a 5 per il deployment con
scale –replicas=5 deployment web –n demo nome web che è stato fatto nel namespace demo
NB: lo scale viene eseguito sempre sul replicaset, pertanto
non viene considerato nel caso di rollback dei deployment

comandi kubectl set image significato

set image deployment webservers nginx=httpd –n modifica la image del deployment webservers nel
intranet namespace intranet da nginx a httpd

comandi kubectl rollout significato

rollout status deployment/nginx-deployment torna lo status del rollout del deployment specificato
rollout status deployment nginx-deployment (ngnx-deployment)
rollout undo deployment/intranet –n marketing effettua il rollback del deployment intranet nel namespace
rollout undo deployment intranet –n marketing marketing a versione precedente

comandi kubectl delete significato

delete ns demo elimina il namespace demo e tutte le risorse (pod,
delete namespace demo deployment etc) in esso contenute
delete –f svc.yaml elimina gli oggetti descritti dentro il file svc.yaml
delete po demo-pod –n demo elimina il pod chiamato demo-pod nel namespace demo

altri comandi kubectl significato

replace –f web.yaml rimpiazza (update) le proprietà degli oggetti indicati in
web.yaml con quanto indicato nello stesso file con
l’approccio imperativo
apply –f ./config/ usando l’approccio dichiarativo applica al sistema le
modifiche tali da ottenere lo stato desiderato dai file .yaml
contenuti nella cartella config
diff –f ./config/ usando l’approccio dichiarativo torna le diff tra la
configurazione attuale del sistema e quella descritta nei
files yaml contenuti in config
api-resources torna l’elenco dei tipi di risorsa conosciute nel sistema
api-resources --namespaced=true torna l’elenco dei tipi di risorsa conosciute rispettivamente
api-resources --namespaced=false dentro o fuori al namespace
describe ns demo descrive le caratteristiche del namespace demo
describe svc kubernetes descrive le caratteristiche del service kubernetes

exec nginx-pod –n demo –it -- /bin/sh
label node k8s-worker3 zone=west
labeled --list no k8s-worker1
expose deploy nginx --port=80
taint node k8s-master1
node-role.kubernetes.io/master:NoSchedule-
taint node k8s-worker3 memory=large:NoSchedule
taint node k8s-worker3 diskType=ssd:NoExecute
DOCKER
(sudo) docker ps
(sudo) docker stats –all –format “table {{.Container}}\
t{{.CPUPerc}}\t{{.MemUsage}}” <id_container>
HELM
sudo snap install heml - - classic
helm repo add http://charts.helm.sh/stable
helm search repo stable
helm install stable/mysql - -generate-name
esegue un comando sul pod nginx-pod del namespace
demo (terminale interattivo)
aggiunge la label al nodo k8s-worker3 zone=west
visualizza tutte le label del nodo k8s-worker1
espone il deploy con nome nginx nel default namespaces
sulla porta 80 nel cluster
rimuove (segno – alla fine)
il taint node-role.kubernetes.io/master:NoSchedule
dal nodo k8s-master1
aggiunge il taint memory=large al nodo k8s-worker3, tutti i
nuovi pod che non hanno la toleration compatibile (=non
rispettano tale taint) non verranno schedulati su tale nodo
aggiunge il taint diskType=ssd al nodo k8s-worker3, il
NoExecute impone che vengano rimossi dal nodo tutti i
pod che non hanno toleration (non rispettano) con tale
taint
elenco processi docker che stanno girando sulla macchina
torna le statistiche di utilizzo risorse di un determinato
container docker
installa helm (sul nodo master) in modalità classic,
disabilitando il security confinement
aggiunge la repo di charts stabili
visualizza le chart disponibili sulla repo stable
installa il chart mysql generando un nome in automatico