Kubernetes: il costo operativo di colpire ogni chiodo con un martello

più grande bugia nel mondo della tecnologia degli ultimi 5-6 anni è: «Metti la sua app su Kubernetes e farà il resto». Chi salirà sul palco delle conferenze Le dirà quanto sia «autorigenerante» Kubernetes (K8s) e uno straordinario strumento di orchestrazione. Ma nessuno Le parla del costo dell'esercito di ingegneri necessario per dirigere quell'orchestra.

La triste verità è che Lei non è Google. Probabilmente non ha nemmeno i problemi di scalabilità di Google. Ma a causa della «FOMO» (paura di essere lasciato indietro) nel settore, Lei cerca di gestire anche un semplice sito web con un sistema complesso di pannelli di controllo dei sottomarini nucleari. Diamo un'occhiata a questa fattura invisibile «inferno YAML».

1. Operazioni del «secondo giorno»: il sogno è finito, la realtà inizia

Configurare il cluster Kubernetes è la parte facile («Giorno 1"). L'incubo principale inizia con le operazioni del «Giorno 2». Mantenere aggiornato il cluster, gestire le rotazioni dei certificati, le incompatibilità delle versioni

• Costo delle risorse umane: gestire K8s è di per sé un lavoro a tempo pieno. È compito dei suoi sviluppatori scrivere codice o eseguire il debug del motivo per cui Ingress Controller
non sta indirizzando il traffico?
• Abstraction Leak: Dicono che l'hardware del K8 sia astratto ma è una bugia. Nel momento in cui imposta i limiti della CPU (`richieste` e `limits`) in modo errato, la sua applicazione si interrompe silenziosamente con l'errore «OOMKilled» (Memoria
esaurita).
• Rete: comunicazione tra POD, Service Mesh, plugin CNI... Una semplice richiesta HTTP può trasformarsi improvvisamente in un problema di ingegneria di rete intrattabile

2. Sviluppo basato sul curriculum

Quando entro in un'azienda come esperto scettico, la prima cosa che guardo è: questa architettura è stata imposta dai requisiti del lavoro o è il desiderio degli ingegneri di scrivere «Kubernetes Expert» nei loro CV?

Se la sua applicazione si inserisce in un singolo server virtuale (VM) e la divide in un cluster K8s di 3 nodi, l'unica cosa che risolve è

3. Vulnerabilità causate dalla complessità

La complessità è il nemico numero uno della sicurezza. Le impostazioni predefinite di Kubernetes sono generalmente «orientate al lavoro», non «sicure».

un contenitore Docker con autorità root, aggiramento della gestione dei segreti (crittografia ecc.) o regole RBAC (Role-Based Access Control) configurate in modo errato... Per gli hacker, K8s è un parco di divertimenti se configurato in modo errato. Per garantire la sicurezza dei K8, Le occorrono strumenti extra (Trivy, Falco, ecc.) e più tempo per gestirli.

4. Quando è K8s, quando è

Quindi, dovremmo buttare via Kubernetes? No. Troviamo l'unghia giusta.

• Microservice Hell: Se ha davvero più di 50 microservizi da gestire e parlano intensamente tra loro, il K8s è un salvatore.
• Applicazioni monolitiche: Se ha un'applicazione monolitica, dockerizzarla ed eseguirla su un semplice PaaS (Heroku, DigitalOcean App Platform, ecc.) o un servizio container gestito (AWS ECS) Le costerà l'80% in meno di carico operativo.