Gebäudeoptimierte Container für Kubernetes

Docker erstellt jedes Mal eine neue Bildebene, wenn eine AnweisungRUN,COPY oderADD ausgeführt wird. Wenn Sie das Image erneut erstellen, überprüft die Build-Engine jede Anweisung, um festzustellen, ob für den Vorgang eine Image-Ebene zwischengespeichert wurde. Wenn im Cache eine Übereinstimmung gefunden wird, wird die vorhandene Bildebene verwendet, anstatt die Anweisung erneut auszuführen und die Ebene neu zu erstellen.

Dieser Prozess kann die Erstellungszeiten erheblich verkürzen, es ist jedoch wichtig, den Mechanismus zu verstehen, der zur Vermeidung potenzieller Probleme verwendet wird. Bei Anweisungen zum Kopieren von Dateien wieCOPY undADD vergleicht Docker die Prüfsummen der Dateien, um festzustellen, ob der Vorgang erneut ausgeführt werden muss. Für die Anweisungen vonRUNprüft Docker, ob eine vorhandene Bildebene für diese bestimmte Befehlszeichenfolge zwischengespeichert ist.

Obwohl dies möglicherweise nicht sofort offensichtlich ist, kann dieses Verhalten zu unerwarteten Ergebnissen führen, wenn Sie nicht vorsichtig sind. Ein häufiges Beispiel hierfür ist das Aktualisieren des lokalen Paketindex und das Installieren von Paketen in zwei separaten Schritten. Wir werden Ubuntu für dieses Beispiel verwenden, aber die Grundvoraussetzung gilt auch für Basis-Images für andere Distributionen:

Beispiel für die Paketinstallation Dockerfile

Hier wird der lokale Paketindex in einer Anweisung vonRUN(apt -y update) aktualisiert und Nginx in einer anderen Operation installiert. Dies funktioniert problemlos, wenn es zum ersten Mal verwendet wird. Wenn die Docker-Datei jedoch später aktualisiert wird, um ein zusätzliches Paket zu installieren, kann es zu Problemen kommen:

Beispiel für die Paketinstallation Dockerfile

Wir haben dem Installationsbefehl, der mit der zweiten Anweisung ausgeführt wird, ein zweites Paket hinzugefügt. Wenn seit dem vorherigen Image-Build eine erhebliche Zeit vergangen ist, schlägt der neue Build möglicherweise fehl. Dies liegt daran, dass in der Anweisung zur Aktualisierung des Paketindex (RUN apt -y update)not geändert wurde, sodass Docker die dieser Anweisung zugeordnete Bildebene wiederverwendet. Da wir einen alten Paketindex verwenden, befindet sich die Version desphp-fpm-Pakets, die wir in unseren lokalen Datensätzen haben, möglicherweise nicht mehr in den Repositorys, was zu einem Fehler führt, wenn der zweite Befehl ausgeführt wird.

Um dieses Szenario zu vermeiden, müssen Sie alle Schritte, die voneinander abhängig sind, in einer einzelnenRUN-Anweisung zusammenfassen, damit Docker bei einer Änderung alle erforderlichen Befehle erneut ausführt:

Beispiel für die Paketinstallation Dockerfile

Die Anweisung aktualisiert jetzt den lokalen Paketcache, sobald sich die Paketliste ändert.

Das vorige Beispiel zeigt, wie das Caching-Verhalten von Docker die Erwartungen untergraben kann. Es gibt jedoch noch einige andere Dinge zu beachten, wie die Anweisungen vonRUNmit dem Layer-System von Docker interagieren. Wie bereits erwähnt, schreibt Docker am Ende jeder Anweisung vonRUNdie Änderungen als zusätzliche Bildebene fest. Um die Kontrolle über den Umfang der erzeugten Bildebenen auszuüben, können Sie unnötige Dateien in der endgültigen Umgebung bereinigen, indem Sie die Artefakte berücksichtigen, die durch die von Ihnen ausgeführten Befehle eingeführt werden.

Im Allgemeinen bietet das Verketten von Befehlen zu einem einzelnenRUN-Befehl eine große Kontrolle über die zu schreibende Ebene. Für jeden Befehl können Sie den Status der Ebene (apt -y update) einrichten, den Kernbefehl (apt install -y nginx php-fpm) ausführen und unnötige Artefakte entfernen, um die Umgebung zu bereinigen, bevor sie festgeschrieben wird. Beispielsweise verketten viele Docker-Dateienrm -rf /var/lib/apt/lists/* bis zum Ende vonapt Befehlen und entfernen die heruntergeladenen Paketindizes, um die endgültige Layergröße zu verringern:

Beispiel für die Paketinstallation Dockerfile

Um die Größe der von Ihnen erstellten Bildebenen weiter zu verringern, kann es hilfreich sein, andere unbeabsichtigte Nebenwirkungen der von Ihnen ausgeführten Befehle zu begrenzen. Beispielsweise installiertapt zusätzlich zu den explizit deklarierten Paketen standardmäßig auch "empfohlene" Pakete. Sie können--no-install-recommends in Ihreapt-Befehle aufnehmen, um dieses Verhalten zu entfernen. Sie müssen möglicherweise experimentieren, um herauszufinden, ob Sie sich auf eine der in den empfohlenen Paketen enthaltenen Funktionen verlassen können.

Wir haben in diesem Abschnitt als Beispiel Paketverwaltungsbefehle verwendet, aber diese Prinzipien gelten auch für andere Szenarien. Die allgemeine Idee besteht darin, die erforderlichen Bedingungen zu erstellen, den Befehl "Minimum Viable" auszuführen und dann alle unnötigen Artefakte in einem einzigenRUN-Befehl zu bereinigen, um den Overhead der zu produzierenden Ebene zu verringern.

Multi-stage builds wurden in Docker 17.05 eingeführt, sodass Entwickler die endgültigen Laufzeitbilder, die sie erstellen, genauer steuern können. Mit mehrstufigen Builds können Sie Ihre Docker-Datei in mehrere Abschnitte unterteilen, die unterschiedliche Stufen darstellen, wobei jeder eineFROM-Anweisung enthält, um separate übergeordnete Bilder anzugeben.

In früheren Abschnitten wurden Bilder definiert, mit denen Sie Ihre Anwendung erstellen und Assets vorbereiten können. Diese enthalten häufig Build-Tools und Entwicklungsdateien, die zum Erstellen der Anwendung benötigt werden, zum Ausführen jedoch nicht erforderlich sind. Jede in der Datei definierte nachfolgende Stufe hat Zugriff auf Artefakte, die von vorherigen Stufen erzeugt wurden.

Die letzte AnweisungFROMdefiniert das Image, das zum Ausführen der Anwendung verwendet wird. In der Regel handelt es sich hierbei um ein reduziertes Image, das nur die erforderlichen Laufzeitanforderungen installiert und dann die Anwendungsartefakte kopiert, die in früheren Phasen erstellt wurden.

Mit diesem System müssen Sie sich weniger Gedanken über die Optimierung der Anweisungen vonRUNin den Erstellungsphasen machen, da diese Containerebenen im endgültigen Laufzeitabbild nicht vorhanden sind. Sie sollten weiterhin darauf achten, wie Anweisungen mit dem Ebenen-Caching in den Erstellungsphasen interagieren, aber Ihre Bemühungen können eher auf die Minimierung der Erstellungszeit als auf die endgültige Bildgröße gerichtet sein. Die Beachtung der Anweisungen in der letzten Phase ist immer noch wichtig für die Reduzierung der Bildgröße. Durch die Trennung der verschiedenen Phasen Ihres Containerbaus ist es jedoch einfacher, optimierte Bilder zu erhalten, ohne die Komplexität von Dockerfiles zu beeinträchtigen.

Im Allgemeinen empfiehlt es sich, jedes Stück unabhängiger Funktionalität in ein separates Container-Image zu packen.

Dies unterscheidet sich von gängigen Strategien in Umgebungen mit virtuellen Maschinen, in denen Anwendungen häufig in einem Image zusammengefasst werden, um die Größe zu verringern und die zum Ausführen der VM erforderlichen Ressourcen zu minimieren. Da Container einfache Abstraktionen sind, die nicht den gesamten Betriebssystemstapel virtualisieren, ist dieser Kompromiss für Kubernetes weniger überzeugend. Während eine virtuelle Webstack-Maschine einen Nginx-Webserver mit einem Gunicorn-Anwendungsserver auf einer einzelnen Maschine bündelt, um eine Django-Anwendung zu bedienen, können diese in Kubernetes in separate Container aufgeteilt werden.

Das Entwerfen von Containern, die eine einzelne Funktionalität für Ihre Dienste implementieren, bietet eine Reihe von Vorteilen. Jeder Container kann unabhängig entwickelt werden, wenn Standardschnittstellen zwischen Diensten eingerichtet sind. Beispielsweise könnte der Nginx-Container möglicherweise als Proxy für eine Reihe verschiedener Backends verwendet werden oder als Load Balancer, wenn eine andere Konfiguration angegeben wird.

Nach der Bereitstellung kann jedes Container-Image unabhängig skaliert werden, um unterschiedliche Ressourcen- und Lasteinschränkungen zu berücksichtigen. Durch die Aufteilung Ihrer Anwendungen in mehrere Container-Images gewinnen Sie Flexibilität bei der Entwicklung, Organisation und Bereitstellung.

In Kubernetes sindpods die kleinste Einheit, die direkt von der Steuerebene verwaltet werden kann. Pods bestehen aus einem oder mehreren Containern sowie zusätzlichen Konfigurationsdaten, um der Plattform mitzuteilen, wie diese Komponenten ausgeführt werden sollen. Die Container in einem Pod werden immer auf demselben Arbeitsknoten im Cluster geplant, und das System startet fehlgeschlagene Container automatisch neu. Die Pod-Abstraktion ist sehr nützlich, führt jedoch eine weitere Entscheidungsebene ein, wie die Komponenten Ihrer Anwendungen gebündelt werden sollen.

Wie Containerbilder werden auch Pods weniger flexibel, wenn zu viele Funktionen in einer Einheit zusammengefasst werden. Pods selbst können mithilfe anderer Abstraktionen skaliert werden, die Container können jedoch nicht unabhängig voneinander verwaltet oder skaliert werden. Um das vorige Beispiel weiter zu verwenden, sollten die separaten Nginx- und Gunicorn-Container wahrscheinlich nicht zu einem einzigen Pod gebündelt werden, damit sie separat gesteuert und bereitgestellt werden können.

Es gibt jedoch Szenarien, in denen es sinnvoll ist, funktional unterschiedliche Container zu einer Einheit zusammenzufassen. Im Allgemeinen können diese als Situationen kategorisiert werden, in denen ein zusätzlicher Container die Kernfunktionalität des Hauptcontainers unterstützt oder verbessert oder dessen Anpassung an die Bereitstellungsumgebung erleichtert. Einige gängige Muster sind:

Wie Sie vielleicht bemerkt haben, unterstützt jedes dieser Muster die Strategie, standardmäßige, generische primäre Container-Images zu erstellen, die dann in verschiedenen Kontexten und Konfigurationen bereitgestellt werden können. Die sekundären Container helfen dabei, die Lücke zwischen dem primären Container und der verwendeten spezifischen Bereitstellungsumgebung zu schließen. Einige Beiwagencontainer können auch wiederverwendet werden, um mehrere Primärcontainer an die gleichen Umgebungsbedingungen anzupassen. Diese Muster profitieren von dem durch die Pod-Abstraktion bereitgestellten gemeinsamen Dateisystem- und Netzwerk-Namespace und ermöglichen dennoch die unabhängige Entwicklung und flexible Bereitstellung standardisierter Container.

Probleme treten häufig auf, wenn Entwickler signifikante Dienstverwaltungsfunktionen in Containern implementieren. Beispielsweise kann das Ausführen von systemd-Diensten im Container oder das Dämonisieren von Webservern als bewährte Methode in einer normalen Computerumgebung angesehen werden, sie widersprechen jedoch häufig den Annahmen, die dem Containermodell inhärent sind.

Hosts verwalten Container-Lebenszyklusereignisse, indem sie Signale an den Prozess senden, der als PID (Prozess-ID) 1 im Container fungiert. PID 1 ist der erste Prozess, der gestartet wird. Dies wäre das Init-System in herkömmlichen Computerumgebungen. Da der Host jedoch nur PID 1 verwalten kann, kann es vorkommen, dass ein herkömmliches Init-System zum Verwalten von Prozessen im Container nicht zur Steuerung der primären Anwendung verwendet werden kann. Der Host kann das interne Init-System starten, stoppen oder beenden, die primäre Anwendung jedoch nicht direkt verwalten. Die Signale geben manchmal das beabsichtigte Verhalten an die laufende Anwendung weiter. Dies erhöht jedoch die Komplexität und ist nicht immer erforderlich.

In den meisten Fällen ist es besser, die Ausführungsumgebung im Container zu vereinfachen, sodass PID 1 die primäre Anwendung im Vordergrund ausführt. In Fällen, in denen mehrere Prozesse ausgeführt werden müssen, ist PID 1 für die Verwaltung des Lebenszyklus nachfolgender Prozesse verantwortlich. Bestimmte Anwendungen, wie Apache, erledigen dies von Haus aus, indem sie Worker, die Verbindungen verwalten, erzeugen und verwalten. Für andere Anwendungen kann in einigen Fällen ein Wrapper-Skript oder ein sehr einfaches Init-System wiedumb-init oder das enthaltenetini-Init-System verwendet werden. Unabhängig von der von Ihnen gewählten Implementierung sollte der als PID 1 im Container ausgeführte Prozess angemessen auf die von Kubernetes gesendetenTERM-Signale reagieren, um sich wie erwartet zu verhalten.

Die Bereitstellungen und Dienste von Kubernetes bieten ein Lebenszyklusmanagement für lang laufende Prozesse und einen zuverlässigen, dauerhaften Zugriff auf Anwendungen, selbst wenn zugrunde liegende Container neu gestartet werden müssen oder die Implementierungen sich ändern. Indem Sie die Verantwortung für die Überwachung und Aufrechterhaltung des Servicestatus außerhalb des Containers übernehmen, können Sie die Tools der Plattform für die Verwaltung fehlerfreier Workloads nutzen.

Damit Kubernetes Container ordnungsgemäß verwalten kann, muss es wissen, ob die in Containern ausgeführten Anwendungen fehlerfrei sind und Arbeit leisten können. Um dies zu ermöglichen, können Container Aktivitätsprüfungen implementieren: Netzwerkendpunkte oder Befehle, mit denen der Anwendungszustand gemeldet werden kann. Kubernetes überprüft regelmäßig die definierten Verfügbarkeitsprüfungen, um festzustellen, ob der Container wie erwartet funktioniert. Wenn der Container nicht ordnungsgemäß reagiert, startet Kubernetes den Container neu, um die Funktionalität wiederherzustellen.

Kubernetes bietet auch Bereitschaftssonden an, ein ähnliches Konstrukt. Anstatt anzuzeigen, ob die Anwendung in einem Container fehlerfrei ist, bestimmen Bereitschaftsprüfungen, ob die Anwendung für den Empfang von Datenverkehr bereit ist. Dies kann hilfreich sein, wenn eine containerisierte Anwendung über eine Initialisierungsroutine verfügt, die abgeschlossen werden muss, bevor Verbindungen empfangen werden können. Kubernetes verwendet Bereitschaftsprüfungen, um zu bestimmen, ob ein Pod zu einem Service hinzugefügt oder aus diesem entfernt werden soll.

Das Definieren von Endpunkten für diese beiden Sondentypen kann Kubernetes dabei helfen, Ihre Container effizient zu verwalten, und kann verhindern, dass Probleme mit dem Containerlebenszyklus die Serviceverfügbarkeit beeinträchtigen. Die Mechanismen zur Beantwortung dieser Art von Integritätsanforderungen müssen in die Anwendung selbst integriert und in der Docker-Image-Konfiguration verfügbar gemacht werden.