Czym jest Ingress i jak kieruje ruch zewnętrzny do Service?

Question

IT Interview Practice · Accepted Answer

**Ingress** to obiekt Kubernetes, który definiuje **reguły routingu HTTP/HTTPS** — mapując nazwy hostów i ścieżki URL na backendowe **Service**. Jest realizowany przez **Ingress Controller** (nginx, Traefik, chmurowe gateway) i daje ci jeden punkt wejścia, terminację TLS oraz routing po hoście/ścieżce zamiast LoadBalancera na każdą usługę.

## Problem, który rozwiązuje Ingress

```text
Wystawianie wielu usług przez type: LoadBalancer oznacza WIELE chmurowych LB (i publicznych IP)
— drogo i bez współdzielonego routingu host/ścieżka ani TLS.
Ingress daje JEDEN punkt wejścia, który kieruje po hoście i ścieżce do wewnętrznych Service ClusterIP.
```

## Jak to się składa

```text
      Internet
         │
   ┌─────┴──────────────┐
   │ Ingress Controller │  (Pod, np. nginx; zwykle za JEDNYM LoadBalancerem)
   │  czyta reguły Ingress│
   └─────┬──────────────┘
         │ kieruje po hoście / ścieżce
   ┌─────┼───────────────┬───────────────┐
   ▼                     ▼               ▼
 Service: web        Service: api    Service: admin  (wszystkie ClusterIP)
   │                     │               │
 Pody                  Pody            Pody

Ingress (reguły)  ≠  Ingress Controller (działające proxy, które je egzekwuje)
```

## Manifest Ingress

```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        # cert/klucz TLS przechowywany w 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" → Pody api
shop.example.com/...     → Service "web" → Pody web
TLS jest terminowany na kontrolerze przy użyciu certu z Secretu "shop-tls".
```

## Kluczowe punkty

```text
• MUSISZ uruchomić Ingress Controller — sam obiekt Ingress nic nie robi.
• ingressClassName wybiera, który kontroler obsługuje reguły.
• Ingress to tylko HTTP/HTTPS (L7). Dla surowego TCP/UDP użyj Service lub Gateway API.
• Nowsze Gateway API to rozwijający się następca z bogatszym, zorientowanym na role routingiem.
```

```bash
kubectl get ingress                  # wypisz reguły, hosty, adresy
kubectl describe ingress app-ingress # zobacz backendy i zdarzenia
```

## Dlaczego to ważne

Ingress to standardowy sposób wystawiania aplikacji HTTP/HTTPS na świat zewnętrzny na Kubernetes, więc jego zrozumienie to niezbędna wiedza o sieci dla inżynierów na poziomie middle. Problem, który rozwiązuje, jest konkretny i powszechny: wystawianie wielu usług przez `type: LoadBalancer` oznacza provisioning osobnego chmurowego load balancera i publicznego IP na każdą usługę — drogo i bez współdzielonego routingu po hoście ani TLS — podczas gdy **Ingress** daje ci jeden punkt wejścia, który kieruje po **hoście i ścieżce** do wewnętrznych Service ClusterIP i terminuje **TLS** centralnie. Rozróżnienie, które podkłada ludziom nogę, jest między **obiektem Ingress** (deklaratywne reguły routingu) a **Ingress Controllerem** (faktyczne działające proxy — nginx, Traefik, chmurowy gateway — które śledzi te reguły i je egzekwuje); reguły nic nie robią bez zainstalowanego kontrolera, a `ingressClassName` wybiera, który kontroler je obsługuje. Zrozumienie, że Ingress działa na **L7 (tylko HTTP/HTTPS)** — więc surowy TCP/UDP potrzebuje Service lub nowszego Gateway API — oraz że **Gateway API** to rozwijający się, bardziej ekspresyjny następca, odzwierciedla aktualną, praktyczną wiedzę. Ponieważ niemal każda aplikacja skierowana do użytkownika na Kubernetes potrzebuje routingu po hoście/ścieżce i TLS z jednego punktu wejścia, a ponieważ rozróżnienie obiekt-vs-kontroler to częste źródło zamieszania zarówno na rozmowach, jak i w praktyce, solidne opanowanie Ingress jest fundamentalne dla wystawiania i obsługi workloadów webowych na klastrze.

Problem, który rozwiązuje Ingress

Jak to się składa

Manifest Ingress

Kluczowe punkty

Dlaczego to ważne

Powiązane pytania