Wie können wir von außen auf den Kubernetes-Container zugreifen, in dem die Anwendung läuft?

Es gibt mehrere Hauptmethoden, um von einem externen Netzwerk aus auf einen Kubernetes-Container zuzugreifen:

1. Service vom Typ LoadBalancer:

   • Cloud-Anbieter (AWS, GCP, Azure) erstellen einen externen Lastverteiler, der den Datenverkehr an die Pods Ihrer Anwendung weiterleitet.
   • Es wird eine externe IP-Adresse zugewiesen.
   • Der einfachste Weg in einer Cloud-Umgebung.

2. Service vom Typ NodePort:

   • Öffnet einen Port auf jedem Knoten im Cluster.
   • Dieser Port leitet den Datenverkehr an den Service Ihrer Anwendung weiter.
   • Zugriff erfolgt über die IP eines beliebigen Knotens und die NodePort-Nummer.
   • Weniger skalierbar und sicher als LoadBalancer.

3. Service vom Typ ClusterIP zusammen mit Ingress:

   • ClusterIP - Dienst, der nur innerhalb des Clusters zugänglich ist.
   • Ingress - API-Objekt, das den externen Zugriff auf Dienste im Cluster steuert.
   • Der Ingress-Controller (z.B. Nginx Ingress Controller, Traefik) hört auf externen Datenverkehr und leitet ihn an den passenden ClusterIP-Service weiter.
   • Ermöglicht eine zentrale Verwaltung des Routings, der SSL-Beendigung, des Lastenausgleichs.
   • Flexibler und skalierbarer Ansatz.

4. Service vom Typ ExternalName:

   • Erstellt einen Alias für eine externe Domain. Bietet keinen direkten Zugriff auf den Container über diesen Service, ermöglicht aber die Verwendung eines DNS-Namens innerhalb des Clusters, um auf eine externe Ressource zuzugreifen. Nicht geeignet für direkten Zugriff auf den Container von außen.

5. Direkter Zugriff auf NodePort/HostPort auf einem Pod:

   • Es kann hostPort in der Pod-Spezifikation angegeben werden, um einen Port auf dem Knoten zu öffnen, auf dem der Pod läuft. Sehr ungeeignet für Produktionsumgebungen aufgrund schlechter Verwaltung und potenzieller Portkonflikte.
   • Ebenso kann nodePort in einem Service vom Typ NodePort angegeben werden.

Beispielkonfigurationen:

• LoadBalancer Service:

  // service.yaml
  apiVersion: v1
  kind: Service
  metadata:
    name: my-app-service
  spec:
    selector:
      app: my-app
    ports:
      - protocol: TCP
        port: 80
        targetPort: 8080
    type: LoadBalancer
  

• NodePort Service:

  // service-nodeport.yaml
  apiVersion: v1
  kind: Service
  metadata:
    name: my-app-service-np
  spec:
    selector:
      app: my-app
    ports:
      - protocol: TCP
        port: 80
        targetPort: 8080
        nodePort: 30000 # optional, Kubernetes weist zu, wenn nicht angegeben
    type: NodePort
  

• Ingress (für ClusterIP-Service):

  // service-clusterip.yaml (bereits vorhanden)
  apiVersion: v1
  kind: Service
  metadata:
    name: my-app-service-ci
  spec:
    selector:
      app: my-app
    ports:
      - protocol: TCP
        port: 80
        targetPort: 8080
    type: ClusterIP
  

  // ingress.yaml
  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: my-app-ingress
  spec:
    rules:
      - host: myapp.example.com
        http:
          paths:
            - path: /
              pathType: Prefix
              backend:
                service:
                  name: my-app-service-ci
                  port:
                    number: 80
  

Die Wahl der Methode hängt von den Anforderungen an Skalierbarkeit, Sicherheit, Deployment-Umgebung (Cloud oder On-Premise) und der Notwendigkeit einer zentralen Zugriffskontrolle ab. Ingress ist die bevorzugte Lösung für Produktionssysteme.