Kubernetes Netzwerk Architektur - Teil 2: Service Typen

Im zweiten Teil (Teil 1) des Beitrags werden verschiedene Kubernetes-Service-Typen näher erläutert und anhand von Beispielen veranschaulicht.

Wie wir bereits wissen, werden Anwendungen in Kubernetes innerhalb von Pods bereitgestellt und müssen sowohl untereinander als auch nach außen kommunizieren. Um diese Kommunikation zu ermöglichen und zu vereinfachen, stellt Kubernetes verschiedene Service-Typen zur Verfügung. Die Service-Typen dienen als Abstraktionsschicht, um eine Netzwerkverbindung zwischen den verschiedenen Pods innerhalb des Clusters und Objekten außerhalb des Clusters bereitzustellen.

Weiter geht es um folgende Kubernetes-Komponenten bzw. Service-Typen:

• ClusterIP
• NodePort
• LoadBalancer
• ExternalIPs
• ExternalName

Die ursprüngliche Visio-Datei können Sie unter folgendem Link herunterladen (Kubernetes_Network_Service_Types.vsdx)

ClusterIP

ClusterIP ist eine Art von virtueller IP-Adresse, die einem Kubernetes-Service zugewiesen wird. Diese IP-Adresse ist nur innerhalb des Clusters verfügbar und ermöglicht es anderen Pods und Services, auf den Service zuzugreifen. ClusterIP ist der Standard Servicetyp in Kubernetes.

Beispiel ClusterIP:

apiVersion: v1
kind: Service
metadata:
  name: test-clusterip-service
spec:
  selector:
    app: test-app
  ports:
    - name: http
      port: 80
      targetPort: 8080

NodePort

NodePort ist eine Netzwerkfunktion, die es einem Service ermöglicht, über eine Port-Nummer auf jedem Node im Cluster verfügbar zu sein. Der Port, der für den NodePort verwendet wird, wird automatisch aus einem Bereich zwischen 30000 bis 32767 ausgewählt. Wenn ein Client auf den Service zugreifen möchte, muss er nur die IP-Adresse eines der Nodes im Cluster und den zugewiesenen NodePort verwenden.

Beispiel NodePort:

apiVersion: v1
kind: Service
metadata:
  name: test-nodeport-service
spec:
  selector:
    app: test-app
  type: NodePort
  ports:
    - name: http
      port: 80
      targetPort: 8080
      nodePort: 30000

LoadBalancer

Der Service-Typ LoadBalancer bietet verständlicherweise einem Service die Möglichkeit, über eine externe Load-Balancer-IP-Adresse erreichbar zu sein. Wenn ein Client auf die Load-Balancer-IP-Adresse zugreift, wird der Datenverkehr an den Service im Cluster weitergeleitet.

LoadBalancer wird normalerweise von einem Cloud-Anbieter bereitgestellt. Welche Load-Balancing-Methoden (z.B. Round Robin, Least Connection, Least Bandwidth, Least Response Time usw.) verwendet werden, hängt von der Implementierung des Load Balancers ab. In vielen Fällen wird Round-Robin-Load-Balancing eingesetzt.

Beispiel LoadBalancer:

apiVersion: v1
kind: Service
metadata:
  name: test-loadbalancer-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
spec:
  selector:
    app: test-app
  type: LoadBalancer
  ports:
    - name: http
      port: 80
      targetPort: 8080

ExternalIPs

Wie Sie auf dem oberen Bild erkennen können, weisen die Service-Typen ExternalIPs und NodePort gewisse Ähnlichkeiten auf. ExternalIPs ermöglicht den Zugriff auf einen internen Dienst über eine externe IP-Adresse, die verständlicherweise nicht vom Kubernetes-Cluster selbst verwaltet wird. Bei Verwendung von ExternalIPs wird der Datenverkehr von den angegebenen externen IP-Adressen direkt auf die Pods im Cluster weitergeleitet.

Diese Funktion kann nützlich sein, wenn man einen Service für den Zugriff von außen bereitstellen möchte, ohne dabei einen LoadBalancer zu verwenden. Auch wenn bestimmte IP-Adressen für den Zugriff auf den Service zugelassen werden müssen, kann diese Funktion sinnvoll sein.

Beispiel ExternalName: 

Sie können eine oder mehrere externe IP-Adressen in der Service-Definition angeben, damit der Service über diese Adressen erreichbar ist. Die IP-Adresse 10.10. 20.10 muss außerhalb des Kubernetes-Clusters verwaltet werden.

apiVersion: v1
kind: Service
metadata:
  name: test-externalip-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
    port: 80
    targetPort: 8080
  externalIPs:
   - 10.10.20.10

So sieht es aus, wenn drei IP-Adressen konfiguriert werden:

  externalIPs:
   - 10.10.20.10
   - 10.10.20.11
   - 10.10.20.12

NodePort vs. ExternalIPs 

Obwohl NodePort und ExternalIPs auf den ersten Blick ähnlich erscheinen, gibt es gravierende Unterschiede zwischen den beiden Service-Typen. Beim NodePort werden die Ports auf jedem Knoten im Cluster automatisch von Kubernetes reserviert und verwaltet. Dabei ist keine manuelle Konfiguration erforderlich, aber die Anzahl der verfügbaren Portbereiche für NodePort-Dienste ist beschränkt. Beim ExternalIPs hingegen müssen eine oder mehrere externe IP-Adressen manuell konfiguriert werden. Es gibt aber keine Beschränkungen für die Portbereiche.

ExternalName

Wie man auf dem Bild erkennen kann, leitet der ExternalName den Datenverkehr in eine umgekehrte Richtung, nämlich nach außen. Dies macht den Service-Typ ExternalName zu einer besondere Art von Service in Kubernetes. Der ExternalName kommt zum Einsatz, wenn Anwendungen innerhalb des Clusters auf externe Dienste zugreifen müssen, ohne dass IPs/Ports direkt in den Konfigurationen verwaltet werden müssen.

Bei der Erstellung eines ExternalName werden keine Selektoren (selector) sondern externen DNS-Namen verwendet. Wenn eine Clients (Pod/Container) innerhalb des Clusters diesen Service ansprechen, wird der angegebene DNS-Name anstelle der Service-Adresse zurückgegeben.

Beispiel ExternalName: 

In unteren Beispiel erstellt der ExternalName-Service einen DNS-Eintrag für test-db-service.svc.cluster.local. Wenn irgendein Pod innerhalb des Clusters versucht, den Service unter dieser Adresse aufzurufen, wird die Anfrage an test-db.demo.lab weitergeleitet.

apiVersion: v1
kind: Service
metadata:
  name: test-db-service
spec:
  type: ExternalName
  externalName: test-db.demo.lab
  ports:
    - name: db-port
    port: 3306
    protocol: TCP

• Zurück
• Weiter