Mein Name ist Viktor Yagofarov und ich entwickle die Kubernetes-Plattform bei DomClick als technischer Entwicklungsmanager im Ops-Team (Betrieb). Ich möchte über die Struktur unserer Dev <-> Ops-Prozesse, die Besonderheiten des Betriebs eines der größten k8s-Cluster in Russland sowie die DevOps/SRE-Praktiken sprechen, die unser Team anwendet.
Ops-Team
Das Ops-Team besteht derzeit aus 15 Personen. Drei davon sind für das Büro zuständig, zwei arbeiten in einer anderen Zeitzone und sind auch nachts erreichbar. Somit ist immer jemand vom Operationsteam am Monitor und bereit, auf einen Vorfall beliebiger Komplexität zu reagieren. Bei uns gibt es keine Nachtschichten, das schont unsere Psyche und gibt jedem die Möglichkeit, ausreichend Schlaf zu bekommen und seine Freizeit nicht nur am Computer zu verbringen.
Jeder hat unterschiedliche Kompetenzen: Netzwerker, DBAs, ELK-Stack-Spezialisten, Kubernetes-Administratoren/-Entwickler, Überwachung, Virtualisierung, Hardware-Spezialisten usw. Eines eint alle – jeder kann jeden von uns bis zu einem gewissen Grad ersetzen: zum Beispiel neue Knoten in den k8s-Cluster einführen, PostgreSQL aktualisieren, eine CI/CD + Ansible-Pipeline schreiben, etwas in Python/Bash/Go automatisieren, Hardware anschließen Rechenzentrum. Starke Kompetenzen in irgendeinem Bereich hindern Sie nicht daran, Ihre Tätigkeitsrichtung zu ändern und sich in einem anderen Bereich zu verbessern. Ich bin zum Beispiel als PostgreSQL-Spezialist in ein Unternehmen eingetreten und jetzt liegt mein Hauptaufgabengebiet bei Kubernetes-Clustern. Im Team ist jede Körpergröße willkommen und das Hebelgefühl ist sehr ausgeprägt.
Übrigens, wir sind auf der Jagd. Die Anforderungen an Kandidaten sind durchaus Standard. Für mich persönlich ist es wichtig, dass jemand ins Team passt, konfliktfrei ist, aber auch seinen Standpunkt zu verteidigen weiß, sich weiterentwickeln will, keine Angst vor Neuem hat und seine Ideen einbringt. Außerdem sind Programmierkenntnisse in Skriptsprachen, Kenntnisse der Grundlagen von Linux und Englisch erforderlich. Englisch wird lediglich benötigt, damit eine Person im Falle eines Fakap in 10 Sekunden und nicht in 10 Minuten eine Lösung für das Problem googeln kann. Es ist mittlerweile sehr schwierig, Spezialisten mit fundierten Linux-Kenntnissen zu finden: Es ist lustig, aber zwei von drei Kandidaten können die Frage „Was ist Load Average?“ nicht beantworten. Woraus besteht es?“ und die Frage „Wie stellt man aus einem C-Programm einen Core-Dump zusammen?“ gilt als etwas aus der Welt der Übermenschen ... oder Dinosaurier. Wir müssen uns damit abfinden, da die Leute normalerweise über hochentwickelte andere Kompetenzen verfügen, aber wir werden Linux unterrichten. Die Antwort auf die Frage „Warum muss ein DevOps-Ingenieur das alles in der modernen Welt der Clouds wissen?“ muss außerhalb des Rahmens des Artikels bleiben, aber in drei Worten: All dies ist notwendig.
Team-Tools
Das Tools-Team spielt eine wichtige Rolle bei der Automatisierung. Ihre Hauptaufgabe besteht darin, praktische Grafik- und CLI-Tools für Entwickler zu erstellen. Mit unserem internen Entwicklungs-Confer können Sie beispielsweise buchstäblich mit nur wenigen Mausklicks eine Anwendung auf Kubernetes ausrollen, ihre Ressourcen, Schlüssel aus dem Tresor usw. konfigurieren. Zuvor gab es Jenkins + Helm 2, aber ich musste mein eigenes Tool entwickeln, um das Kopieren und Einfügen zu eliminieren und den Software-Lebenszyklus einheitlich zu gestalten.
Das Ops-Team schreibt keine Pipelines für Entwickler, kann aber bei allen Problemen beim Schreiben beratend zur Seite stehen (einige Leute haben immer noch Helm 3).
DevOps
Was DevOps betrifft, sehen wir das so:
Entwicklerteams schreiben Code und führen ihn über Confer to dev -> qa/stage -> prod aus. Die Verantwortung dafür, dass der Code nicht langsamer wird und keine Fehler enthält, liegt bei den Dev- und Ops-Teams. Tagsüber sollte der diensthabende Administrator des Ops-Teams zunächst mit seinem Antrag auf einen Vorfall reagieren und abends und nachts sollte der diensthabende Administrator (Ops) den diensthabenden Entwickler wecken, wenn er es weiß Stellen Sie sicher, dass das Problem nicht in der Infrastruktur liegt. Alle Metriken und Warnungen im Monitoring werden automatisch oder halbautomatisch angezeigt.
Der Verantwortungsbereich von Ops beginnt mit der Einführung der Anwendung in die Produktion, aber die Verantwortung von Dev endet hier nicht – wir machen das Gleiche und sitzen im selben Boot.
Entwickler beraten Administratoren, wenn sie Hilfe beim Schreiben eines Admin-Microservices benötigen (z. B. Go-Backend + HTML5), und Administratoren beraten Entwickler bei allen Infrastrukturproblemen oder Problemen im Zusammenhang mit k8s.
Übrigens haben wir überhaupt keinen Monolithen, sondern nur Microservices. Ihre Zahl schwankt bisher zahlenmäßig zwischen 900 und 1000 im prod k8s-Cluster Implementierungen. Die Anzahl der Pods schwankt zwischen 1700 und 2000. Derzeit befinden sich etwa 2000 Pods im Produktcluster.
Genaue Zahlen kann ich nicht nennen, da wir unnötige Microservices überwachen und halbautomatisch ausschalten. K8s hilft uns, den Überblick über unnötige Entitäten zu behalten , was eine Menge Ressourcen und Geld spart.
Ressourcen Management
Überwachung
Eine gut strukturierte und informative Überwachung wird zum Grundstein für den Betrieb eines großen Clusters. Da wir noch keine universelle Lösung gefunden haben, die alle Überwachungsanforderungen zu 100 % abdeckt, erstellen wir in dieser Umgebung regelmäßig verschiedene maßgeschneiderte Lösungen.
- Zabbix. Gutes altes Monitoring, das in erster Linie den Gesamtzustand der Infrastruktur verfolgen soll. Es sagt uns, wann ein Knoten in Bezug auf Verarbeitung, Speicher, Festplatten, Netzwerk usw. ausfällt. Nichts Übernatürliches, aber wir haben auch ein separates DaemonSet von Agenten, mit dessen Hilfe wir beispielsweise den Status von DNS im Cluster überwachen: Wir suchen nach dummen Coredns-Pods, wir prüfen die Verfügbarkeit externer Hosts. Es scheint, dass man sich damit die Mühe machen sollte, aber bei großen Verkehrsmengen stellt diese Komponente eine ernsthafte Fehlerquelle dar. Ich habe schon , wie ich mit der DNS-Leistung in einem Cluster zu kämpfen hatte.
- Prometheus-Operator. Eine Reihe verschiedener Exporter bietet einen umfassenden Überblick über alle Komponenten des Clusters. Als nächstes visualisieren wir das alles auf großen Dashboards in Grafana und nutzen den Alertmanager für Alarme.
Ein weiteres nützliches Tool für uns war . Wir haben es geschrieben, nachdem wir mehrere Male auf eine Situation gestoßen waren, in der ein Team die Ingress-Pfade eines anderen Teams überlappte, was zu 50-fachen Fehlern führte. Vor der Bereitstellung in der Produktion prüfen die Entwickler nun, ob niemand betroffen ist, und für mein Team ist dies ein gutes Tool für die Erstdiagnose von Problemen mit Ingresses. Es ist lustig, dass es zunächst für Administratoren geschrieben wurde und eher „unbeholfen“ aussah, aber nachdem sich die Entwicklerteams in das Tool verliebt hatten, veränderte es sich stark und sah nicht mehr so aus, als ob „ein Administrator ein Webgesicht für Administratoren erstellt hätte“. ” Bald werden wir dieses Tool aufgeben und solche Situationen werden bereits vor der Einführung der Pipeline validiert.
Teamressourcen im Cube
Bevor wir uns mit den Beispielen befassen, lohnt es sich zu erklären, wie wir Ressourcen zuweisen Mikrodienste.
Um zu verstehen, welche Teams und in welchen Mengen sie nutzen Ressourcen (Prozessor, Speicher, lokale SSD) weisen wir jedem Befehl seinen eigenen zu Namensraum im „Cube“ und begrenzen Sie seine maximalen Fähigkeiten in Bezug auf Prozessor, Speicher und Festplatte, nachdem zuvor die Bedürfnisse der Teams besprochen wurden. Dementsprechend blockiert ein Befehl im Allgemeinen nicht den gesamten Cluster für die Bereitstellung und weist Tausende von Kernen und Terabyte Speicher zu. Der Zugriff auf den Namespace wird über AD gewährt (wir verwenden RBAC). Namespaces und ihre Grenzen werden über einen Pull-Request zum GIT-Repository hinzugefügt, und dann wird alles automatisch über die Ansible-Pipeline ausgerollt.
Ein Beispiel für die Zuweisung von Ressourcen an ein Team:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Anforderungen und Grenzen
Gewürfelt" PREISANFRAGE (Request) ist die Anzahl der garantiert reservierten Ressourcen für Schote (ein oder mehrere Docker-Container) in einem Cluster. Das Limit ist ein nicht garantiertes Maximum. In den Diagrammen können Sie oft sehen, dass ein Team zu viele Anfragen für alle seine Anwendungen gestellt hat und die Anwendung nicht im „Cube“ bereitstellen kann, da alle Anfragen unter ihrem Namensraum bereits „ausgegeben“ wurden.
Der richtige Ausweg aus dieser Situation besteht darin, den tatsächlichen Ressourcenverbrauch zu betrachten und ihn mit der angeforderten Menge (Anfrage) zu vergleichen.
In den Screenshots oben können Sie sehen, dass „Angeforderte“ CPUs der tatsächlichen Anzahl von Threads entsprechen und die Grenzwerte die tatsächliche Anzahl von CPU-Threads überschreiten können =)
Schauen wir uns nun einige Namespaces im Detail an (ich habe den Namespace kube-system gewählt – den Systemnamespace für die Komponenten des „Cube“ selbst) und sehen wir uns das Verhältnis der tatsächlich verwendeten Prozessorzeit und des Speichers zur angeforderten an:
Es ist offensichtlich, dass viel mehr Speicher und CPU für Systemdienste reserviert ist, als tatsächlich genutzt wird. Im Fall des Kube-Systems ist dies gerechtfertigt: Es kam vor, dass Nginx-Ingress-Controller oder Nodelocaldns auf ihrem Höhepunkt die CPU trafen und viel RAM verbrauchten, daher ist hier eine solche Reserve gerechtfertigt. Darüber hinaus können wir uns nicht auf Diagramme der letzten drei Stunden verlassen: Es ist wünschenswert, historische Kennzahlen über einen längeren Zeitraum anzuzeigen.
Es wurde ein System von „Empfehlungen“ entwickelt. Hier können Sie beispielsweise sehen, für welche Ressourcen es besser wäre, die „Limits“ (die obere zulässige Leiste) anzuheben, damit keine „Drosselung“ auftritt: der Moment, in dem eine Ressource in der zugewiesenen Zeitscheibe bereits CPU oder Speicher verbraucht hat und wartet, bis es „aufgetaut“ wird:
Und hier sind die Schoten, die ihren Appetit zügeln sollten:
Про Drosselung + Ressourcenüberwachung, Sie können mehr als einen Artikel schreiben, stellen Sie also Fragen in den Kommentaren. In wenigen Worten kann ich sagen, dass die Aufgabe, solche Metriken zu automatisieren, sehr schwierig ist und viel Zeit und einen Balanceakt mit „Fenster“-Funktionen und „CTE“ Prometheus / VictoriaMetrics erfordert (diese Begriffe stehen in Anführungszeichen, da sie fast vorhanden sind). In PromQL gibt es nichts Vergleichbares, und Sie müssen gruselige Abfragen in mehrere Textbildschirme aufteilen und diese optimieren.
Dadurch stehen Entwicklern Tools zur Überwachung ihrer Namespaces in Cube zur Verfügung und sie können selbst entscheiden, wo und zu welchem Zeitpunkt welche Anwendungen ihre Ressourcen „kürzungen“ erhalten und welchen Servern die ganze Nacht über die gesamte CPU zur Verfügung gestellt werden kann.
Methoden
Im Unternehmen, wie es jetzt ist modisch, wir halten uns an DevOps- und SRE-Praktiker Wenn ein Unternehmen über 1000 Microservices, etwa 350 Entwickler und 15 Admins für die gesamte Infrastruktur verfügt, muss man „in Mode“ sein: Hinter all diesen „Baswords“ steckt der dringende Bedarf, alles und jeden zu automatisieren, und Admins sollten kein Flaschenhals sein in Prozessen.
Als Ops stellen wir Entwicklern verschiedene Metriken und Dashboards im Zusammenhang mit Service-Antwortraten und Fehlern zur Verfügung.
Wir verwenden Methoden wie: , и indem man sie miteinander kombiniert. Wir versuchen, die Anzahl der Dashboards zu minimieren, damit auf einen Blick klar ist, welcher Dienst sich derzeit verschlechtert (z. B. Antwortcodes pro Sekunde, Antwortzeit im 99. Perzentil) usw. Sobald für allgemeine Dashboards neue Metriken erforderlich werden, zeichnen wir diese sofort ein und fügen sie hinzu.
Ich habe seit einem Monat keine Grafiken mehr gezeichnet. Das ist wahrscheinlich ein gutes Zeichen: Es bedeutet, dass die meisten „Wünsche“ bereits in Erfüllung gegangen sind. Es kam vor, dass ich unter der Woche mindestens einmal am Tag eine neue Grafik zeichnete.
Das daraus resultierende Ergebnis ist wertvoll, da sich Entwickler heutzutage nur noch selten mit der Frage an Administratoren wenden, „wo sie sich eine Art Metrik ansehen sollen“.
Внедрение Service-Mesh steht vor der Tür und soll das Leben für alle deutlich einfacher machen. Die Kollegen von Tools stehen bereits kurz vor der Umsetzung des abstrakten „Istio eines gesunden Menschen“: Der Lebenszyklus jeder HTTP(s)-Anfrage wird im Monitoring sichtbar sein, und zwar Während der dienstübergreifenden (und nicht nur) Interaktion wird es immer möglich sein zu verstehen, „in welchem Stadium alles kaputt gegangen ist“. Abonnieren Sie Neuigkeiten vom DomClick-Hub. =)
Unterstützung der Kubernetes-Infrastruktur
Historisch gesehen verwenden wir die gepatchte Version Würfelspray – Ansible-Rolle für die Bereitstellung, Erweiterung und Aktualisierung von Kubernetes. Irgendwann wurde die Unterstützung für Nicht-Kubeadm-Installationen aus dem Hauptzweig gestrichen und der Prozess der Umstellung auf Kubeadm wurde nicht vorgeschlagen. Infolgedessen erstellte das Unternehmen Southbridge einen eigenen Fork (mit Kubeadm-Unterstützung und einer schnellen Lösung für kritische Probleme).
Der Prozess zum Aktualisieren aller k8s-Cluster sieht folgendermaßen aus:
- nehmen Würfelspray aus Southbridge, schauen Sie in unserem Thread nach, Merjim.
- Wir führen das Update für aus Stress- „Würfel“.
- Wir führen das Update Knoten für Knoten aus (in Ansible ist dies „seriell: 1“) Entwickler- „Würfel“.
- Wir aktualisieren Prod am Samstagabend einen Knoten nach dem anderen.
Es gibt Pläne, es in Zukunft zu ersetzen Würfelspray für etwas schnelleres und gehen Sie zu kubeadm.
Insgesamt haben wir drei „Cubes“: Stress, Dev und Prod. Wir planen die Einführung eines weiteren (Hot-Standby) Prod-„Cube“ im zweiten Rechenzentrum. Stress и Entwickler leben in „virtuellen Maschinen“ (oVirt für Stress und VMWare Cloud für Dev). Prod- „Cube“ lebt von „Bare Metal“: Das sind identische Knoten mit 32 CPU-Threads, 64-128 GB Speicher und 300 GB SSD RAID 10 – insgesamt gibt es 50 davon. Drei „dünne“ Knoten sind den „Mastern“ gewidmet. Prod- „Kuba“: 16 GB Speicher, 12 CPU-Threads.
Für den Verkauf verwenden wir bevorzugt „Bare Metal“ und verzichten auf unnötige Schichten wie z OpenStack: Wir brauchen keine „lauten Nachbarn“ und keine CPU Zeit stehlen. Und der Verwaltungsaufwand verdoppelt sich bei hauseigenem OpenStack etwa um das Doppelte.
Für CI/CD „Cubic“ und andere Infrastrukturkomponenten verwenden wir einen separaten GIT-Server, Helm 3 (es war ein ziemlich schmerzhafter Übergang von Helm 2, aber wir sind mit den Optionen sehr zufrieden Atom-), Jenkins, Ansible und Docker. Wir lieben Feature-Branches und die Bereitstellung in verschiedenen Umgebungen aus einem Repository.
Abschluss
So sieht im Allgemeinen der DevOps-Prozess bei DomClick aus der Sicht eines Betriebsingenieurs aus. Der Artikel erwies sich als weniger technisch als erwartet. Verfolgen Sie daher die DomClick-Nachrichten auf Habré: Es wird mehr „Hardcore“-Artikel über Kubernetes und mehr geben.
Source: habr.com