Em dic Viktor Yagofarov i estic desenvolupant la plataforma Kubernetes a DomClick com a gerent de desenvolupament tècnic a l'equip d'operacions (operacions). M'agradaria parlar-vos de l'estructura dels nostres processos Dev <-> Ops, de les característiques d'operar un dels clústers k8s més grans de Rússia, així com de les pràctiques DevOps / SRE que utilitza el nostre equip.
Opcions d'equip
Actualment l'equip d'Ops compta amb 15 persones. Tres d'ells són responsables de l'oficina, dos treballen en una zona horària diferent i estan disponibles, fins i tot de nit. Així, algú d'Ops està sempre al monitor i està preparat per respondre a un incident de qualsevol complexitat. No tenim torns de nit, la qual cosa preserva la nostra mentalitat i dóna l'oportunitat a tothom de dormir prou i passar el temps lliure no només davant l'ordinador.
Cadascú té competències diferents: usuaris de xarxa, DBA, especialistes en pila ELK, administradors/desenvolupadors de Kubernetes, monitorització, virtualització, especialistes en maquinari, etc. Una cosa uneix a tothom: tothom pot substituir qualsevol de nosaltres fins a cert punt: per exemple, introduir nous nodes al clúster k8s, actualitzar PostgreSQL, escriure una canalització CI / CD + Ansible, automatitzar alguna cosa a Python / Bash / Go, connectar una peça. de maquinari a DPC. Les competències fortes en cap àrea no interfereixen amb el canvi de direcció de l'activitat i començar a bombejar en alguna altra àrea. Per exemple, vaig aconseguir una feina en una empresa com a especialista en PostgreSQL, i ara la meva principal àrea de responsabilitat són els clústers de Kubernetes. A l'equip, qualsevol creixement és només benvingut i el sentit de l'espatlla està molt desenvolupat.
Per cert, cacem. Els requisits per als candidats són bastant estàndard. Per a mi personalment, és important que una persona encaixi a l'equip, no sigui conflictiva, però també sàpiga defensar el seu punt de vista, vulgui desenvolupar-se i no tingui por de fer alguna cosa nova, d'oferir les seves idees. També es requereixen coneixements de programació en llenguatges de script, coneixements bàsics de Linux i anglès. L'anglès es necessita només perquè una persona en el cas d'un fakap pugui buscar a Google la solució al problema en 10 segons, i no en 10 minuts. Amb especialistes amb profunds coneixements de Linux, ara és molt difícil: divertit, però dos de cada tres candidats no poden respondre a la pregunta “Què és la mitjana de càrrega? En què consisteix? ", I la pregunta "Com recollir un abocador de nuclis d'un programa sish" es considera una cosa del món dels superhumans... o dels dinosaures. Hem d'aguantar això, ja que normalment la gent té altres competències molt desenvolupades, i nosaltres ensenyarem Linux. La resposta a la pregunta "per què un enginyer de DevOps necessita saber tot això en el món modern dels núvols" s'haurà de deixar fora de l'àmbit de l'article, però en tres paraules: tot això és necessari.
Comandament d'eines
L'equip d'eines té un paper important en l'automatització. La seva tasca principal és crear eines gràfiques i CLI convenients per als desenvolupadors. Per exemple, el nostre desenvolupament intern de Confer us permet desplegar una aplicació a Kubernetes amb només uns quants clics del ratolí, configurar els seus recursos, claus des de la bóveda, etc. Abans hi havia Jenkins + Helm 2, però vaig haver de desenvolupar la meva pròpia eina per eliminar el còpia i enganxar i uniformitzar el cicle de vida del programari.
L'equip d'operacions no escriu pipelines per als desenvolupadors, però pot assessorar sobre qualsevol problema en escriure'ls (alguns encara tenen Helm 3).
DevOps
Pel que fa a DevOps, ho veiem així:
Els equips de desenvolupadors escriuen codi, desplega'l mitjançant Confer to dev -> qa/stage -> prod. És responsabilitat dels equips de desenvolupament i d'operacions assegurar-se que el codi no s'alenteix i no genera errors. Durant el dia, l'oficial de servei de l'equip d'operacions hauria de respondre a un incident amb la seva aplicació i, al vespre i a la nit, l'administrador de servei (Ops) hauria de despertar el desenvolupador de servei si sap del cert que el problema no és a la infraestructura. Totes les mètriques i alertes del monitoratge apareixen automàticament o semiautomàticament.
L'àrea de responsabilitat d'Ops comença des del moment en què l'aplicació es desplega fins a la producció, però la responsabilitat de Dev no acaba aquí: fem una cosa i estem al mateix vaixell.
Els desenvolupadors aconsellen als administradors si necessiten ajuda per escriure un microservei d'administració (per exemple, Go backend + HTML5) i els administradors assessoren els desenvolupadors sobre qualsevol problema relacionat amb la infraestructura o amb k8s.
Per cert, no tenim cap monòlit, només microserveis. El seu nombre fins ara oscil·la entre 900 i 1000 al clúster prod k8s, si es mesura pel nombre desplegaments. El nombre de beines oscil·la entre els 1700 i els 2000. Les beines del grup de productes són ara al voltant dels 2000.
No puc donar números exactes, ja que monitoritzem microserveis innecessaris i els tallem en mode semiautomàtic. Fer un seguiment de les entitats innecessàries a k8s ens ajuda que estalvia recursos i diners.
Gestió de recursos
Seguiment
El seguiment informatiu i construït amb competència es converteix en la pedra angular en el funcionament d'un gran clúster. Encara no hem trobat una solució universal que cobreixi el 100% de totes les necessitats de monitorització, per la qual cosa reblonem periòdicament diferents solucions personalitzades en aquest entorn.
- Zabbix. Una bona monitorització antiga, que està dissenyada principalment per controlar l'estat general de la infraestructura. Ens indica quan un node mor per processador, memòria, discs, xarxa, etc. Res de sobrenatural, però també tenim un DaemonSet d'agents separat, amb l'ajuda del qual, per exemple, controlem l'estat del DNS al clúster: busquem pods coredns estúpids, comprovem la disponibilitat d'amfitrions externs. Sembla que per això molestar-se per això, però en grans volums de trànsit aquest component és un punt de fallada greu. Abans en tinc com es va lluitar amb el rendiment de DNS al clúster.
- Operador Prometeu. Un conjunt d'exportadors diferents ofereix una gran visió general de tots els components del clúster. A continuació, visualitzem tot això en taulers grans de Grafana i utilitzem alertmanager per a les notificacions.
Una altra eina útil per a nosaltres és . Ho vam escriure després de trobar-nos diverses vegades amb una situació en què un equip superposava l'entrada d'un altre equip amb els seus camins, cosa que va provocar errors 50x. Ara, abans de desplegar-se en producció, els desenvolupadors comproven que no faran mal a ningú, i per al meu equip aquesta és una bona eina per al diagnòstic inicial de problemes amb Ingresses. És curiós que al principi es va escriure per a administradors i semblava bastant "maldestre", però després que els equips de desenvolupament es van enamorar de l'eina, va canviar molt i va començar a semblar que no "l'administrador va fer una cara web per als administradors". . Aviat abandonarem aquesta eina i aquestes situacions es validaran fins i tot abans que el gasoducte es desplega.
Recursos de l'equip a "Cube"
Abans de continuar amb els exemples, val la pena explicar com disposem de l'assignació de recursos microserveis.
Entendre quins equips i en quines quantitats els fan servir recursos (processador, memòria, SSD local), hi assignem el nostre espai de noms al "Cube" i limitar les seves màximes capacitats pel que fa a processador, memòria i disc, havent comentat prèviament les necessitats dels equips. En conseqüència, una comanda, en el cas general, no bloquejarà tot el clúster per al desplegament, assignant-se milers de nuclis i terabytes de memòria. Els accessos a l'espai de noms s'emeten mitjançant AD (utilitzem RBAC). Els espais de noms i els seus límits s'afegeixen mitjançant una sol·licitud d'extracció al repositori GIT i, tot seguit, tot es desplega automàticament mitjançant la canalització Ansible.
Un exemple d'assignació de recursos per equip:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Peticions i límits
Cubit" Sol · licitar és el nombre de recursos reservats garantits sota beina (un o més contenidors docker) en un clúster. El límit és un màxim no garantit. Sovint es pot veure als gràfics com algun equip s'ha fet massa sol·licituds per a totes les seves aplicacions i no pot desplegar l'aplicació al "Cube", ja que sota el seu espai de noms totes les sol·licituds ja s'han "gastat".
La manera correcta de sortir d'aquesta situació és mirar el consum real de recursos i comparar-lo amb la quantitat sol·licitada (Solicitud).
Les captures de pantalla anteriors mostren que les CPU "sol·licitades" (sol·licitades) es seleccionen al nombre real de fils, i els límits poden superar el nombre real de fils de CPU =)
Ara analitzem en detall alguns espais de noms (he escollit l'espai de noms kube-system, l'espai de noms del sistema per als components del propi "Cube") i veiem la relació entre el temps i la memòria del processador realment utilitzats amb la sol·licitada:
És obvi que hi ha molta més memòria i CPU reservada per als serveis del sistema de la que s'utilitza realment. En el cas del sistema kube, això està justificat: va passar que el controlador d'entrada nginx o el nodelocaldns al pic es recolzaven a la CPU i es menjaven molta memòria RAM, de manera que aquí es justifica aquest marge. A més, no podem confiar en els gràfics de les últimes 3 hores: és desitjable veure mètriques històriques durant un gran període de temps.
Es va desenvolupar un sistema de "recomanacions". Per exemple, aquí podeu veure quins recursos seria millor augmentar els "límits" (la barra permesa superior) perquè no es produeixi "acceleració": el moment en què el pod ja ha gastat la CPU o la memòria durant el quàntic de temps assignat. i està esperant fins que es "descongeli":
I aquí teniu les beines que haurien de moderar la seva gana:
Про estrangulament + recursos de seguiment, podeu escriure més d'un article, així que feu preguntes als comentaris. En poques paraules, puc dir que la tasca d'automatitzar aquestes mètriques és molt difícil i requereix molt de temps i d'equilibri amb les funcions "finestra" i "CTE" Prometheus / VictoriaMetrics (aquests termes estan entre cometes, ja que hi ha gairebé res com això a PromQL, i heu de cercar consultes espantoses en diverses pantalles de text i optimitzar-les).
Com a resultat, els desenvolupadors disposen d'eines per supervisar els seus espais de noms al "Cube" i poden triar on i a quina hora quines aplicacions poden "tallar" els recursos i quins pods poden rebre tota la CPU tota la nit.
Metodologies
En companyia com ara de moda, ens adherim a DevOps- i SRE-practicant Quan una empresa té 1000 microserveis, uns 350 desenvolupadors i 15 administradors per a tota la infraestructura, cal "estar de moda": darrere de totes aquestes "paraules de moda" hi ha una necessitat urgent d'automatitzar-ho tot i tot, i els administradors no haurien de ser un coll d'ampolla. en processos.
Com a Ops, oferim diverses mètriques i taulers de control per als desenvolupadors relacionats amb el temps de resposta dels serveis i els seus errors.
Utilitzem metodologies com ara: , и combinant-los junts. Intentem minimitzar el nombre de quadres de comandament perquè d'un cop d'ull quedi clar quin servei s'està degradant actualment (per exemple, codis de resposta per segon, temps de resposta al percentil 99), etc. Tan bon punt es facin necessàries algunes mètriques noves per als taulers generals, les dibuixem i les afegim immediatament.
Fa un mes que no dibuixo gràfics. Probablement això és un bon senyal: vol dir que la majoria dels "desitjos" ja s'han implementat. Va passar que durant una setmana vaig dibuixar algun gràfic nou almenys un cop al dia.
El resultat resultant és valuós, ja que ara els desenvolupadors rarament acudeixen als administradors amb preguntes "on veure algun tipus de mètriques".
Implementació Malla de servei està a la volta de la cantonada i hauria de facilitar la vida a tothom, els companys d'Eines ja estan a prop d'implementar l'abstract "Istio of a healthy person": el cicle de vida de cada sol·licitud HTTP(s) serà visible a la supervisió i sempre serà possible entendre "en quina etapa es va trencar tot" en la interacció entre serveis (i no només). Subscriu-te a les notícies del centre de DomClick. =)
Suport a la infraestructura de Kubernetes
Històricament, utilitzem la versió pegada Kubespray - Funció Ansible per desplegar, ampliar i actualitzar Kubernetes. En algun moment, es va tallar el suport per a instal·lacions no kubeadm de la branca principal i no es va proposar el procés de transició a kubeadm. Com a resultat, Southbridge va crear la seva pròpia bifurcació (amb suport per a kubeadm i una solució ràpida per a problemes crítics).
El procés d'actualització per a tots els clústers k8s és el següent:
- Prengui Kubespray des de Southbridge, consulteu amb la nostra sucursal, merjim.
- Desplegant l'actualització a Estrès- "Cub".
- Despleguem l'actualització un node a la vegada (a Ansible això és "sèrie: 1") Dev- "Cub".
- Actualització Punxar dissabte al vespre, un node a la vegada.
En el futur hi ha plans per substituir Kubespray a una cosa més ràpida i anar a kubeadm.
En total, tenim tres "Cubs": Stress, Dev i Prod. Tenim previst llançar-ne un altreespera en calent) Prod- "Cube" al segon centre de dades. Estrès и Dev viuen a màquines virtuals (oVirt for Stress i VMWare cloud for Dev). Punxar- "Cube" viu en "bare metal" (bare metal): són els mateixos nodes amb 32 fils de CPU, 64-128 GB de memòria i 300 GB de SSD RAID 10: n'hi ha 50 en total. Tres nodes "prims" estan dedicats als "mestres" Punxar- "Cuba": 16 GB de memòria, 12 fils de CPU.
Per a les vendes, preferim utilitzar "metall nu" i evitar capes innecessàries com OpenStack: no necessitem "veïns sorollosos" i CPU robar el temps. I la complexitat de l'administració augmenta aproximadament la meitat en el cas d'OpenStack intern.
Per a CI/CD Cubic i altres components d'infraestructura utilitzem un servidor GIT independent, Helm 3 atòmica), Jenkins, Ansible i Docker. Ens encanten les branques de funcions i desplegar-les a diferents entorns des del mateix dipòsit.
Conclusió
Així és, en termes generals, el procés DevOps a DomClick des del costat d'un enginyer d'operacions. L'article va resultar ser menys tècnic del que esperava: per tant, seguiu les notícies de DomClick a Habré: hi haurà més articles "hardcore" sobre Kubernetes i més.
Font: www.habr.com