{"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\/de\/blog\/administrirovanie\/kubernetes-v-domklik-kak-spat-spokojno-upravlyaya-klasterom-na-1000-mikroservisov","title":{"rendered":"Kubernetes bei DomClick: Wie man ruhig schlafen kann, w\u00e4hrend man ein Cluster mit 1000 Mikrodiensten verwaltet","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Mein Name ist Viktor Yagofarov, und ich bin als technischer Leiter f\u00fcr die Entwicklung des Kubernetes-Systems bei DomClick im Bereich Operations t\u00e4tig. Ich m\u00f6chte \u00fcber die Struktur unserer Dev Ops-Prozesse, die Besonderheiten des Betriebs eines der gr\u00f6\u00dften K8s-Cluster in Russland sowie \u00fcber die DevOps\/SRE-Praktiken sprechen, die unser Team anwendet.<\/p>\n

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

Operations-Team<\/h4>\n

\nIm Operations-Team arbeiten derzeit 15 Personen. Drei von ihnen sind f\u00fcr das B\u00fcro zust\u00e4ndig, zwei sind in einer anderen Zeitzone t\u00e4tig und stehen auch nachts zur Verf\u00fcgung. Somit ist immer jemand aus dem Ops-Team am Monitor und bereit, auf Vorf\u00e4lle jeder Art zu reagieren. Wir haben keine Nachtdienste, was unsere Psyche sch\u00fctzt und es allen erm\u00f6glicht, auszuschlafen und die Freizeit nicht nur vor dem Computer zu verbringen.<\/p>\n

\"Kubernetes
\n
\nDie Kompetenzen sind vielf\u00e4ltig: Netzwerkadministratoren, Datenbankadministratoren, ELK-Stack-Spezialisten, Kubernetes-Administratoren\/-Entwickler, Monitoring-Experten, Virtualisierungsspezialisten, Hardware-Profis usw. Was uns vereint, ist das: Jeder kann in gewissem Ma\u00dfe jeden von uns ersetzen. Das bedeutet zum Beispiel, neue Knoten in ein k8s-Cluster einf\u00fcgen, PostgreSQL aktualisieren, eine CI\/CD-Pipeline mit Ansible schreiben, etwas mit Python\/Bash\/Go automatisieren oder Hardware im Rechenzentrum anschlie\u00dfen. Starke Kompetenzen in einem bestimmten Bereich hindern nicht daran, die Richtung zu wechseln und in einem anderen Bereich weiterzulernen. Zum Beispiel habe ich mich als PostgreSQL-Spezialist in einem Unternehmen beworben, und jetzt ist mein Hauptverantwortungsbereich die Kubernetes-Cluster-Administration. Im Team wird pers\u00f6nliches Wachstum stets begr\u00fc\u00dft und das Gef\u00fchl der Unterst\u00fctzung ist sehr ausgepr\u00e4gt.<\/p>\n

\u00dcbrigens, wir sind auf der Suche nach neuen Talenten. Die Anforderungen an die Bewerber sind ziemlich Standard. Besonders wichtig ist mir, dass die Person gut ins Team passt, konfliktf\u00e4hig ist, aber auch in der Lage ist, ihre Meinung zu vertreten, den Wunsch hat, sich weiterzuentwickeln und keine Angst hat, Neues zu probieren und eigene Ideen einzubringen. Au\u00dferdem sind Programmierkenntnisse in Skriptsprachen sowie Grundkenntnisse in Linux und Englisch erforderlich. Englisch ist notwendig, damit die Person im Falle eines Fehlers innerhalb von 10 Sekunden eine L\u00f6sung googeln kann, und nicht innerhalb von 10 Minuten. Es ist leider schwierig, Fachkr\u00e4fte mit fundierten Linux-Kenntnissen zu finden: Es ist zwar komisch, aber zwei von drei Kandidaten k\u00f6nnen die Frage nicht beantworten: \u201eWas ist der Load Average? Woraus setzt er sich zusammen?\u201c und sie betrachten die Frage \u201eWie erstellt man einen Core Dump aus einem C-Programm?\u201c als etwas aus der Welt der Supermenschen\u2026 oder Dinosaurier. Damit m\u00fcssen wir uns abfinden, da die Menschen in der Regel stark in anderen Kompetenzen sind, und das \u201eLinux\u201c bringen wir ihnen bei. Warum all das f\u00fcr einen DevOps-Ingenieur in der modernen Cloud-Welt wichtig ist, kann ich hier nicht im Detail erl\u00e4utern, aber wenn ich es in drei Worten sagen m\u00fcsste: Das alles ist notwendig.<\/p>\n

Team Tools<\/h4>\n

\nEin wesentlicher Bestandteil der Automatisierung ist das Team Tools. Ihre Hauptaufgabe besteht darin, benutzerfreundliche grafische und CLI-Tools f\u00fcr Entwickler zu erstellen. Zum Beispiel erm\u00f6glicht unser internes Tool Confer, mit nur wenigen Klicks eine Anwendung in Kubernetes auszurollen, die Ressourcen und Schl\u00fcsseln aus einem Vault zu konfigurieren usw. Zuvor verwendeten wir Jenkins + Helm 2, aber es war notwendig, ein eigenes Tool zu entwickeln, um Copy-Paste zu vermeiden und Einheitlichkeit im Software-Lebenszyklus zu gew\u00e4hrleisten.<\/p>\n

Das Ops-Team schreibt keine Pipelines f\u00fcr die Entwickler, kann jedoch bei Fragen zur Erstellung beraten (einige verwenden immer noch Helm 3).<\/p>\n

DevOps<\/h4>\n

\nWas DevOps betrifft, so verstehen wir es so:<\/p>\n

Die Dev-Teams schreiben Code und stellen ihn \u00fcber Confer in dev -> qa\/stage -> prod bereit. Die Verantwortung daf\u00fcr, dass der Code fl\u00fcssig l\u00e4uft und keine Fehler aufweist, liegt bei den Dev- und Ops-Teams. W\u00e4hrend der Tageszeit sollte in erster Linie der diensthabende Ops-Mitarbeiter auf Vorf\u00e4lle mit seiner Anwendung reagieren. In den Abend- und Nachtstunden muss der Ops-Administrator den diensthabenden Entwickler benachrichtigen, wenn er sicher ist, dass das Problem nicht in der Infrastruktur liegt. Alle Metriken und Alarme im Monitoring erscheinen automatisch oder halbautomatisch.<\/p>\n

Der Verantwortungsbereich von Ops beginnt mit der Bereitstellung der Anwendung in der Produktion, doch die Verantwortung von Dev endet damit nicht \u2014 wir arbeiten zusammen und befinden uns im selben Boot.<\/p>\n

Entwickler beraten die Administratoren, wenn Hilfe beim Schreiben eines Admin-Microservices ben\u00f6tigt wird (zum Beispiel Go-Backend + HTML5), w\u00e4hrend die Administratoren die Entwickler zu allen Infrastrukturfragen oder Fragen im Zusammenhang mit k8s beraten.<\/p>\n

\u00dcbrigens haben wir \u00fcberhaupt kein Monolithen, sondern nur Microservices. Ihre Anzahl schwankt derzeit zwischen 900 und 1000 im Prod-k8s-Cluster, gemessen an der Anzahl. deployments<\/i>. Die Anzahl der Pods variiert zwischen 1700 und 2000. Im Prod-Cluster befinden sich derzeit etwa 2000 Pods.<\/p>\n

Genaue Zahlen kann ich nicht nennen, da wir uns um unn\u00f6tige Mikrodienste k\u00fcmmern und diese in einem halbautomatischen Modus entfernen. Die \u00dcberwachung \u00fcberfl\u00fcssiger Entit\u00e4ten in k8s erfolgt durch useless-operator<\/a><\/noindex>, was Ressourcen und Kosten erheblich spart.<\/p>\n

Ressourcenmanagement <\/h2>\n

<\/p>\n

\u00dcberwachung <\/h4>\n

\nEin gut strukturiertes und informatives Monitoring ist der Schl\u00fcssel zum Betrieb eines gro\u00dfen Clusters. Bisher haben wir keine universelle L\u00f6sung gefunden, die 100 % aller Anforderungen an das Monitoring abdeckt, deshalb entwickeln wir regelm\u00e4\u00dfig verschiedene ma\u00dfgeschneiderte L\u00f6sungen in diesem Bereich.<\/p>\n