Kubernetes Patterns, 2. Auflage

Kapitel 18. Botschafter

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Das Ambassador-Pattern ist ein spezialisierter Sidecar, der externe Komplexitäten ausblendet und eine einheitliche Schnittstelle für den Zugriff auf Dienste außerhalb des Pods bereitstellt. In diesem Kapitel wirst du sehen, wie das Ambassador-Pattern als Proxy fungieren und den Hauptcontainer vom direkten Zugriff auf externe Abhängigkeiten entkoppeln kann.

Problem

Containerisierte Dienste existieren nicht isoliert und müssen sehr oft auf andere Dienste zugreifen, die unter Umständen nur schwer auf zuverlässige Weise zu erreichen sind. Die Schwierigkeit, auf andere Dienste zuzugreifen, kann auf dynamische und sich ändernde Adressen, die Notwendigkeit des Lastausgleichs von geclusterten Dienstinstanzen, ein unzuverlässiges Protokoll oder schwierige Datenformate zurückzuführen sein. Idealerweise sollten Container für einen einzigen Zweck bestimmt und in verschiedenen Kontexten wiederverwendbar sein. Wenn wir jedoch einen Container haben, der eine bestimmte Geschäftsfunktionalität bereitstellt und einen externen Dienst auf eine spezielle Art und Weise nutzt, hat der Container mehr als eine Aufgabe.

Um den externen Dienst zu nutzen, ist möglicherweise eine spezielle Service Discovery Library erforderlich, die wir nicht in unseren Container einbauen wollen. Oder wir wollen verschiedene Arten von Diensten austauschen, indem wir ...