Service Mesh va trafik siyosati

1) Nima uchun Service Mesh kerak?

• Andoza xavfsizlik: mTLS, sertifikatlarni avtomatik ravishda berish/almashtirish, xizmatlarning oʻziga xosligi.
• Trafik siyosati: L7 yo’nalishi, kanar/AV testlari, degradatsiya va barqarorlik.
• Kuzatish darajasi: metrika, loglar, trastirovkalar, har bir chaqiruvdagi oltin signallar.
• Amallar: barcha tillar/fraymvorklar uchun yagona siyosatlar.

API-shlyuzdan farq: shlyuz - north-south perimetri; mesh - klaster/tashkilot ichidagi east-west. Ko’pincha birga ishlaydi.

2) Arxitektura: tekisliklar va patternlar

Data Plane: sidecar-proksi (Envoy/Linkerd-proxy/haproxy).
Control Plane: konfiguratsiyalarni (marshrutlar, siyosatlar, sertifikatlar) taqsimlaydi, holatini saqlaydi, servis diskoverlarini nashr etadi.
Identity: odatda SPIFFE ID va avtomatik X.509 sertifikatlari (SPIRE/oʻrnatilgan CA).
Kirish/chiqish nuqtalari: chegara oqimlarini nazorat qilish uchun ingress/egress-gateway.
Joriy etish rejimlari: har biriga sidecar; yangi amalga oshirishlarda per-uzel/ambient-modalar.

3) Xavfsizlik va zero-trust siyosati

1. mTLS by default: shifrlash va oʻzaro autentifikatsiya xizmati.

• AuthN: Faqat CA mesh’a (SPIFFE) tomonidan berilgan identifikatsiyalarga ishonamiz.
• AuthZ: «kim kimga va qanday qila oladi» deklarativ qoidalari (RBAC/ABAC).

3. Izolyatsiya va egress-nazorat:

• Ruxsat etilgan domenlar/kichik tarmoqlar; egress-gateway orqali majburiy chiqish.
• Podlardan to’g «ridan to’g» ri chiqishlarni blokirovka qilish.

4. Sirlarning rotatsiyasi: qisqa umr ko’rish sertifikatlari, proksining avtomatik qayta konfiguratsiyasi.

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) Trafik siyosati: barqarorlik va yo’nalish

4. 1 Taymautlar va retralar

Timeouts: (connect/read/overall).
Retries: faqat idempotent operatsiyalari uchun; backoff + jitter; per-try timeout limitlari.

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: Bir vaqtning o’zida so’rovlarni/ulanishlarni cheklaydi.
Outlier: xato/maxfiylik tufayli «yomon» holatlarni tashlaydi.

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 Kanareya va shartlar bo’yicha

Weighted: trafikni v1/v2 tarozilariga ajratish.
Header-based: bayroqlar/cookie/tenant → yangi versiyaga koʻchiriladi.
Session affinity: kalit xeshi.

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 va degradatsiya

Barqarorlik testi va SLO uchun kechikishlar/xatolarni in’ektsiya qilish.

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

5) Tarmoq chegaralari: ingress/egress va tashqi servislar

Ingress-gateway: tashqi mijozlar uchun mesh-ga kirishning yagona nuqtasi; WAF/OIDC/ratelimits bilan integratsiya.
Egress-gateway: ruxsat etilgan xostlar ro’yxati bilan markaziy chiqish, TLS inspeksiyasi, telemetriya yozuvi.
ServiceEntry: Tashqi SNI/host mesh (siyosat va mTLS-origination qoʻllanilishi mumkin) qismi sifatida eʼlon qiladi.

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-network va gibrid

Umumiy PKI/trast-domen: klasterlar orasidagi yagona SPIFFE identifikatsiyalari.
Endpoint discovery: mintaqalar o’rtasidagi servislar to’plari; lokal ustuvorlik va failover.
Hududiy izolyatsiya: per-mintaqaviy siyosat, limitlar va ustuvorliklar.
VM to mesh: legacy/Stateful tizimlarini proksi va bir xil siyosatga ulash.

7) Kuzatish, SLO va ekspluatatsiya

Метрики: `requests_total`, `request_duration_ms{p50,p95,p99}`, `5xx_rate`, `retry_attempts`, `cb_state`, `mTLS_authz_denied`.
Kirish daftarlari:’traceparent’,’user/tenant’,’response _ flags’.
Treysing: sarlavhalarni avto-inyeksiya qilish (W3C Trace Context), samplash, hop-darajasida uxlash.
SLO: r99/yo’nalishdagi xatolar (service → service).
Alertlar: splash’5xx’, o’sish’reset’,’outlier _ ejections’, degradatsiya mTLS (handshake failures).

8) Unumdorlik va qiymat

• Donadorlik: kerak bo’lganda siyosatni o’z ichiga olish; Hamma joyda og’ir filtrlarni yoqmaslik.
• Pullar: yo’llarni (kritik/fon) turli yo’nalishlar va limitlarga bo’lish.
• Profillash: p99 «sovuq» yo’nalishlarda, telemetriya hajmi (rate-limit log/treys).
• Ambient/sidecarless rejimlarini ko’rib chiqish, agar ular qo’llab-quvvatlansa va talablarga javob bersa.

9) Xavfsizlik va komplayens

Minimal foydalanish: yo’nalish va usullarni aniq hal qilish.
Neyspeys/tenant siyosati: tarmoq/avtorizatsiya chegaralari.
Kalit/SA rotatsiyasi: rejali va avariya; qisqa TTL sertifikatlari.
PII/sirlar: loglarda/treyslarda yashirish; simda/xotirjam shifrlash.
Audit: kim, qachon va qanday siyosatni o’zgartirdi; ikki bosqichli oqimlar.

10) K8s darajasi bilan integratsiya

Mesh siyosati NetworkPolicy oʻrniga uni toʻldiradi.
Ingress/egress-gateway’da PodSecurity/PSA’ni pastga osib qoʻyish mumkin.
NRA/avtoskeyling: retrajni hisobga oling/SV - ular yukni o’zgartiradi.
Reliz rejalari: VirtualService + SLO orqali avtomatik ravishda oldinga siljish.

11) Joriy etish chek-varaqasi

• Ishonch chegaralari aniqlandi va STRICT mTLS yoqilgan.
• AuthZ siyosati kiritilgan: kimga, qaysi portlarda/usullarda.
• Timeouts/retries va outlier detection moslashtirilgan, idempotent yoʻllar aniqlangan.
• Kanareya yo’nalishlari va rollback-reja yozilgan; fault-injection - faqat nooprodga.
• Egress-gateway va ServiceEntry orqali tashqi qaramliklar chiqarildi.
• Metriklar, loglar, trassalar sozlangan; p99/5xx/CB dashbordlar va alertlar.
• per-tenant/namespace kvotalari/limitlari nazarda tutilgan.
• Runbooks tayyorlandi: sertifikat sizib chiqishi, CA nosozligi, apstrimning degradatsiyasi, ommaviy 503/RESET.
• Multi-cluster rejasi (umumiy PKI, mahalliy ustuvorliklar, DR-stsenariylar).
• Test kunlari (game days): control plane qulashi, sidecar to’xtashi, tarmoq uzilishi, «zaharli» oqim.

12) Anti-patternlar

Mesh «hamma joyda va darhol» yo’nalishlarni inventarizatsiyasiz va SLO → qimmat murakkablik.
Barcha usullar uchun andoza retralar → effektlar dubli va trafik koʻchkisi.
Oʻchirilgan mTLS «vaqtinchalik» → abadiy qoladi.
Shlyuzsiz Egress → ma’lumotlar tarqalishi/hisobga olinmagan qaramliklar.
Barcha xizmatlar uchun bitta global siyosat → soxta xavfsizlik va yolg’on ishlashlar.
Nol observability: mesh yoqilgan, lekin metrik/treys yig’mayapmiz - ma’noni yo’qotamiz.

13) Tezkor retseptlar

Linkerd: mTLS va policy serverni yoqish

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

Kichik jamoaga mesh kerakmi?
Agar 3-5 ta servis mavjud bo’lsa, ko’pincha mavjud emas. Yaxshi ingress va barqarorlik kutubxonalaridan boshlang. mTLS andoza, yagona siyosatlar va trassirovkalarni kodni oʻzgartirmasdan ulash.

Narxni qanday nazorat qilish kerak?
Og’ir yo’llarda yuk xati (CPU/RAM/latency) ni o’lchang, ortiqcha filtrlarni o’chirib qo’ying, loglar/treyslarni kamaytiring, xavfsiz joyda sidecarsiz rejimlardan foydalaning.

Mesh va qoʻlda sozlangan proksiga aralashish mumkinmi?
Ha, lekin ikki marshrut/bir-birini takrorlovchi retrajlardan qoching. Yagona joy haqiqat - control plane.

Nima muhimroq: xavfsizlik yoki samaradorlik?
Andoza - xavfsizlik (mTLS, AuthZ). Unumdorlikka connection pools, outlier detection, maqsadli yoʻnalishlar yordamida erishiladi.

15) Yakunlar

Service Mesh xizmatlar o’rtasidagi tarmoqni yagona siyosatga ega dasturlanadigan qatlamga aylantiradi: shifrlash va o’ziga xoslik, nozik marshrutlash va barqarorlik, telemetriya va kvotalar. Tanqidiy yo’llar bilan boshlang, STRICT mTLS va aniq AuthZ-ni yoqing, taymautlar/retrajlar/SV bering, egress-ni nazorat qiling, p99 va 5xx o’lchang, game days o’tkazing. Shunda mesh kutilmagan hodisalar manbai emas, balki relizlarning ishonchliligi va tezligini kuchaytiradi.