Servis Mesh: Istio, Linkerd

Servis Mesh: Istio, Linkerd

1) Service Mesh nedir ve ne zaman gereklidir

Service Mesh, uçtan uca mTLS, yönlendirme, hata toleransı ve kod yeniden yazılmadan hizmetler arasında gözlemlenebilirlik sağlayan bir ağ veri/kontrol düzlemi katmanıdır.

• Varsayılan güvenlik (sıfır güven, hizmet kimlikleri, erişim ilkesi).
• Trafik yönetimi (Kanarya/Mavi-Yeşil, A/B, gölgeleme).
• Güvenilirlik (retras, zaman aşımları, devre kesilmesi).
• Gözlemlenebilirlik (metrikler, günlükler, izler).
• Operasyonel standardizasyon (kod olarak politikalar, GitOps).

• Çok dillilik ve mTLS gereksinimi olan birçok mikro hizmet.
• Uygulamayı değiştirmeden gelişmiş yönlendirme/deneme senaryoları gerekir.
• Ağ düzeyinde denetim/politika gereksinimleri vardır.

2) Istio vs Linkerd - kısa bir karşılaştırma

3) Mimari ve dağıtım modelleri

3. 1 Sidecar mesh (klasik)

Her Pod bir proxy sidecar alır.
Artıları: olgunluk, tam L7 kontrolü.
Eksileri: CPU/RAM yükü, tükenme/hata ayıklamanın karmaşıklığı.

3. 2 Istio Ortam Mesh

Düğüm + yol noktası proxy'lerinde (L7) ztunnel (L4) gerektiği gibi.
Artıları: daha düşük maliyet ve karmaşıklık, L7 kademeli dahil.
Eksileri: Daha yeni, tüm L7 vakaları yol noktası olmadan mevcut değildir.

4) Kimlik ve mTLS (sıfır güven)

4. 1 SPIFFE/SPIRE ve sertifikalar

Her antrenmana bir SPIFFE kimliği atanır: 'spiffe ://cluster. Yerel/ns/NS/sa/SA '.
Kimlik doğrulama: Hizmetler arasında karşılıklı TLS.
Anahtar döndürme - otomatik olarak (kı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 varsayılan

'Linkerd install' + 'linkerd inject'den sonra etkinleştirildi.
Kümeler - kendi güven-çapa, otomatik dönüş.

5) Trafik yönetimi

5. 1 Istio: VirtualService (rotalar, kanaryalar)

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) Giriş/Çıkış ve API ağ geçitleri

Istio Ağ Geçidi (giriş/çıkış) - gelen/giden trafiği, TLS sonlandırmasını, mTLS geçişini kontrol eder.
Linkerd mevcut giriş denetleyicileri (NGINX/Contour/Traefik) ile çalışır; çıkış - NetworkPolicy/çıkış-gateway-patternleri üzerinden.
Çıkış politikaları: etki alanı beyaz listeleri, SNI politikası, doğrudan internet yasağı.

7) Yetkilendirme ve politika

7. 1 Istio Yetkilendirme Politikası (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 ilkesi (sunucu + sunucu yetkilendirmesi)

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) Gözlemlenebilirlik ve telemetri

8. 1 Metrikler

Istio Telemetri API - Prometheus: 'istio _ requests _ total', 'istio _ request _ duration _ milisaniye _ bucket', 'istio _ tcp _ received _ bytes _ total'.
Linkerd viz: 'request _ total', latency p50/p95/p99, 'success _ rate'.

8. 2 Yollar ve günlükler

W3C İzleme Bağlamını itin.
Istio/Elçi - OTLP в OpenTelemetry Collector; Linkerd - sidecar kaydediciler/uygulama SDK aracılığıyla.

8. 3 Örnek

İzleme-atlama için süre histogramlarına trace _ id ekleyin.

9) Oran sınırları, WAF, özel filtreler

Istio: Yerel fiyat limitleri için EnvoyFilter/WASM, ekstrernal-rate-limit hizmeti (Redis) ve WAF mantığı (Lua/WASM).
Linkerd: sınırlı yerel destek; hız sınırı - giriş/ağ geçidi seviyesinde.

10) Çoklu küme

Istio: doğu-batı ağ geçidi, paylaşılan PKI veya güven paketi, ServiceEntry, Federasyon aracılığıyla hizmet keşfi.
Linkerd: 'linkerd multicluster link', küme başına ağ geçidi, servis-ayna контроллер.

Kullanım durumları: varlık bölgeleri, trafik yerelleştirme, federasyon sıfır güven.

11) Performans ve maliyet

Sidecar mesh: Pod başına CPU/RAM yükü, artan gecikme süresi (genellikle sabit durumda atlama başına + 1-3 ms).
Ortam (Istio): L4 için daha az tüketim, L7 noktası açılır.
Linkerd: Hafif proxy genellikle daha az ek yük, ancak daha az aşırı L7 yetenekleri.
Uygulama: p95/CPU önce/sonra ölçün, SLO kapılarını bozulma için saklayın.

12) Güvenlik

mTLS her yerde, kısa TTL, otomatik dönüş.
Kod Olarak Politika (OPA/Gatekeeper, Kyverno) 'yetkilendirmePolitikası: HERKESE İZİN VER' koşulları için.
Sırlar - CSI/Vault aracılığıyla, manifestolarda değil.
Çıkış denetimi: varsayılan olarak reddet, açık izin listeleri.
Ortamlar için ayrı güven alanları (prod/stage).

13) Sürümler ve SLO gating ile entegrasyon

Kanarya/Mavi-Yeşil örgü yolları ile uygulanır (örneklere bakınız).
Argo Rollouts Analizinde Metrik Analizi (Prometheus/SpanMetrics )Şablon - Burn-rate/p95/5xx değerinde otostop/Rollback.
Grafana sürümlerinin ek açıklamaları: karşılaştırma 'sürüm = kararlı' kanarya '.

14) Anti-desenler

"Her yerde ve bir kerede" örgü ekleyin - altyapı şoku.
Proxy'den metriklerin/günlüklerin kardinalitesini göz ardı edin - TSDB/günlük depolama alanını aşırı yükleyin.
mTLS'yi sonsuza dek PERMISSIVE/opak modunda bırakın.
Ağ geçidi/uygulama yerine EnvoyFilter içinde karmaşık WAF/iş mantığı oluşturmaya çalışın.
Çıkış politikası yok - internet sızıntıları/uyumluluk bypass.
': 15000' hata ayıklayıcı içeren proxy'ler dışarıya açık.

15) Uygulama kontrol listesi (0-60 gün)

0-15 gün

Model seçimi: Sidecar vs Ambient (Istio )/Linkerd yük profiline göre.
1-2 kritik hizmet için mTLS STRICT, temel yetkilendirme ilkelerini etkinleştirin.
Temel yollar (zaman aşımı/yeniden denemeler), RED/SLO panoları.

16-30 gün

Canary/TrafficSplit, sıcak pistlerde aykırı algılama/devre kesme.
OTEL entegrasyonu: yollar + Örnekler; Uyarı yanma hızı.
Çıkış-ağ geçitleri ve etki alanı beyaz listeleri; Varsayılan olarak reddet.

31-60 gün

Çok kümeli bağlantı (gerekirse), federasyon güveni.
Kod Olarak İlke на AuthorizationPolicy/ServerAuthorization.
Oyun günü: olayın simülasyonu ve rota/politika geri dönüşü.

16) Olgunluk metrikleri

Hizmetlerin %95'ini mTLS (STRICT/otomatik döndürme) kapsamı ≥.
Kanarya/progresif salımlarla trafiğin payı %80 ≥.
Ortalama ek yük p95 <+ taban çizgisinin %5'i (optimizasyondan sonra).
0 izinsiz açık çıkış, temel AuthZ ile %100 hizmet.
RCA "programdan parçaya" ≤ 2 dakika (p50).

17) "Kod olarak politika" örnekleri

Gatekeeper (prod'da PERMISSIVE yasağı)

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 için gerekli etiketler)

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) Operasyonel ipuçları

Sürüm politikaları ve yolları (semver), GitOps aracılığıyla tanıtım.
Proxy gözlemlenebilirlik: bireysel "proxy doygunluğu" gösterge panoları (CPU/yığın, yeniden çalışır, 429/503).
Kardinalite bütçesi: etiketler 'rota', 'kod', 'hedef' - sadece şablon.
Ağ sınırları/ad alanı kotaları (NetworkPolicy/LimitRange).
Komut dokümantasyonu: runbook "mTLS routes/policy/keys nasıl geri alınır".

19) Sonuç

Istio ve Linkerd de aynı şeyi yapıyor - çapraz hizmet iletişiminin güvenliğini, güvenilirliğini ve görünürlüğünü standartlaştırıyor - ancak bunu farklı derinliklerde ve sahip olma maliyetinde yapıyor.

Zengin L7 özelliklerine ve esnek politikalara ihtiyacınız var - Istio'yu alın (ek yükü azaltmak için Ambient'i düşünün).
Basitliğe ve küçük ek yüke ihtiyacınız var - Linkerd'i alın.

Hangi kafesi seçerseniz seçin: Varsayılan olarak mTLS'yi etkinleştirin, yönlendirmeyi kod olarak yönetin, metrikleri parçalarla ilişkilendirin, çıkışı kapatın ve sürümlere SLO geçişi ekleyin. Daha sonra ağ katmanı'kara kutu "olmaktan çıkacak ve istikrar ve değişim hızı için öngörülebilir bir araç haline gelecektir.