Hvad er Ingress, og hvordan router det ekstern trafik til Services?

Question

IT Interview Practice · Accepted Answer

En **Ingress** er et Kubernetes-objekt, der definerer **HTTP/HTTPS-routing-regler** — mapping af hostnavne og URL-stier til backend-**Services**. Den opfyldes af en **Ingress Controller** (nginx, Traefik, cloud-gateways) og giver dig ét indgangspunkt, TLS-terminering og host/sti-routing i stedet for en LoadBalancer pr. service.

## Problemet Ingress løser

```text
At eksponere mange services med type: LoadBalancer betyder MANGE cloud-LB'er (og offentlige IP'er)
— dyrt, og ingen fælles host/sti-routing eller TLS.
Ingress giver ÉT indgangspunkt, der router via host & sti til interne ClusterIP-Services.
```

## Hvordan det hænger sammen

```text
      Internet
         │
   ┌─────┴──────────────┐
   │ Ingress Controller │  (en Pod, fx nginx; normalt bag ÉN LoadBalancer)
   │  læser Ingress-regler│
   └─────┬──────────────┘
         │ router via host / sti
   ┌─────┼───────────────┬───────────────┐
   ▼                     ▼               ▼
 Service: web        Service: api    Service: admin  (alle ClusterIP)
   │                     │               │
 Pods                  Pods            Pods

Ingress (regler)  ≠  Ingress Controller (den kørende proxy, der håndhæver dem)
```

## Et 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/nøgle gemt i en Secret
  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 termineres ved controlleren med certifikatet i "shop-tls"-Secret'en.
```

## Nøglepunkter

```text
• Du SKAL køre en Ingress Controller — Ingress-objektet alene gør intet.
• ingressClassName vælger, hvilken controller der håndterer reglerne.
• Ingress er kun HTTP/HTTPS (L7). Til rå TCP/UDP brug en Service eller Gateway API.
• Den nyere Gateway API er den fremvoksende efterfølger med rigere, rolle-orienteret routing.
```

```bash
kubectl get ingress                  # list regler, hosts, adresser
kubectl describe ingress app-ingress # se backends & events
```

## Hvorfor det betyder noget

Ingress er standardmåden at eksponere HTTP/HTTPS-applikationer til omverdenen på Kubernetes, så det er essentiel netværksviden for ingeniører på mellemniveau at forstå det. Problemet, det løser, er konkret og almindeligt: at eksponere mange services via `type: LoadBalancer` betyder at provisionere en separat cloud-load-balancer og offentlig IP pr. service — dyrt og uden fælles host-routing eller TLS — hvorimod en **Ingress** giver dig ét enkelt indgangspunkt, der router via **host og sti** til interne ClusterIP-Services og terminerer **TLS** centralt. Den skelnen, der spænder ben for folk, er mellem **Ingress-objektet** (deklarative routing-regler) og **Ingress Controller'en** (den faktiske kørende proxy — nginx, Traefik, en cloud-gateway — der overvåger disse regler og håndhæver dem); reglerne gør intet uden en installeret controller, og `ingressClassName` vælger, hvilken controller der håndterer dem. At forstå, at Ingress opererer på **L7 (kun HTTP/HTTPS)** — så rå TCP/UDP kræver en Service eller den nyere Gateway API — og at **Gateway API** er den fremvoksende, mere udtryksfulde efterfølger, afspejler aktuel viden fra den virkelige verden. Fordi næsten enhver brugervendt applikation på Kubernetes har brug for host/sti-baseret routing og TLS fra ét indgangspunkt, og fordi objekt-vs-controller-skelnen er en hyppig kilde til forvirring både i interviews og i praksis, er et solidt greb om Ingress fundamentalt for at eksponere og drive web-workloads på en klynge.

Problemet Ingress løser

Hvordan det hænger sammen

Et Ingress-manifest

Nøglepunkter

Hvorfor det betyder noget

Relaterede spørgsmål