Xidmət Mesh və Trafik Siyasəti

1) Niyə Xidmət Mesh lazımdır

• Default təhlükəsizlik: mTLS, sertifikatların avtomatik verilməsi/rotasiyası, xidmətlərin kimliyi.
• Trafik siyasəti: L7 marşrutlaşdırma, kanar/AV testləri, deqradasiya və sabitlik.
• Müşahidə: metriklər, qeydlər, izlər, hər çağırışda qızıl siqnallar.
• Əməliyyatlar: Bütün dillər/çərçivələr üçün vahid siyasətlər.

API şlyuzundan fərqi: şlyuz - şimal-cənub perimetri; mesh - klaster/təşkilat daxilində şərq-qərb. Tez-tez birlikdə işləyir.

2) Memarlıq: müstəvilər və nümunələr

Data Plane: sidecar-proxy (Envoy/Linkerd-proxy/haproxy), pod/VM trafikinə mane olur.
Control Plane: konfiqurasiyaları (marşrutlar, siyasətlər, sertifikatlar) paylayır, vəziyyəti saxlayır, xidmət disketlərini dərc edir.
Identity: adətən SPIFFE ID və avtomatik X.509 sertifikatları (SPIRE/daxili CA).
Giriş/çıxış nöqtələri: sərhəd axınlarına nəzarət etmək üçün ingress/egress-gateway.
Tətbiq rejimləri: hər alt üçün sidecar; yeni tətbiqlərdə per-nodal/ambient-moda.

3) Təhlükəsizlik siyasəti və sıfır-trust

1. mTLS by default: şifrələmə və qarşılıqlı autentifikasiya xidməti, xidmət.

• AuthN: yalnız CA mesh (SPIFFE) tərəfindən verilmiş şəxsiyyətlərə etibar edirik.
• AuthZ: «kim kimə və necə edə bilər» bəyannamə qaydaları (RBAC/ABAC).

3. İzolyasiya və egress-nəzarət:

• Icazə verilən domenlər/alt şəbəkələr; egress-gateway vasitəsilə məcburi çıxış.
• Paltolardan birbaşa nəticələrin bloklanması.

4. Sirlərin rotasiyası: qısa ömürlü sertifikatlar, avtomatik proxy yenidən konfiqurasiyası.

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 siyasəti: sabitlik və marşrutlaşdırma

4. 1 Vaxt və retrajlar

Timeouts: bir çağırış (connect/read/overall) təyin edilir.
Retries: yalnız idempotent əməliyyatlar üçün; backoff + jitter; limitləri 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: axınları qoruyaraq eyni vaxtda sorğuları/əlaqələri məhdudlaşdırır.
Outlier: səhvlər/gizli «pis» instansiyaları atır.

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 Kanarya və şərtlərə görə

Weighted: v1/v2 ağırlıqlarına görə trafik bölgüsü.
Header-based: bayraqlar/cookies/tenant → yeni versiyası atmaq.
Session affinity: açar hash (ölçmə ilə diqqətlə).

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 və Deqradasiya

davamlı test və SLO üçün gecikmələr/səhvlər inyeksiya.

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

5) Şəbəkə sərhədləri: ingress/egress və xarici xidmətlər

Ingress-gateway: mesh xarici müştərilər üçün yeganə giriş nöqtəsi; WAF/OIDC/ratelimits ilə inteqrasiya.
Egress-gateway: icazə verilən hostların siyahısı ilə mərkəzi çıxış, TLS-yoxlama, telemetriya qeydləri.
ServiceEntry: mesh hissəsi kimi xarici SNI/host elan (siyasət və mTLS-origination tətbiq olunur).

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 və hibrid

Ümumi PKI/Trust Domain: Klasterlər arasında vahid SPIFFE identifikasiyaları.
Endpoint discovery: regionlar arasında xidmət topları; yerli prioritet və failover.
Zona təcrid: per-regional siyasətlər, limitlər və prioritetlər.
VM-in mesh: legacy/Stateful sistemlərinin proxy və eyni siyasətlərə qoşulması.

7) Müşahidə, SLO və əməliyyat

Метрики: `requests_total`, `request_duration_ms{p50,p95,p99}`, `5xx_rate`, `retry_attempts`, `cb_state`, `mTLS_authz_denied`.
Giriş qeydləri: struktur, 'traceparent', 'user/tenant', 'response _ flags'.
Trace: başlıqların avtomatik inyeksiyası (W3C Trace Context), sampling, hop səviyyəsində yuxu.
SLO: marşrutda p99/səhv hədəfləri (service → service).
Alertlər: sıçrayış '5xx', böyümə 'reset', 'outlier _ ejections', deqradasiya mTLS (handshake failures).

8) Performans və dəyəri

• Taxılçılıq: lazım olan siyasəti daxil etmək; hər yerdə ağır filtrləri daxil deyil.
• Hovuzlar: yolları (kritik/fon) müxtəlif marşrutlara və limitlərə bölmək.
• Profil: «soyuq» marşrutlarda p99, telemetriya həcmi (rate-limit log/treys).
• Dəstəklənən və tələblərə uyğun olduqda ambient/sidecarless rejimlərini nəzərdən keçirin.

9) Təhlükəsizlik və uyğunluq

Minimum tələb olunan giriş: istiqamətləri və metodları açıq şəkildə həll etmək.
Neyspeys/tenant siyasətləri: şəbəkə/avtorizasiya sərhədləri.
Açarların rotasiyası/SA: planlı və təcili; qısa TTL sertifikatları.
PII/sirləri: log/treys maskalanması; simli/rahat şifrələmə.
Audit: kim, nə vaxt və hansı siyasəti dəyişdi; iki mərhələli pruvalar.

10) K8s səviyyəsi ilə inteqrasiya

Mesh siyasətçiləri NetworkPolicy-ni əvəz etmir.
Ingress/egress-gateway-də siz PodSecurity/PSA səviyyəsini aşağı asa bilərsiniz.
NRA/Avtoskeylinq: retrajları/SV nəzərə alın - onlar yükü dəyişir.
Buraxılış planları: VirtualService vasitəsilə kanarya çəkisi + SLO avtomatik təşviqi.

11) Giriş çek siyahısı

• Etibarlılıq sərhədləri müəyyən edilmiş və STRICT mTLS daxil edilmişdir.
• AuthZ siyasətləri daxildir: kimə, hansı limanlarda/metodlarda.
• Xüsusi timeouts/retries və outlier detection, müəyyən idempotent yolları.
• Kanarya marşrutları və rollback planı; fault-injection - yalnız qeyri-prod.
• Egress-gateway və ServiceEntry vasitəsilə xarici asılılıqlar.
• Metrik, log, trek; daşbordlar və p99/5xx/CB alertlər.
• per-tenant/namespace kvotaları/limitləri nəzərdə tutulur.
• runbooks hazırlanmışdır: sertifikat sızması, CA uğursuzluğu, axının deqradasiyası, kütləvi 503/RESET.
• Multi-cluster planı (ümumi PKI, yerli prioritetlər, DR ssenariləri).
• Test günləri (game days): control plane düşməsi, sidecar dayandırılması, şəbəkə qırılması, «zəhərli» axın.

12) Anti-nümunələr

Mesh «hər yerdə və dərhal» marşrutları və SLO inventar olmadan → bahalı mürəkkəblik.
Bütün üsullar üçün default retrailer → duple effektləri və trafik uçqunu.
Off mTLS «müvəqqəti» → əbədi qalır.
Şlüz olmadan Egress → məlumat sızması/nəzərə alınmayan asılılıqlar.
Bütün xidmətlər üçün bir qlobal siyasət → saxta təhlükəsizlik və saxta işləmələr.
Sıfır observability: mesh aktiv, lakin metrik/treys toplamırıq - mənasını itiririk.

13) Sürətli reseptlər

Linkerd: Serverdə mTLS və policy daxil edin

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

Kiçik bir komanda mesh lazımdır?
3-5 xidmət varsa - daha çox yoxdur. Yaxşı ingress və sabitlik kitabxanaları ilə başlayın. mTLS default, vahid siyasət və kodu dəyişdirmədən izləmə ehtiyacı olduqda mesh qoşun.

Qiyməti necə idarə etmək olar?
Kritik yollarda qəbz (CPU/RAM/latency) ölçün, lazımsız filtrləri söndürün, giriş/treys həcmini azaltın, təhlükəsiz olan yerlərdə sidecar olmadan rejimlərdən istifadə edin.

Mesh və əl ilə qurulmuş proxy müdaxilə edə bilərəmmi?
Bəli, lakin ikiqat marşrutlaşdırma/təkrarlanan retrajlardan çəkinin. Bir yer həqiqətdir - control plane.

Daha vacib olan: təhlükəsizlik və ya performans?
Default - təhlükəsizlik (mTLS, AuthZ). Performans connection pools, outlier detection, hədəf marşrutları ilə əldə edilir.

15) Nəticələr

Service Mesh, xidmətlər arasındakı şəbəkəni vahid siyasətlə proqramlaşdırıla bilən bir təbəqəyə çevirir: şifrələmə və şəxsiyyət, incə marşrutlaşdırma və sabitlik, telemetri və kvotalar. Kritik yollarla başlayın, STRICT mTLS və açıq AuthZ-ləri daxil edin, vaxtları/retrajları/SV-ləri təyin edin, egresi idarə edin, p99 və 5xx ölçün, oyun günlərini keçirin. Sonra mesh sürprizlərin mənbəyi deyil, etibarlılıq və buraxılış sürətinin gücləndiricisi olacaq.