Service Mesh: Istio, Linkerd

Service Mesh: Istio, Linkerd

1) Service Mesh nima va qachon kerak

Service Mesh - ma’lumotlar/boshqaruvning tarmoq tekisligi qatlami bo’lib, u mTLS, yo’naltirish, nosozlikka chidamlilik va kodni qayta yozmasdan xizmatlar o’rtasida kuzatishni ta’minlaydi.

• Andoza xavfsizlik (zero-trust, xizmatlarning oʻziga xosligi, kirish siyosati).
• Trafikni boshqarish (Canary/Blue-Green, A/B, shadowing).
• Ishonchlilik (retray, taymaut, circuit breaking).
• Kuzatilganlik (metriklar, loglar, treyslar).
• Operatsion standartlashtirish (kod sifatida siyosatlar, GitOps).

• Ko’p tillilik va mTLS talabiga ega bo’lgan ko’plab mikroservislar mavjud.
• Ilovani o’zgartirmasdan marshrutlash/tajriba uchun ilg’or skriptlar kerak.
• Tarmoq darajasida audit/siyosat talablari mavjud.

2) Istio vs Linkerd - qisqacha taqqoslash

3) Arxitektura va joylashtirish modellari

3. 1 Sidecar mesh (klassika)

Har bir Pod proksi-saidkar oladi.
Ijobiy tomonlari: yetuklik, to’liq L7 nazorati.
Kamchiliklar: CPU/RAMning qo’shimcha xarajatlari, deploylarning murakkablashishi/sozlanishi.

3. 2 Istio Ambient Mesh

ztunnel (L4) tugunida + waypoint proxies (L7) kerak bo’lganda.
Afzalliklari: past qiymat va murakkablik, L7 bosqichma-bosqich qo’shish.
Kamchiliklar: yangi, barcha L7-keyslar waypointsiz mavjud emas.

4) O’ziga xoslik va mTLS (zero-trust)

4. 1 SPIFFE/SPIRE va sertifikatlar

Har bir vorkload uchun SPIFFE ID:’spiffe ://cluster beriladi. local/ns/NS/sa/SA`.
Autentifikatsiya: xizmatlar oʻrtasida oʻzaro TLS.
Kalitlarning rotatsiyasi - avtomatik ravishda (qisqa 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 Linkerd - mTLS andoza

’linkerd install’ +’linkerd inject’dan keyin kiritiladi.
Klasterlar - o’z trust-anchor, rotatsiya avtomatik.

5) Trafik-menejment

5. 1 Istio: VirtualService (marshrutlar, kanareykalar)

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 va API-shlyuzlar

Istio Gateway (ingress/egress) - kiruvchi/chiquvchi trafikni boshqaradi, TLS termination, mTLS passthrough.
Linkerd mavjud ingress-kontrollerlar (NGINX/Contour/Traefik) bilan ishlaydi; egress - NetworkPolicy/egress-gateway-patternlari orqali.
Egress siyosati: domenlarning oq ro’yxati, SNI-policy, to’g’ridan-to’g’ri Internetni taqiqlash.

7) Avtorizatsiya va siyosat

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) Kuzatish va telemetriya

8. 1 Metrika

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 Treys va loglar

W3C Trace Context dasturini tashlang.
Istio/Envoy → OTLP в OpenTelemetry Collector; Linkerd - sidecar-logger/app-SDK orqali.

8. 3 nusxa (Exemplars)

Jump-to-trace uchun’trace _ id’ni gistogrammalarga qoʻshing.

9) Rate limits, WAF, kastom filtrlar

Istio: EnvoyFilter/WASM uchun lokal rate limits, eksternal-rate-limit service (Redis), shuningdek WAF-logika (Lua/WASM).
Linkerd: cheklangan mahalliy qo’llab-quvvatlash; rate limit - ingress/shlyuz darajasida.

10) Ko’p klasterlilik

Istio: east-west gateway, umumiy PKI yoki trust-bundle, ServiceEntry, Federation orqali xizmat diskaverlari.
Linkerd: `linkerd multicluster link`, gateway per cluster, service-mirror контроллер.

Use-cases: aktiv-aktiv hududlar, trafikni mahalliylashtirish, federal zero-trust.

11) Unumdorlik va qiymat

Sidecar mesh: har bir Pod uchun CPU/RAM overxed, orttirilgan latentlik (odatda steady-state-da hop uchun + 1-3 ms).
Ambient (Istio): L4, L7 uchun kamroq isteʼmol nuqtaga qoʻshiladi.
Linkerd: engil proksi odatda overhead dan kamroq, ammo L7 ning ekstremal imkoniyatlari kamroq.
Amaliyot: p95/CPU oldin/keyin o’lchang, SLO-geytlarni tanazzulga yo’l qo’ying.

12) Xavfsizlik

mTLS hamma joyda, qisqa TTL, avtomatik rotatsiya.
Policy as Code (OPA/Gatekeeper, Kyverno) taqiqlar uchun’authorizationPolicy: ALLOW all’.
Sirlar - CSI/Vault orqali, manifestlarda emas.
Egress-nazorat: deny-by-default, aniq allow-varaqlar.
Alohida trust domains (prod/stage).

13) Relizlar va SLO-geyting bilan integratsiya

Canary/Blue-Green mesh yo’nalishlarida amalga oshiriladi (misollarga qarang).
Argo Rollouts AnalysisTemplate da metriklarni (Prometheus/SpanMetrics) tahlil qilish - burn-rate/p95/5xx da avtostop/orqaga qaytish.
Grafanadagi relizlar izohlari: taqqoslash’version = stable’canary’.

14) Anti-patternlar

Mesh «hamma joyda va darhol» ni yoqish → infratuzilma zarbasi.
Proksidan metrik/loglarning kardinalligini eʼtiborsiz qoldirish → TSDB/logaxonani ortiqcha yuklash.
mTLSni PERMISSIVE/opaque rejimida abadiy qoldirish.
gateway/ilova o’rniga EnvoyFilter ichida murakkab WAF/biznes mantig’ini yaratishga harakat qiling.
Egress siyosati mavjud emas.
s’: 15000’debug proksi ochiq.

15) Joriy etish chek-varaqasi (0-60 kun)

0-15 kun

Modelni tanlash: Sidecar vs Ambient (Istio )/Linkerd.
mTLS STRICT, 1-2 ta muhim xizmatlar uchun avtorizatsiyaning asosiy siyosatini kiritish.
Bazaviy yo’nalishlar (timeout/retries), RED/SLO dashbordlari.

16-30 kun

Canary/TrafficSplit, outlier detection/circuit breaking.
MEHMONXONA integratsiyasi: treyslar + Exemplars; burn-rate alertlari.
Egress-gateways va domenlarning oq ro’yxatlari; deny-by-default.

31-60 kun

Ko’p klasterli link (agar kerak bo’lsa), federation trust.
Policy as Code на AuthorizationPolicy/ServerAuthorization.
Game-day: hodisa va yo’nalishlar/siyosatlar simulyatsiyasi.

16) Etuklik metrikasi

mTLS (STRICT/auto-rotate) xizmatlarining 95 foizini ≥.
Kanar/progressiv relizlar orqali trafik ulushi ≥ 80%.
Asosiy chiziqning oʻrtacha overhead p95 <+ 5% (optimallashtirilgandan keyin).
0 ruxsatsiz ochiq egress, bazaviy AuthZ bilan 100% servislar.
RCA «grafikdan trassaga» ≤ 2 daqiqa (p50).

17) «Kod sifatida siyosat» misollari

Gatekeeper (mahsulotda PERMISSIVE taqiqlangan)

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 uchun majburiy labels)

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) Ekspluatatsiya kengashlari

GitOps orqali targ’ib qilinadigan siyosat va yo’nalishlarni (semver) versiya qiling.
Proksi kuzatilishi: alohida dashbordlar «proxy saturation» (CPU/heap, retries, 429/503).
’route’,’code’,’destination’belgilari faqat shablondir.
Namespace (NetworkPolicy/LimitRange) darajasiga tarmoq limitlari/kvotalari.
Buyruq hujjatlari: runbook «mTLS yoʻllari/siyosati/kalitlarini qanday qaytarish kerak».

19) Xulosa

Istio va Linkerd bitta vazifani hal qilishadi - xizmatlararo kommunikatsiyalarning xavfsizligi, ishonchliligi va ko’rinishini standartlashtirish - lekin buni turli chuqurlik va egalik qiymati bilan amalga oshiradilar.

Boy L7 imkoniyatlari va moslashuvchan siyosatlar kerak - Istio-ni oling (yuklarni kamaytirish uchun Ambientni ko’rib chiqing).
Soddalik va kichik overhead kerak - Linkerd oling.

Qaysi mesh tanlanishidan qatʼi nazar: mTLSni andoza sifatida yoqing, yoʻnalishni kod sifatida boshqaring, metriklarni treyslarga bogʻlang, egress-ni yoping va relizlarga SLO-geyting qoʻshing. Shunda tarmoq qatlami «qora quti» bo’lishni to’xtatadi va barqarorlik va o’zgarish tezligining bashorat qilinadigan vositasiga aylanadi.