რა არის Service-ები Kubernetes-ში და რა განსხვავებაა ClusterIP-ს, NodePort-სა და LoadBalancer-ს შორის?

Question

IT Interview Practice · Accepted Answer

**Service** სტაბილურ ქსელურ იდენტობას (ვირტუალურ IP-სა და DNS სახელს) აძლევს label-ებით შერჩეულ *Pod-ების ერთობლიობას*. რადგან Pod-ები წარმავალია და IP-ებს იცვლიან, Service არის ის მდგრადი მისამართი, რომელსაც კლიენტები იყენებენ, და ის **ტვირთს ანაწილებს (load-balances)** უკან მდგარ ჯანსაღ Pod-ებზე.

## რატომ არსებობს Service-ები

```text
Pods come and go (new IP each time). Clients need a STABLE endpoint.
A Service:
  → selects Pods by label  (selector: app=web)
  → gets a fixed virtual IP + DNS name (web.default.svc.cluster.local)
  → load-balances requests across the matching, READY Pods
```

## Service-ის სამი მთავარი ტიპი

```text
ClusterIP    (default)  → reachable ONLY inside the cluster
                          for pod-to-pod / internal service communication
NodePort               → opens a port on EVERY node (30000-32767)
                          external traffic hits nodeIP:nodePort → Service → Pods
LoadBalancer           → provisions an external cloud load balancer
                          gives a public IP that routes to the Service
```

```text
       Internet
          │
   ┌──────┴───────┐
   │ LoadBalancer │  (cloud LB, public IP)   ← for public services
   └──────┬───────┘
          │
   ┌──────┴───────┐
   │  NodePort    │  (node:30080)            ← exposes on each node
   └──────┬───────┘
          │
   ┌──────┴───────┐
   │  ClusterIP   │  (10.96.x.x, internal)   ← the base building block
   └──────┬───────┘
       Pods (app=web)
LoadBalancer builds on NodePort, which builds on ClusterIP.
```

## ClusterIP (შიდა)

```yaml
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: ClusterIP          # ნაგულისხმევი; შეიძლება გამოტოვდეს
  selector:
    app: web               # ემთხვევა Pod-ებს label-ით app=web
  ports:
    - port: 80             # Service-ის პორტი
      targetPort: 8080     # კონტეინერის პორტი
```

სხვა Pod-ები მას DNS-ით სწვდებიან: `http://web` (იმავე namespace-ში) ან `http://web.default.svc.cluster.local`.

## NodePort და LoadBalancer

```yaml
# NodePort — ყოველი node უსმენს nodePort-ზე და ტრაფიკს Service-ს გადასცემს
spec:
  type: NodePort
  selector: { app: web }
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080      # არასავალდებულო; 30000-32767
---
# LoadBalancer — cloud გამოყოფს გარე LB-ს public IP-ით
spec:
  type: LoadBalancer
  selector: { app: web }
  ports:
    - port: 80
      targetPort: 8080
```

```bash
kubectl get svc            # ტიპების, cluster IP-ებისა და external IP-ების ნახვა
kubectl get endpoints web  # Service-ის უკან მდგარი რეალური Pod IP-ები
```

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

Service-ები არის ის, თუ როგორ მუშაობს ქსელი Kubernetes-ში, ამიტომ მათი და ტიპების იერარქიის გაგება არსებითი, ყოველდღიური ცოდნაა. რადგან Pod-ები წარმავალია და ყოველ ხელახალ შექმნაზე ახალ IP-ებს იღებენ, კლიენტებს პირდაპირ Pod-ების IP-ებზე ვერ მიუთითებთ; **Service** ამას აგვარებს, როცა label-ით შერჩეული Pod-ების ერთობლიობის წინ **სტაბილურ ვირტუალურ IP-სა და DNS სახელს** აწვდის და ტრაფიკს **ანაწილებს (load-balancing)** მხოლოდ იმ Pod-ებზე, რომლებიც Ready-ა. სამი ტიპი ფენოვან პროგრესიას ქმნის: **ClusterIP** (ნაგულისხმევი) იძლევა მხოლოდ შიდა მისამართს pod-to-pod და service-to-service კომუნიკაციისთვის და საბაზისო სამშენებლო ბლოკია; **NodePort** ხსნის ფიქსირებულ პორტს ყოველ node-ზე, რომ გარე ტრაფიკმა Service-ს მიაღწიოს; ხოლო **LoadBalancer** კიდევ უფრო შორს მიდის და გამოყოფს გარე ღრუბლოვან load balancer-ს public IP-ით — თითოეული ტიპი ქვემოთ მდგომ ტიპზე შენდება. იმის ცოდნა, თუ რომელს მიმართოთ — ClusterIP შიდა მიკროსერვისების ტრაფიკისთვის, NodePort ძირითადი გარე წვდომისთვის ან on-prem კონფიგურაციებისთვის, LoadBalancer ღრუბელზე public endpoint-ის გამოსატანად (და, პრაქტიკაში, Ingress ClusterIP Service-ების წინ HTTP მარშრუტიზაციისთვის) — ცენტრალურია იმის დასაპროექტებლად, თუ როგორ ესაუბრებიან კომპონენტები ერთმანეთსა და გარე სამყაროს. რადგან თითქმის ყველა რეალურ workload-ს სჭირდება სტაბილური კავშირი და load balancing, Service-ებისა და მათი ტიპების გაგება Kubernetes-ის ქსელური ცოდნის ფუნდამენტია, რომელიც განუწყვეტლივ ჩნდება როგორც დაპროექტებისას, ისე debug-ისას.

რატომ არსებობს Service-ები

Service-ის სამი მთავარი ტიპი

ClusterIP (შიდა)

NodePort და LoadBalancer

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

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