Vad är Ingress och hur dirigerar det extern trafik till Services?

Question

IT Interview Practice · Accepted Answer

En **Ingress** är ett Kubernetes-objekt som definierar **routing-regler för HTTP/HTTPS** — som mappar hostnamn och URL-sökvägar till backend-**Services**. Den uppfylls av en **Ingress Controller** (nginx, Traefik, molngateways) och ger dig en enda ingångspunkt, TLS-terminering och host/sökvägs-routing istället för en LoadBalancer per tjänst.

## Problemet Ingress löser

```text
Exposing many services with type: LoadBalancer means MANY cloud LBs (and public IPs)
— expensive, and no shared hostname/path routing or TLS.
Ingress gives ONE entry point that routes by host & path to internal ClusterIP Services.
```

## Hur det hänger ihop

```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)
```

## Ett 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/nyckel lagrad 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 is terminated at the controller using the cert in the "shop-tls" Secret.
```

## Viktiga punkter

```text
• You MUST run an Ingress Controller — the Ingress object alone does nothing.
• ingressClassName selects which controller handles the rules.
• Ingress is HTTP/HTTPS (L7) only. For raw TCP/UDP use a Service or Gateway API.
• The newer Gateway API is the evolving successor with richer, role-oriented routing.
```

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

## Varför det är viktigt

Ingress är standardsättet att exponera HTTP/HTTPS-applikationer mot omvärlden på Kubernetes, så att förstå det är väsentlig nätverkskunskap för ingenjörer på middle-nivå. Problemet det löser är konkret och vanligt: att exponera många tjänster via `type: LoadBalancer` innebär att tillhandahålla en separat molnbaserad load balancer och publik IP per tjänst — dyrt och utan delad hostnamns-routing eller TLS — medan en **Ingress** ger dig en enda ingångspunkt som dirigerar efter **host och sökväg** till interna ClusterIP-Services och terminerar **TLS** centralt. Distinktionen som ställer till det för folk är den mellan **Ingress-objektet** (deklarativa routing-regler) och **Ingress Controllern** (den faktiskt körande proxyn — nginx, Traefik, en molngateway — som bevakar dessa regler och upprätthåller dem); reglerna gör ingenting utan en installerad controller, och `ingressClassName` väljer vilken controller som hanterar dem. Att förstå att Ingress opererar på **L7 (endast HTTP/HTTPS)** — så att rå TCP/UDP behöver en Service eller det nyare Gateway API:et — och att **Gateway API** är den framväxande, mer uttrycksfulla efterföljaren, speglar aktuell kunskap från verkligheten. Eftersom nästan varje användarvänd applikation på Kubernetes behöver host/sökvägs-baserad routing och TLS från en enda ingångspunkt, och eftersom distinktionen objekt-kontra-controller är en frekvent källa till förvirring i både intervjuer och praktik, är en gedigen förståelse av Ingress grundläggande för att exponera och driva web-workloads på ett kluster.

Problemet Ingress löser

Hur det hänger ihop

Ett Ingress-manifest

Viktiga punkter

Varför det är viktigt

Relaterade frågor