Mi chiamo Viktor Yagofarov e sto sviluppando la piattaforma Kubernetes presso DomClick come responsabile dello sviluppo tecnico nel team Ops (operativo). Vorrei parlare della struttura dei nostri processi Dev <-> Ops, delle caratteristiche della gestione di uno dei più grandi cluster k8 in Russia, nonché delle pratiche DevOps/SRE applicate dal nostro team.
Squadra operativa
Il team operativo è attualmente composto da 15 persone. Tre di loro sono responsabili dell'ufficio, due lavorano in un fuso orario diverso e sono disponibili anche di notte. Pertanto, qualcuno dell'Ops è sempre al monitor e pronto a rispondere a un incidente di qualsiasi complessità. Non abbiamo turni notturni, il che preserva la nostra psiche e dà a tutti l’opportunità di dormire a sufficienza e di trascorrere il tempo libero non solo davanti al computer.
Ognuno ha competenze diverse: networker, DBA, specialisti dello stack ELK, amministratori/sviluppatori Kubernetes, monitoraggio, virtualizzazione, specialisti hardware, ecc. Una cosa unisce tutti: tutti possono sostituire chiunque di noi in una certa misura: ad esempio, introdurre nuovi nodi nel cluster k8s, aggiornare PostgreSQL, scrivere una pipeline CI/CD + Ansible, automatizzare qualcosa in Python/Bash/Go, collegare l'hardware a Banca dati. Forti competenze in qualsiasi area non ti impediscono di cambiare la direzione della tua attività e di iniziare a migliorare in qualche altra area. Ad esempio, sono entrato in un'azienda come specialista PostgreSQL e ora la mia principale area di responsabilità sono i cluster Kubernetes. Nel team qualunque statura è benvenuta e il senso di leva è molto sviluppato.
A proposito, stiamo cacciando. I requisiti per i candidati sono abbastanza standard. Per me personalmente è importante che una persona si adatti alla squadra, non sia conflittuale, ma sappia anche difendere il suo punto di vista, voglia svilupparsi e non abbia paura di fare qualcosa di nuovo, offra le sue idee. Inoltre, sono richieste competenze di programmazione in linguaggi di scripting, conoscenza delle basi di Linux e dell'inglese. L'inglese è necessario semplicemente affinché una persona, in caso di fakap, possa cercare su Google una soluzione al problema in 10 secondi e non in 10 minuti. Oggi è molto difficile trovare specialisti con una profonda conoscenza di Linux: è divertente, ma due candidati su tre non riescono a rispondere alla domanda “Che cos'è il carico medio? Di cosa è fatto?”, e la domanda “Come assemblare un core dump da un programma C” viene considerata qualcosa del mondo dei superuomini... o dei dinosauri. Dobbiamo sopportarlo, dato che di solito le persone hanno altre competenze molto sviluppate, ma insegneremo Linux. La risposta alla domanda “perché un ingegnere DevOps ha bisogno di sapere tutto questo nel moderno mondo del cloud” dovrà essere lasciata fuori dallo scopo dell'articolo, ma in tre parole: tutto questo serve.
Strumenti della squadra
Il team Strumenti svolge un ruolo significativo nell'automazione. Il loro compito principale è creare strumenti grafici e CLI convenienti per gli sviluppatori. Ad esempio, il nostro sviluppo interno Confer ti consente di implementare letteralmente un'applicazione su Kubernetes con pochi clic del mouse, configurarne le risorse, le chiavi dal vault, ecc. In precedenza c'era Jenkins + Helm 2, ma ho dovuto sviluppare il mio strumento per eliminare il copia-incolla e portare uniformità al ciclo di vita del software.
Il team Ops non scrive pipeline per gli sviluppatori, ma può consigliare eventuali problemi nella loro scrittura (alcune persone hanno ancora Helm 3).
DevOps
Per quanto riguarda DevOps, lo vediamo così:
I team di sviluppo scrivono il codice, lo distribuiscono tramite Confer to dev -> qa/stage -> prod. La responsabilità di garantire che il codice non rallenti e non contenga errori spetta ai team Dev e Ops. Durante il giorno, la persona in servizio del team Ops dovrebbe prima di tutto rispondere all'incidente con la sua domanda, mentre la sera e di notte l'amministratore in servizio (Ops) dovrebbe svegliare lo sviluppatore in servizio se lo sa certo che il problema non è nelle infrastrutture. Tutte le metriche e gli avvisi nel monitoraggio vengono visualizzati automaticamente o semiautomaticamente.
L'area di responsabilità di Ops inizia dal momento in cui l'applicazione viene messa in produzione, ma la responsabilità di Dev non finisce qui: facciamo la stessa cosa e siamo sulla stessa barca.
Gli sviluppatori consigliano gli amministratori se hanno bisogno di aiuto per scrivere un microservizio di amministrazione (ad esempio, Go backend + HTML5) e gli amministratori consigliano gli sviluppatori su eventuali problemi dell'infrastruttura o relativi a k8.
A proposito, non abbiamo affatto un monolite, solo microservizi. Il loro numero finora oscilla tra 900 e 1000 nel cluster prod k8s, se misurato in base al numero implementazioni. Il numero di pod oscilla tra 1700 e 2000. Attualmente ci sono circa 2000 pod nel cluster di produzione.
Non posso fornire numeri esatti, poiché monitoriamo i microservizi non necessari e li eliminiamo in modo semiautomatico. K8 ci aiuta a tenere traccia delle entità non necessarie , che consente di risparmiare molte risorse e denaro.
Правление ресурсами
Monitoraggio
Un monitoraggio ben strutturato e informativo diventa la pietra angolare del funzionamento di un grande cluster. Non abbiamo ancora trovato una soluzione universale che copra il 100% di tutte le esigenze di monitoraggio, quindi creiamo periodicamente diverse soluzioni personalizzate in questo ambiente.
- Zabbix. Il buon vecchio monitoraggio, che mira principalmente a monitorare lo stato generale dell'infrastruttura. Ci dice quando un nodo muore in termini di elaborazione, memoria, dischi, rete e così via. Niente di soprannaturale, ma abbiamo anche un DaemonSet separato di agenti, con l'aiuto del quale, ad esempio, monitoriamo lo stato del DNS nel cluster: cerchiamo stupidi pod coredns, controlliamo la disponibilità di host esterni. Sembrerebbe che perché preoccuparsi di questo, ma con grandi volumi di traffico questo componente è un serio punto di fallimento. io già , come ho avuto problemi con le prestazioni DNS in un cluster.
- Operatore Prometeo. Un insieme di diversi esportatori offre un’ampia panoramica di tutti i componenti del cluster. Successivamente, visualizziamo tutto questo su dashboard di grandi dimensioni in Grafana e utilizziamo alertmanager per gli avvisi.
Un altro strumento utile per noi è stato . L'abbiamo scritto dopo che diverse volte abbiamo riscontrato una situazione in cui una squadra si sovrapponeva ai percorsi di ingresso di un'altra squadra, generando errori 50x. Ora, prima della distribuzione in produzione, gli sviluppatori controllano che nessuno venga interessato e per il mio team questo è un ottimo strumento per la diagnosi iniziale dei problemi con Ingresses. È divertente che all'inizio fosse stato scritto per gli amministratori e sembrasse piuttosto "goffo", ma dopo che i team di sviluppo si sono innamorati dello strumento, è cambiato molto e ha iniziato a non sembrare come se "un amministratore avesse creato una faccia web per gli amministratori". " Presto abbandoneremo questo strumento e tali situazioni saranno validate anche prima che il gasdotto venga lanciato.
Risorse del team nel cubo
Prima di entrare negli esempi, vale la pena spiegare come allochiamo le risorse microservizi.
Per capire quali squadre e in che quantità utilizzano i propri ресурсы (processore, memoria, SSD locale), assegniamo a ciascun comando il proprio namespace nel “Cubo” e limitarne le capacità massime in termini di processore, memoria e disco, dopo aver discusso in precedenza le esigenze dei team. Di conseguenza, un comando, in generale, non bloccherà l'intero cluster per la distribuzione, allocando migliaia di core e terabyte di memoria. L'accesso allo spazio dei nomi è concesso tramite AD (usiamo RBAC). Gli spazi dei nomi e i relativi limiti vengono aggiunti tramite una richiesta pull al repository GIT, quindi tutto viene automaticamente distribuito tramite la pipeline Ansible.
Un esempio di allocazione delle risorse a un team:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Richieste e limiti
A cubetti" RICHIEDI è il numero di risorse riservate garantite per baccello (uno o più contenitori docker) in un cluster. Il limite è un massimo non garantito. Spesso puoi vedere nei grafici come alcuni team si sono imposti troppe richieste per tutte le loro applicazioni e non possono distribuire l'applicazione nel "Cubo", poiché tutte le richieste sotto il loro spazio dei nomi sono già state "spese".
La soluzione corretta per uscire da questa situazione è guardare il consumo effettivo delle risorse e confrontarlo con l'importo richiesto (Richiesta).
Negli screenshot qui sopra puoi vedere che le CPU "richieste" corrispondono al numero reale di thread e che i limiti possono superare il numero reale di thread della CPU =)
Ora diamo un'occhiata ad alcuni spazi dei nomi in dettaglio (ho scelto lo spazio dei nomi kube-system - lo spazio dei nomi di sistema per i componenti del "Cubo" stesso) e vediamo il rapporto tra il tempo del processore e la memoria effettivamente utilizzati e quello richiesto:
È ovvio che per i servizi di sistema viene riservata molta più memoria e CPU di quella effettivamente utilizzata. Nel caso del sistema kube, questo è giustificato: è successo che il controller di ingresso nginx o nodelocaldns al loro picco ha colpito la CPU e ha consumato molta RAM, quindi qui tale riserva è giustificata. Inoltre, non possiamo fare affidamento sui grafici delle ultime 3 ore: è auspicabile vedere i parametri storici su un ampio periodo di tempo.
È stato sviluppato un sistema di “raccomandazioni”. Ad esempio, qui puoi vedere quali risorse converrebbero alzare i “limiti” (la barra superiore consentita) in modo che non si verifichi il “throttling”: il momento in cui una risorsa ha già speso CPU o memoria nell'intervallo di tempo assegnato e sta aspettando finché non sarà “scongelato”:
Ed ecco i baccelli che dovrebbero frenare il loro appetito:
Про strozzatura + monitoraggio delle risorse, puoi scrivere più di un articolo, quindi fai domande nei commenti. In poche parole, posso dire che il compito di automatizzare tali metriche è molto difficile e richiede molto tempo e un lavoro di bilanciamento con le funzioni “finestra” e “CTE” Prometheus / VictoriaMetrics (questi termini sono tra virgolette, poiché esiste quasi niente di simile in PromQL e devi dividere le query spaventose in diverse schermate di testo e ottimizzarle).
Di conseguenza, gli sviluppatori dispongono di strumenti per monitorare i propri spazi dei nomi in Cube e possono scegliere da soli dove e a che ora, a quali applicazioni possono essere “tagliate” le risorse e a quali server può essere assegnata l’intera CPU per tutta la notte.
Metodologie
Nell'azienda così com'è adesso moda, aderiamo a DevOps- e SRE-praticante Quando un’azienda ha 1000 microservizi, circa 350 sviluppatori e 15 amministratori per l’intera infrastruttura, bisogna “essere alla moda”: dietro tutte queste “parolacce” c’è l’urgenza di automatizzare tutto e tutti, e gli amministratori non devono essere un collo di bottiglia nei processi.
Come Ops, forniamo varie metriche e dashboard per gli sviluppatori relativi ai tassi di risposta e agli errori del servizio.
Utilizziamo metodologie come: , и combinandoli insieme. Cerchiamo di ridurre al minimo il numero di dashboard in modo che a colpo d'occhio sia chiaro quale servizio è attualmente in peggioramento (ad esempio, codici di risposta al secondo, tempo di risposta del 99° percentile) e così via. Non appena alcune nuove metriche diventano necessarie per le dashboard generali, le disegniamo e le aggiungiamo immediatamente.
Non disegno grafici da un mese. Questo è probabilmente un buon segno: significa che la maggior parte dei “desideri” sono già stati realizzati. Mi capitava che durante la settimana disegnassi qualche nuovo grafico almeno una volta al giorno.
Il risultato risultante è prezioso perché ora gli sviluppatori raramente si rivolgono agli amministratori con domande su “dove guardare qualche tipo di metrica”.
Внедрение Rete di servizio è dietro l'angolo e dovrebbe rendere la vita molto più semplice a tutti, i colleghi di Tools sono già vicini a implementare l'abstract “Istio di una persona sana”: il ciclo di vita di ogni richiesta HTTP(s) sarà visibile nel monitoraggio, e sarà sempre possibile capire “in quale fase si è rotto tutto” durante l'interazione tra servizi (e non solo). Iscriviti alle notizie dall'hub DomClick. =)
Supporto dell'infrastruttura Kubernetes
Storicamente, utilizziamo la versione con patch Kubespray — Ruolo Ansible per la distribuzione, l'estensione e l'aggiornamento di Kubernetes. Ad un certo punto, il supporto per le installazioni non kubeadm è stato interrotto dal ramo principale e il processo di passaggio a kubeadm non è stato proposto. Di conseguenza, l'azienda di Southbridge ha creato il proprio fork (con supporto kubeadm e una soluzione rapida per i problemi critici).
Il processo per aggiornare tutti i cluster k8s è simile al seguente:
- prendere Kubespray da Southbridge, controlla con il nostro thread, Merjim.
- Stiamo distribuendo l'aggiornamento a Stress- “Cubo”.
- Lanciamo l'aggiornamento un nodo alla volta (in Ansible questo è "serial: 1") in Dev- “Cubo”.
- Aggiorniamo Prod sabato sera un nodo alla volta.
Ci sono piani per sostituirlo in futuro Kubespray per qualcosa di più veloce e vai a kubeadm.
In totale abbiamo tre “Cubi”: Stress, Dev e Prod. Stiamo progettando di lanciarne un altro (attesa calda) Prod-“Cube” nel secondo data center. Stress и Dev vivono in “macchine virtuali” (oVirt for Stress e VMWare cloud for Dev). Prod- "Cube" vive di "bare metal": si tratta di nodi identici con 32 thread CPU, 64-128 GB di memoria e SSD RAID 300 da 10 GB - ce ne sono 50 in totale. Tre nodi “thin” sono dedicati ai “master” Prod- “Cuba”: 16 GB di memoria, 12 thread CPU.
Per le vendite preferiamo utilizzare il “bare metal” ed evitare strati non necessari come OpenStack: non abbiamo bisogno di “vicini rumorosi” e CPU rubare tempo. E con OpenStack interno la complessità amministrativa quasi raddoppia.
Per CI/CD "Cubic" e altri componenti dell'infrastruttura utilizziamo un server GIT separato, Helm 3 (è stata una transizione piuttosto dolorosa da Helm 2, ma siamo molto soddisfatti delle opzioni atomico), Jenkins, Ansible e Docker. Adoriamo i rami delle funzionalità e la distribuzione in ambienti diversi da un unico repository.
conclusione
Questo è, in termini generali, come appare il processo DevOps in DomClick dal punto di vista di un ingegnere operativo. L'articolo si è rivelato meno tecnico di quanto mi aspettassi: seguite quindi le news di DomClick su Habré: ci saranno articoli più “hardcore” su Kubernetes e altro ancora.
Fonte: habr.com