რა არის Ingress და როგორ მარშრუტიზებს ის გარე ტრაფიკს Service-ებამდე?

Question

IT Interview Practice · Accepted Answer

**Ingress** არის Kubernetes-ის ობიექტი, რომელიც განსაზღვრავს **HTTP/HTTPS მარშრუტიზაციის წესებს** — ჰოსტსახელებისა და URL გზების backend **Service-ებზე** მიბმას. მას ასრულებს **Ingress Controller** (nginx, Traefik, ღრუბლოვანი gateway-ები) და გაძლევთ ერთ შესასვლელ წერტილს, TLS termination-სა და host/path მარშრუტიზაციას, ნაცვლად თითო სერვისზე თითო LoadBalancer-ისა.

## პრობლემა, რომელსაც Ingress აგვარებს

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

## როგორ ეწყობა ერთმანეთთან

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

## 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 შენახული 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.
```

## ძირითადი პუნქტები

```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                  # წესების, ჰოსტების, მისამართების სია
kubectl describe ingress app-ingress # backend-ებისა და მოვლენების ნახვა
```

## რატომ არის ეს მნიშვნელოვანი

Ingress არის სტანდარტული გზა HTTP/HTTPS აპლიკაციების Kubernetes-ზე გარე სამყაროსთვის გამოსატანად, ამიტომ მისი გაგება არსებითი ქსელური ცოდნაა middle-დონის ინჟინრებისთვის. პრობლემა, რომელსაც ის აგვარებს, კონკრეტული და გავრცელებულია: ბევრი სერვისის `type: LoadBalancer`-ით გამოტანა ნიშნავს თითო სერვისზე ცალკე ღრუბლოვანი load balancer-ისა და public IP-ის გამოყოფას — ძვირი და გაზიარებული ჰოსტსახელით მარშრუტიზაციისა და TLS-ის გარეშე — ხოლო **Ingress** გაძლევთ ერთ შესასვლელ წერტილს, რომელიც **host-ითა და path-ით** მარშრუტიზებს შიდა ClusterIP Service-ებზე და **TLS**-ს ცენტრალურად ამთავრებს (terminate). განსხვავება, რომელზეც ხალხი ცდება, არის **Ingress ობიექტსა** (დეკლარაციული მარშრუტიზაციის წესები) და **Ingress Controller-ს** (რეალური მომუშავე proxy — nginx, Traefik, ღრუბლოვანი gateway — რომელიც ამ წესებს ადევნებს თვალს და აღასრულებს) შორის; წესები არაფერს აკეთებენ ინსტალირებული კონტროლერის გარეშე, ხოლო `ingressClassName` განსაზღვრავს, რომელი კონტროლერი ამუშავებს მათ. იმის გაგება, რომ Ingress მუშაობს **L7-ზე (მხოლოდ HTTP/HTTPS)** — ასე რომ raw TCP/UDP-ს სჭირდება Service ან ახალი Gateway API — და რომ **Gateway API** არის განვითარებადი, უფრო გამომსახველი მემკვიდრე, ასახავს მიმდინარე, რეალურ ცოდნას. რადგან Kubernetes-ზე თითქმის ყველა მომხმარებელზე ორიენტირებულ აპლიკაციას სჭირდება host/path-ზე დაფუძნებული მარშრუტიზაცია და TLS ერთი შესასვლელი წერტილიდან, და რადგან ობიექტ-vs-კონტროლერის განსხვავება ხშირად აბნევს როგორც ინტერვიუებში, ისე პრაქტიკაში, Ingress-ის მყარი ცოდნა ფუნდამენტურია კლასტერზე ვებ workload-ების გამოსატანად და გასამართად.

პრობლემა, რომელსაც Ingress აგვარებს

როგორ ეწყობა ერთმანეთთან

Ingress-ის manifest

ძირითადი პუნქტები

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები