Service Mesh: Istio, Linkerd

Service Mesh: Istio, Linkerd

1) რა არის Service Mesh და როდის არის ეს საჭირო

Service Mesh არის ქსელის მონაცემთა/კონტროლის სიბრტყის ფენა, რომელიც უზრუნველყოფს mTLS- ის გავლით, მარშრუტიზაციას, უკმარისობას და სერვისებს შორის დაკვირვებას კოდის გადაწერის გარეშე.

• ნაგულისხმევი უსაფრთხოება (zero-trust, სერვისების იდენტურობა, დაშვების პოლიტიკა).
• ტრაფიკის მენეჯმენტი (Canary/Blue-Green, A/B, shadowing).
• საიმედოობა (retrai, Taimauts, circuit breaking).
• დაკვირვება (მეტრიკა, ლოგოები, ტრეისი).
• ოპერაციული სტანდარტიზაცია (პოლიტიკა, როგორც კოდი, GitOps).

• მრავალი მიკროსერვისი პოლინგვალურობით და mTLS მოთხოვნით.
• ჩვენ გვჭირდება მოწინავე მარშრუტიზაციის/ექსპერიმენტების სცენარები პროგრამის შეცვლის გარეშე.
• ქსელის დონეზე არსებობს აუდიტის/პოლიტიკის მოთხოვნები.

2) Istio vs Linkerd - მოკლე შედარება

3) არქიტექტურა და განლაგების მოდელები

3. 1 Sidecar mesh (კლასიკური)

თითოეული Pod იღებს მარიონეტულ sidcar- ს.
დადებითი: სიმწიფე, სრული L7 კონტროლი.
უარყოფითი: CPU/RAM- ის ზედმეტი ხარჯები, დეპლოების/გამართვის გართულება.

3. 2 Istio Ambient Mesh

ztunnel (L4) კვანძზე + waypoint proxies (L7) საჭიროებისამებრ.
დადებითი: უფრო დაბალი ღირებულება და სირთულე, თანდათანობითი ჩართვა L7.
უარყოფითი მხარეები: ახალი, ყველა L7 შემთხვევა არ არის ხელმისაწვდომი waypoint- ის გარეშე.

4) პირადობა და mTLS (zero-trust)

4. 1 SPIFFE/SPIRE და სერთიფიკატები

თითოეულ workload- ს ენიჭება SPIFFE ID: 'spiffe ://cluster. local/ns/NS/sa/SA`.
ავთენტიფიკაცია: ურთიერთგამომრიცხავი TLS სერვისებს შორის.
გასაღებების როტაცია - ავტომატურად (მოკლე TTL).

4. 2 Istio (PeerAuthentication + DestinationRule)

yaml apiVersion: security. istio. io/v1 kind: PeerAuthentication metadata: { name: default, namespace: payments }
spec:
mtls: { mode: STRICT }
apiVersion: networking. istio. io/v1 kind: DestinationRule metadata: { name: payments-dr, namespace: payments }
spec:
host: payments. svc. cluster. local trafficPolicy:
tls: { mode: ISTIO_MUTUAL }

4. 3 ლინკერდი - mTLS ნაგულისხმევი

ჩართულია 'ლინკერის ინსტალაციის' + 'ლინკერდის ინექციის' შემდეგ.
მტევანი - საკუთარი trust-anchor, ავტომატური როტაცია.

5) ტრაფიკის მენეჯმენტი

5. 1 Istio: VirtualService (მარშრუტები, კანარეები)

yaml apiVersion: networking. istio. io/v1 kind: VirtualService metadata: { name: payments }
spec:
hosts: ["payments"]
http:
- route:
- destination: { host: payments, subset: v1 } # stable weight: 90
- destination: { host: payments, subset: v2 } # canary weight: 10 retries: { attempts: 2, perTryTimeout: 300ms }
timeout: 2s

yaml apiVersion: networking. istio. io/v1 kind: DestinationRule metadata: { name: payments }
spec:
host: payments subsets:
- name: v1 labels: { version: v1 }
- name: v2 labels: { version: v2 }
trafficPolicy:
loadBalancer: { simple: LEAST_CONN }
outlierDetection:
consecutive5xx: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

5. 2 Linkerd: ServiceProfile + TrafficSplit

yaml apiVersion: linkerd. io/v1alpha2 kind: ServiceProfile metadata:
name: payments. default. svc. cluster. local spec:
routes:
- name: POST /withdraw condition:
method: POST pathRegex: "/withdraw"
isRetryable: true timeout: 2s apiVersion: split. smi-spec. io/v1alpha2 kind: TrafficSplit metadata: { name: payments }
spec:
service: payments backends:
- service: payments-v1 weight: 90
- service: payments-v2 weight: 10

6) Ingress/Egress და API კარიბჭეები

Istio Gateway (ingress/egress) - მართავს შემომავალი/გამავალი ტრაფიკი, TLS termination, mTLS passthrough.
ლინკერდი მუშაობს არსებულ ingress კონტროლერებთან (NGINX/Contour/Traefik); egress - ქსელის პოლიტიკის/egress-gateway ნიმუშების საშუალებით.
Egress პოლიტიკოსები: დომენების თეთრი სიები, SNI პოლიტიკა, პირდაპირი ინტერნეტის აკრძალვა.

7) ავტორიზაცია და პოლიტიკა

7. 1 Istio AuthorizationPolicy (RBAC/ABAC)

yaml apiVersion: security. istio. io/v1 kind: AuthorizationPolicy metadata: { name: allow-withdraw, namespace: payments }
spec:
selector: { matchLabels: { app: payments } }
action: ALLOW rules:
- from:
- source:
principals: ["spiffe://cluster. local/ns/api/sa/gateway"]
to:
- operation:
methods: ["POST"]
paths: ["/withdraw"]
when:
- key: request. auth. claims[role]
values: ["cashout"]

7. 2 Linkerd policy (server + serverauthorization)

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

8) დაკვირვება და ტელემეტრია

8. 1 მეტრიკა

Istio Telemetry API → Prometheus: `istio_requests_total`, `istio_request_duration_milliseconds_bucket`, `istio_tcp_received_bytes_total`.
Linkerd viz: `request_total`, latency p50/p95/p99, `success_rate`.

8. 2 ტრეისი და ლოგოები

სცადეთ W3C Trace Context.
Istio/Envoy → OTLP в OpenTelemetry Collector; ლინკერდი - sidecar-loggers/app-SDK მეშვეობით.

8. 3 ეგზემპლარები

დაამატეთ 'trace _ id "ხანგრძლივობის ჰისტოგრამებს" jump-to-trace ".

9) Rate limits, WAF, კასტომის ფილტრები

Istio: EnvoyFilter/WASM ადგილობრივი ლიმიტებისთვის, eksternal-rate-limit სერვისისთვის (Redis), ასევე WAF ლოგიკა (Lua/WASM).
ლინკერდი: შეზღუდული მშობლიური მხარდაჭერა; rate limit - ინგრესის/კარიბჭის დონეზე.

10) მრავალმხრივი

Istio: East-west gateway, საერთო PKI ან trust-bundle, discovery სერვისის საშუალებით Entry, Federation.
Linkerd: `linkerd multicluster link`, gateway per cluster, service-mirror контроллер.

Use-cases: აქტივი აქტივი რეგიონებისთვის, ტრეფიკის ლოკალიზაცია, ფედერირებული zero-trust.

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

Sidecar mesh: overhead CPU/RAM თითოეული Pod, გაზრდილი ლატენტობა (ჩვეულებრივ + 1-3 ms hop steady-state- ში).
Ambient (Istio): ნაკლები მოხმარება L4- სთვის, L7 ჩართულია წერტილოვანი.
ლინკერდი: მსუბუქი წონის მარიონეტული, როგორც წესი, ნაკლები overhead, მაგრამ ნაკლები ექსტრემალური L7 შესაძლებლობები.
პრაქტიკა: გაზომეთ p95/CPU ადრე/მის შემდეგ, შეინახეთ SLO კარიბჭეები დეგრადაციისთვის.

12) უსაფრთხოება

mTLS ყველგან, მოკლე TTL, ავტომატური როტაცია.
Policy as Code (OPA/Gatekeeper, Kyverno) აკრძალვისთვის „authorizationPolicy: ALLOW all“.
საიდუმლოებები - CSI/Vault- ის საშუალებით, არა მანიფესტებში.
Egress კონტროლი: deny-by-default, აშკარა allow ფურცლები.
ცალკეული trust domains გარემოცვისთვის (stage/stage).

13) ინტეგრაცია გამოშვებებთან და SLO კარიბჭესთან

Canary/Blue-Green ხორციელდება mesh მარშრუტებით (იხ. მაგალითები).
მეტრიკის ანალიზი (Prometheus/GeneMetrics) Argo Rollouts AnalysisTemplate- ში - გამოტოვება/გამოტოვება burn-rate/p95/5xx.
Grafana- ს გამოცემების მენიუ: შედარება 'version = stable' canary '.

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

ჩართეთ mesh „ყველგან და დაუყოვნებლივ“ ინფრასტრუქტურის შოკი.
მეტრიული/ლოგების კარდინალობის უგულებელყოფა მარიონეტებისგან არის TSDB/საცავის გადატვირთვა.
სამუდამოდ დატოვეთ mTLS PERMISSIVE/opaque რეჟიმში.
შეეცადეთ შექმნათ რთული WAF/ბიზნეს ლოგიკა EnvoyFilter- ის შიგნით, gateway/პროგრამის ნაცვლად.
არ არსებობს egress პოლიტიკა - გაჟონვა ინტერნეტით/შესაბამისობის გვერდის ავლით.
მარიონეტული ': 15,000' debug ღიაა.

15) განხორციელების სიის სია (0-60 დღე)

0-15 დღე

მოდელის არჩევანი: Sidecar vs Ambient (Istio )/Linkerd დატვირთვის პროფილში.
ჩართეთ mTLS STRICT, ძირითადი ავტორიზაციის პოლიტიკა 1-2 კრიტიკული მომსახურებისთვის.
საბაზო მარშრუტები (Timeout/retries), RED/SLO დაშბორდები.

16-30 დღე

Canary/TrafficSplit, outlier detection/circuit breaking ცხელ გზაზე.
OTEL ინტეგრაცია: ტრეისი + Exemplars; ალერტები burn-rate.
Egress-gateways და დომენის თეთრი სიები; deny-by-default.

31-60 დღე

მრავალსაფეხურიანი საბრძოლო (საჭიროების შემთხვევაში), federation trust.
Policy as Code на AuthorizationPolicy/ServerAuthorization.
თამაშის დღე: ინციდენტის სიმულაცია და მარშრუტების დაბრუნება/პოლიტიკოსი.

16) სიმწიფის მეტრიკა

MTLS (STRICT/auto-rotate) დაფარვა მომსახურების 95% -ს შეადგენს.
კანარის/პროგრესული გამოშვებების საშუალებით ტრეფიკის წილი 80% -ს შეადგენს.
საშუალო overhead p95 <+ 5% საბაზო ხაზისგან (ოპტიმიზაციის შემდეგ).
0 ღია ნებართვის გარეშე, სერვისების 100% ძირითადი AuthZ.
RCA „გრაფიკიდან ტრასამდე“ 2 წუთი (p50).

17) „პოლიტიკის კოდის“ მაგალითები

Gatekeeper (PERMISSIVE აკრძალვა გაყიდვაში)

yaml apiVersion: constraints. gatekeeper. sh/v1beta1 kind: K8sIstiomTLSStrict metadata: { name: deny-permissive-prod }
spec:
match:
kinds: [{ apiGroups: ["security. istio. io"], kinds: ["PeerAuthentication"] }]
namespaces: ["prod-"]
parameters:
allowedModes: ["STRICT"]

Kyverno (სავალდებულო ლაბორატორიები VS/DR)

yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata: { name: require-mesh-labels }
spec:
rules:
- name: vs-dr-labels match:
any:
- resources:
kinds: ["VirtualService","DestinationRule"]
validate:
message: "owner and service labels required"
pattern:
metadata:
labels:
owner: "?"
service: "?"

18) საოპერაციო საბჭო

გააფორმეთ პოლიტიკოსები და მარშრუტები (semver), დაწინაურდით GitOps- ის საშუალებით.
მარიონეტული დაკვირვება: ცალკეული დაშბორდები „პროქსის სატურნა“ (CPU/heap, retries, 429/503).
კარდინალობის ბიუჯეტი: ეტიკეტები 'მარშრუტი', 'კოდექსი', 'destination' - მხოლოდ შაბლონები.
ქსელის ლიმიტები/კვოტები namespace (ქსელის პოლიტიკა/LimitRange).
გუნდის დოკუმენტაცია: runbook „როგორ გადავიდეთ მარშრუტები/პოლიტიკა/mTLS გასაღებები“.

19) დასკვნა

Istio და Linkerd წყვეტენ ერთ პრობლემას - უსაფრთხოების სტანდარტიზება, ურთიერთდახმარების კომუნიკაციების საიმედოობა და ხილვადობა - მაგრამ ამას აკეთებენ სხვადასხვა სიღრმით და საკუთრების ღირებულებით.

ჩვენ გვჭირდება მდიდარი L7 შესაძლებლობები და მოქნილი პოლიტიკოსები - მიიღეთ Istio (განიხილეთ Ambient ყალბი შემცირების მიზნით).
ჩვენ გვჭირდება სიმარტივე და პატარა overhead - მიიღეთ ლინკერდი.

რაც არ უნდა აირჩიოთ mesh: ჩართეთ mTLS ნაგულისხმევი, მართეთ მარშრუტიზაცია, როგორც კოდი, დააკავშირეთ მეტრიკები ტრეიზერებთან, დახურეთ egress და დაამატეთ SLO გეიტინგი გამოშვებებში. შემდეგ ქსელის ფენა შეწყვეტს „შავ ყუთს“ და გახდება პროგნოზირებადი ინსტრუმენტი სტაბილურობისა და ცვლილების სიჩქარეზე.