Apps mit Services zugänglich machen

In Kubernetes sind Pods die kleinsten bereitstellbaren Einheiten. Sie sind für eine vorübergehende Existenz ausgelegt und können von Kubernetes jederzeit erstellt, zerstört oder verschoben werden.

Diese Flexibilität ist ideal für die Ausfallsicherheit, bringt aber eine Herausforderung mit sich: Wie können andere Anwendungen diese ständig wechselnden Pods zuverlässig finden und mit ihnen kommunizieren?

Jeder Pod erhält eine eigene IP-Adresse. Wenn ein Pod neu gestartet oder skaliert wird, erhält er häufig eine neue IP-Adresse. Eine direkte Verbindung zur IP eines Pods ist wie der Versuch, ein bewegliches Ziel zu treffen!

Stellen Sie sich eine Webanwendung mit mehreren Pods vor. Wenn ein Pod neu gestartet wird, ändert sich seine IP-Adresse, wodurch Verbindungen anderer Dienste oder Benutzer unterbrochen werden.

Hier kommen Kubernetes Services ins Spiel! Ein Service stellt einen stabilen, festen Netzwerk-Endpunkt für eine Gruppe von Pods bereit.

Stellen Sie ihn sich als dauerhafte Adresse für Ihre Anwendung vor, selbst wenn die dahinterliegenden Pods ihre individuellen Adressen ständig ändern.

Ein Service fungiert als Abstraktionsebene über einer Gruppe von Pods. Er stellt eine einheitliche IP-Adresse und einen DNS-Namen bereit.

• Andere Anwendungen verwenden diese stabile Service-IP bzw. diesen Namen.
• Der Service leitet den Datenverkehr anschließend an die von ihm verwalteten gesunden Pods weiter.
• Dadurch werden Clients von den IP-Adressen einzelner Pods entkoppelt.

Woher weiß ein Service, an welche Pods er den Datenverkehr weiterleiten soll? Er verwendet Labels und Selector!

Wenn Sie einen Service definieren, geben Sie einen selector an. Jeder Pod, der diesen Labels entspricht, wird automatisch Teil der Gruppe dieses Services.

Durch diese dynamische Zuordnung werden neue Pods automatisch hinzugefügt und nicht gesunde Pods entfernt.

Services steuern den Fluss des Netzwerkverkehrs. Sie definieren Ports, um eingehende Anfragen den richtigen Ports Ihrer Pods zuzuordnen.

Wichtige Port-Konzepte:

• port: Der Port, an dem der Service selbst auf Anfragen wartet.
• targetPort: Der Port des Pods, an den der Service den Datenverkehr weiterleitet.

Wie die meisten Kubernetes-Ressourcen werden Services mithilfe von YAML-Dateien definiert. Sehen wir uns die grundlegende Struktur an:

• apiVersion: v1
• kind: Service
• metadata: Name, Labels
• spec: Enthält die Kerndefinition einschließlich selector und ports.

Der häufigste Service-Typ für die interne Kommunikation ist ClusterIP. Er stellt den Service über eine interne IP-Adresse innerhalb des Clusters bereit.

Hier ist ein Beispiel für eine einfache Webanwendung:

Sobald Ihr Service-YAML vorliegt, können Sie es mit kubectl in Ihrem Cluster bereitstellen, genau wie bei Pods oder Deployments.

Dieser Befehl weist Kubernetes an, den Service entsprechend Ihrer Definition zu erstellen:

Nach der Bereitstellung erhält Ihr Service innerhalb des Clusters eine stabile IP-Adresse und einen DNS-Namen. Andere Pods können Ihre Anwendung nun über diesen Namen erreichen.

Beispielsweise könnte sich ein anderer Pod mit my-web-service:80 verbinden, und der Service würde die Weiterleitung an die richtigen my-webapp-Pods übernehmen.

Sie haben gelernt, wie Kubernetes Services einen stabilen Netzwerkzugriff auf dynamische Pods ermöglichen.

Welche der folgenden Aussagen beschreibt die Hauptaufgabe eines Kubernetes Service am besten?

Sehr gut! In dieser Lektion haben wir Kubernetes Services untersucht.

• Pods sind kurzlebig und haben dynamische IP-Adressen.
• Services stellen stabile Netzwerk-Endpunkte für Pods bereit.
• Sie verwenden Selectoren, um Ziel-Pods zu finden.
• Services ordnen den externen port dem internen targetPort zu.
• ClusterIP ist ein gängiger Typ für die interne Kommunikation.

Als Nächstes sehen wir uns verschiedene Service-Typen und ihre Einsatzmöglichkeiten genauer an!