Service Mesh: Istio, Linkerd

Service Mesh: Istio, Linkerd

1) Qu'est-ce que Service Mesh et quand il est nécessaire

Service Mesh est une couche de plan de données/contrôle réseau qui fournit un mTLS de bout en bout, le routage, la tolérance aux pannes et l'observation entre les services sans réécrire le code.

• Sécurité par défaut (zero-trust, identité des services, politique d'accès).
• Gestion du trafic (Canary/Blue-Green, A/B, shadowing).
• Fiabilité (retraits, délais, breaking circuit).
• Observabilité (métriques, logs, tracés).
• Normalisation opérationnelle (politiques en tant que code, GitOps).

• Beaucoup de microservices avec polylinguisme et exigence mTLS.
• Vous avez besoin de scripts de routage/expériences avancés sans modifier l'application.
• Il existe des exigences d'audit/règles au niveau du réseau.

2) Istio vs Linkerd - comparaison rapide

3) Architecture et modèles de déploiement

3. 1 mesh Sidecar (classique)

Chaque Pod reçoit un saydcar proxy.
Avantages : maturité, contrôle L7 complet.
Inconvénients : frais généraux CPU/RAM, complication des débogages/débogages.

3. 2 Istio Ambient Mesh

ztunnel (L4) sur le nœud + waypoint proxies (L7) par nécessité.
Avantages : coût et complexité inférieurs, incorporation progressive du L7.
Inconvénients : plus récents, pas tous les cas L7 sont disponibles sans waypoint.

4) Identité et mTLS (zero-trust)

4. 1 SPIFFE/SPIRE et certificats

Chaque workload se voit attribuer un SPIFFE ID : 'spiffe ://cluster. local/ns/NS/sa/SA`.
Authentification : réciproque TLS entre les services.
Rotation des clés - automatiquement (TTL court).

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 par défaut

Est activé après 'linkerd install' + 'linkerd inject'.
Les clusters sont leur propre trust-anchor, la rotation est automatique.

5) Gestion du trafic

5. 1 Istio : VirtualService (itinéraires, Canaries)

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 et API passerelles

Istio Gateway (ingress/egress) - Contrôle le trafic entrant/sortant, terminaison TLS, mTLS passthrough.
Linkerd travaille avec les contrôleurs ingress existants (NGINX/Contour/Traefik) ; egress - via les modèles NetworkPolicy/egress-gateway.
Politiques egress : listes blanches de domaines, politique SNI, interdiction de l'internet direct.

7) Autorisation et politique

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) Observation et télémétrie

8. 1 Métriques

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 Trajets et loges

Découvrez le W3C Trace Context.
Istio/Envoy → OTLP в OpenTelemetry Collector; Linkerd - via sidecar-loggers/app-SDK.

8. 3 instances (Exemplars)

Ajoutez 'trace _ id'aux histogrammes de durée pour' jump-to-trace '.

9) Limites de taux, WAF, filtres sur mesure

Istio : EnvoyFilter/WASM pour les limites de taux locales, le service eksternal-rate-limit (Redis), ainsi que la logique WAF (Lua/WASM).
Linkerd : support natif limité ; rate limit - au niveau ingress/passerelle.

10) Multicapacité

Istio : passerelle est-ouest, ICP générale ou trust-bundle, service-discovery via ServiceEntry, Federation.
Linkerd: `linkerd multicluster link`, gateway per cluster, service-mirror контроллер.

Use-cases : régions atout-atout, localisation du trafic, zero-trust fédéré.

11) Productivité et coût

Sidecar mesh : CPU/RAM sur chaque Pod, latence augmentée (typiquement + 1-3 ms par hop dans l'état steady).
Ambient (Istio) : moins de consommation pour L4, L7 s'allume ponctuellement.
Linkerd : le proxy léger est généralement moins overhead, mais moins les capacités extrêmes du L7.
Pratique : mesurer les p95/CPU avant/après, garder les gates SLO en état de dégradation.

12) Sécurité

mTLS partout, TTL court, rotation automatique.
Policy as Code (OPA/Gatekeeper, Kyverno) pour les interdictions « autorisationPolicy : ALLOW all ».
Secrets - via CSI/Vault, pas dans les manifestes.
Contrôle egress : deny-by-default, feuilles d'allow explicites.
Domaines de confiance distincts pour les environnements (prod/stage).

13) Intégration avec les versions et le jeu SLO

Canary/Blue-Green sont mis en œuvre par des itinéraires mesh (voir exemples).
Analyse des métriques (Prometheus/SpanMetrics) dans Argo Rollouts AnalysisTemplate - auto-stop/reculs sur burn-rate/p95/5xx.
Annotations de version dans Grafana : comparaison 'version = stable' canary '.

14) Anti-modèles

Activer mesh « partout et immédiatement » → le choc de l'infrastructure.
Ignorer la cardinalité des métriques/logs du proxy → la surcharge TSDB/Logging.
Laisser mTLS en mode PERMISSIVE/opaque pour toujours.
Essayez de faire une logique WAF/Business complexe à l'intérieur d'EnvoyFilter au lieu de gateway/application.
Pas de politique egress - fuites sur Internet/contournement de la conformité.
Le proxy avec ': 15000' debug est ouvert vers l'extérieur.

15) Chèque de mise en œuvre (0-60 jours)

0-15 jours

Sélection du modèle : Sidecar vs Ambient (Istio )/Linkerd par profil de charge.
Inclure mTLS STRICT, les politiques d'autorisation de base pour 1 à 2 services critiques.
Itinéraires de base (timeout/retries), dashboards RED/SLO.

16-30 jours

Canary/TraficSplit, outlier detection/circuit breaking sur les voies chaudes.
Intégration OTEL : Trails + Exemplars ; alerte burn-rate.
Egress-gateways et listes blanches de domaines ; deny-by-default.

31-60 jours

Link multi-plaques (si nécessaire), federation trust.
Policy as Code на AuthorizationPolicy/ServerAuthorization.
Game-day : simulation de l'incident et du retour des itinéraires/politiques.

16) Métriques de maturité

Couverture mTLS (STRICT/auto-rotate) ≥ 95 % des services.
La part du trafic dans les releases de canari/progressifs ≥ 80 %.
Overhead moyen p95 <+ 5 % de la ligne de base (après optimisation).
0 egress ouvert sans autorisation, 100 % des services avec AuthZ de base.
RCA « de l'horaire à la piste » ≤ 2 minutes (p50).

17) Exemples de « politiques en tant que code »

Gatekeeper (interdiction de la vente de PERMISSIVE)

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 (labels obligatoires pour VS/DR)

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) Conseils d'exploitation

Versez les politiques et les itinéraires (semver), promotionnez via GitOps.
Proxy Observability : dashboards individuels « proxy saturation » (CPU/heap, retries, 429/503).
Le budget кардинальности : les marques ' route ', ' code ', ' destination ' - seulement banal.
Limites réseau/quotas de niveau namespace (NetworkPolicy/LimitRange).
Documentation de la commande : runbook « Comment repasser les itinéraires/politiques/clés mTLS ».

19) Conclusion

Istio et Linkerd répondent à un défi : uniformiser la sécurité, la fiabilité et la visibilité des communications interservices, mais avec des profondeurs et des coûts de propriété différents.

Vous avez besoin de riches capacités L7 et de politiques flexibles - prenez Istio (considérez Ambient pour réduire les frais généraux).
Il faut de la simplicité et une petite overhead - prenez Linkerd.

Quel que soit le mesh que vous choisissez : activez le mTLS par défaut, gérez le routage en tant que code, liez les métriques aux trajets, fermez l'egress et ajoutez le SLO-gate aux versions. Ensuite, la couche réseau cessera d'être une « boîte noire » et deviendra un outil prévisible pour la stabilité et la vitesse des changements.