Mesh de serviciu și politica de trafic

1) De ce Mesh de serviciu

• Securitate implicită: mTLS, emiterea automată/rotirea certificatelor, identități de serviciu.
• Politica de trafic: rutare L7, teste canar/AV, degradare și stabilitate.
• Observabilitate: valori, busteni, urme, semnale de aur la fiecare apel.
• Operațiuni: politici uniforme pentru toate limbile/cadrele.

Diferența față de gateway-ul API: gateway-ul - perimetrul nord-sud; plasă - est-vest în cadrul clusterului/organizației. De multe ori lucrează împreună.

2) Arhitectura: Planuri și modele

Data Plane: proxy sidecar (Envoy/Linkerd-proxy/haproxy), care interceptează traficul pod/VM.
Control Plane: distribuie configurații (rute, politici, certificate), stochează starea, publică unități de service.
Identitate: de obicei SPIFFE ID și certificate automate X.509 (SPIRE/built-in CA).
Puncte de intrare/ieşire: intrare/ieşire-gateway pentru a monitoriza fluxurile de limită.
Moduri de implementare: ataș pentru fiecare sub; per-node/ambient-moduri în noi implementări.

3) Politica de securitate și zero-încredere

1. mTLS în mod implicit - criptare servis↔servis și autentificare reciprocă.

• AuthN: încredere numai identități emise de CA mesh 'a (SPIFFE).
• AuthZ: declarativ „cine poate cui și cum” reguli (RBAC/ABAC).

3. Izolarea și controlul ieșirii:

• Domenii/subrețele permise; ieşire forţată prin poarta de ieşire.
• Blocarea rezultatelor directe din vatră.

4. Rotație secretă: certificate de scurtă durată, reconfigurare automată proxy.

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) Politica de trafic: persistență și rutare

4. 1 Intervale de timp şi retrageri

Timeouts: trebuie să fie setat pe apel (conectați/citiți/în ansamblu).
Retries: numai pentru operațiuni idempotente; backoff + jitter; limitele 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 и detectarea outlier

CB: restricționează cererile/conexiunile simultane, protejând amonte.
Outlier: aruncă instanțe „rele” prin eroare/latență.

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 Canare și de condiții

Ponderat - Traficul este împărțit la ponderi v1/v2.
Header-based: steaguri/cookie-uri/chiriaș → fi transferat la noua versiune.
Afinitate sesiune: hash cu cheie (scalate frumos).

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 Injectarea și degradarea defecțiunilor

Injecție de întârziere/eroare pentru testul de robustețe și SLO.

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

5) Limitele rețelei: intrare/ieșire și servicii externe

Intrare-gateway: singurul punct de intrare pentru clienții externi în plasă; integrarea cu WAF/OIDC/ratelimits.
Egress-gateway: ieșire centrală cu o listă de gazde permise, inspecție TLS, înregistrare telemetrie.
ServiceEntry: declară SNI extern/gazdă ca parte a mesh (se aplică politici și mTLS-originare).

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-rețea și hibrid

Domeniu partajat PKI/trust: identități unice SPIFFE între clustere.
Descoperirea punctului final: bile de serviciu între regiuni; prioritate locală și eșec.
Izolarea zonală: politici per-regionale, limite și priorități.
VM în plasă: conectarea sistemelor moștenite/Statful la proxy-uri și aceleași politici.

7) Observabilitate, SLO și funcționare

Метрики: 'requests _ total', 'request _ duration _ ms {p50, p95, p99}', '5xx _ rate', 'retry _ încercări', 'cb _ state', 'mTLS _ authz _ neged'.
Jurnale de acces: structurale, cu "traceparent", "utilizator/chiriaș", "response _ flags'.
Urmărire: auto-injectarea anteturilor (W3C Trace Context), prelevarea de probe, se întinde la nivelul hamei.
SLO: obiective cu p99/erori pe traseu (service→service).
Alerte: '5xx' spike, 'reset' rise, 'outlier _ ejections', mTLS degradare (eșecuri de strângere de mână).

8) Performanță și cost

• Graininess: include politica acolo unde este necesar; nu porniți filtre grele peste tot.
• Piscine: trasee împărțite (critice/de fundal) în diferite rute și limite.
• Profilare: p99 pe trasee „reci”, volum telemetric (busteni/trasee cu rate limită).
• Luați în considerare modurile ambientale/laterale dacă sunt acceptate și adecvate.

9) Siguranță și conformitate

Acces minim necesar: Permiteți în mod explicit instrucțiuni și metode.
Politici privind neimspaces/chiriași: limite de rețea/autorizare.
Rotație cheie/AC: planificată și de urgență; scurte certificate TTL.
PII/secrete: mascare in busteni/piste; criptare pe sârmă/în repaus.
Audit: cine, când și ce politică s-a schimbat; Cu două trepte.

10) Integrarea cu K8s strat

Politicile de plasă completează, nu înlocuiesc, NetworkPolicy.
În intrare/ieşire-gateway, puteţi atârna PodSecurity/PSA la un nivel de mai jos.
NRA/autoscaling: luați în considerare retraiele/CB-urile - acestea schimbă sarcina.
Planuri de lansare: greutăți canare prin VirtualService + promovare automată SLO.

11) Lista de verificare a implementării

• Limitele de încredere definite și STRICT mTLS activat.
• Politicile AuthZ au permis: cui, pe care porturi/metode.
• Timeouts/retries și detectarea outlier sunt configurate, căile idempotente sunt definite.
• Rutele canare și planul de rollback sunt înregistrate; injecție de eroare - numai în non-prod.
• Dependențele externe sunt derivate din gateway-ul de ieșire și ServiceEntry.
• Metrica, busteni, urme sunt configurate; tablouri de bord și alerte pe p99/5xx/CB.
• Cotele/limitele per chiriaș/namespace sunt disponibile.
• Cărți de alergare pregătite: scurgeri de certificate, eșec CA, degradare în amonte, 503/RESET în masă.
• Plan multi-cluster (PKI partajat, priorități locale, scenarii DR).
• Zile de testare (zile de joc): picătură plan de control, oprire ataș, pauză de rețea, otrăvitoare în amonte.

12) Anti-modele

Mesh „peste tot și la o dată”, fără inventar de traseu și SLO → complexitate costisitoare.
Retroactive implicite pentru toate metodele → duplicate de efect și avalanșe de trafic.
Un → mTLS cu handicap „temporar” rămâne permanent.
Ieșire fără gateway → scurgeri de date/dependențe neînregistrate.
O politică globală pentru toate serviciile → securitate falsă și fals pozitive.
Observabilitate zero: plasă inclusă, dar nu colectați metrici/trasee - pierdeți sensul.

13) Rețete rapide

Linkerd: activați mTLS și politica de server

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 intenție + 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) ÎNTREBĂRI FRECVENTE

Mesh are nevoie de o echipă mică?
Dacă 3-5 servicii - mai des nu. Începeți cu biblioteci bune de intrare și reziliență. Conectați fileul atunci când este nevoie de mTLS-default, politici uniforme și urmărire fără modificări de cod.

Cum de a controla costul?
Măsurați deasupra capului (CPU/RAM/latență) pe căile critice, dezactivați filtrele inutile, reduceți volumul de jurnale/trasee, utilizați moduri fără ataș în cazul în care este sigur.

Este posibil să interfereze cu plasă și proxy-uri configurate manual?
Da, dar evitați retraiele duble/duplicate. Un singur loc este adevărat - planul de control.

Ce este mai important: securitate sau performanță?
Implicit este de securitate (mTLS, AuthZ). Performanța se realizează prin tuning piscine de conexiune, detectare outlier, trasee țintă.

15) Totaluri

Service Mesh transformă rețeaua dintre servicii într-un strat programabil cu politici uniforme: criptare și identități, rutare fină și reziliență, telemetrie și cote. Începeți cu căi critice, activați STRICT mTLS și AuthZ explicit, setați timeout/retrays/CB, controlați ieșirea, măsurați p99 și 5xx, petreceți zile de joc. Apoi, ochiurilor de plasă va deveni un amplificator de fiabilitate și viteza de eliberări, și nu o sursă de surprize.