conraid ha scritto: ↑mer 26 feb 2020, 18:05
sono hipster e usano il mac ahahaha
Ehi! Guarda che prima di essere stato illuminato sulla via di Damasco da Tim Cook ero uno Slackwarista anch'io!
miklos ha scritto: ↑mer 26 feb 2020, 20:58
ci lavoro da poco ma ho visto fare cose a openshift tipo l'autoscaling dei container in base al traffico (in più e in meno).. switch di intere piattaforme containerizzate da una versione all'altra davvero con 2 click dal browser..e queste cose con le tecniche tradizionali (virtualizzazione e bare metal classici) non sono cosi immediate...
Senza contare le funzionalità di ResourceLimit/Quota che ti permettono di partizionare le risorse allocate sui singoli pod o addirittura container.
poi se vai a scavare nella piattaforma trovi attrezzi tipo haproxy + dnsmasq per gestire l'autoscaling e le rotte fra i vari container...e quindi capisci che alla fine linux quello è e la gente sveglia ci sarebbe comunque riuscita...
Beh, da un punto di vista teorico sì, hai ragione perché è tutto software-defined.
Dal punto di vista pratico, non proprio. Fare che quello che fa Kubernetes è una roba mica da ridere, perché fa astrazione di tutte le componenti di un data center per permetterti di sostituirle con chi ti pare e piace senza effort o senza intaccare il resto dell'infrastruttura.
Puoi sostituire un Ingress Controller con un altro e non accorgerti che sei passato da NGINX ad HAProxy nel giro di poche frazioni di secondo, perché tutto ciò che hai cambiato era una Annotation nel manifest della Ingress.
Lo stesso dicasi per lo storage: vai a fare provisioning delle LUN in automatico per ogni nuovo applicativo che va in produzione, senza una roba come Kubernetes. Minimo dovrai rimboccarti le maniche e scrivere una soluzione "dipendente" dal vendor in Ansible e testarla
rigorosamente (è lo storage di produzione, d'altronde). Io, avendolo fatto, per una grossa banca italiana che usava EMC VMAX, ti posso assicurare che è una roba non da poco.
Con Kubernetes hai le Storage Class. Tu crei la tua Storage Class e via: hai il provisioning di volumi automatico e su misura per le tue esigenze.
Devi fare una resize di un volume? Bene, con Kubernetes: patch sul PVC e via. Con VMAX a manella...
beh, lasciamo stare che è meglio.
Cioè, sia chiaro: Kubernetes è magia nera. Lo sappiamo. Ma piace proprio per quello. Perché scriversi la roba a manella pesa parecchio, e spesso è lavoro inutile che non puoi riciclare perché sei legato mani e piedi ad una infrastruttura specifica.
Kubernetes fa da framework, astraendo tutto e permettendoti di focalizzarti su ciò che ti serve davvero. Poi vabbe', il sistemista serve comunque. Ma quello è scontato.
Kubernetes va mantenuto, e richiede comunque delle skill apposite.
ponce ha scritto: ↑mer 26 feb 2020, 22:15
il problema e' che il 99% delle persone lo usa male, pacchettizzando dei container che tempo pochissimo hanno giocoforza software obsoleto e redistribuendoli, facendo credere che non serva piu' essere degli amministratori di sistema per far funzionare le cose: e' questa gente che mi fa fare affermazioni come quella sopra.
Beh, quello dipende dal fatto che per alcuni qualunque fogna da cui prendere i container, tra cui Docker Hub, va bene. Docker Hub è l'AUR di Docker, e proprio come AUR è una fogna in cui ci trovi di tutto, dal software ufficiale allo spacciatore di crack che di solito sta all'angolo della via.
Una buona strategia sarebbe quella di fare immagini in casa, basandole su fonti ufficiali, e metterle in un registry privato, che magari faccia anche vulnerability scanning. Red Hat Quay lo fa usando clair.
Se invece poi si vuole andare di tiziorandom/paperino:latest perché è comodo, beh... non è tanto diverso dal prendere rpm a caso da repository non ufficiali.
:cf
)