Siatka serwisowa i polityka ruchu

1) Dlaczego usługa siatki

• Domyślne zabezpieczenie: mTLS, automatyczna emisja/rotacja certyfikatów, identyfikacja usługi.
• Polityka ruchu: routing L7, testy kanaryjskie/AV, degradacja i stabilność.
• Obserwowalność: metryki, kłody, ślady, złote sygnały na każdym wezwaniu.
• Operacje: jednolite zasady dla wszystkich języków/ram.

Różnica od bramy API: brama - obwód północno-południowy; oczka - wschód-zachód w obrębie klastra/organizacji. Często pracują razem.

2) Architektura: samoloty i wzory

Płaszczyzna danych: sidecar proxy (Envoy/Linkerd-proxy/haproxy), który przechwytuje ruch pod/VM.
Control Plane: dystrybuuje konfiguracje (trasy, zasady, certyfikaty), przechowuje status, publikuje dyski serwisowe.
Tożsamość: zazwyczaj identyfikator SPIFFE i automatyczne certyfikaty X.509 (SPIRE/wbudowane CA).
Punkty wejścia/wyjścia: wejście/wyjście-brama w celu monitorowania przepływów granicznych.
Tryby realizacji: boczny ekr dla każdego z nich; tryby na węzeł/otoczenie w nowych implementacjach.

3) Polityka bezpieczeństwa i zero zaufania

1. mTLS domyślnie - serwo, szyfrowanie i wzajemne uwierzytelnianie.

• AuthN: tylko tożsamość zaufania wydana przez CA mesh'a (SPIFFE).
• AuthZ: deklaratywny „kto może komu i jak” (RBAC/ABAC).

3. Kontrola izolacji i wylotu:

• Dozwolone domeny/podsieci; przymusowe wyjście przez bramę.
• Blokowanie bezpośrednich wyników z serc.

4. Tajna rotacja: certyfikaty krótkotrwałe, automatyczna rekonfiguracja serwera 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) Polityka ruchu: trwałość i routing

4. 1 Terminy i rekolekcje

Terminy: należy ustawić na wywołaniu (podłączyć/przeczytać/ogólnie).
Ponowne próby: tylko w przypadku operacji idempotentnych; backoff + jitter; limity czasu na próbę.

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 Wykrywanie wyłącznika obwodu

CB: ogranicza jednoczesne żądania/połączenia, chroniąc górny strumień.
Outlier: wyrzuca „złe” przypadki przez błąd/opóźnienie.

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 Kanaryjskie i według warunków

Ważony - Ruch jest podzielony przez wagi v1/v2.
Na podstawie nagłówka: flagi/ciasteczka/najemca → być przeniesione do nowej wersji.
Powinowactwo sesji: hash by key (starannie skalowane).

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 Wtrysk usterki i degradacja

Opóźnienie/błąd wtrysku do testu odporności i SLO.

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

5) Granice sieci: wejście/wyjście i usługi zewnętrzne

Ingress-gateway: jedyny punkt wejścia dla zewnętrznych klientów w siatce; integracja z WAF/OIDC/ratelimitami.
Egress-gateway: centralne wyjście z listą dozwolonych hostów, inspekcja TLS, rekord telemetrii.
Wjazd: deklaruje zewnętrzny SNI/host jako część siatki (obowiązują zasady i mTLS-origination).

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-network i hybrid

Wspólna domena PKI/trust: pojedyncze tożsamości SPIFFE pomiędzy klastrami.
Odkrycie punktu końcowego: kulki serwisowe między regionami; priorytet lokalny i awaria.
Izolacja strefowa: polityka regionalna, limity i priorytety.
VM in mesh: połączenie systemów spuścizny/Statious z serwerami proxy i tymi samymi politykami.

7) Obserwowalność, SLO i działanie

Метрика: 'requests _ total', 'request _ duration _ ms {p50, p95, p99}', '5xx _ rate', 'retry _ attempts', 'cb _ state', 'mTLS _ authz _ denied'.
Dzienniki dostępu: strukturalne, z 'traceparent',' użytkownik/najemca ',' response _ flags'.
Śledzenie: automatyczne wtryskiwanie nagłówków (W3C Trace Context), pobieranie próbek, przęsła na poziomie chmielu.
SLO: cele według p99/błędy na trasie (usługa → usługa).
Wpisy: '5xx' spike, 'reset' rise, 'outlier _ ejections', mTLS degradacja (uścisk dłoni).

8) Wydajność i koszt

• Ziarno: w razie potrzeby uwzględniać politykę; nie włączaj wszędzie ciężkich filtrów.
• Baseny: podzielić ścieżki (krytyczne/tło) na różne trasy i granice.
• Profilowanie: p99 na „zimnych” trasach, objętość telemetrii (dzienniki/trasy limitu prędkości).
• Należy rozważyć tryby otoczenia/bezstronne, jeśli są obsługiwane i odpowiednie.

9) Bezpieczeństwo i zgodność

Minimalny wymagany dostęp: Wyraźnie zezwalaj na kierunki i metody.
Zasady dotyczące neimspaces/najemców: granice sieci/autoryzacji.
Rotacja klucza/prądu przemiennego: planowane i awaryjne; krótkie certyfikaty TTL.
PII/tajemnice: maskowanie w logach/torach; szyfrowanie na drucie/w spoczynku.
Audyt: kto, kiedy i co zmieniła się polityka; dwustopniowe zaprzęgi.

10) Integracja z warstwą K8s

Polityka siatki stanowi uzupełnienie, a nie jej zastąpienie.
W ingress/egress-gateway, można powiesić PodSecurity/PSA na poziomie poniżej.
NRA/autoskalowanie: rozważyć retray/BC - zmieniają obciążenie.
Plany wydania: wagi kanaryjskie za pośrednictwem VirtاService + automatyczna promocja SLO.

11) Lista kontrolna wdrażania

• Zdefiniowane granice zaufania i włączone STRICT mTLS.
• Polityka AuthZ umożliwiła: komu, na jakich portach/metodach.
• Czasowe/ponowne próby i wykrywanie zewnętrzne są konfigurowane, definiowane są ścieżki idempotentne.
• Trasy kanaryjskie i plan wycofania są rejestrowane; wtrysk uszkodzenia - tylko w nie-prod.
• Zależność zewnętrzna wynika z bramy wyjściowej i wjazdu.
• Mierniki, kłody, ślady są skonfigurowane; deski rozdzielcze i wpisy na p99/5xx/CB.
• Dostępne są kontyngenty/limity na najemcę/obszar nazw.
• Przygotowane książeczki startowe: wyciek certyfikatu, awaria CA, degradacja w górnym biegu, 503/RESET masy.
• Plan wielomianowy (wspólny PKI, priorytety lokalne, scenariusze DR).
• Dni testowe (dni gry): drop control plane, stop sidecar, break network, trujący upstream.

12) Anty-wzory

Siatka „wszędzie i jednocześnie” bez inwentaryzacji trasy i SLO → kosztowna złożoność.
Domyślne przekładki dla wszystkich metod → efekty duplikaty i lawiny ruchu.
Wyłączony mTLS „tymczasowo” → pozostaje na stałe.
Egress bez bramy → wyciek danych/nieznane zależności.
Jedna globalna polityka dla wszystkich usług → fałszywe bezpieczeństwo i fałszywe pozytywy.
Zero obserwowalność: zawarte oczka, ale nie zbierać mierniki/szlaki - stracić znaczenie.

13) Szybkie przepisy kulinarne

Linkerd: włącz mTLS i zasady według serwera

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

Konsul (L7 intent + 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) FAQ

Czy siatka potrzebuje małej drużyny?
Jeśli 3-5 usług - częściej nie. Zacznij od dobrych bibliotek wnikania i odporności. Podłącz siatkę, gdy istnieje potrzeba domyślnego mTLS, jednolitych zasad i śledzenia bez zmian kodu.

Jak kontrolować koszt?
Zmierzyć napowietrzne (CPU/RAM/latency) na ścieżkach krytycznych, wyłączyć zbędne filtry, zmniejszyć objętość kłód/ścieżek, używać trybów bez bocznego ekranu, gdzie jest bezpieczny.

Czy można ingerować w siatkę i ręcznie skonfigurowane serwery proxy?
Tak, ale unikaj podwójnego routingu/duplikatu retras. Jedno miejsce jest prawdziwe - samolot sterujący.

Co jest ważniejsze: bezpieczeństwo lub wydajność?
Domyślnym jest zabezpieczenie (mTLS, AuthZ). Wydajność osiąga się poprzez dostrajanie puli połączeń, wykrywanie zewnętrzne, trasy docelowe.

15) Kwoty całkowite

Usługa Mesh przekształca sieć między usługami w warstwę programowalną o jednolitej polityce: szyfrowanie i tożsamość, drobne routing i odporność, telemetria i kwoty. Zacznij od ścieżek krytycznych, włącz STRICT mTLS i explicit AuthZ, ustawić czasowe/retrays/CB, kontrolować egress, mierzyć p99 i 5xx, spędzić dni gry. Wtedy siatka stanie się wzmacniaczem niezawodności i szybkości wydań, a nie źródłem niespodzianek.