{"id":91199,"date":"2020-08-10T01:42:03","date_gmt":"2020-08-09T23:42:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kubernetes-v-domklik-kak-spat-spokojno-upravlyaya-klasterom-na-1000-mikroservisov"},"modified":"2020-08-10T01:42:03","modified_gmt":"2020-08-09T23:42:03","slug":"kubernetes-v-domklik-kak-spat-spokojno-upravlyaya-klasterom-na-1000-mikroservisov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kubernetes-v-domklik-kak-spat-spokojno-upravlyaya-klasterom-na-1000-mikroservisov","title":{"rendered":"Kubernetes in DomClick: come dormire tranquilli gestendo un cluster di 1000 microservizi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Mi chiamo Viktor Yagofarov e mi occupo dello sviluppo della piattaforma Kubernetes presso la compagnia DomClick nel ruolo di responsabile tecnico dello sviluppo nel team Ops (operazioni). Vorrei parlare del nostro processo Dev  Ops, delle particolarit\u00e0 della gestione di uno dei pi\u00f9 grandi cluster k8s in Russia, e delle pratiche DevOps\/SRE adottate dal nostro team.<\/p>\n<p><img decoding=\"async\" alt=\"Kubernetes in DomClick: come dormire tranquilli gestendo un cluster di 1000 microservizi\" src=\"\/wp-content\/uploads\/2020\/08\/6c908104c734b36cc7a960fbe4d65e3f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h4>Team Ops<\/h4>\n<p>\nAttualmente nel team Ops lavorano 15 persone. Tre di loro si occupano dell'ufficio, due lavorano in un altro fuso orario e sono disponibili anche di notte. In questo modo, c'\u00e8 sempre qualcuno di Ops al monitor pronto a reagire a qualsiasi tipo di incidente. Non abbiamo turni notturni, il che preserva la nostra salute mentale e consente a tutti di riposare e trascorrere il tempo libero non solo davanti al computer.<\/p>\n<p><img decoding=\"async\" alt=\"Kubernetes in DomClick: come dormire tranquilli gestendo un cluster di 1000 microservizi\" src=\"\/wp-content\/uploads\/2020\/08\/47051db273f116df376e64bad67c6f37.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe competenze sono varie: specialisti di rete, DBA, esperti del stack ELK, amministratori\/sviluppatori Kubernetes, specialisti di monitoraggio, virtualizzazione, hardware, ecc. Ci unisce una cosa: ognuno di noi pu\u00f2 sostituire in qualche modo l'altro: ad esempio, inserire nuovi nodi nel cluster k8s, aggiornare PostgreSQL, scrivere un pipeline CI\/CD + Ansible, automatizzare qualcosa in Python\/Bash\/Go, collegare apparecchiature nei data center. Forti competenze in un'area non impediscono di cambiare direzione e iniziare a investire in un'altra area. Ad esempio, io sono entrato in azienda come specialista di PostgreSQL e ora la mia principale responsabilit\u00e0 \u00e8 i cluster Kubernetes. Nel team qualsiasi crescita \u00e8 benvenuta e si sviluppa molto il senso di supporto reciproco.<\/p>\n<p>A proposito, stiamo cercando. I requisiti per i candidati sono piuttosto standard. Personalmente, \u00e8 importante per me che la persona si integri nel team, sia non conflittuale, ma anche capace di difendere le proprie opinioni, desideri di svilupparsi e non abbia paura di fare qualcosa di nuovo, proponendo le proprie idee. Inoltre, \u00e8 fondamentale avere competenze di programmazione in linguaggi di scripting, conoscenza delle basi di Linux e dell'inglese. L'inglese \u00e8 necessario semplicemente affinch\u00e9 la persona possa cercare online una soluzione a un problema in caso di errore, in 10 secondi, e non in 10 minuti. Con esperti di Linux molto competenti \u00e8 attualmente molto difficile: \u00e8 divertente, ma due candidati su tre non possono rispondere alla domanda \"Che cos'\u00e8 il Load Average? Di cosa \u00e8 composto?\", e considerano la domanda \"Come raccogliere un core dump da un programma C\" come qualcosa proveniente da un mondo di supereroi... o di dinosauri. Dobbiamo accettarlo, poich\u00e9 di solito le persone hanno sviluppato molto altre competenze e noi insegneremo il \"linux\". La risposta alla domanda \"perch\u00e9 bisogna sapere tutto questo per un ingegnere DevOps nel moderno mondo del cloud\" dovr\u00e0 rimanere al di fuori di questo articolo, ma se dovessi sintetizzarla in tre parole: tutto questo \u00e8 necessario.<\/p>\n<h4>Team Tools<\/h4>\n<p>\nIl team Tools gioca un ruolo significativo nell'automazione. Il loro obiettivo principale \u00e8 la creazione di strumenti grafici e CLI comodi per gli sviluppatori. Ad esempio, il nostro strumento interno Confer consente di rilasciare un'applicazione in Kubernetes con pochi clic del mouse, configurandole le risorse, le chiavi dal vault, ecc. Prima usavamo Jenkins + Helm 2, ma abbiamo dovuto sviluppare il nostro strumento per eliminare il copia-incolla e portare uniformit\u00e0 nel ciclo di vita del software.<\/p>\n<p>Il team Ops non scrive pipeline per gli sviluppatori, ma pu\u00f2 fornire consulenza su qualsiasi questione riguardante la loro scrittura (alcuni hanno ancora Helm 3).<\/p>\n<h4>DevOps<\/h4>\n<p>\nPer quanto riguarda il DevOps, lo vediamo in questo modo:<\/p>\n<p>I team Dev scrivono codice, lo rilasciano tramite Confer in dev -&gt; qa\/stage -&gt; prod. La responsabilit\u00e0 affinch\u00e9 il codice non rallenti e non generi errori ricade sui team Dev e Ops. Durante il giorno, l'incidente con la propria applicazione deve essere gestito, in primo luogo, dal turno di lavoro del team Ops, mentre di sera e durante la notte l'amministratore di turno (Ops) deve svegliare il programmatore di turno se \u00e8 certo che il problema non sia nell'infrastruttura. Tutte le metriche e gli avvisi nel monitoraggio appaiono automaticamente o semi-automaticamente.<\/p>\n<p>La zona di responsabilit\u00e0 degli Ops inizia nel momento in cui l'applicazione viene distribuita in produzione, ma la responsabilit\u00e0 degli sviluppatori non finisce qui: facciamo lo stesso lavoro e siamo sulla stessa barca.<\/p>\n<p>Gli sviluppatori consigliano gli amministratori nel caso abbiano bisogno di aiuto nella scrittura di un microservizio per admin (ad esempio, backend Go + HTML5), mentre gli amministratori consigliano gli sviluppatori su qualsiasi questione infrastrutturale o relativa a k8s.<\/p>\n<p>A proposito, non abbiamo affatto un monolito, solo microservizi. Il loro numero oscilla attualmente tra 900 e 1000 nel cluster k8s di produzione, se lo misuriamo in base alla quantit\u00e0. <i>deployments<\/i>Il numero di pod varia tra 1700 e 2000. Attualmente, ci sono circa 2000 pod nel cluster di produzione.<\/p>\n<p>Non posso fornire numeri esatti, poich\u00e9 seguiamo i microservizi non necessari e li rimuoviamo in modo semi-automatico. Monitorare le entit\u00e0 superflue in k8s ci aiuta <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Nastradamus\/useless-operator\">useless-operator<\/a><\/noindex>, il che risparmia notevolmente risorse e denaro.<\/p>\n<h2> Gestione delle risorse <\/h2>\n<p><\/p>\n<h4> Monitoraggio <\/h4>\n<p>\nIn un grande cluster, un monitoraggio ben strutturato e informativo diventa un pilastro fondamentale. Finora non abbiamo trovato una soluzione universale che copra il 100% di tutte le richieste in materia di monitoraggio, quindi di tanto in tanto sviluppiamo diverse soluzioni personalizzate in questo ambito.<\/p>\n<ul>\n<li><b>Zabbix<\/b>Il monitoraggio tradizionale, che \u00e8 principalmente destinato a monitorare lo stato generale dell'infrastruttura. Ci avvisa quando un nodo si guasta a causa di CPU, memoria, dischi, rete e cos\u00ec via. Niente di stratosferico, ma abbiamo anche un DaemonSet di agenti, con cui monitoriamo, ad esempio, lo stato del DNS nel cluster: cerchiamo pod coredns che rallentano e controlliamo la disponibilit\u00e0 degli host esterni. Potrebbe sembrare superfluo, ma su grandi volumi di traffico questo componente \u00e8 un importante punto di rottura. In precedenza ho gi\u00e0 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/domclick\/blog\/495450\/\">descritto<\/a><\/noindex>parlato di come ho affrontato la performance del DNS nel cluster.<\/li>\n<li><b>Prometheus Operator<\/b>Una serie di diversi exporter offre una grande panoramica di tutti i componenti del cluster. Successivamente, visualizziamo tutto questo su grandi dashboard in Grafana e utilizziamo alertmanager per le notifiche.\n<\/li>\n<\/ul>\n<p>\nUn altro strumento utile per noi \u00e8 diventato <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Nastradamus\/list-ingress\">list-ingress<\/a><\/noindex>. Abbiamo scritto questo strumento dopo aver affrontato pi\u00f9 volte la situazione in cui un team sovrapponeva i propri percorsi Ingress a quelli di un altro team, causando errori 50x. Ora, prima di effettuare il deploy in produzione, gli sviluppatori controllano che nessuno venga colpito, e per il mio team \u00e8 uno strumento utile per la diagnosi iniziale dei problemi con gli Ingress. \u00c8 divertente notare che inizialmente era stato scritto per gli amministratori e appariva piuttosto \"grezzo\", ma dopo che lo strumento \u00e8 piaciuto ai team di sviluppo, ha subito notevoli trasformazioni ed \u00e8 diventato meno simile a un \"frontend per amministratori\". Presto abbandoneremo questo strumento e situazioni simili verranno validate prima del rilascio del pipeline.<\/p>\n<h4>Risorse dei team in 'Kube'<\/h4>\n<p>\nPrima di passare agli esempi, \u00e8 opportuno spiegare come funziona la gestione delle risorse per <i>microservizi<\/i>.<\/p>\n<p>Per comprendere quali team e in quali quantit\u00e0 utilizzano le proprie <i>risorse<\/i> (CPU, memoria, SSD locale), riserviamo a ciascun team una propria <i>namespace<\/i> in \"Kubernetes\" e limitiamo le sue massime capacit\u00e0 in termini di CPU, memoria e disco, discutendo preventivamente le esigenze dei team. Di conseguenza, un team, in linea di massima, non bloccher\u00e0 l'intero cluster per il deploy, assegnandosi migliaia di core e terabyte di memoria. Gli accessi nei namespace vengono forniti attraverso AD (utilizziamo RBAC). I namespace e i loro limiti vengono aggiunti attraverso una pull request nel repository GIT e poi, tramite un pipeline Ansible, il tutto viene distribuito automaticamente.<\/p>\n<p>Esempio di allocazione delle risorse per un team:<\/p>\n<pre><code class=\"go\">namespaces:\n\n  chat-team:\n    pods: 23\n    limits:\n      cpu: 11\n      memory: 20Gi\n    requests:\n      cpu: 11\n      memory: 20Gi\n<\/code><\/pre>\n<p><\/p>\n<h4>Richieste e limiti<\/h4>\n<p>\nIn 'Kube' <i>Request<\/i> \u2014 \u00e8 la quantit\u00e0 di risorse riservate garantite per <i>pod<\/i> (uno o pi\u00f9 container Docker) nel cluster. Limit \u00e8 il massimo non garantito. Spesso si pu\u00f2 osservare nei grafici come un team abbia assegnato troppi richieste per tutte le proprie applicazioni e non sia in grado di fare deploy di un'applicazione in \"Kubernetes\", poich\u00e9 tutte le request nel loro namespace sono gi\u00e0 \"esaurite\".<\/p>\n<p>La soluzione corretta in questa situazione \u00e8 monitorare il reale consumo di risorse e confrontarlo con la quantit\u00e0 richiesta (Request).<\/p>\n<p><img decoding=\"async\" alt=\"Kubernetes in DomClick: come dormire tranquilli gestendo un cluster di 1000 microservizi\" src=\"\/wp-content\/uploads\/2020\/08\/417373d4421064f28d57a03b6bb5bf94.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Kubernetes in DomClick: come dormire tranquilli gestendo un cluster di 1000 microservizi\" src=\"\/wp-content\/uploads\/2020\/08\/3168ad6dc8b159059b21e1177e145376.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNegli screenshot sopra \u00e8 visibile che le 'richieste' (Requested) di CPU si avvicinano alla reale quantit\u00e0 di thread, mentre i Limiti possono superare il reale numero di thread della CPU =)<\/p>\n<p>Ora analizziamo in dettaglio un namespace (ho scelto il namespace kube-system \u2014 namespace di sistema per i componenti del \u00abCubo\u00bb) e vediamo il rapporto tra il tempo di CPU e la memoria realmente utilizzati e quelli richiesti:<\/p>\n<p><img decoding=\"async\" alt=\"Kubernetes in DomClick: come dormire tranquilli gestendo un cluster di 1000 microservizi\" src=\"\/wp-content\/uploads\/2020\/08\/ed6160de5397b8cd39cbae172d4bb872.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00c8 evidente che la memoria e la CPU riservate ai servizi di sistema siano molto superiori a quelle effettivamente utilizzate. Nel caso di kube-system questo \u00e8 giustificato: \u00e8 capitato che il controller ingress nginx o nodelocaldns, durante i picchi, utilizzassero molta CPU e consumassero molta RAM, quindi \u00e8 giustificato avere un margine qui. Inoltre, non possiamo fare affidamento solo sui grafici delle ultime 3 ore: sarebbe opportuno avere metriche storiche su un lungo periodo di tempo.<\/p>\n<p>\u00c8 stato sviluppato un sistema di \u00abraccomandazioni\u00bb. Ad esempio, qui \u00e8 possibile vedere quali risorse sarebbe meglio aumentare i \u00ablimiti\u00bb (il massimo consentito) per evitare il \u00abthrottling\u00bb: il momento in cui si \u00e8 gi\u00e0 consumata CPU o memoria per il periodo di tempo assegnato e si \u00e8 in attesa che vengano \u00abscongelati\u00bb:<\/p>\n<p><img decoding=\"async\" alt=\"Kubernetes in DomClick: come dormire tranquilli gestendo un cluster di 1000 microservizi\" src=\"\/wp-content\/uploads\/2020\/08\/f23aece10a585e6847bcacfe947031d1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEcco i pod che dovrebbero moderare le loro richieste:<\/p>\n<p><img decoding=\"async\" alt=\"Kubernetes in DomClick: come dormire tranquilli gestendo un cluster di 1000 microservizi\" src=\"\/wp-content\/uploads\/2020\/08\/1ec9996ce6355aeba603008d51aac209.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSu <i>throttling<\/i> + la monitorizzazione delle risorse potrebbe riempire pi\u00f9 di un articolo, quindi sentitevi liberi di fare domande nei commenti. In poche parole, posso dire che automatizzare metriche di questo tipo \u00e8 un compito piuttosto complesso e richiede molto tempo e destrezza con le funzioni \u00abwindow\u00bb e \u00abCTE\u00bb di Prometheus \/ VictoriaMetrics (questi termini sono tra virgolette perch\u00e9 in PromQL non esiste nulla di simile, e bisogna costruire query complesse lunghe diversi schermi di testo e occuparsi della loro ottimizzazione).<\/p>\n<p>Di conseguenza, gli sviluppatori hanno strumenti per monitorare i propri namespace nel \u00abCubo\u00bb e possono decidere autonomamente dove e quando a quali applicazioni \u00e8 possibile \u00abridurre\u00bb le risorse, mentre a quali pod si pu\u00f2 concedere tutta la CPU per tutta la notte.<\/p>\n<h4>Metodologie<\/h4>\n<p>\nNell'azienda, come \u00e8 di moda ora <i>\u00e8 alla moda<\/i>, seguiamo pratiche DevOps e <i>SRE<\/i>-pratiche. Quando in azienda ci sono 1000 microservizi, circa 350 sviluppatori e 15 admin per tutta l'infrastruttura, bisogna \u00abessere alla moda\u00bb: dietro a tutte queste \u00abbuzzword\u00bb si cela un'urgente necessit\u00e0 di automatizzare tutto, e gli admin non devono diventare il collo di bottiglia nei processi.<\/p>\n<p>Come Ops, forniamo diverse metriche e dashboard per gli sviluppatori, connesse alla velocit\u00e0 di risposta dei servizi e ai loro errori.<\/p>\n<p>Utilizziamo metodologie come: <noindex><a rel=\"nofollow\" href=\"https:\/\/thenewstack.io\/monitoring-microservices-red-method\/\">RED<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/usemethod.html\">USARE<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/forepaas\/distributed-monitoring-101-the-four-golden-signals-305bbbc33d35\">Golden Signals<\/a><\/noindex>, combinandoli insieme. Cerchiamo di ridurre al minimo il numero di dashboard in modo che a colpo d'occhio si possa capire quale servizio sta attualmente degradando (ad esempio, i codici di risposta al secondo, il tempo di risposta al 99\u00b0 percentile), e cos\u00ec via. Non appena sono necessarie nuove metriche per le dashboard comuni, le disegniamo e le aggiungiamo immediatamente.<\/p>\n<p><i>Non disegno grafici da un mese. Probabilmente \u00e8 un buon segno: significa che la maggior parte delle 'richieste' \u00e8 gi\u00e0 stata realizzata. A volte, in una settimana, disegnavo almeno un nuovo grafico al giorno.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Kubernetes in DomClick: come dormire tranquilli gestendo un cluster di 1000 microservizi\" src=\"\/wp-content\/uploads\/2020\/08\/574f1b4d2be78fb779f1771bffac51dd.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Kubernetes in DomClick: come dormire tranquilli gestendo un cluster di 1000 microservizi\" src=\"\/wp-content\/uploads\/2020\/08\/6ab2aa05f912839b14bdbcf84faaeb3a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl risultato ottenuto \u00e8 prezioso perch\u00e9 ora gli sviluppatori raramente si rivolgono agli amministratori con domande su 'dove posso vedere una certa metrica'.<\/p>\n<p>Implementazione <i>Service Mesh<\/i> non \u00e8 lontano e dovrebbe semplificare notevolmente la vita di tutti, i colleghi di Tools sono gi\u00e0 vicini all'implementazione di un 'Istio per persone sane': il ciclo di vita di ogni richiesta HTTP(s) sar\u00e0 visibile nel monitoraggio, e sar\u00e0 sempre possibile capire 'in quale fase tutto si \u00e8 rotto' durante le interazioni tra servizi (e non solo). Iscriviti agli aggiornamenti del hub dell'azienda DomKlick. =)<\/p>\n<h2>Supporto per l'infrastruttura Kubernetes<\/h2>\n<p>\nStoricamente, abbiamo utilizzato una versione patchata <i>Kubespray<\/i> \u2014 Ruolo Ansible per il deployment, l'espansione e l'aggiornamento di Kubernetes. A un certo punto, il supporto per le installazioni non kubeadm \u00e8 stato rimosso dal ramo principale, e non \u00e8 stata proposta una transizione a kubeadm. Di conseguenza, l'azienda Southbridge ha creato il proprio fork (con supporto kubeadm e rapida risoluzione di problemi critici). <\/p>\n<p>Il processo di aggiornamento di tutti i cluster k8s \u00e8 il seguente:<\/p>\n<ul>\n<li>Prendiamo <i>Kubespray<\/i> da Southbridge, confrontiamo con il nostro ramo, uniamo.<\/li>\n<li>Distribuiamo l'aggiornamento in <i>Stress<\/i>- 'Cubo'.<\/li>\n<li>Distribuiamo l'aggiornamento nodo per nodo (in Ansible \u00e8 'serial: 1') in <i>Dev<\/i>- 'Cubo'.<\/li>\n<li>Aggiorniamo <i>Prod<\/i> sabato sera nodo per nodo.<\/li>\n<\/ul>\n<p>\nIn futuro, ci sono piani per sostituire <i>Kubespray<\/i> con qualcosa di pi\u00f9 veloce e passare a <i>kubeadm<\/i>.<\/p>\n<p>Abbiamo in totale tre 'Cubi': Stress, Dev e Prod. Prevediamo di avviare un altro (<i>hot standby<\/i>) Cubo Prod in un secondo data center. <i>Stress<\/i> e <i>Dev<\/i> vivono in 'virtual machines' (oVirt per Stress e VMWare cloud per Dev). <i>Prod<\/i>- 'Cubo' vive su 'hardware nudo' (bare metal): sono nodi identici con 32 thread CPU, 64-128 GB di memoria e 300 GB SSD RAID 10 \u2014 in totale sono 50 unit\u00e0. Tre nodi 'snelli' sono dedicati ai 'master' <i>Prod<\/i>-'Cubo': 16 GB di memoria, 12 thread CPU.<\/p>\n<p>Per la produzione preferiamo usare 'hardware nudo' ed evitiamo strati extra come <i>OpenStack<\/i>: non abbiamo bisogno di 'vicini rumorosi' e del tempo rubato dalla CPU <i>steal time<\/i>. Inoltre, la complessit\u00e0 dell'amministrazione aumenta di circa il doppio nel caso di OpenStack in-house.<\/p>\n<p>Per CI\/CD dei componenti \u00abKubernetes\u00bb e altre infrastrutture utilizziamo un server GIT separato, Helm 3 (abbiamo fatto il passaggio in modo piuttosto doloroso da Helm 2, ma siamo molto contenti dell'opzione <i>atomic<\/i>), Jenkins, Ansible e Docker. Amore per i feature branch e il deploy in ambienti diversi da un unico repository.<\/p>\n<h3>Conclusione<\/h3>\n<p><img decoding=\"async\" alt=\"Kubernetes in DomClick: come dormire tranquilli gestendo un cluster di 1000 microservizi\" src=\"\/wp-content\/uploads\/2020\/08\/34ddcd1f275c63c1ad821218d16b5abb.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nCos\u00ec, in linea generale, il processo DevOps in DomClick appare dal punto di vista dell'ingegnere di funzionamento. L'articolo \u00e8 risultato meno tecnico di quanto mi aspettassi: quindi, seguite le novit\u00e0 di DomClick su Habr: ci saranno articoli pi\u00f9 'hardcore' su Kubernetes e non solo.<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/domclick\/blog\/501122\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0412\u0438\u043a\u0442\u043e\u0440 \u042f\u0433\u043e\u0444\u0430\u0440\u043e\u0432, \u0438 \u044f \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0441\u044c \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0435\u043c Kubernetes-\u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0414\u043e\u043c\u041a\u043b\u0438\u043a \u0432 \u0434\u043e\u043b\u0436\u043d\u043e\u0441\u0442\u0438 \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435 Ops (\u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u044f). \u042f \u0445\u043e\u0442\u0435\u043b \u0431\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u043e\u0431 \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0435 \u043d\u0430\u0448\u0438\u0445 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0432 Dev &lt;-&gt; Ops, \u043e\u0431 \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e\u0441\u0442\u044f\u0445 \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u0438 \u043e\u0434\u043d\u043e\u0433\u043e \u0438\u0437 \u0441\u0430\u043c\u044b\u0445 \u0431\u043e\u043b\u044c\u0448\u0438\u0445 k8s-\u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u0432 \u0432 \u0420\u043e\u0441\u0441\u0438\u0438, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043e DevOps\/SRE-\u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0430\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u0440\u0438\u043c\u0435\u043d\u044f\u0435\u0442 \u043d\u0430\u0448\u0430 \u043a\u043e\u043c\u0430\u043d\u0434\u0430. \u041a\u043e\u043c\u0430\u043d\u0434\u0430 Ops \u0412 \u043a\u043e\u043c\u0430\u043d\u0434\u0435 Ops [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91200,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91199","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0412\u0438\u043a\u0442\u043e\u0440 \u042f\u0433\u043e\u0444\u0430\u0440\u043e\u0432, \u0438 \u044f \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0441\u044c \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0435\u043c Kubernetes-\u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0414\u043e\u043c\u041a\u043b\u0438\u043a \u0432 \u0434\u043e\u043b\u0436\u043d\u043e\u0441\u0442\u0438 \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435 Ops (\u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u044f).\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kubernetes-v-domklik-kak-spat-spokojno-upravlyaya-klasterom-na-1000-mikroservisov\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Kubernetes \u0432 \u0414\u043e\u043c\u041a\u043b\u0438\u043a: \u043a\u0430\u043a \u0441\u043f\u0430\u0442\u044c \u0441\u043f\u043e\u043a\u043e\u0439\u043d\u043e, \u0443\u043f\u0440\u0430\u0432\u043b\u044f\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u043c \u043d\u0430 1000 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0412\u0438\u043a\u0442\u043e\u0440 \u042f\u0433\u043e\u0444\u0430\u0440\u043e\u0432, \u0438 \u044f \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0441\u044c \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0435\u043c Kubernetes-\u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0414\u043e\u043c\u041a\u043b\u0438\u043a \u0432 \u0434\u043e\u043b\u0436\u043d\u043e\u0441\u0442\u0438 \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435 Ops (\u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u044f).\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kubernetes-v-domklik-kak-spat-spokojno-upravlyaya-klasterom-na-1000-mikroservisov\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-08-09T23:42:03+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-08-09T23:42:03+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Kubernetes in DomClick: come dormire sonni tranquilli gestendo un cluster di 1000 microservizi | ProHoster","description":"Mi chiamo Viktor Yagofarov e mi occupo dello sviluppo della piattaforma Kubernetes in DomClick in qualit\u00e0 di responsabile tecnico dello sviluppo nel team Ops (operazioni).","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kubernetes-v-domklik-kak-spat-spokojno-upravlyaya-klasterom-na-1000-mikroservisov","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Kubernetes \u0432 \u0414\u043e\u043c\u041a\u043b\u0438\u043a: \u043a\u0430\u043a \u0441\u043f\u0430\u0442\u044c \u0441\u043f\u043e\u043a\u043e\u0439\u043d\u043e, \u0443\u043f\u0440\u0430\u0432\u043b\u044f\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043e\u043c \u043d\u0430 1000 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 | ProHoster","og:description":"\u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0412\u0438\u043a\u0442\u043e\u0440 \u042f\u0433\u043e\u0444\u0430\u0440\u043e\u0432, \u0438 \u044f \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0441\u044c \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0435\u043c Kubernetes-\u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0414\u043e\u043c\u041a\u043b\u0438\u043a \u0432 \u0434\u043e\u043b\u0436\u043d\u043e\u0441\u0442\u0438 \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435 Ops (\u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0430\u0446\u0438\u044f).","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kubernetes-v-domklik-kak-spat-spokojno-upravlyaya-klasterom-na-1000-mikroservisov","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-09T23:42:03+00:00","article:modified_time":"2020-08-09T23:42:03+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"91199","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:32:23","updated":"2022-09-28 06:43:59","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/91199","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=91199"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/91199\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/91200"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=91199"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=91199"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=91199"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}