Please enable JavaScript.
Coggle requires JavaScript to display documents.
Kubernetes OPS - Coggle Diagram
Kubernetes OPS
Configurazioni K8s
VPC-Native
default ora no, diventerà si.
Ottimizzazione instradamento,
necessità IP aliasing
-
OS NodePool
Container OS (COS)
Base Chromium OS, ridotto all'osso e ottimizzato per eseguire container. Per verifica dei problemi bisogna installare ogni cosa.
Meno roba, meno vulnerabilità.
Usa il Docker Runtime per eseguire i container.
COS containerd
Come Container OS (COS) ma il runtime è containerd.
Containerd è un container enginer è progetto (con Docker come contributor) che ha solo le funzionalità per eseguire container (non per crearli, ecc...)
Diventerà standard per uso in Kubernetes
Ubuntu
Distribuzione Ubuntu. Più pesante ma ci dà la possibilità di installare librerie in più, ecc..
Runtime Docker
Regional/Zonal Cluster
Regional Cluster
-
Tutte le zone di una regione devono avere la stessa topologia
Se imposto 2 nodi nel nodePool saranno 2 nodi per zona e un master per ogni zona
Si pagano solo i nodi worker (no master)
Resilienza, se va giù una zona non ci sono problemi.
99.5 uptime
Posso aggiornare un master senza problemi visto che rispondono gli altri. Tutti i master possono gestire tutti i nodi, anche in altre zone
Zonal Cluster
-
-
Se aggiorno master perdo funzionalità di controllo, healtcheck, ecc...
I nodi continuano ad andare.
si possono impostare più zone così da avere nodi in più zone. Una è principale (dov'è sempre il master), le atre secondarie. Se non va giù la zona principale ma un'altra i nodi della zona in fallimento possono essere ricreati sull'altra. Se va giù la zona principale con il master non succede.
Autoscaling
Node
-
Si usano metriche, di default usa la CPU.
Soglia configurabile e anche metriche valutate in autoscaling.
node auto-provisioning
GKE permette di modificare le caratteristiche delle VM dei nodi. Si può ad esempio aumentare le CPU e la memoria
Il cluster, se abilitato l'autoscaling, gestisce il numero di nodi ed è in grado di crearli/distruggerli
Si definisce un min-nodes e un max-nodes
Si basa sulle metriche
Scale-up facile, scale-down meno perché i pod si spengono in modo bilanciato e non ad esempio solo su una macchina. In pratica non avrò mai una macchina scarica.
Pod
Horizontal pod autoscaler (HPA)
Gestisce in modo automatico il parametro replicas del deployments e di conseguenza aggiunge o diminuisce copie.
Lavora anche su più zone.
Vertical pod autoscaler (VPA)
Permette di definire uno scaling di risorse di CPU/Memoria del Pod. Non funziona a caldo, il pod va distrutto e ricreato.
Consigliato per capire di quante risorse ha bisogno un pod. In produzione non è consigliato perché quando scala ci sono errori su chi sta usando il pod.
Load Balancer
Esterno
Non sono nella network, proxy all'esterno e non controllati da noi. Su Google possono configurare Cloud Aware Proxy, CDN, protezione DoD
Creato da k8 se creato un ingress e non creato da console si possono configurare le feature speciali di Google con le annotation (si chiamano backendConfig).
-
GPU & TPU
E' possibile associare ai nodi GPU/TPU. Costose.
Non tutte le CPU possono montarle e dipendono dalle zone
Sono fisicamente collegate alle macchine e limita le sue capacità di migrazione. Quindi deve essere distrutta e ricreata.
Se uso GPU/TPU le VM non possono essere preemptible
Si devono creare almeno due NodePool, uno primario senza GPU e uno secondario con le macchina GPU. Nel primario gira master che così non paga la GPU
Anthos
-
Usato per multi-cluster
Fa si che più cluster possano essere visti come uno.
Multi-cluster permettono di superare limite della Region, del vendor, ecc...
-
Le configurazioni sono gestite su un repo Git, Anthos Configuration Managment si occupa di propagare configurazioni sui vari cluster
Private clusters
-
Usa nodi privati (non hanno IP esterno, NO internet)
-
-
Master può avere ragionamento a parte.
Visto che è in un altra network può essere privato o pubblico. Se è privato bisogna accedere dalla rete dei nodi worker (c'è il peering), se è public si dovrebbero impostare delle regole di firewall (es. ip whitelist)
-
GKE Upgrades
Kubernetes
Modalità:
Automatica (opzione release channel)
Gestita tramite console, Google ha una finestra di versioni e decide quando e aggiornare. Noi possiamo scegliere il canale di aggiornamenti (ad esempio solo le stabili). Pensa lui ad aggiornare master e nodi
Manuale (opzione static)
Decido i quando aggiornare. Si può fare dalla console tramite pulsante e poi ci pensa lui. Si deve lanciare aggiornamento del master poi aggiornamento nodi.
-
-
si usa semantic versioning. Possibili problemi ci sono aggiornando di 3 minor (i deprecati sono annunciati con 2 versioni di anticipo)
Forma x.y.z-gke.n => n è il numero di patch
Considerare affinità/anti-affinità. Ad esempio VM con GPU e pod che devono girare solo su quelle macchine
Considerare aggiornamento OS Nodi.
Se si sceglie COS => ci pensa Google con politiche di rolling update
Se si sceglie Ubuntu => ci dobbiamo pensare noi
Sulle lib/software sui nodi => nostra responsabilità
-
Consigliato avere diversi ambienti k8s (prod, staging, dev) e tra questi una distanza massima di 2 salti così da anticipare tempi.
Es.
Se uso static => prod 1.17, staging 1.18, dev 1.19
Se uso finestra => prod stable, staging regular, dev regular
Strategie di upgrade può gestire una strategia blue-green o expand and contract (default, rolling update). Per expand and contract serve anche un sistema per validare la nuova configurazione così posso eliminare la vecchia in modo automatico. Per blue-green serve che il sistema sia duplicabile, se non è ammesso non può essere usata.
Prima di farlo considerare:
- piano di downgrade
- verificare changelog per eventuali aggiustamenti ai progetti
- i deprecati sono annunciati 2 minor prima
- più facile se cluster regionale, potenzialmente nessun disservizio sul master
API
Sono REST e versionate.
La forma è <gruppo>/v1/<kind risorsa>
Sono specificate nei descrittori nei campi in testa:
apiVersions: apps/v1
kind: Deployment
-
-
Versioning (sul gruppo) ha 3 livelli: alpha (disabilitata di default), beta, GA (stable). Per passare in beta ci vogliono almeno 9 mesi/3 release di alpha, per GA 1 anno/3 release di beta.
kubectl convert -f pod.yaml --output-version v1
Tool automatico per convertire le versioni dei descrittori. Attenzione che va di minor in minor.
-
-
Sicurezza
Project security
Access
controllare chi ha accesso ai vari cluster (ambienti, es. prod o dev). Adottare regola dei privilegi minimi. Usare IAM
Isolation
Cluster di produzione devono essere isolati.
A livello di network attenti a shared VPC e anche a VPN e risorse condivise come risorse on-premise, a scaling dei nodi
Configurazione
Compliance: dare regole di comportamento (soft o hard). Es. IP esterni non possono essere creati, adottare processo di code review
Consistency: usare strumenti centralizzati, già usati, template
Repeatability: automatizzare quando possibile per evitare errori
Riduzione accessi: limitare accessi (anche service account)
Risorse
Quotas: dimensionare quote per evitare starvation. Attenzione anche a casi ad es. per rispondere ad un attacco
Le quote possono essere definite a livello di cluster (così da limitarli), attenti però che più le quote sono distribuite e più è complicato capire il quadro generale.
Strategie
One shared cluster
Shared project
Shared cluster
Un namespace per environment
Pro: semplice
Contro: poca difesa, se entrano entrano su tutti, IAM condivisi sugli env, poco isolamento sulle risorse, stesso master
Cluster per env
Shared project
Cluster per ogni env
Pro: nodi isolati, master isolati, un solo progetto da gestire
Contro: IAM condivisi, gestione configurazione
Project per env
Un project per env
Un cluster per project
Pro: difesa, IAM indipendenti, isolamento nodi, master isolati
Contro: costa di più la gestione
Key point
- livello di isolamento (env/team)
- utenti hanno diversi permessi tra env
- ci sono compliance requirement diversi (env/team)
- altri motivi per il full isolation
- region diverse?
Cluster security
Network
Firewall
Traffico ammesso o no. Attenti a traffico tra nodi (healthcheck, loadbalancer, ad esempio)
-
-
Ip masquerading
Permette di nascondere gli IP dei nodi quando fanno chiamate esterne. Si esce con un IP. Utile per gestire le regole di firewall. Requisiti IP aliasing e network policy
Consiglio abilitare IP aliasing e network policy (se abilitato dopo va ricreato cluster e se non usato non fa nulla)
Network Policy
Va abilitato. Google usa Kaniko, permette di definire policy di comunicazione tra pod (o tutto quello che può ricevere pacchetti). Definisce regole di ingress e/o egress applicati a podSelector. Regole by namespace, by pod, by IP.
Valori di default
-
-
Node service account (all'attivazione di compute engine API è creato un service account con privilegi editor e se entro in una macchina e chiamo API di Google e non specifico un utente usa quello) -> soluzioni 2: IAM di secondo livello, non usare service account di default
Workload identity, permette di usare un solo service account sui nodi e filtrare i privilegi dal namespace.
Metadata server (la macchina VM per sapere informazioni su sé stessa può chiedere a un servizio di rete). Può essere usato per attacchi sulla macchina. Si può limitare accesso a metadata service usando credenziali.
Accesso
-
Role-Based Access Control (RBAC)
Permessi interni al cluster, ad esempio se un utente ha visibilità o meno su un namespace. Non sono mappati su Google con IAM ma all'interno del cluster. Google in base ad IAM può impostare a livello di cluster (ad esempio developer può gestire k8s API)
-
Permette di configurare chi ha accesso a quale risorsa (kind) e con quale privilegio. I permessi sono a loro volte risorse.
Possono essere su determinate operazioni (leggere/scrivere secret). Se pensiamo a REST possiamo pensare a quale CRUD posso fare su una determinata risorsa.
Ogni pod ha un service account (se non specificato default). Posso dare permessi sul service account.
Definizione ruoli (collezione di permessi)
ClusterRole
Vale a livello di cluster
Role
Vale a livello di namespace (altri namespace non vedono questo ruolo)
-
-
Application security
-
Resource Limit
Quote su risorse per namespace per limitare risorse che può prendere un namespace. Così un applicazione non può saturare cluster
Host Network
Se abilitata i pod possono usare l'ip del nodo. Ma è un male perché non si distiugue più se è il nodo o il pod a fare richieste. Il pod accedere alle risorse dedicate al nodo. Più POD non possono fare bind sulla stessa porta (solo 1).
Da evitare! IP masquerating diverso perché è un NAT
Service account del custer
Le comunicazioni partono dal POD, su k8s per definire cosa può fare un POD si definiscono dei service account. In RBAC definisco poi cosa può fare. Campo serviceAccountName nel descrittore del POD. Se non definisco è usato il service account chiamato default a cui assegna un RBAC di default
Security contexts
Sono dei privilegi con cui si configurano il lancio del container. Ad esempio, un container può partire in modalità privilege (può usare utente root) o no. Per farlo si usano dei flag nel comando.
Pod security policies
Flag da abilitare dal cluster e abilita un controller su k8s che prende in input un descrittore che contiene le condizioni di base di sicurezza a cui tutti i pod devono sottostare. Lavora a livello di cluster. Ad esempio posso indicare che root non si può usare
Resource Quotas
Se un pod non specifica le risorse di cui ha bisogno con le quote ti do un default. Possibile definire hard o soft. Hard vince su quello difinito a livello di POD
Limit Range
Sui POD è possibile definire le risorse di cui ha bisogno. Possono essere 2, il minimo (default) e il max.
Binary authorization
Copre il gap che c'è tra il rilascio del codice e il deploy vero e proprio. Ad esempio fasi di test.
All'immagine viene posta una firma che viene verificata al deploy. Posso definire anche policy su chi ha creato l'immagine.
Certificati
Si possono usare certificati gestiti (stile let's encrypt) e gestisce Google. Con rolling update ogni 3 mesi.
