Als Ingress Controller wird eine spezielle App auf deinem Kubernetescluster bezeichnet, die alle eingehenden Datenströme entgegennimmt und an deine entsprechenden internen Apps weiterleitet.

Als “Reverse Proxy” fungiert sie quasi als Empfangsbüro für deinen Kubernetes Cluster.

Wie du mit dem Ingress Controller automatisch SSL Zertifikate bei Let’s Encrypt beantragen kannst um HTTPS zu verwenden lernst du hier.

In diesem Beitrag lernst du das Konzept eines Ingress Controllers kennen und wie es dir helfen kann:

  • Struktur in deinen Kubernetescluster zu bringen
  • für mehr Sicherheit zu sorgen
  • das Managen der Zertifikate abzunehmen
  • und sogar Kosten zu reduzieren

Wozu brauchst du einen Ingress Controller

Die simple Variante einen Web-Service in Kubernetes von außen erreichbar zu machen ist es, einen Loadbalancer für die jeweilige App anzulegen. Dieser kriegt dann eine eigene externe statische IP-Adresse und kann somit vom Internet erreicht werden.

Wie das geht habe ich im letzten Beitrag anhand des Hallo-Welt-Beispiels gezeigt.

Sobald du allerdings mehrere Webservices auf deinem Kubernetescluster anbieten möchtest, stehst du vor dem Problem, dass du für jeden Webservice eine eigene IP-Adresse anlegen musst. Eine statische IP-Adresse kostet bei Azure aktuell etwa 3 € im Monat.

Bei diesem Problem schafft ein Ingress Controller Abhilfe, indem alle eingehenden Datenströme zunächst über dieselbe IP geleitet und erst dort auf die Webanwendungen verteilt werden.

Das Verteilen geschieht - je nach Ingress Controller - meist mithilfe von Ports und URL Pfaden.

Dadurch ist es dir sogar möglich wie bei einer Firewall bestimmte Teile deiner Web-Apps, wie zum Beispiel Adminoberflächen, von der Außenwelt komplett unerreichbar zu machen und dadurch ein Stück Sicherheit zu gewährleisten.

Was ist Ingress-NGINX

Die Wahl des Ingress Controllers fällt für die meisten Webseiten auf den NGINX Ingress Controller. Dieser basiert auf dem NGINX Container und wird vom offiziellen Kubernetes Team bereitgestellt.

Dem Cloud Native Computing Foundation Survey Report ist zu entnehmen, dass Ingress-NGINX mit 62 % Anteil der meistgenutzte Ingress Controller im Jahr 2020 war.

Die Aufgabe des NGINX Ingress Controller ist es, die Ingress Regeln der jeweiligen Webapps zu interpretieren und entsprechend auszuführen. Da die Kubernetesentwickler selbst an diesem Projekt sitzen kannst du davon ausgehen, dass es auch zukünftig schnell mit den neusten Updates aus der Kubernetes Welt versorgt wird.

Neben Ingress-NGINX gibt es auch cloudspezifische Ingress Controller.

Cloudanbieter Ingress-Controller
Microsoft Azure AKS Application Gateway Ingress Controller
Amazon Web Services AWS ALB Ingress Controller
Google Cloud Platform GCP GLBC/GCE-Ingress Controller

Diese können von Vorteil sein, wenn du deinen Kubernetes Cluster mit PaaS bzw. SaaS Ressourcen des jeweiligen Anbieters verbinden möchtest.

In der Kubernetes Dokumentation kannst du eine Liste von weiteren Ingress Controllern anschauen.

Für die meisten Webseiten tut es allerdings der normale Ingress-NGINX. Vorallem, wenn du dir die Option freihalten willst irgendwann einmal zwischen Cloudplattformen zu wechseln ist er eine gute Variante.

Wie binde ich Verschlüsselung und SSL Zertifikate an

Über die einfache Weiterleitung hinaus übernimmt der Ingress Controller oft auch Aufgaben wie die SSL Verschlüsselung und das automatische Erneuern eines Zertifikats.

Letzteres macht Ingress-NGINX nicht selbst, sondern mithilfe eines Certificate Manager Controllers den du separat installieren musst.

Die cert-manager App kannst du relativ unkompliziert mithilfe von Helm installieren.

Nachdem du in den Ingress Regeln definiert hast für welche Weiterleitung welcher Certificate Manager Controller verwendet werden soll übernimmt Ingress-NGINX das Verschlüsseln des Traffics von Externen Anfragen für dich.

So kannst du den internen Traffic in deiner Webapp auch unverschlüsselt entwickeln ohne Sicherheitseinbußen hinnehmen zu müssen.

Was sind Ingress Regeln

Die Regeln zur Weiterleitung funktionieren über sogenannte “Ingress” Ressourcen von Kubernetes.

Um direkt mit einem praktischen Beispiel einzusteigen, zeige ich dir die Ingress Regel für meinen eigenen Blog. In meinem Fall nutze ich die URL quisl.de sowie die Subdomäne www.quisl.de:

UPDATE 2022-12-16:

networking.k8s.io/v1beta1 gibt es nicht mehr… Du musst jetzt networking.k8s.io/v1 verwenden. Hier trotzdem beide Beispiele.

Pre 1.19:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: wordpress-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$1
    nginx.ingress.kubernetes.io/use-regex: "true"
    cert-manager.io/cluster-issuer: letsencrypt
spec:
  tls:
  - hosts:
    - quisl.de
    - www.quisl.de
    secretName: tls-secret
  rules:
  - host: quisl.de
    http:
      paths:
      - backend:
          serviceName: wordpress
          servicePort: 80
        path: /(.*)
  - host: www.quisl.de
    http:
      paths:
      - backend:
          serviceName: wordpress
          servicePort: 80
        path: /(.*)

Post 1.19:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wordpress-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$1
    nginx.ingress.kubernetes.io/use-regex: "true"
    cert-manager.io/cluster-issuer: letsencrypt
spec:
  tls:
  - hosts:
    - quisl.de
    - www.quisl.de
    secretName: tls-secret
  rules:
  - host: quisl.de
    http:
      paths:
      - backend:
          name: wordpress
          port: 
            number: 80
        path: /(.*)
        pathType: ImplementationSpecific

  - host: www.quisl.de
    http:
      paths:
      - backend:
          name: wordpress
          port: 
            number: 80
        path: /(.*)
        pathType: ImplementationSpecific

Im metadata Teil werden spezielle Konfigurationen für die Syntax der Pfade, die Klasse des ingresscontrollers (NGINX) oder der Certificate Manager Controller (letsencrypt) gesetzt.

Der Punkt spec ist zweiteilig:

tls - hier stehen die Domänen, für die ein SSL Zertifikat bereitgestellt werden soll, sowie der Name eines Secrets das für den Certification Manager benötigt wird.

rules - hier definiere ich Weiterleitungsregeln anhand des Domainnamens, der URL sowie des Ports. Dazu musste ich einfach den Namen und den Port einer Webapp (hier wordpress:80) nennen.

Abschließende Gedanken

Je mehr Webanwendungen du auf deinem Cluster verwaltest, desto größer wird dein Drang nach Struktur. Der Ingress Controller kann helfen da du hierdurch eine zentrale Stelle hat die alle Apps “kennt”.

Für mich ist das automatische Verwalten der SSL Zertifikate ein großer Pluspunkt da dies ein Thema ist, mit dem ich mich nicht wirklich bei jeder neuen Web-App beschäftigen will.

Auch das Einsparen der Statischen IP-Adressen hat mir unheimlich viele Kosten erspart.

Wie du einen Ingress Controller auf deinem eigenen Azure Kubernetes Service einrichtest kannst du im Tutorial von Microsoft Azure nachlesen.


Konnte ich helfen? Ich freue mich über einen Drink! 💙