{"id":81173,"date":"2020-05-11T13:42:51","date_gmt":"2020-05-11T11:42:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/production-ready-images-for-k8s"},"modified":"2020-05-11T13:42:51","modified_gmt":"2020-05-11T11:42:51","slug":"production-ready-images-for-k8s","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/production-ready-images-for-k8s","title":{"rendered":"Produktionsfertige Images f\u00fcr k8s","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Diese Geschichte handelt davon, wie wir Container in der Produktivumgebung nutzen, insbesondere unter Kubernetes. Der Artikel widmet sich der Sammlung von Metriken und Logs aus Containern sowie dem Erstellen von Images.<\/p>\n

\"Produktionsfertige
\n<\/a><\/noindex>
\nWir sind ein Fintech-Unternehmen namens Exness, das Dienstleistungen f\u00fcr den Online-Handel und Fintech-Produkte f\u00fcr B2B und B2C entwickelt. In unserer F&E gibt es viele verschiedene Teams, in der Entwicklungsabteilung arbeiten \u00fcber 100 Mitarbeiter.<\/p>\n

Wir repr\u00e4sentieren ein Team, das f\u00fcr die Plattform zust\u00e4ndig ist, \u00fcber die unsere Entwickler Code bereitstellen und ausf\u00fchren. Insbesondere sind wir verantwortlich f\u00fcr die Sammlung, Speicherung und Bereitstellung von Metriken, Logs und Ereignissen aus Anwendungen. Derzeit betreiben wir etwa dreitausend Docker-Container in der Produktivumgebung, unterst\u00fctzen unser Big Data-Speicher mit 50 TB und bieten architektonische L\u00f6sungen an, die auf unserer Infrastruktur basieren: Kubernetes, Rancher und verschiedene \u00f6ffentliche Cloud-Anbieter.\u00a0<\/p>\n

Unsere Motivation<\/h1>\n

\nWas brennt? Niemand kann das sagen. Wo ist der Brandherd? Schwer zu verstehen. Wann gab es das Feuer? Man kann es herausfinden, aber nicht sofort.\u00a0<\/p>\n

\"Produktionsfertige
\n
\nWarum stehen einige Container still, w\u00e4hrend andere abst\u00fcrzen? Welcher Container war der Grund daf\u00fcr? Denn \u00e4u\u00dferlich sind die Container identisch, doch jeder hat seinen eigenen Neo im Inneren.<\/p>\n

\"Produktionsfertige
\n
\nUnsere Entwickler sind versierte Leute. Sie erstellen gute Dienste, die dem Unternehmen Gewinn bringen. Doch manchmal gibt es Pannen, wenn die Container mit den Anwendungen durcheinander geraten. Ein Container verbraucht zu viel CPU, ein anderer das Netzwerk, ein dritter f\u00fchrt Ein- und Ausgaben aus, und der vierte \u2014 man versteht \u00fcberhaupt nicht, was er mit den Sockets macht. All das f\u00e4llt aus, und das Schiff sinkt.\u00a0<\/p>\n

Agenten<\/h1>\n

\nUm zu verstehen, was drinnen passiert, haben wir beschlossen, Agenten direkt in die Container zu setzen.<\/p>\n

\"Produktionsfertige
\n
\nDiese Agenten sind Schutzprogramme, die sicherstellen, dass die Container in einem Zustand bleiben, in dem sie sich nicht gegenseitig besch\u00e4digen. Die Agenten sind standardisiert, was es erm\u00f6glicht, den Ansatz zur Wartung der Container zu standardisieren.\u00a0<\/p>\n

In unserem Fall m\u00fcssen die Agenten Logs im Standardformat bereitstellen, getaggt und mit Throttling. Au\u00dferdem m\u00fcssen sie uns standardisierte Metriken zur Verf\u00fcgung stellen, die in Bezug auf Gesch\u00e4ftsanwendungen erweiterbar sind.<\/p>\n

Unter Agenten versteht man auch Tools f\u00fcr Betrieb und Wartung, die in verschiedenen Orchestrierungssystemen arbeiten k\u00f6nnen und unterschiedliche Images unterst\u00fctzen (Debian, Alpine, Centos usw.).<\/p>\n

Letztendlich m\u00fcssen die Agenten einen einfachen CI\/CD-Pipeline unterst\u00fctzen, die Docker-Dateien beinhaltet. Andernfalls wird das Schiff auseinanderbrechen, da die Container \u00fcber \"schiefe\" Schienen geliefert werden.<\/p>\n

Der Build-Prozess und die Erstellung des Ziel-Images<\/h1>\n

\nUm alles zu standardisieren und verwaltbar zu machen, ist es notwendig, einen standardisierten Build-Prozess einzuhalten. Daher haben wir uns entschieden, Container mit Containern zu bauen \u2013 eine Art Rekursion.<\/p>\n

\"Produktionsfertige
\n
\nHier werden die Container durch durchgehende Konturen dargestellt. Wir haben auch entschieden, Distributive darin zu platzieren, damit das \u201eLeben nicht wie ein Himbeerbaum erscheint\u201c. Warum dies gemacht wurde, werden wir weiter unten erl\u00e4utern.
\n\u00a0
\nDas Ergebnis ist ein Werkzeug f\u00fcr den Build \u2013 ein Container einer bestimmten Version, der auf bestimmte Versionen von Distributiven und Skripten verweist.<\/p>\n

Wie verwenden wir es? Wir haben ein Docker Hub, das den Container enth\u00e4lt. Wir spiegeln ihn in unser System, um externe Abh\u00e4ngigkeiten loszuwerden. So entstand ein Container, der gelb markiert ist. Wir erstellen eine Vorlage, um alle ben\u00f6tigten Distributive und Skripte in den Container zu installieren. Danach erstellen wir ein betriebsbereites Image: Die Entwickler legen ihren Code und einige spezielle Abh\u00e4ngigkeiten hinein.\u00a0<\/p>\n

Was ist gut an diesem Ansatz?\u00a0<\/p>\n