Buongiorno, vi chiedo perdono per l'estrema lunghezza di questo messaggio, se non vi interessa approfondire i concetti alla base di kubernetes et al fareste meglio a ignorarmi :-)
Damiano Verzulli <dami...@verzulli.it> writes: > Cambio oggetto e espando la discussione... perché trovo spunti degni di > approfondimento: chissa' che con questo thread non facciamo --almeno > qui, in lista, con diversi "*NON* addetti ai lavori"-- un po' di > chiarezza... Giusto cercare di fare un po' di chiarezza almeno in questa lista, purtroppo però le cose sono sufficientemente complesse da risultare a volte poco chiare anche agli addetti ai lavori, me per primo sicuramente. > Il 02/05/24 6:33 PM, Giuseppe Attardi ha scritto: >> [...] >> Kamal, da una breve scorsa alla documentazione, è qualcosa tipo >> Ansible [...] Hanson spiega che Kubernetes è complesso e richiede >> competenze (appunto come sospettavo), perché è “dichiarativo”. Iniziamo con un paio di concetti: 1. kubernetes è un sistema di gestione dei cluster, piuttosto complesso https://en.wikipedia.org/wiki/Kubernetes; di sistemi di gestione cluster è piena la storia dell'IT [1], kubernetes non sarà l'ultimo... e nemmeno il penultimo. La caratteristica di kubernetes, che lo rende così /complicato/, è che *ingloba* un sacco di altri servizi che in altri sistemi di gestione dei cluster sono lasciati ad altri software che i sistemisti devono scegliere, installare e configurare indipendentemente. 2. ansible è un sistema di gestione della configurazione (Infrastructure as Code) https://en.wikipedia.org/wiki/Ansible_(software); di sistemi di configuration management è piena la storia dell'IT, ansible non sarà l'ultimo e nemmeno il penultimo :-) > Kubernetes è complesso... perché chi l'ha pensato aveva in mente di > gestire il workload di Google, su scala worldwide. A quella scala, la > complessità di kubernetes... è insignificante rispetto > all'infrastruttura che dovra' gestire. I sistemi di "cluster management for world sized cloud infrastructure" sono figli dell'/ideologia/ "pets vs cattle" [2] --8<---------------cut here---------------start------------->8--- Pets Servers or server pairs that are treated as indispensable or unique systems that can never be down. Typically they are manually built, managed, and “hand fed”. Examples include mainframes, solitary servers, HA loadbalancers/firewalls (active/active or active/passive), database systems designed as master/slave (active/passive), and so on. Cattle Arrays of more than two servers, that are built using automated tools, and are designed for failure, where no one, two, or even three servers are irreplaceable. Typically, during failure events no human intervention is required as the array exhibits attributes of “routing around failures” by restarting failed servers or replicating data through strategies like triple replication or erasure coding. Examples include web server arrays, multi-master datastores such as Cassandra clusters, multiple racks of gear put together in clusters, and just about anything that is load-balanced and multi-master. --8<---------------cut here---------------end--------------->8--- (http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/) Come se i due insiemi descritti sopra fossero davvero _disgiunti_: sarà mica una cosa seria? (e infatti kubernetes usa il termine "Pet Sets" che l'autore dell'articolo sopra contesta... non proprio "rocket science" diciamo :-D ) L'ideologia "pets vs cattle" è stata osannata come il "nuovo (cattle) che avanza sul vecchio (pets)", nonostante sia _evidente_ sia è frutto di mistificazione su come funzionavano i sistemi "high availability clusters" già mooolto tempo prima che il _meme_ fosse inventato. Il tutto è anche frutto della confusione assordante tra "scale-out" vs "scale-up", che tra l'altro sono problemi che si incontrano _regolarmente_ nel ciclo di vita di una infrastruttura IT, che essendo "fatta di bit" è da decenni che è "nomade". Tutto ciò ha portato alla /reificazione/ del concetto che i container sono _ephemeral_ by nature... tranne che i dati (https://en.wikipedia.org/wiki/Kubernetes#Storage) e le configurazioni (https://en.wikipedia.org/wiki/Kubernetes#etcd) che servono non lo sono affatto: Comunque: --8<---------------cut here---------------start------------->8--- You don't need Kubernetes when the following four conditions are true: 1 You are deploying a very small number of containers to a very small number of machines (hosts). 2 The number of containers and machines is static and does not scale up or down. 3 Your containers and machines do not fail often. 4 You do not need additional features like persistent storage, LoadBalancing, configuration management, service discovery, autohealing, autoscaling, etc. Or you do need those features but you have very limited requirements and don't mind vendor lock-in. --8<---------------cut here---------------end--------------->8--- (via https://home.robusta.dev/blog/kubernetes-is-complex-because-you-want-complex-things) Il punto 4 sopra mi fa rotolare dal ridere, come se "persintent storage" (che è lo standard storage dal 1960), "distributed storage", "load balancing" ecc. non fossero già implementati e usati in produzione da anni prima che fosse "inventato" kubernetes (con autoscaling e _soprattutto_ autohealing che meriterebbero un capitolo a parte). Il punto 3 (Your containers and machines do not fail often) è pura poesia: se i tuoi container falliscono spesso, caro sistemista, hai uun problema e invece di mettere in pista kubernetes per sparare a raffica container che falliscono, sarebbe opportuno fare debugging. Il combinato disposto dei punti 1 e 2 sopra fa sì che sistemi complessi come kubernetes vanno bene solo se l'infrastruttura deve vendere macchine (containers) usa e getta (per te) perché hai tonnellate di ferro che non stai usando e devi in qualche modo riciclare facendolo pagare almeno 10 volte tanto a chi fa fatica a gestirsi la propria infrastruttura IT in autonomia (anche avvalendosi di terzi neh, ma il concetto fondamentale è /autonomia/). > Il discorso cambia a scale piu' piccole (Ateneo, ASL, Regione...). A > queste scale, la complessita' di K8S si sente, forte. E' la stessa scala > di Hey/Heinemeier e per questo Heinemeier ha premuto "reset": a lui, > semplicemente, non serviva. Meglio: era sufficiente qualcosa di *MOLTO* > piu' semplice. > > E' un folle? E' un ignorante? Oppure è semplicemente un "realista"? É un sistemista che ha ben presente lo "use case" di kubernetes e ha chiaramente capito che a lui proprio non serve. Dopotutto deve /solo/ erogare 4/5 applicazioni web con backend per i dati, mica fare AWS. ...poi essendo un bravissimo sviluppatore si diverte anche a reinventare la ruota (Kamal) perché gli piace fare "il sarto", ma vabbè, ognuno ha il suo ego :-) [...] >> Appunto, dichiarativo vs procedurale. >> La differenza sta lì, da una parte fai tutto tu a mano, devi tenere >> traccia di tutyo e ogni modifica costa quanto ricominciare daccapo. Questa "una parte" sarebbe Ansible? Ma Ansible è dichiarativo! ...ormai "tutto è dichiarativo" :-)... "Infrastrutcture as Code". >> Dall’altra hai un sistema dichiarativo, in cui specifichi i requisiti >> e gli obiettivi, e il software che gestisce la piattaforma, determina >> i passi per attuare la soluzione. Come il venerabile CFEngine... in teoria (Promise Theory) :-O ...e Puppet, Salt, Chef; ma in pratica... Il problema irrisolvibile per tutti i sistemi di configuration management per sistemi operativi la cui gestione dei pacchetti _e_ della configurazione è _stateful_ [3] è che è praticamente impossibile ottenere l'idempotenza [4]. Nel caso specifico dei container Docker definiti coi Dockerfiles, l'idempotenza è _doppiamente impossibile_. Nel caso di Ansible: --8<---------------cut here---------------start------------->8--- Reliable. When carefully written, an Ansible playbook can be idempotent, to prevent unexpected side effects on the managed systems. It is possible to write playbooks that are not idempotent. --8<---------------cut here---------------end--------------->8--- (https://en.wikipedia.org/wiki/Ansible_(software)#Design_goals) Divertente "it is possible... not idempotent": chiunque ha un po' di esperienza con simili sistemi sa che la promessa di poter ottenere "playbook" (o "manifests") idempotenti è una... _forzatura_ Per fare un esempio semplice su cosa significa idempotenza in una dichiarazione di un "manifest" Puppet (su cui ho esperienza) et al, per installare un pacchetto, nel manifest del sistema devi dichiarare: --8<---------------cut here---------------start------------->8--- package { 'openssh': ensure => installed, name => openssh, [...] } --8<---------------cut here---------------end--------------->8--- (https://www.puppet.com/docs/puppet/7/types/package.html) e poi applicare il manifest al sistema per ottenere il nuovo stato. Se il pacchetto NON lo vuoi, invece, non basta _non inserire_ quella dichiarazione dal manifest di sistema ma devi dichiarare: --8<---------------cut here---------------start------------->8--- package { 'openssh': ensure => absent, name => openssh, [...] } --8<---------------cut here---------------end--------------->8--- e poi *applicare* il manifest al sistema... tranne che magari "openssh" è una dipendenza di altri packages e il manifest non "concilia". [...] > Ed e' finita che oggi, una parte consistente della "mia" > infrastruttura è definita (e gestita) con "terraform" [1], soluzione > di riferimento in ambito dichiarativo: server virtuali, dischi, > segmenti di rete, regole di firewalling e di routing sono tutte > definite "dichiarativamente". Sì ma anche Damiano è incappato in quello che prima o poi succede a tutti coloro che hanno usato simili sistemi dichiarativi /supposti/ idempotenti: la dichiarazione NON coincide con lo stato :-( https://www.garrlab.it/p3_terraform_state/ --8<---------------cut here---------------start------------->8--- Today I discovered a mismatch between the state and the real infrastructure. If not addressed and solved, such a mismatch could cause serious problem to the infrastructure itself (dropping and re-creating three OpenStack instances… and related services!) [...] So, now it’s clear that the image used to build the three VMs were gone, and replaced with a different one, with same name. [...] The bad image ref id (00ece84f-c723-4ea0-a4fb-5555bea06c8d) is tightly associate to the VM at the OpenStack level. The same problem apply to the other two VMs: --8<---------------cut here---------------end--------------->8--- La cosa è (ovviamente) risolvibile, come ha dimostrato Damiano, ma c'è stato bisongo di un processo di _riconciliazione_ tra la dichiarazione e lo stato, cosa che in un sistema idempotente sarebbe... impensabile [...] > Dall'altro lato, mi è chiarissimo il paradigma "imperativo" (hai citato > "ansible"), anche lui ampiamente testato in questi anni. > *NON* concordo sulla tua affermazione: "/...ogni modifica costa quanto > ricominciare daccapo.../". No infatti, secondo me è fuorviante; con Ansible (et al) raramente è necessario "ricominciare daccapo" > Non conosco gli altri strumenti, ma sono sicuro che ansible porta con > se l'idempotenza: applicare un playbook (la lista delle cose da fare, > nella sequenza indicata) su un set di sistemi sui quali, in > precedenza, la stessa ricetta è stata gia' applicata... *NON* produce > conseguenze. Tranne che può succedere che ci siano incongruenze tra la dichiarazione e lo status, come è successo quella vota a Damiano... e allora bisogna riconciliare. [...] > Insomma: non c'e' una ricetta magica per tutto. Sì invece: «Purely Functional System Configuration Management» by Eelco Dolstra and Armijn Hemel, 2007-05-07 --8<---------------cut here---------------start------------->8--- System configuration management is difficult because systems evolve in an undisciplined way: packages are upgraded, configuration files are edited, and so on. The management of existing operating systems is strongly imperative in nature, since software packages and configuration data (e.g., /bin and /etc in Unix) can be seen as imperative data structures: they are updated in-place by system administration actions. In this paper we present an alternative approach to system configuration management: a purely functional method, analogous to languages like Haskell. In this approach, the static parts of a configuration — software packages, configuration files, control scripts — are built from pure functions, i.e., the results depend solely on the specified inputs of the function and are immutable. As a result, realising a system configuration becomes deterministic and reproducible. Upgrading to a new configuration is mostly atomic and doesn’t overwrite anything of the old configuration, thus enabling rollbacks. We have implemented the purely functional model in a small but realistic Linuxbased operating system distribution called NixOS. --8<---------------cut here---------------end--------------->8--- (https://edolstra.github.io/pubs/hotos-final.pdf) Oggi quei concetti sono implementati in NixOS e Guix System; per i manifest di packages e servizi il primo usa un _mix_ di Nix - un DSL funzionale sviluppato ad-hoc - e bash, il secondo usa Guile, un dialetto di Scheme. [...] >> [...kubernetes...] >> Se cambiano i requisiti, basta cambiare le specifiche e il sistema si >> riadatta ad esse in modo totalmente automatico. > Su questo elemento *DISSENTO* fortemente. In *TEORIA* funziona cosi'. > Nella pratica, dipende assolutamente dall'applicazione che deve > girarci. Confermo: la statefulness dei sistemi purtroppo a volte è _embedded_ nelle applicazioni che sono progettate proprio male [3] > Se a dover essere gestita è una applicazione "classica" (un Wordpress > che richiede un MySQL; un GitLab che richiede millemila prerequisiti; un > applicativo "old-school" che utilizza il file-system come repository di > dati; etc.)... portarlo su kubernets è un bagno di sangue anche GitLab (o analogo) che richiede millemila prerequisiti? Ho in mente decine di applicazioni _webbiche_ che richiedono millemila prerequisiti. [...] > Chiaramente, se ti chiami AWS, Google Microsoft, alla tua scala ti > organizzi solo con applicativi che ricadono nella prima categoria. > Pero', poi, vorrai che anche gli utenti che hanno applicativi della > seconda categoria... appunto, e magari prendono una _virtual machine_ "sul cloud" con attaccato un persistent storage proprietario, un'istanza RDMBS e robe simili e poi ci installano su Ubuntu per farci girare Wordpress o una applicazione PHP custom sviluppata su framework Laravel [...] > Tu e AWS volete "vendere" la vostra piattaforma. Heinemeier preferisce > gestirla per i fatti suoi (perché pensa di sapere quello che fa). > > A me piace piu' il suo approccio... Non è solo una questione di gusti, è che a parità di competenze l'approccio on-premises costa almeno un ordine di grandezza meno. La questione quindi si "riduce" a: per farselo "da soli" occorre avere adeguate competenze, se lo facciamo "in cloud" non abbiamo bisogno di quelle competenze e quindi _risparmiamo_... ...tranne poi rendersi conto che dopo 5 anni, non 10, non 20, stai spendendo una fucilata indecente che faresti meglio a spendere per avere le competenze "in casa", anche fornite da terzi, ma con un "technical debt" gestibile, non con uno col quale rischi di fallire da un momento all'altro nel caso il tuo vendor decida di dismettere un servizio essenziale per la tua infrastruttura > sia perché la "vostra" piattaforma offre il suo lato migliore, solo in > condizioni particolarissime, sia, soprattutto, perché soltanto cosi' > Heinemeier resta competitivo a lungo termine. esatto: on-premises is (already!) the new normal :-D [...] >> Quello è semplicemente utilizzo di infrastrutture cloud, altrimenti >> detto IaaS, non è cloud computing nativo, che richiede riprogettare le >> soluzioni in ottica cloud. ammesso e _non_ concesso che l'"ottica cloud" sia quella dei microservices, allora anche quel concetto è ormai obsoleto (anche se difficile da superare) detto in altre parole: le applicazioni ben progettate che girano su sistemi on-premises ben progettati sono di almeno 1 ordine di grandezza più efficienti di quelle "cloud native"; per rimanare solo sul piano di progettazione delle applicazioni: --8<---------------cut here---------------start------------->8--- Replacing method calls and module separations with network invocations and service partitioning within a single, coherent team and application is madness in almost all cases. --8<---------------cut here---------------end--------------->8--- (https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-microservices-59625580) > Mi è moltissimo chiaro. Ma mi è altrettanto chiaro che quella > "riprogettazione" --che tu poni come "prerequisito" del cd. > cloud-computing nativo-- *NON* la fa... nessuno. No infatti: continuano (quasi) tutti a usare applicazioni client-server webbiche "tradizionali", come si facevano anche prima dell'hype ...anche perché le applicazioni per essere "cloud native" devono praticamente essere riscritte da sviluppatori competenti, a meno di far su un paciugone di codice SOAP/REST che ci mette 100 volte il tempo che ci metteva prima > Tutti, pero', dicono: "Siamo sul cloud". Se non hanno fatto quella > riprogettazione... come fanno a starci? Prendono una/dieci/cento VM su AWS, ci attaccano storage, database ecc e ci installano Ubuntu con su la loro bella webapp. [...] >>> Sono, io, "cloud"? >> Stai gestendo a mano, con l’ausilio di tool, una infrastruttura >> fornita da altri. >> Il cloud GARR è basato su OpenStack e Kubernetes, entrambi orchestrati >> in modo dichiarativo da Canonical Juju. >> La scelta di una soluzione dichiarativa era quella che consentiva di >> gestire una piattaforma così sofisticata con solo 5 persone, anziché >> 50. Il fine ultimo di tutti questi bei ragionamenti è questo e soltanto questo: decimare le persone necessarie a far funzionare una infrastruttura come quelle di GARR o altre organizzazioni pubbliche o private? Tra l'altro i 5 rimasti devono limitarsi a fare 4 click su un "admin panel". Figuriamoci se io ho qualcosa contro l'automazione, il mio alter ego ci lavora per l'automazione, ma non può sempre e _solo_ limitarsi tutto a _risparmiare_ sugli stipendi. Infine, sarà anche che alla fine rimangono in 5 su 50 a gestire una intrastruttura basata su kubernetes... ma prima o poi le cose cominciano a non funzionare più con 4 click e allora... parte il _cinema_. [...] > La chiave è l'automazione. Non la modalita' con la quale viene > implementata. Non vorrei dire ma per _sviluppare_ le librerie necessarie a rendere _accessibile_ l'automazione nel "Infrastructure as Code" è necessario tanto lavoro competente... ma a quello non ci pensa nessuno? Le "librerie" di Terraform, Ansible, Puppet, NixOS, Guix crescono sugli alberi? [...] > Mi fermo. Mi sa che ho esagerato :-( Perdonatemi... Ops, mi sa anche io :-/ > [1] https://www.terraform.io/ > [2] https://docs.gitlab.com/ee/user/infrastructure/iac/ > [3] https://www.proxmox.com/en/proxmox-virtual-environment/overview > [4] https://opentofu.org/ > [5] https://registry.terraform.io/providers/bpg/proxmox/latest/docs Grazie mille per questo bel thread! Saluti, 380° [1] kubernetes è basato sulla Promise Theory di Mark Burgess, autore di CFEngine rilasciato la prima volta nel 1993 https://en.wikipedia.org/wiki/CFEngine [2] http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/ [3] a volte la statefulness _purtroppo_ è legata a come è progettata (male!) l'applicazione stessa, come nel caso di Nextcloud ad esempio [4] https://en.wikipedia.org/wiki/Idempotence -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
signature.asc
Description: PGP signature
