{"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":"

Mi chiamo Viktor Yagofarov e mi occupo dello sviluppo della piattaforma Kubernetes presso DomKlik in qualit\u00e0 di responsabile tecnico dello sviluppo nel team Ops (operazioni). Vorrei raccontarvi come sono organizzati i nostri processi Dev <-> Ops, le peculiarit\u00e0 della gestione di uno dei pi\u00f9 grandi cluster k8s in Russia e le pratiche DevOps\/SRE adottate dal nostro team.<\/p>\n

\"Kubernetes
\n<\/a><\/noindex><\/p>\n

Team Ops<\/h4>\n

\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 del team Ops davanti al monitor, pronto a reagire a un incidente di qualsiasi complessit\u00e0. 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

\"Kubernetes
\n
\nLe competenze variano: ci sono esperti di rete, DBA, specialisti del stack ELK, amministratori\/developers di Kubernetes, monitoraggio, virtualizzazione, hardware, ecc. Ci\u00f2 che ci unisce \u00e8 che ognuno di noi pu\u00f2 sostituire in qualche modo un altro: ad esempio, introdurre nuovi nodi in un cluster k8s, aggiornare PostgreSQL, scrivere pipeline CI\/CD + Ansible, automatizzare qualcosa in Python\/Bash\/Go, collegare hardware nel data center. Una forte competenza in un determinato settore non esclude di cambiare direzione e iniziare a svilupparsi in un altro campo. Ad esempio, sono entrato in un'azienda come specialista di PostgreSQL, e ora il mio principale ambito di responsabilit\u00e0 sono i cluster Kubernetes. Nella squadra, ogni crescita \u00e8 benvenuta e c'\u00e8 un forte senso di sostegno reciproco.<\/p>\n

A proposito, stiamo cercando personale. I requisiti per i candidati sono abbastanza standard. Personalmente, \u00e8 importante per me che la persona si integri nel team, sia collaborativa, ma anche capace di difendere il proprio punto di vista, desideri crescere e non teme di provare qualcosa di nuovo, proponendo le proprie idee. Inoltre, \u00e8 fondamentale avere competenze nella programmazione in linguaggi script, conoscenza di base di Linux e della lingua inglese. L'inglese \u00e8 necessario semplicemente affinch\u00e9 la persona possa cercare la soluzione a un problema in caso di difficolt\u00e0 in 10 secondi anzich\u00e9 in 10 minuti. Con specialisti con una profonda conoscenza di Linux \u00e8 attualmente molto difficile: \u00e8 divertente, ma due candidati su tre non riescono a rispondere alla domanda 'Che cos'\u00e8 il Load Average? Di cosa si compone?', e considerano la domanda 'Come creare un core dump da un programma in C' qualcosa proveniente dal mondo dei supereroi... o dei dinosauri. Dobbiamo accettarlo, poich\u00e9 di solito le persone hanno sviluppato fortemente altre competenze, e noi insegneremo il 'Linux'. La risposta alla domanda 'perch\u00e9 \u00e8 tutto ci\u00f2 che un ingegnere DevOps deve sapere nel mondo moderno del cloud' dovr\u00e0 rimanere al di fuori di questo articolo, ma se dovessimo riassumerlo in tre parole: \u00e8 tutto necessario.<\/p>\n

Team Tools<\/h4>\n

\nUn ruolo importante nell'automazione \u00e8 ricoperto dal team Tools. Il loro compito principale \u00e8 creare strumenti grafici e CLI accessibili per gli sviluppatori. Ad esempio, il nostro strumento interno Confer consente di rilasciare un'applicazione in Kubernetes con pochi semplici clic, configurandone risorse, chiavi da vault, ecc. In passato utilizzavamo Jenkins + Helm 2, ma abbiamo dovuto sviluppare uno strumento proprio per eliminare la copia e incolla e garantire coerenza nel ciclo di vita del software.<\/p>\n

Il team Ops non scrive pipeline per gli sviluppatori, ma pu\u00f2 fornire consulenza su qualsiasi questione relativa alla loro scrittura (alcuni utilizzano ancora Helm 3).<\/p>\n

DevOps<\/h4>\n

\nPer quanto riguarda DevOps, lo vediamo in questo modo:<\/p>\n

I team di sviluppo scrivono codice e lo rilasciano tramite Confer in dev -> qa\/stage -> prod. La responsabilit\u00e0 di garantire che il codice non si blocchi e non generi errori ricade sui team di sviluppo e operazioni. Durante il giorno, la persona di guardia del team Ops deve reagire agli incidenti relativi alla propria applicazione, mentre di sera e di notte l'amministratore di guardia (Ops) deve svegliare il developer di guardia se sa con certezza che il problema non \u00e8 dovuto all'infrastruttura. Tutte le metriche e gli alert nel monitoraggio appaiono automaticamente o semi-automaticamente.<\/p>\n

L'area di responsabilit\u00e0 di Ops inizia al momento del rilascio dell'applicazione in produzione, ma la responsabilit\u00e0 di Dev non finisce qui: stiamo facendo lo stesso lavoro e siamo nella stessa barca.<\/p>\n

Gli sviluppatori consultano gli amministratori se hanno bisogno di aiuto nella scrittura di un microservizio per gli amministratori (ad esempio, backend Go + HTML5), mentre gli amministratori consultano gli sviluppatori su qualsiasi questione relativa all'infrastruttura o a problematiche legate a k8s.<\/p>\n

A proposito, non abbiamo affatto un monolite, solo microservizi. Il loro numero oscilla attualmente tra 900 e 1000 nel cluster k8s di produzione, se lo si misura in base al numero di deployments<\/i>. Il numero di nodi varia tra 1700 e 2000. Attualmente ci sono circa 2000 nodi nel cluster di produzione.<\/p>\n

Non posso fornire numeri esatti, poich\u00e9 monitoriamo i microservizi non necessari e li rimuoviamo in modo semi-automatico. Ci aiuta a tenere traccia delle entit\u00e0 superflue in k8s useless-operator<\/a><\/noindex>, il che consente di risparmiare risorse e denaro.<\/p>\n

Gestione delle risorse <\/h2>\n

<\/p>\n

Monitoraggio <\/h4>\n

\nUn elemento fondamentale per la gestione di un grande cluster \u00e8 un monitoraggio ben strutturato e informativo. Fino ad ora non abbiamo trovato una soluzione universale che copra il 100% di tutte le esigenze di monitoraggio, quindi periodicamente sviluppiamo diverse soluzioni personalizzate in questo ambiente.<\/p>\n