Mijn naam is Viktor Yagofarov en ik ontwikkel het Kubernetes-platform bij DomClick als technisch ontwikkelingsmanager in het Ops (operation)-team. Ik wil het graag hebben over de structuur van onze Dev <-> Ops-processen, de kenmerken van het runnen van een van de grootste k8s-clusters in Rusland, evenals de DevOps/SRE-praktijken die ons team toepast.
Ops-team
Het Ops-team bestaat momenteel uit 15 mensen. Drie van hen zijn verantwoordelijk voor het kantoor, twee werken in een andere tijdzone en zijn beschikbaar, ook 's nachts. Zo staat er altijd iemand van Ops achter de monitor en staat klaar om te reageren op een incident van welke complexiteit dan ook. We hebben geen nachtdiensten, wat onze psyche beschermt en iedereen de kans geeft om voldoende te slapen en vrije tijd door te brengen, niet alleen achter de computer.
Iedereen heeft verschillende competenties: netwerkers, DBA’s, ELK-stackspecialisten, Kubernetes-beheerders/-ontwikkelaars, monitoring, virtualisatie, hardwarespecialisten, etc. Eén ding verenigt iedereen: iedereen kan ieder van ons tot op zekere hoogte vervangen: bijvoorbeeld nieuwe knooppunten introduceren in het k8s-cluster, PostgreSQL updaten, een CI/CD + Ansible-pijplijn schrijven, iets automatiseren in Python/Bash/Go, hardware aansluiten op Datacentrum. Sterke competenties op welk gebied dan ook weerhouden u er niet van om uw activiteitenrichting te veranderen en op een ander gebied vooruitgang te boeken. Ik ben bijvoorbeeld bij een bedrijf gaan werken als PostgreSQL-specialist en nu ben ik vooral verantwoordelijk voor Kubernetes-clusters. In het team is elke lengte welkom en het gevoel van invloed is zeer ontwikkeld.
Trouwens, we zijn aan het jagen. De vereisten voor kandidaten zijn vrij standaard. Voor mij persoonlijk is het belangrijk dat een persoon in het team past, niet-conflict is, maar ook zijn standpunt weet te verdedigen, zich wil ontwikkelen en niet bang is om iets nieuws te doen, zijn ideeën aandraagt. Ook zijn programmeervaardigheden in scripttalen, kennis van de basisprincipes van Linux en Engels vereist. Er is eenvoudigweg Engels nodig zodat iemand in het geval van een fakap binnen 10 seconden een oplossing voor het probleem kan googlen, en niet binnen 10 minuten. Het is nu erg moeilijk om specialisten te vinden met diepgaande kennis van Linux: het is grappig, maar twee op de drie kandidaten kunnen de vraag “Wat is Load Average?” niet beantwoorden. Waar is het van gemaakt?”, en de vraag “Hoe assembleer je een kerndump uit een C-programma” wordt beschouwd als iets uit de wereld van supermensen... of dinosaurussen. We moeten dit accepteren, omdat mensen doorgaans andere competenties hoog ontwikkeld hebben, maar we zullen Linux onderwijzen. Het antwoord op de vraag “waarom moet een DevOps-ingenieur dit allemaal weten in de moderne wereld van de cloud” zal buiten de reikwijdte van het artikel moeten worden gelaten, maar in drie woorden: dit alles is nodig.
Teamhulpmiddelen
Het Tools-team speelt een belangrijke rol in de automatisering. Hun hoofdtaak is het creëren van handige grafische en CLI-tools voor ontwikkelaars. Met onze interne ontwikkelingsconferentie kunt u bijvoorbeeld letterlijk met slechts een paar muisklikken een applicatie naar Kubernetes uitrollen, de bronnen ervan configureren, sleutels uit de kluis gebruiken, enz. Voorheen was er Jenkins + Helm 2, maar ik moest mijn eigen tool ontwikkelen om kopiëren en plakken te elimineren en uniformiteit in de softwarelevenscyclus te brengen.
Het Ops-team schrijft geen pijplijnen voor ontwikkelaars, maar kan adviseren over eventuele problemen bij het schrijven ervan (sommige mensen hebben nog steeds Helm 3).
DevOps
Wat DevOps betreft, zien we het als volgt:
Ontwikkelteams schrijven code en rollen deze uit via Confer to dev -> qa/stage -> prod. De verantwoordelijkheid om ervoor te zorgen dat de code niet vertraagt en geen fouten bevat, ligt bij de Dev- en Ops-teams. Overdag moet de dienstdoende medewerker van het Ops-team allereerst reageren op een incident met zijn aanvraag, en 's avonds en 's nachts moet de dienstdoende beheerder (Ops) de dienstdoende ontwikkelaar wakker maken als hij weet zeker dat het probleem niet in de infrastructuur zit. Alle statistieken en waarschuwingen in de monitoring verschijnen automatisch of semi-automatisch.
Het verantwoordelijkheidsgebied van Ops begint vanaf het moment dat de applicatie in productie wordt genomen, maar de verantwoordelijkheid van Dev eindigt daar niet: we doen hetzelfde en zitten in hetzelfde schuitje.
Ontwikkelaars adviseren beheerders als ze hulp nodig hebben bij het schrijven van een beheerdersmicroservice (bijvoorbeeld Go backend + HTML5), en beheerders adviseren ontwikkelaars over eventuele infrastructuurproblemen of problemen met betrekking tot k8s.
We hebben trouwens helemaal geen monoliet, alleen microservices. Hun aantal schommelt tot nu toe tussen 900 en 1000 in het prod k8s-cluster, gemeten naar aantal implementaties. Het aantal peulen schommelt tussen 1700 en 2000. Momenteel bevinden zich ongeveer 2000 peulen in het productiecluster.
Ik kan geen exacte cijfers geven, omdat we onnodige microservices monitoren en deze semi-automatisch verwijderen. K8s helpt ons onnodige entiteiten bij te houden , wat veel middelen en geld bespaart.
авление есурсами
controle
Goed gestructureerde en informatieve monitoring wordt de hoeksteen van de werking van een groot cluster. We hebben nog geen universele oplossing gevonden die 100% van alle monitoringbehoeften zou dekken, dus creëren we periodiek verschillende maatwerkoplossingen in deze omgeving.
- Zabbix. Goede oude monitoring, die vooral bedoeld is om de algehele toestand van de infrastructuur in kaart te brengen. Het vertelt ons wanneer een knooppunt sterft in termen van verwerking, geheugen, schijven, netwerk, enzovoort. Niets bovennatuurlijks, maar we hebben ook een aparte DaemonSet van agenten, met behulp waarvan we bijvoorbeeld de status van DNS in het cluster monitoren: we zoeken naar domme coredns-pods, we controleren de beschikbaarheid van externe hosts. Het lijkt erop dat waarom je hier druk over zou maken, maar bij grote verkeersvolumes is dit onderdeel een ernstig faalpunt. Vroeger heb ik al , hoe ik worstelde met DNS-prestaties in een cluster.
- Prometheus-operator. Een set van verschillende exporteurs geeft een groot overzicht van alle componenten van het cluster. Vervolgens visualiseren we dit allemaal op grote dashboards in Grafana, en gebruiken alertmanager voor alerts.
Een ander handig hulpmiddel voor ons was . We schreven het nadat we verschillende keren een situatie tegenkwamen waarin het ene team de Ingress-paden van een ander team overlapte, wat resulteerde in 50x fouten. Voordat ontwikkelaars het in productie nemen, controleren ze of niemand hierdoor wordt getroffen, en voor mijn team is dit een goed hulpmiddel voor de eerste diagnose van problemen met Ingresses. Het is grappig dat het in eerste instantie voor beheerders was geschreven en dat het er nogal "onhandig" uitzag, maar nadat de ontwikkelteams verliefd werden op de tool, veranderde het veel en begon het er niet meer uit te zien als "een beheerder maakte een webgezicht voor beheerders". ” Binnenkort zullen we deze tool verlaten en dergelijke situaties zullen worden gevalideerd nog voordat de pijplijn is uitgerold.
Teambronnen in de Kubus
Voordat we op de voorbeelden ingaan, is het de moeite waard om uit te leggen hoe we middelen toewijzen microservices.
Om te begrijpen welke teams en in welke hoeveelheden hun gebruiken middelen (processor, geheugen, lokale SSD), wijzen we elke opdracht zijn eigen opdracht toe namespace in de “Cube” en de maximale mogelijkheden ervan te beperken op het gebied van processor, geheugen en schijf, nadat we eerder de behoeften van de teams hadden besproken. Dienovereenkomstig zal één commando in het algemeen niet het hele cluster blokkeren voor implementatie, waarbij duizenden kernen en terabytes aan geheugen worden toegewezen. Toegang tot de naamruimte wordt verleend via AD (we gebruiken RBAC). Naamruimten en hun limieten worden via een pull-verzoek toegevoegd aan de GIT-repository, en vervolgens wordt alles automatisch uitgerold via de Ansible-pijplijn.
Een voorbeeld van het toewijzen van middelen aan een team:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Verzoeken en limieten
In blokjes" Aanvraag is het aantal gegarandeerde gereserveerde bronnen voor peul (een of meer dockercontainers) in een cluster. Limiet is een niet-gegarandeerd maximum. Je kunt vaak in de grafieken zien hoe een team zichzelf te veel verzoeken heeft gesteld voor al zijn applicaties en de applicatie niet in de “Cube” kan implementeren, omdat alle verzoeken onder hun naamruimte al zijn “uitgegeven”.
De juiste uitweg uit deze situatie is door naar het werkelijke verbruik van hulpbronnen te kijken en dit te vergelijken met de gevraagde hoeveelheid (Verzoek).
In de bovenstaande schermafbeeldingen kun je zien dat de “Aangevraagde” CPU’s overeenkomen met het werkelijke aantal threads, en dat de limieten het werkelijke aantal CPU-threads kunnen overschrijden =)
Laten we nu eens in detail naar een bepaalde naamruimte kijken (ik heb gekozen voor naamruimte kube-system - de systeemnaamruimte voor de componenten van de "Kubus" zelf) en de verhouding bekijken tussen feitelijk gebruikte processortijd en geheugen en de gevraagde:
Het is duidelijk dat er veel meer geheugen en CPU wordt gereserveerd voor systeemdiensten dan feitelijk wordt gebruikt. In het geval van het kube-systeem is dit gerechtvaardigd: het gebeurde dat de nginx-ingangscontroller of nodelocaldns op hun hoogtepunt de CPU raakten en veel RAM verbruikten, dus hier is een dergelijke reserve gerechtvaardigd. Bovendien kunnen we niet vertrouwen op grafieken van de afgelopen drie uur: het is wenselijk om historische statistieken over een lange periode te zien.
Er werd een systeem van “aanbevelingen” ontwikkeld. Hier kunt u bijvoorbeeld zien welke bronnen er beter aan doen de “limieten” (de bovenste toegestane balk) te verhogen, zodat er geen “throttling” optreedt: het moment waarop een resource de CPU of het geheugen al heeft verbruikt in de toegewezen tijdsperiode en wacht totdat het wordt “ontvroren”:
En hier zijn de peulen die hun eetlust zouden moeten beteugelen:
Про smoren + monitoring van bronnen, u kunt meer dan één artikel schrijven, dus stel vragen in de reacties. In een paar woorden kan ik zeggen dat de taak van het automatiseren van dergelijke statistieken erg moeilijk is en veel tijd en evenwichtsoefening vereist met “venster”-functies en “CTE” Prometheus / VictoriaMetrics (deze termen staan tussen aanhalingstekens, aangezien er bijna geen zoiets bestaat niet in PromQL, en je moet enge zoekopdrachten in verschillende tekstschermen verdelen en deze optimaliseren).
Als gevolg hiervan beschikken ontwikkelaars over tools om hun naamruimten in Cube te monitoren, en kunnen ze zelf kiezen waar en op welk tijdstip van welke applicaties de resources kunnen worden 'bezuinigd', en welke servers de hele nacht de hele CPU kunnen krijgen.
Methodologieën
In het bedrijf zoals het nu is in de mode, wij houden ons aan DevOps- en SRE-beoefenaar Wanneer een bedrijf 1000 microservices, ongeveer 350 ontwikkelaars en 15 beheerders voor de gehele infrastructuur heeft, moet je ‘in de mode zijn’: achter al deze ‘baswoorden’ schuilt een dringende noodzaak om alles en iedereen te automatiseren, en beheerders mogen geen knelpunt zijn bij processen.
Als Ops bieden we verschillende statistieken en dashboards voor ontwikkelaars met betrekking tot serviceresponspercentages en fouten.
Wij gebruiken methodieken zoals: , и door ze met elkaar te combineren. We proberen het aantal dashboards te minimaliseren, zodat in één oogopslag duidelijk is welke service momenteel degradeert (bijvoorbeeld responscodes per seconde, responstijd op 99e percentiel), enzovoort. Zodra er nieuwe metrics nodig zijn voor algemene dashboards, tekenen en voegen wij deze direct toe.
Ik heb al een maand geen grafieken getekend. Dit is waarschijnlijk een goed teken: het betekent dat de meeste ‘wensen’ al zijn gerealiseerd. Het gebeurde dat ik gedurende de week minstens één keer per dag een nieuwe grafiek tekende.
Het resulterende resultaat is waardevol omdat ontwikkelaars nu zelden naar beheerders gaan met de vraag “waar ze naar een bepaalde statistiek moeten kijken.”
Внедрение Servicenetwerk staat voor de deur en zou het leven voor iedereen een stuk makkelijker moeten maken, collega’s van Tools zijn al dicht bij de implementatie van het abstracte “Istio van een gezond mens”: de levenscyclus van elk HTTP(s)-verzoek zal zichtbaar zijn in de monitoring, en het zal altijd mogelijk zijn om te begrijpen “in welk stadium alles kapot ging” tijdens de interactie tussen diensten (en niet alleen). Abonneer u op nieuws van de DomClick-hub. =)
Ondersteuning voor Kubernetes-infrastructuur
Historisch gezien gebruiken we de gepatchte versie Kubespray — Ansible-rol voor het inzetten, uitbreiden en updaten van Kubernetes. Op een gegeven moment werd de ondersteuning voor niet-kubeadm-installaties uit de hoofdtak stopgezet en werd het proces van overstappen naar kubeadm niet voorgesteld. Als gevolg hiervan maakte het bedrijf Southbridge zijn eigen fork (met kubeadm-ondersteuning en een snelle oplossing voor kritieke problemen).
Het proces voor het updaten van alle k8s-clusters ziet er als volgt uit:
- nemen Kubespray uit Southbridge, neem contact op met onze draad, Merjim.
- We rollen de update uit naar Spanning- "Kubus".
- We rollen de update knooppunt voor knooppunt uit (in Ansible is dit “serieel: 1”) Dev- "Kubus".
- Wij updaten Porren op zaterdagavond knooppunt voor knooppunt.
Er zijn plannen om deze in de toekomst te vervangen Kubespray voor iets snellers en ga naar Kubeadm.
In totaal hebben we drie “Cubes”: Stress, Dev en Prod. We zijn van plan er nog een te lanceren (hete stand-by) Prod-“Cube” in het tweede datacenter. Spanning и Dev live in “virtuele machines” (oVirt voor Stress en VMWare cloud voor Dev). Porren- "Cube" leeft op "bare metal": dit zijn identieke knooppunten met 32 CPU-threads, 64-128 GB geheugen en 300 GB SSD RAID 10 - er zijn er in totaal 50. Drie “dunne” knooppunten zijn bedoeld voor “meesters” Porren- “Cuba”: 16 GB geheugen, 12 CPU-threads.
Voor de verkoop gebruiken wij bij voorkeur “bare metal” en vermijden we onnodige lagen zoals OpenStack: we hebben geen “luidruchtige buren” en CPU nodig tijd stelen. En de complexiteit van het beheer verdubbelt ongeveer bij in-house OpenStack.
Voor CI/CD “Cubic” en andere infrastructuurcomponenten gebruiken we een aparte GIT-server, Helm 3 (het was een nogal pijnlijke overgang vanaf Helm 2, maar we zijn erg blij met de opties atomair), Jenkins, Ansible en Docker. We houden van feature branches en implementatie in verschillende omgevingen vanuit één repository.
Conclusie
Dit is in algemene termen hoe het DevOps-proces er bij DomClick uitziet vanuit het perspectief van een operations engineer. Het artikel bleek minder technisch dan ik had verwacht: volg daarom het DomClick-nieuws op Habré: er komen meer “hardcore” artikelen over Kubernetes en meer.
Bron: www.habr.com