Was ist Ingress und wie routet es externen Traffic zu Services?

Question

IT Interview Practice · Accepted Answer

Ein **Ingress** ist ein Kubernetes-Objekt, das **HTTP/HTTPS-Routing-Regeln** definiert — es mappt Hostnamen und URL-Pfade auf Backend-**Services**. Es wird von einem **Ingress-Controller** (nginx, Traefik, Cloud-Gateways) erfüllt und gibt dir einen Eintrittspunkt, TLS-Terminierung und Host-/Path-Routing statt eines LoadBalancers pro Service.

## Das Problem, das Ingress löst

```text
Viele Services mit type: LoadBalancer freizugeben bedeutet VIELE Cloud-LBs (und öffentliche IPs)
— teuer und ohne gemeinsames Hostname-/Path-Routing oder TLS.
Ingress gibt EINEN Eintrittspunkt, der per Host & Pfad zu internen ClusterIP-Services routet.
```

## Wie es zusammenpasst

```text
      Internet
         │
   ┌─────┴──────────────┐
   │ Ingress Controller │  (a Pod, e.g. nginx; usually behind ONE LoadBalancer)
   │  reads Ingress rules│
   └─────┬──────────────┘
         │ routes by host / path
   ┌─────┼───────────────┬───────────────┐
   ▼                     ▼               ▼
 Service: web        Service: api    Service: admin  (all ClusterIP)
   │                     │               │
 Pods                  Pods            Pods

Ingress (rules)  ≠  Ingress Controller (the running proxy that enforces them)
```

## Ein Ingress-Manifest

```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  tls:
    - hosts: [shop.example.com]
      secretName: shop-tls        # TLS-Cert/Key in einem Secret gespeichert
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api
                port: { number: 80 }
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port: { number: 80 }
```

```text
shop.example.com/api/... → Service "api" → api Pods
shop.example.com/...     → Service "web" → web Pods
TLS wird am Controller mit dem Cert aus dem "shop-tls"-Secret terminiert.
```

## Kernpunkte

```text
• Du MUSST einen Ingress-Controller betreiben — das Ingress-Objekt allein tut nichts.
• ingressClassName wählt aus, welcher Controller die Regeln behandelt.
• Ingress ist nur HTTP/HTTPS (L7). Für rohes TCP/UDP nutze einen Service oder die Gateway API.
• Die neuere Gateway API ist der sich entwickelnde Nachfolger mit reicherem, rollenorientiertem Routing.
```

```bash
kubectl get ingress                  # Regeln, Hosts, Adressen auflisten
kubectl describe ingress app-ingress # Backends & Events ansehen
```

## Warum es wichtig ist

Ingress ist die Standardart, um HTTP/HTTPS-Anwendungen auf Kubernetes nach außen freizugeben, daher ist sein Verständnis essenzielles Networking-Wissen für Ingenieure auf mittlerem Level. Das Problem, das es löst, ist konkret und häufig: Viele Services über `type: LoadBalancer` freizugeben bedeutet, einen separaten Cloud-Load-Balancer und eine öffentliche IP pro Service zu provisionieren — teuer und ohne gemeinsames Hostname-Routing oder TLS —, während ein **Ingress** dir einen einzigen Eintrittspunkt gibt, der per **Host und Pfad** zu internen ClusterIP-Services routet und **TLS** zentral terminiert. Die Unterscheidung, die Leute stolpern lässt, ist die zwischen dem **Ingress-Objekt** (deklarative Routing-Regeln) und dem **Ingress-Controller** (dem tatsächlich laufenden Proxy — nginx, Traefik, ein Cloud-Gateway —, der diese Regeln überwacht und durchsetzt); die Regeln tun nichts ohne installierten Controller, und `ingressClassName` wählt aus, welcher Controller sie behandelt. Zu verstehen, dass Ingress auf **L7 (nur HTTP/HTTPS)** arbeitet — sodass rohes TCP/UDP einen Service oder die neuere Gateway API braucht — und dass die **Gateway API** der sich entwickelnde, ausdrucksstärkere Nachfolger ist, spiegelt aktuelles, praxisnahes Wissen wider. Weil nahezu jede nutzerorientierte Anwendung auf Kubernetes host-/pfadbasiertes Routing und TLS von einem einzigen Eintrittspunkt braucht und weil die Objekt-vs-Controller-Unterscheidung eine häufige Verwirrungsquelle sowohl in Interviews als auch in der Praxis ist, ist ein solides Verständnis von Ingress grundlegend für das Freigeben und Betreiben von Web-Workloads auf einem Cluster.

Das Problem, das Ingress löst

Wie es zusammenpasst

Ein Ingress-Manifest

Kernpunkte

Warum es wichtig ist

Ähnliche Fragen