Servis Ağı ve Trafik Politikası

1) Neden Servis Mesh

• Varsayılan güvenlik: mTLS, sertifikaların otomatik olarak verilmesi/döndürülmesi, hizmet kimlikleri.
• Trafik politikası: L7 yönlendirme, kanarya/AV testleri, bozulma ve istikrar.
• Gözlemlenebilirlik: metrikler, günlükler, izler, her aramada altın sinyaller.
• İşlemler: tüm diller/çerçeveler için tekdüze politikalar.

API ağ geçidinden farkı: ağ geçidi - kuzey-güney çevresi; örgü - küme/organizasyon içinde doğu-batı. Genellikle birlikte çalışırlar.

2) Mimari: Düzlemler ve Desenler

Veri Düzlemi: Pod/VM trafiğini kesen sidecar proxy (Envoy/Linkerd-proxy/haproxy).
Denetim Düzlemi: yapılandırmaları dağıtır (yollar, ilkeler, sertifikalar), durumu depolar, hizmet sürücülerini yayınlar.
Kimlik: Genellikle SPIFFE ID ve otomatik X.509 sertifikaları (SPIRE/yerleşik CA).
Giriş/çıkış noktaları: sınır akışlarını izlemek için giriş/çıkış-ağ geçidi.
Uygulama modları: her biri için sidecar; Yeni uygulamalarda per-node/ambient-modes.

3) Güvenlik politikası ve sıfır güven

1. Varsayılan olarak mTLS - servis↔servis şifreleme ve karşılıklı kimlik doğrulama.

• AuthN: Yalnızca CA mesh'a (SPIFFE) tarafından verilen güven kimlikleri.
• AuthZ: "Who can to whom and how" (RBAC/ABAC) kurallarını açıklar.

3. İzolasyon ve çıkış kontrolü:

• İzin verilen etki alanları/alt ağlar; Çıkış kapısı üzerinden zorla çıkış.
• Ocaklardan gelen doğrudan sonuçları engellemek.

4. Gizli rotasyon: kısa ömürlü sertifikalar, otomatik proxy yeniden yapılandırma.

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 politikası: sebat ve yönlendirme

4. 1 Zaman Aşımları ve Geri Çekilmeler

Zaman aşımları: çağrıda ayarlanmalıdır (bağlan/oku/genel olarak).
Yeniden çalışır: sadece idempotent işlemler için; backoff + jitter; Deneme başına zaman aşımını sınırlar.

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. Aykırı algılama и 2 Devre Kesici

CB: Eşzamanlı istekleri/bağlantıları kısıtlayarak yukarı akışı korur.
Aykırı: hata/gecikme ile "kötü" örnekleri atar.

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 ve koşullara göre

Ağırlıklı - Trafik v1/v2 ağırlıklarına bölünür.
Başlık tabanlı: bayraklar/çerezler/kiracı - yeni sürüme aktarılacak.
Oturum yakınlığı: anahtara göre karma (düzgün ölçeklenmiş).

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 Hata Enjeksiyonu ve Bozulması

Sağlamlık testi ve SLO için gecikme/hata enjeksiyonu.

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

5) Ağ sınırları: giriş/çıkış ve dış hizmetler

Giriş ağ geçidi: ağdaki dış istemciler için tek giriş noktası; WAF/OIDC/ratelimits ile entegrasyon.
Çıkış ağ geçidi: izin verilen ana bilgisayarların bir listesi ile merkezi çıkış, TLS denetimi, telemetri kaydı.
ServiceEntry: Harici SNI/host'u mesh'in bir parçası olarak bildirir (policies and mTLS-origination apply).

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) Çok kümeli, çok ağlı ve hibrit

Paylaşılan PKI/güven alanı: Kümeler arasında tek SPIFFE kimlikleri.
Uç nokta keşfi: bölgeler arasındaki servis topları; Yerel öncelik ve yük devretme.
Bölgesel izolasyon: bölgesel politikalar, sınırlar ve öncelikler.
Ağdaki VM: eski/Durumsal sistemleri proxy'lere ve aynı politikalara bağlamak.

7) Gözlemlenebilirlik, SLO ve çalışma

Метрики: 'requests _ total', 'request _ duration _ ms {p50, p95, p99}', '5xx _ rate', 'retry _ entry', 'cb _ state', 'mTLS _ authz _ denied'.
Erişim günlükleri: yapısal, 'traceparent', 'user/tenant', 'response _ flags'ile.
İzleme: Başlıkların otomatik enjeksiyonu (W3C Trace Context), örnekleme, atlama düzeyinde yayılma.
SLO: Rotadaki p99/hatalara göre hedefler (servis - servis).
Uyarılar: '5xx' spike, 'reset' rise, 'outlier _ ejections', mTLS degradation (handshake failures).

8) Performans ve maliyet

• Grenlilik: gerektiğinde siyaset dahil; Her yerde ağır filtreler açmayın.
• Havuzlar: Yolları (kritik/arka plan) farklı rotalara ve sınırlara böler.
• Profilleme: "Soğuk" rotalarda p99, telemetri hacmi (oran limitli günlükler/yollar).
• Destekleniyorsa ve uygunsa ortam/yanaksız modları göz önünde bulundurun.

9) Güvenlik ve uyumluluk

Minimum gerekli erişim: Yönlere ve yöntemlere açıkça izin verin.
Neimspaces/kiracılarla ilgili politikalar: ağ/yetkilendirme sınırları.
Anahtar rotasyon/AC: planlı ve acil durum; Kısa TTL sertifikaları.
PII/sırlar: günlüklerde/izlerde maskeleme; Telde/dinlenme yerinde şifreleme.
Denetim: kim, ne zaman ve hangi politika değişti; İki aşamalı kargaşa.

10) K8s katmanla entegrasyon

Mesh ilkeleri, NetworkPolicy'yi tamamlar, değiştirmez.
Giriş/çıkış ağ geçidinde, PodSecurity/PSA'yı aşağıdaki bir seviyede asabilirsiniz.
NRA/otomatik ölçekleme: retrays/CB'leri düşünün - yükü değiştirirler.
Sürüm planları: VirtualService + otomatik SLO promosyonu ile kanarya ağırlıkları.

11) Uygulama kontrol listesi

• Güven sınırları tanımlı ve STRICT mTLS etkin.
• AuthZ politikaları etkinleştirildi: kime kime, hangi bağlantı noktalarında/yöntemlerde.
• Zaman aşımları/yeniden denemeler ve aykırı değer algılama yapılandırılır, idempotent yollar tanımlanır.
• Kanarya yolları ve geri dönüş planı kayıtlıdır; Hata-enjeksiyon - sadece non-prod.
• Dış bağımlılıklar, çıkış ağ geçidi ve ServiceEntry aracılığıyla türetilir.
• Metrikler, günlükler, izler yapılandırılır; p99/5xx/CB panolar ve uyarılar.
• Kiracı/ad alanı başına kotalar/sınırlar mevcuttur.
• Hazırlanan çalışma kitapları: sertifika sızıntısı, CA hatası, yukarı yönlü bozulma, kütle 503/RESET.
• Çok kümeli plan (paylaşılan PKI, yerel öncelikler, DR senaryoları).
• Test günleri (oyun günleri): bırakma kontrol düzlemi, durdurma sidecar, ağ arası, zehirli yukarı akış.

12) Anti-desenler

Rota envanteri ve SLO olmadan'her yerde ve aynı anda "Mesh - pahalı karmaşıklık.
Tüm yöntemler için varsayılan yeniden denemeler - etki kopyaları ve trafik çığları.
Devre dışı bırakılmış bir mTLS "geçici olarak" kalıcı olarak kalır.
Gateway olmadan çıkış - veri sızıntısı/hesaplanmamış bağımlılıklar.
Tüm hizmetler için bir küresel politika - yanlış güvenlik ve yanlış pozitifler.
Sıfır gözlemlenebilirlik: dahil örgü, ancak metrikleri/izleri toplamaz - anlamını kaybeder.

13) Hızlı tarifler

Linkerd: sunucu tarafından mTLS ve ilkeyi etkinleştir

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"]

Konsolos (L7 niyet + ayırıcı)

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) SSS

Mesh'in küçük bir ekibe ihtiyacı var mı?
Eğer 3-5 hizmet - daha sık değil. İyi giriş ve esneklik kütüphaneleriyle başlayın. mTLS-varsayılan, tek tip ilkeler ve kod değişikliği olmadan izleme gerektiğinde kafesi bağlayın.

Maliyet nasıl kontrol edilir?
Kritik yollardaki yükü (CPU/RAM/gecikme) ölçün, gereksiz filtreleri kapatın, günlüklerin/izlerin hacmini azaltın, güvenli olduğu yerlerde kenar çubuğu olmadan modları kullanın.

Mesh ve manuel olarak yapılandırılmış proxy'lere müdahale etmek mümkün mü?
Evet, ama çift yönlendirme/yinelenen retrays kaçının. Tek bir yer doğrudur - kontrol düzlemi.

Hangisi daha önemli: güvenlik mi performans mı?
Varsayılan değer güvenliktir (mTLS, AuthZ). Performans, bağlantı havuzlarının ayarlanması, aykırı madde tespiti, hedef rotaları ile sağlanır.

15) Toplam

Service Mesh, servisler arasındaki ağı tek tip ilkelerle programlanabilir bir katmana dönüştürür: şifreleme ve kimlikler, ince yönlendirme ve esneklik, telemetri ve kotalar. Kritik yollarla başlayın, STRICT mTLS ve açık AuthZ'yi açın, zaman aşımları/geri çekilmeler/CB ayarlayın, kontrol çıkışı, p99 ve 5xx ölçün, oyun günlerini geçirin. Daha sonra mesh, bir sürpriz kaynağı değil, bir güvenilirlik ve sürüm hızı amplifikatörü haline gelecektir.