Kubernetes Ingress: HTTP-Verkehr in den Cluster leiten

Kurz: Eine Regel-Sammlung, die festlegt, welche Webadressen von außen zu welchen Diensten im Kubernetes-Cluster führen.

Genauer: Pods in Kubernetes sind von außen nicht direkt erreichbar. Ein Service macht sie im Cluster auffindbar. Damit eine Webanfrage aus dem Internet ankommt, braucht es zusätzlich einen Ingress: Er beschreibt Regeln wie „shop.example.com geht an den Dienst shop“. Die Regeln setzt ein Ingress-Controller (zum Beispiel nginx oder Traefik) um.

Im Detail

Beispiel

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
spec:
  tls:
    - hosts: [shop.example.com]
      secretName: shop-tls
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service: { name: shop, port: { number: 80 } }

Hier wird der Host shop.example.com mit TLS-Zertifikat an den Dienst shop geleitet.

Aufgaben des Controllers

Der Controller läuft als Pod im Cluster und liest die Ingress-Ressourcen. Er arbeitet als Reverse Proxy: nimmt Verbindungen an, beendet TLS, wählt anhand von Host und Pfad den Dienst und verteilt auf dessen Pods. Zusätzliche Funktionen wie Weiterleitung HTTP zu HTTPS, Zeitlimits oder Rate Limits steuert man über Annotationen.

Zertifikate automatisch

Mit cert-manager lassen sich Zertifikate (zum Beispiel von Let’s Encrypt) automatisch anfordern und erneuern. Der Ingress verweist dann nur noch auf den Namen des Secrets.

Gateway API

Als Nachfolger gilt die Gateway API. Sie trennt Rollen genauer (Infrastruktur-Betreiber stellt ein Gateway bereit, Anwendungsteams legen Routen an) und unterstützt mehr als HTTP. Der klassische Ingress ist aber weiterhin weit verbreitet.

Siehe auch: Kubernetes-Grundlagen, nginx und Reverse Proxy, Let’s Encrypt und TLS-Zertifikate, Load Balancer