Service Mesh და ტრაფიკის პოლიტიკა

1) რატომ გვჭირდება სერვისი Mesh

• ნაგულისხმევი უსაფრთხოება: mTLS, სერთიფიკატების ავტომატური გაცემა/როტაცია, მომსახურების იდენტურობა.
• ტრაფიკის პოლიტიკა: L7 მარშრუტიზაცია, კანარის/AB ტესტები, დეგრადაცია და სტაბილურობა.
• დაკვირვება: მეტრიკა, ლოგოები, ტრეკები, ოქროს სიგნალები თითოეულ ზარზე.
• ოპერაციები: ერთიანი პოლიტიკოსები ყველა ენაზე/ჩარჩოებში.

განსხვავება API კარიბჭისგან: კარიბჭე - ჩრდილოეთ სამხრეთის პერიმეტრი; mesh - east west კლასტერის/ორგანიზაციის შიგნით. ხშირად ერთად მუშაობენ.

2) არქიტექტურა: თვითმფრინავები და ნიმუშები

Data Plane: sidecar მარიონეტული (Envoy/Linkerd-proxy/haproxy), რომელიც აკონტროლებს poda/VM ტრაფიკს.
Control Plane: ანაწილებს კონფიგურაციას (მარშრუტები, პოლიტიკოსები, სერთიფიკატები), ინახავს მდგომარეობას, აქვეყნებს მომსახურების დისკებს.
პირადობა: ჩვეულებრივ, SPIFFE ID და ავტომატური X.509 სერთიფიკატები (SPIRE/ჩაშენებული CA).
შესასვლელი/გასასვლელი წერტილები: ingress/egress-gateway სასაზღვრო ნაკადების გასაკონტროლებლად.
განხორციელების რეჟიმები: თითოეული სახის sidecar; პრე-კვანძი/ambient მოდის ახალ განხორციელებაში.

3) უსაფრთხოების პოლიტიკა და zero-trust

1. mTLS by default: სამსახურის დაშიფვრა და ურთიერთდახმარების ავთენტიფიკაცია.

• AuthN: ჩვენ ვენდობით მხოლოდ CA mesh (SPIFFE) მიერ გაცემულ იდენტურობას.
• AuthZ: დეკლარაციული წესები „ვის შეუძლია ვისთან და როგორ“ (RBAC/ABAC).

3. იზოლაცია და ეგრეთ წოდებული კონტროლი:

• ნებადართული დომენები/ქვესახეები; იძულებითი გამოსავალი egress-gateway- ით.
• პირდაპირი შედეგების ბლოკირება.

4. საიდუმლოებების როტაცია: მოკლევადიანი სერთიფიკატები, მარიონეტული ავტომატური რეკონსტრუქცია.

yaml apiVersion: security. istio. io/v1beta1 kind: PeerAuthentication metadata: { name: default, namespace: istio-system }
spec:
mtls: { mode: STRICT }

yaml apiVersion: security. istio. io/v1beta1 kind: AuthorizationPolicy metadata: { name: billing-allow, namespace: prod }
spec:
selector: { matchLabels: { app: billing } }
rules:
- from:
- source: { principals: ["spiffe://corp. local/ns/prod/sa/inventory"] }
to:
- operation: { ports: ["8080"], methods: ["POST"], paths: ["/proto. Billing/"] }

4) ტრაფიკის პოლიტიკა: სტაბილურობა და მარშრუტიზაცია

4. 1 ტაიმაუტები და რეტრაები

Timeouts: დარწმუნდით, რომ დარეკეთ (connect/read/overall).
Retries: მხოლოდ idempotent ოპერაციებისთვის; backoff + jitter; per-try timeout ლიმიტები.

yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService metadata: { name: orders }
spec:
hosts: ["orders"]
http:
- route:
- destination: { host: orders, subset: v1, port: { number: 8080 } }
timeout: 5s retries:
attempts: 2 perTryTimeout: 2s retryOn: "5xx,connect-failure,reset"

4. 2 Circuit Breaker и outlier detection

CB: ზღუდავს ერთდროულ მოთხოვნებს/კავშირებს, იცავს აფსიდებს.
Outlier: გადაყრის „ცუდ“ ინსტანციებს შეცდომების/ლატენტობის გამო.

yaml apiVersion: networking. istio. io/v1beta1 kind: DestinationRule metadata: { name: orders }
spec:
host: orders trafficPolicy:
connectionPool:
http: { http1MaxPendingRequests: 1024, maxRequestsPerConnection: 100 }
outlierDetection:
consecutive5xxErrors: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

4. 3 კანარი და პირობები

Wighted: ტრეფიკის გამიჯვნა წონა v1/v2.
Header-based: დროშები/ქუქი-ფაილები/tenant - გადატანა ახალ ვერსიაში.
Session affinity: hash გასაღები (ფრთხილად მასშტაბებით).

yaml http:
- match: [{ headers: { "x-experiment": { exact: "new" } } }]
route: [{ destination: { host: orders, subset: v2 } }]
- route:
- destination: { host: orders, subset: v1, weight: 90 }
- destination: { host: orders, subset: v2, weight: 10 }

4. 4 Fault Injection და დეგრადაცია

შეფერხებების/შეცდომების ინექცია სტაბილურობის ტესტირებისთვის და SLO.

yaml fault:
delay: { fixedDelay: 300ms, percentage: { value: 10 } }
abort: { httpStatus: 503, percentage: { value: 1 } }

5) ქსელის საზღვრები: ingress/egress და გარე სერვისები

Ingress-gateway: ერთადერთი შესასვლელი წერტილი გარე მომხმარებლებისთვის mesh; ინტეგრაცია WAF/OIDC/ratelimits- ით.
Egress-gateway: ცენტრალური გასასვლელი ნებადართული მასპინძელთა სიით, TLS შემოწმება, ტელემეტრიული ჩანაწერი.
Intry Entry: აცხადებს გარე SNI/host- ს, როგორც მესის ნაწილს (პოლიტიკა და mTLS-origination გამოიყენება).

yaml apiVersion: networking. istio. io/v1beta1 kind: ServiceEntry metadata: { name: payments-external }
spec:
hosts: ["api. payments. com"]
ports: [{ number: 443, name: https, protocol: TLS }]
resolution: DNS location: MESH_EXTERNAL

6) Multi cluster, multi ქსელი და ჰიბრიდი

საერთო PKI/ნდობის დომენი: ერთიანი SPIFFE იდენტურობა მტევნებს შორის.
Endpoint discovery: სერვისების ბურთები რეგიონებს შორის; ადგილობრივი პრიორიტეტი და failover.
ზონალური იზოლაცია: პრო-რეგიონალური პოლიტიკოსები, ლიმიტები და პრიორიტეტები.
VM მესში: legacy/Stateful სისტემების დაკავშირება მარიონეტულ და იმავე პოლიტიკოსებთან.

7) დაკვირვება, SLO და ოპერაცია

Метрики: `requests_total`, `request_duration_ms{p50,p95,p99}`, `5xx_rate`, `retry_attempts`, `cb_state`, `mTLS_authz_denied`.
წვდომის ლოგოები: სტრუქტურული, 'traceparent', 'user/tenant', 'response _ flags'.
ტრეისი: სათაურების ინექცია (W3C Trace Context), სიმულაცია, სპილენძი hop დონეზე.
SLO: მიზნები p99/შეცდომებზე მარშრუტზე (მომსახურება).
ალერტები: ზრდა '5xx', ზრდა 'reset', 'outlier _ ejections', mTLS დეგრადაცია (handshake failures).

8) პროდუქტიულობა და ღირებულება

• მარცვლეული: ჩართეთ პოლიტიკა, სადაც საჭიროა; არ ჩართოთ მძიმე ფილტრები ყველგან.
• აუზები: დაყოფა ბილიკები (კრიტიკული/ფონი) სხვადასხვა მარშრუტებსა და ლიმიტებად.
• პროფილირება: p99 „ცივ“ მარშრუტებზე, ტელემეტრიული მოცულობა (საბაზო-ლიმიტის ლოგოების/ტრეისების).
• განიხილეთ ambient/sidecarless რეჟიმები, თუ ისინი მხარს უჭერენ და შეესაბამება მოთხოვნებს.

9) უსაფრთხოება და შესაბამისობა

მინიმალური საჭირო წვდომა: აშკარად გადაჭრა მიმართულებები და მეთოდები.
ნეიმსპაზების/ტენანტების პოლიტიკოსები: ქსელის/ავტორიზაციის საზღვრები.
გასაღებების როტაცია/SA: დაგეგმილი და გადაუდებელი; მოკლე TTL სერთიფიკატები.
PII/საიდუმლოებები: შენიღბვა ლოგოებში/ტრეისებში; მავთულის დაშიფვრა/მარტო.
აუდიტი: ვინ, როდის და რა პოლიტიკა შეიცვალა; ორსაფეხურიანი აფროუები.

10) ინტეგრაცია K8s დონესთან

Mesh პოლიტიკოსები ავსებენ და არ შეცვლიან ქსელის პოლიტიკას.
ingress/egress-gateway შეგიძლიათ ჩამოკიდოთ PodSecurity/PSA ქვემოთ.
NRA/ავტო სკეილინგი: გაითვალისწინეთ retrais/SV - ისინი ცვლის დატვირთვას.
გამოშვების გეგმები: კანარის წონა VirtualService + მეშვეობით SLO ავტომატური წინსვლა.

11) განხორციელების სია

• განსაზღვრულია ნდობის საზღვრები და შედის STRICT mTLS.
• ჩართულია AuthZ პოლიტიკოსები: ვინ ვისთან, რომელ პორტებზე/მეთოდებზე.
• იდენტიფიცირებულია timeouts/retries და outlier detection, განისაზღვრება იდემპოტენტური ბილიკები.
• ასახულია კანარის მარშრუტები და როლბაკის გეგმა; Fault-injection - მხოლოდ პროდ.
• გარეგანი დამოკიდებულებები იწარმოება egress-gateway და Microsoft Entry.
• განლაგებულია მეტრიკა, ლოგოები, ბილიკები; დაშბორდები და ალერტები p99/5xx/CB.
• გათვალისწინებულია კვოტები/შეზღუდვები per-tenant/namespace.
• მომზადებულია runbooks: სერტიფიკატის გაჟონვა, CA უკმარისობა, აფსიდის დეგრადაცია, მასობრივი 503/RESET.
• მრავალკლასიანი გეგმა (ზოგადი PKI, ადგილობრივი პრიორიტეტები, DR სცენარები).
• ტესტის დღეები (თამაშის დღეები): Control plane- ის ვარდნა, sidecar გაჩერება, ქსელის რღვევა, „შხამიანი“ აფსიდი.

12) ანტი შაბლონები

Mesh „ყველგან და დაუყოვნებლივ“ მარშრუტების ინვენტარიზაციის გარეშე და SLO ძვირადღირებული სირთულეა.
ნაგულისხმევი რეაგირება ეფექტების დუბლის და ტრაფიკის ზვავის ყველა მეთოდისთვის.
MTLS „დროებით“ გამორთვა სამუდამოდ რჩება.
Egress კარიბჭის გარეშე - მონაცემთა გაჟონვა/არაცნობიერი დამოკიდებულება.
ყველა სერვისის ერთი გლობალური პოლიტიკა არის ყალბი უსაფრთხოება და ყალბი სამუშაოები.
ნულოვანი observability: ჩართეთ mesh, მაგრამ არ აგროვებთ მეტრიკებს/ტრასებს - ჩვენ კარგავს მნიშვნელობას.

13) სწრაფი რეცეპტები

ლინკერდი: ჩართეთ mTLS და სერვერის პოლიტიკა

yaml apiVersion: policy. linkerd. io/v1beta1 kind: Server metadata: { name: billing, namespace: prod }
spec:
podSelector: { matchLabels: { app: billing } }
port: 8080 apiVersion: policy. linkerd. io/v1beta1 kind: ServerAuthorization metadata: { name: billing-allow-inventory, namespace: prod }
spec:
server: { name: billing }
client:
meshTLS:
identities: ["inventory. prod. serviceaccount. identity. linkerd. cluster. local"]

Consul (L7 intent + splitter)

hcl
Kind = "service-router"
Name = "orders"
Routes = [{
Match { HTTP { PathPrefix = "/v1" } }
Destination { Service = "orders" }
}]
Kind = "service-splitter"
Name = "orders"
Splits = [
{ Weight = 90, ServiceSubset = "v1" },
{ Weight = 10, ServiceSubset = "v2" }
]

14) FAQ

გვჭირდება პატარა გუნდი?
თუ 3-5 სერვისი უფრო ხშირად არ არის. დაიწყეთ კარგი ინგრედიენტები და სტაბილურობის ბიბლიოთეკები. დააკავშირეთ mesh, როდესაც საჭიროა mTLS ნაგულისხმევი, ერთიანი პოლიტიკოსები და ტრეკერი კოდის შეცვლის გარეშე.

როგორ გავაკონტროლოთ ღირებულება?
შეაფასეთ ყალბი (CPU/RAM/ლატენტობა) კრიტიკულ მარშრუტებზე, გამორთეთ ზედმეტი ფილტრები, შეამცირეთ ლოგოების/ტრეისების მოცულობა, გამოიყენეთ რეჟიმები sidecar- ის გარეშე, სადაც ის უსაფრთხოა.

შესაძლებელია თუ არა მესისა და ხელით მოაზროვნე მარიონეტული ჩარევა?
დიახ, მაგრამ თავიდან აიცილეთ ორმაგი მარშრუტიზაცია/დუბლიკატი. ერთი ადგილი ჭეშმარიტია - კონტროლი თვითმფრინავი.

რა არის უფრო მნიშვნელოვანი: უსაფრთხოება თუ პროდუქტიულობა?
სტანდარტულად - უსაფრთხოება (mTLS, AuthZ). პროდუქტიულობა მიიღწევა tuning კავშირი pools, outlier detection, სამიზნე მარშრუტები.

15) შედეგები

Service Mesh სერვისებს შორის ქსელს პროგრამირებულ ფენად აქცევს ერთ პოლიტიკოსებთან: დაშიფვრა და იდენტურობა, თხელი მარშრუტიზაცია და სტაბილურობა, ტელემეტრია და კვოტები. დაიწყეთ კრიტიკული ბილიკებით, ჩართეთ STRICT mTLS და აშკარა AuthZ, დააყენეთ taimauts/retrais/SV, აკონტროლეთ egress, გაზომეთ p99 და 5xx, ჩაატარეთ game days. შემდეგ mesh გახდება გამოშვების საიმედოობისა და სიჩქარის გამაძლიერებელი და არა სიურპრიზის წყარო.