Siatka serwisowa: Istio, Linkerd

Siatka serwisowa: Istio, Linkerd

1) Czym jest siatka serwisowa i kiedy jest potrzebna

Usługa Siatka jest sieciową warstwą płaszczyzny danych/kontroli zapewniającą końcowe mTLS, routing, tolerancję błędów i obserwowalność między usługami bez przepisywania kodu.

• Zabezpieczenie domyślne (zero zaufania, tożsamość usługi, polityka dostępu).
• Zarządzanie ruchem (kanaryjski/niebiesko-zielony, A/B, cieniowanie).
• Niezawodność (retras, timeouts, breaking circuit).
• Obserwowalność (mierniki, kłody, szlaki).
• Normalizacja operacyjna (polityka jako kod, GitOps).

• Wiele mikroservices z wymogiem wielojęzyczności i mTLS.
• Potrzebujesz zaawansowanych scenariuszy routingu/eksperymentowania bez zmiany aplikacji.
• Na poziomie sieci istnieją wymogi dotyczące audytu/polityki.

2) Istio vs Linkerd - krótkie porównanie

3) Modele architektury i wdrażania

3. 1 Siatka boczna (klasyczna)

Każda z nich otrzymuje pełnomocnika.
Plusy: dojrzałość, pełna kontrola L7.
Minusy: CPU/RAM overhead, złożoność wyczerpania/debugowania.

3. 2 Siatka otoczenia Istio

ztunnel (L4) na węźle + proxies waypoint (L7) zgodnie z wymaganiami.
Plusy: niższy koszt i złożoność, stopniowe włączenie L7.
Minusy: Nowsze, nie wszystkie przypadki L7 są dostępne bez waypoint.

4) Identyfikacja i mTLS (zero-trust)

4. 1 SPIFFE/SPIRE i certyfikaty

Każdemu treningowi przypisano identyfikator SPIFFE: 'spiffe ://cluster. local/ns/NS/sa/SA '.
Uwierzytelnianie: wzajemne TLS między usługami.
Obrót klucza - automatycznie (krótki TTL).

4. 2 Istio (PeerAuthentication + Zasada)

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 - domyślnie mTLS

Włączony po 'linkerd install' + 'linkerd inject'.
Klastry - własna kotwica zaufania, automatyczna rotacja.

5) Zarządzanie ruchem

5. 1 Istio: wirtualny serwis (trasy, kanarki)

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: Profil i split

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) Bramki Ingress/Egress i API

Istio Gateway (ingress/egress) - kontroluje ruch przychodzący/wychodzący, zakończenie TLS, mTLS passthrough.
Linkerd współpracuje z istniejącymi kontrolerami wnikania (NGINX/Contour/Traefik); egress - poprzez Politykę/wyjście-brama-wzory.
Polityka Egress: whitelist domeny, polityka SNI, bezpośredni zakaz internetu.

7) Autoryzacja i polityka

7. 1 Polityka autoryzacji Istio (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 Zasady Linkerd (serwer + 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) Obserwowalność i telemetria

8. 1 Metryka

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 Szlaki i kłody

Push W3C kontekst śladowy.
Istio/Envoy → OTLP меровий Торомерскова; Linkerd - poprzez rejestratory boczne/aplikację SDK.

8. 3 Instancje

Dodaj ślad _ id do histogramów czasu trwania dla skakania do śladu.

9) Limity stawki, WAF, niestandardowe filtry

Istio: EnvoyFilter/WASM dla lokalnych limitów stawki, eksternal-rate-limit service (Redis), a także logika WAF (Lua/WASM).
Linkerd: ograniczone wsparcie natywne; limit stawki - na poziomie wlotu/bramy.

10) Multi-cluster

Istio: brama wschodnio-zachodnia, wspólna PKI lub pakiet zaufania, odkrycie usług za pośrednictwem Systemu Wjazdowego, Federacja.
Linkerd: 'linkerd multicluster link', gateway per cluster, service-mirror контролей.

Przypadki użycia: aktywa-regiony, lokalizacja ruchu, sfederowane zero zaufania.

11) Wydajność i koszt

Siatka boczna: CPU/RAM na podczerwień, zwiększona opóźnienie (zwykle + 1-3 ms na chmielu w stanie stacjonarnym).
Otoczenie (Istio): mniej zużycia dla L4, L7 jest włączony.
Linkerd: Lekki proxy jest na ogół mniej napowietrzny, ale mniej skrajne możliwości L7.
Praktyka: zmierzyć p95/CPU przed/po, przechowywać bramy SLO do degradacji.

12) Bezpieczeństwo

mTLS wszędzie, krótki TTL, automatyczny obrót.
Polityka jako kod (OPA/Gatekeeper, Kyverno) dla 'autoryzacjPolityka: ZEZWALAJ na wszystkie' wystawy.
Sekrety - przez CSI/Skarbiec, nie w manifestach.
Sterowanie Egress: odmowa domyślnie, wyraźne listy zezwoleń.
Oddzielne domeny zaufania dla środowisk (prod/stage).

13) Integracja z wersjami i gating SLO

Kanaryjski/niebiesko-zielony są wdrażane przez trasy siatki (patrz przykłady).
Analiza metryki (Prometheus/SpanMetrics) w Argo Rollouts Szablon - Autostopowicz/Rollback w tempie spalania/p95/5xx.
Adnotacje wydań w Grafanie: porównanie 'wersja = stabilna' kanarka '.

14) Anty-wzory

Dodaj siatkę „wszędzie i naraz” → szok infrastrukturalny.
Ignoruj kardynalność mierników/dzienników z serwera proxy → przeciążenie pamięci TSDB/log.
Pozostaw mTLS w trybie PERMISSIVE/nieprzezroczystym na zawsze.
Spróbuj stworzyć złożoną logikę WAF/business wewnątrz EnvoyFilter zamiast bramy/aplikacji.
Brak polityki wyjścia - wycieki z internetu/obwodnica zgodności.
Proxy z ': 15000' debug otwarte na zewnątrz.

15) Lista kontrolna realizacji (0-60 dni)

0-15 dni

Wybór modelu: Sidecar vs Ambient (Istio )/Linkerd według profilu obciążenia.
Włącz mTLS STRICT, podstawowe zasady autoryzacji dla 1-2 kluczowych usług.
Podstawowe trasy (timeout/retries), deski rozdzielcze RED/SLO.

16-30 dni

Kanaryjski/ Split, wykrywanie/łamanie obwodu na gorących torach.
Integracja OTEL: szlaki + przykłady; wskaźnik poparzeń alarmowych.
bramy i białe bramki domeny; odmówić domyślnie.

31-60 dni

Link multi-cluster (w razie potrzeby), zaufanie federacyjne.
Polityka jako Code на AuthorizationPolicy/ServerAuthorization.
Gra-day: symulacja incydentu i route/policy rollback.

16) Wskaźniki zapadalności

zasięg mTLS (STRICT/auto-rotate) ≥ 95% usług.
Udział ruchu kanaryjskiego/progresywnego uwalnia ≥ 80%.
Średnia wartość napowietrzna p95 <+ 5% wartości wyjściowej (po optymalizacji).
0 otwarte wyjście bez pozwolenia, 100% usługi z podstawowym AuthZ.
RCA „od harmonogramu do toru” ≤ 2 minuty (p50).

17) Przykłady „polityki jako kodu”

Bramkarz (zakaz PERMISSIVE in prod)

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 (wymagane etykiety dla 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) Wskazówki operacyjne

Zasady wersji i trasy (semver), promocja za pośrednictwem GitOps.
Obserwowalność proxy: indywidualne deski rozdzielcze „nasycenia proxy” (CPU/hałda, retries, 429/503).
Budżet kardynalności: etykiety „trasa”, „kod”, „miejsce przeznaczenia” - tylko szablon.
Limity sieci/kontyngenty obszaru nazw (Polityka/Zakres limitów).
Dokumentacja polecenia: książka startowa „Jak odwrócić trasy/zasady/klucze mTLS”.

19) Wniosek

Istio i Linkerd robią to samo - standaryzują bezpieczeństwo, niezawodność i widoczność komunikacji międzysystemowej - ale robią to na różnych głębokościach i kosztach własności.

Potrzebujesz bogatych możliwości L7 i elastycznych polityk - weź Istio (weź pod uwagę Ambient, aby zmniejszyć koszty ogólne).
Potrzebujesz prostoty i małych napowietrznych - weź Linkerd.

Niezależnie od wybranej siatki: Włącz mTLS domyślnie, zarządzaj routingiem jako kod, skojarzaj mierniki z utworami, zamknij egress i dodaj SLO gating do wersji. Następnie warstwa sieciowa przestanie być „czarną skrzynką” i stanie się przewidywalnym narzędziem stabilności i szybkości zmian.