Ce este Ingress și cum rutează traficul extern spre Services?

Question

IT Interview Practice · Accepted Answer

Un **Ingress** este un obiect Kubernetes care definește **reguli de rutare HTTP/HTTPS** — mapând hostname-uri și path-uri URL la **Services** de backend. Este îndeplinit de un **Ingress Controller** (nginx, Traefik, gateway-uri de cloud) și îți oferă un singur punct de intrare, TLS termination și rutare pe host/path în loc de câte un LoadBalancer per serviciu.

## Problema pe care o rezolvă Ingress

```text
Expunerea multor servicii cu type: LoadBalancer înseamnă MULTE LB-uri de cloud (și IP-uri publice)
— scump, și fără rutare partajată pe hostname/path sau TLS.
Ingress oferă UN singur punct de intrare care rutează după host & path spre Service-uri ClusterIP interne.
```

## Cum se îmbină

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

## Un manifest de 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/cheie TLS stocate într-un 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" → Pod-uri api
shop.example.com/...     → Service "web" → Pod-uri web
TLS este terminat la controller folosind cert-ul din Secret-ul "shop-tls".
```

## Puncte cheie

```text
• TREBUIE să rulezi un Ingress Controller — obiectul Ingress singur nu face nimic.
• ingressClassName selectează care controller gestionează regulile.
• Ingress este doar HTTP/HTTPS (L7). Pentru TCP/UDP brut folosește un Service sau Gateway API.
• Noul Gateway API este succesorul în evoluție, cu rutare mai bogată, orientată pe roluri.
```

```bash
kubectl get ingress                  # listează regulile, host-urile, adresele
kubectl describe ingress app-ingress # vezi backend-urile & evenimentele
```

## De ce contează

Ingress este modul standard de a expune aplicații HTTP/HTTPS către lumea exterioară pe Kubernetes, așa că înțelegerea lui este cunoaștere esențială de networking pentru inginerii de nivel middle. Problema pe care o rezolvă este concretă și comună: expunerea multor servicii via `type: LoadBalancer` înseamnă provizionarea unui load balancer de cloud separat și a unui IP public per serviciu — scump și fără rutare partajată pe hostname sau TLS — în timp ce un **Ingress** îți oferă un singur punct de intrare care rutează după **host și path** spre Service-uri ClusterIP interne și termină **TLS** centralizat. Distincția care îi încurcă pe oameni este între **obiectul Ingress** (reguli declarative de rutare) și **Ingress Controller** (proxy-ul care rulează efectiv — nginx, Traefik, un gateway de cloud — care urmărește acele reguli și le impune); regulile nu fac nimic fără un controller instalat, iar `ingressClassName` selectează care controller le gestionează. Înțelegerea faptului că Ingress operează la **L7 (doar HTTP/HTTPS)** — deci TCP/UDP brut are nevoie de un Service sau de noul Gateway API — și că **Gateway API** este succesorul în evoluție, mai expresiv, reflectă cunoaștere actuală, din lumea reală. Deoarece aproape orice aplicație orientată spre utilizator pe Kubernetes are nevoie de rutare pe host/path și TLS dintr-un singur punct de intrare, și deoarece distincția obiect-vs-controller este o sursă frecventă de confuzie atât în interviuri, cât și în practică, o stăpânire solidă a Ingress este fundamentală pentru a expune și opera workload-uri web pe un cluster.

Problema pe care o rezolvă Ingress

Cum se îmbină

Un manifest de Ingress

Puncte cheie

De ce contează

Întrebări conexe