Service Mesh: Istio, Linkerd

Service Mesh: Istio, Linkerd

1) Xidmət Mesh nədir və lazım olduqda

Service Mesh - kodu yenidən yazmadan xidmətlər arasında keçid mTLS, marşrutlaşdırma, nasazlıq və müşahidə təmin edən şəbəkə məlumat/idarəetmə müstəvisi təbəqəsidir.

• Standart təhlükəsizlik (zero-trust, xidmət kimliyi, giriş siyasəti).
• Trafik nəzarəti (Canary/Blue-Green, A/B, shadowing).
• Etibarlılıq (retras, taymaut, circuit breaking).
• Müşahidə (metriklər, loqlar, treyslər).
• Əməliyyat standartlaşdırma (kod kimi siyasət, GitOps).

• Polilinqvallıq və mTLS tələbi ilə bir çox mikroservis.
• Tətbiqi dəyişdirmədən qabaqcıl marşrut/təcrübə ssenariləri lazımdır.
• Şəbəkə səviyyəsində audit/siyasət tələbləri var.

2) Istio vs Linkerd - qısa müqayisə

3) Memarlıq və yerləşdirmə modelləri

3. 1 Sidecar mesh (klassik)

Hər Pod proxy-saidcar alır.
Üstünlüklər: yetkinlik, tam L7-nəzarət.
Mənfi cəhətləri: CPU/RAM, deploes/hata ayıklama.

3. 2 Istio Ambient Mesh

ztunnel (L4) node + waypoint proxies (L7) lazım.
Üstünlüklər: aşağı qiymət və mürəkkəblik, L7 tədricən daxil.
Mənfi cəhətləri: yeni, bütün L7-cases waypoint olmadan mövcuddur.

4) Kimlik və mTLS (zero-trust)

4. 1 SPIFFE/SPIRE və Sertifikatlar

Hər bir workload SPIFFE ID verilir: 'spiffe ://cluster. local/ns/NS/sa/SA`.
Autentifikasiya: xidmətlər arasında qarşılıqlı TLS.
Açarların rotasiyası - avtomatik (qısa 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 default

'linkerd install' + 'linkerd inject' sonra aktivləşdirilir.
Klasterlər - öz trust-anchor, rotasiya avtomatik.

5) Trafik menecmenti

5. 1 Istio: VirtualService (marşrutlar, 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 və API şlüzləri

Istio Gateway (ingress/egress) - giriş/çıxış trafikini, TLS termination, mTLS passthrough idarə edir.
Linkerd mövcud ingress-controller (NGINX/Contour/Traefik) ilə işləyir; egress - NetworkPolicy/egress-gateway-patternlər vasitəsilə.
Egress siyasətləri: ağ domen siyahıları, SNI-policy, birbaşa internet qadağası.

7) Avtorizasiya və siyasət

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) Müşahidə və 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 və Logs

W3C Trace Context atın.
Istio/Envoy → OTLP в OpenTelemetry Collector; Linkerd - sidecar-loqgerlər/app-SDK vasitəsilə.

8. 3 nüsxələr (Exemplars)

«Jump-to-trace» üçün uzunluq histoqramlarına 'trace _ id' əlavə edin.

9) Rate limits, WAF, xüsusi filtrlər

Istio: EnvoyFilter/WASM üçün lokal rate limits, eksternal-rate-limit service (Redis), həmçinin WAF-məntiq (Lua/WASM).
Linkerd: məhdud yerli dəstək; rate limit - ingress/şlüz səviyyəsində.

10) Çoxklasterlik

Istio: east-west gateway, ümumi PKI və ya trust-bundle, ServiceEntry, Federation vasitəsilə xidmət discovery.
Linkerd: `linkerd multicluster link`, gateway per cluster, service-mirror контроллер.

Use-cases: aktiv-aktiv regionlar, trafikin lokallaşdırılması, federal sıfır-trust.

11) Performans və dəyəri

Sidecar mesh: hər Pod-da CPU/RAM overhed, artan gecikmə (adətən steady-state-də hop-da + 1-3 ms).
Ambient (Istio): L4 üçün daha az istehlak, L7 nöqtə ilə açılır.
Linkerd: yüngül proxy adətən daha az overhead, lakin daha az ekstremal L7 imkanları.
Təcrübə: əvvəl/sonra p95/CPU ölçün, deqradasiya üçün SLO geytaları saxlayın.

12) Təhlükəsizlik

mTLS hər yerdə, qısa TTL, avtomatik rotasiya.
Policy as Code (OPA/Gatekeeper, Kyverno) qadağalar üçün 'authorizationPolicy: ALLOW all'.
Sirlər - CSI/Vault vasitəsilə, manifestlərdə deyil.
Egress-control: deny-by-default, aydın allow-vərəqlər.
Ətraf mühit üçün ayrı-ayrı trust domains (prod/stage).

13) Relizlər və SLO Gating ilə inteqrasiya

Canary/Blue-Green mesh marşrutları ilə həyata keçirilir (nümunələrə baxın).
Argo Rollouts AnalysisTemplate-da metriklərin təhlili (Prometheus/SpanMetrics) - burn-rate/p95/5xx-də avtomatik stop/geri dönüş.
Qrafana-da buraxılış şərhləri: müqayisə 'version = stable' canary '.

14) Anti-nümunələr

mesh «hər yerdə və dərhal» → şok infrastruktur.
proxy → həddindən artıq TSDB/log-dən metrik/log kardinallığına məhəl qoymayın.
mTLS-i PERMISSIVE/opaque rejimində əbədi buraxın.
gateway/app əvəzinə EnvoyFilter daxilində mürəkkəb WAF/biznes məntiqi etməyə çalışın.
Heç bir egress siyasəti - internetə sızma/komplayens aşma.
s 'proxy: 15000' debug açıq.

15) Giriş çek siyahısı (0-60 gün)

0-15 gün

Model seçimi: Sidecar vs Ambient (Istio )/Linkerd yükləmə profili.
1-2 kritik xidmətlər üçün mTLS STRICT, əsas avtorizasiya siyasətlərini daxil edin.
Əsas marşrutlar (timeout/retries), RED/SLO daşbordları.

16-30 gün

Canary/TrafficSplit, isti yollarda outlier detection/circuit breaking.
OTEL inteqrasiya: treys + Exemplars; burn-rate alertləri.
Egress-gateways və ağ domen siyahıları; deny-by-default.

31-60 gün

Çoxklasterli link (lazım olduqda), federation trust.
Policy as Code на AuthorizationPolicy/ServerAuthorization.
Game-day: hadisənin simulyasiyası və marşrutların/siyasətlərin geri qaytarılması.

16) Yetkinlik metrikası

mTLS-in əhatə dairəsi (STRICT/auto-rotate) xidmətlərin 95% -ni ≥.
Kanarya/proqressiv relizlər vasitəsilə trafik payı ≥ 80%.
Orta overhead p95 <+ 5% baza xətti (optimallaşdırdıqdan sonra).
0 icazəsiz açıq egress, baza AuthZ ilə 100% xidmətlər.
RCA «qrafikdən trasa» ≤ 2 dəqiqə (p50).

17) «kod kimi siyasət» nümunələri

Gatekeeper (məhsulda PERMISSIVE qadağası)

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 üçün məcburi 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) Əməliyyat şuraları

Siyasətləri və marşrutları versiya edin (semver), GitOps vasitəsilə promosyon.
Proxy müşahidə: ayrı-ayrı daşbordlar «proxy saturation» (CPU/heap, retries, 429/503).
Büdcə kardinallığı: 'route', 'code', 'destination' işarələri yalnız şablonlardır.
namespace (NetworkPolicy/LimitRange) səviyyəsinə şəbəkə limitləri/kvotalar.
Komanda sənədləşdirilməsi: runbook «mTLS marşrutları/siyasət/açarları geri necə».

19) Nəticə

Istio və Linkerd bir problemi həll edir - xidmətlərarası kommunikasiyaların təhlükəsizliyini, etibarlılığını və görünüşünü standartlaşdırmaq - lakin bunu müxtəlif dərinlik və sahib olma dəyəri ilə edirlər.

Zəngin L7 imkanları və çevik siyasətlərə ehtiyacınız var - Istio-nu götürün (yükləri azaltmaq üçün Ambient-i nəzərdən keçirin).
Sadəlik və kiçik overhead lazımdır - Linkerd götürün.

Hansı mesh seçdiyinizdən asılı olmayaraq: mTLS-i default olaraq açın, marşrutu kod kimi idarə edin, metrləri treyslərlə əlaqələndirin, egresi bağlayın və buraxılışlara SLO geytinq əlavə edin. Sonra şəbəkə təbəqəsi «qara qutu» olmağı dayandıracaq və sabitlik və dəyişmə sürətinin proqnozlaşdırıla bilən alətinə çevriləcəkdir.