Service Mesh: Istio, Linkerd

Service Mesh: Istio, Linkerd

1) Service Mesh дегеніміз не және ол қажет болғанда

Service Mesh - бұл mTLS, бағыттауды, істен шығуға төзімділікті және сервистер арасында кодты қайта жазусыз байқауды қамтамасыз ететін деректердің/басқарудың желілік жазықтығының қабаты.

• Әдепкі қауіпсіздік (zero-trust, сервистердің сәйкестігі, кіру саясаты).
• Трафикті басқару (Canary/Blue-Green, A/B, shadowing).
• Сенімділік (ретралар, таймауттар, circuit breaking).
• Бақылау (метрика, логия, трейстер).
• Операциялық стандарттау (GitOps коды ретіндегі саясат).

• Полилингвальды және mTLS талабы бар көптеген микросервистер.
• Бағдарламаны өзгертпей, озық бағыттау/эксперимент сценарийлері қажет.
• Желілік деңгейде аудит/саясат талаптары бар.

2) Istio vs Linkerd - қысқаша салыстыру

3) Сәулет және өрістету модельдері

3. 1 Sidecar mesh (классика)

Әрбір Pod прокси-сайдкарды алады.
Артықшылықтары: жетілу, толық L7-бақылау.
Кемшіліктері: CPU/RAM үстеме шығыстары, деплойлардың/жөндеудің күрделенуі.

3. 2 Istio Ambient Mesh

ztunnel (L4) + waypoint proxies (L7) торабында қажет болғанда.
Артықшылықтары: құны мен күрделілігі төмен, біртіндеп қосу L7.
Кемшіліктері: жаңа, барлық L7-кейстері waypoint-сіз қол жетімді емес.

4) Сәйкестігі және mTLS (zero-trust)

4. 1 SPIFFE/SPIRE және сертификаттар

Әрбір ворклоадқа SPIFFE ID: 'spiffe ://cluster беріледі. local/ns/NS/sa/SA`.
Аутентификация: қызметтер арасындағы өзара TLS.
Кілттерді ротациялау - автоматты түрде (қысқа TTL).

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 әдепкі

'linkerd install' + 'linkerd inject' дегеннен кейін қосылады.
Кластерлер - меншікті trust-anchor, ротация автоматты.

5) Трафик-менеджмент

5. 1 Istio: VirtualService (бағыттар, канарейка)

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 және API-шлюздер

Istio Gateway (ingress/egress) - кіріс/шығыс трафигін, TLS termination, mTLS passthrough басқарады.
Linkerd қолданыстағы ingress-контроллерлермен (NGINX/Contour/Traefik) жұмыс істейді; egress - NetworkPolicy/egress-gateway-паттерндер арқылы.
egress саясаты: домендердің ақ тізімдері, SNI-policy, тікелей интернетке тыйым салу.

7) Авторизация және саясат

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) Бақылау және телеметрия

8. 1 Өлшемдері

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 Трейдерлер мен логтар

W3C Trace Context бағдарламасын лақтырыңыз.
Istio/Envoy → OTLP в OpenTelemetry Collector; Linkerd - sidecar-логгер/апп-SDK арқылы.

8. 3 даналары (Exemplars)

jump-to-trace үшін 'trace _ id' дегенді ұзақтық гистограммаларына қосыңыз.

9) Rate limits, WAF, кастомдық сүзгілер

Istio: EnvoyFilter/WASM жергілікті rate limits, eksternal-rate-limit service (Redis), сондай-ақ WAF-логика (Lua/WASM) үшін.
Linkerd: шектеулі ұлттық қолдау; rate limit - ingress/шлюз деңгейінде.

10) Көп кластерлік

Istio: east-west gateway, жалпы PKI немесе trust-bundle, ServiceEntry, Federation арқылы сервис-дискавери.
Linkerd: `linkerd multicluster link`, gateway per cluster, service-mirror контроллер.

Use-cases: актив-актив өңірлер, трафикті оқшаулау, федералды zero-trust.

11) Өнімділік және құн

Sidecar mesh: әрбір Pod-қа CPU/RAM оверхед, ұлғайтылған латенттілік (әдетте steady-state-те hop-қа + 1-3 ms).
Ambient (Istio): L4, L7 үшін аз тұтыну нүктелі қосылады.
Linkerd: жеңіл салмақты прокси әдетте overhead аз, бірақ L7 экстремалды мүмкіндіктері аз.
Практика: p95/CPU дейін/кейін өлшеңіз, SLO-гейттерді тозуға ұстаңыз.

12) Қауіпсіздік

mTLS барлық жерде, қысқа TTL, автоматты ротация.
Тыйым салу үшін Policy as Code (OPA/Gatekeeper, Kyverno) 'authorizationPolicy: ALLOW all'.
Құпиялар - манифестте емес, CSI/Vault арқылы.
Egress-бақылау: deny-by-default, айқын allow-парақтар.
Орталар үшін жеке trust domains (prod/stage).

13) Релиздермен және SLO-гейтингпен интеграциялау

Canary/Blue-Green mesh маршруттарымен іске асырылады (мысалдарды қараңыз).
Метриктерді талдау (Prometheus/SpanMetrics) в Argo Rollouts AnalysisTemplate - burn-rate/p95/5xx кезінде автотұрақ/қайту.
Графанадағы релиздер аңдатпалары: 'version = stable' canary '.

14) Қарсы үлгілер

mesh қосу «барлық жерде және бірден» → шок инфрақұрылым.
Проксиден метриктер/логтардың түбегейлігін елемеу → TSDB/логқойманың жүктелімі.
mTLS-ті PERMISSIVE/opaque режимінде мәңгі қалдыру.
EnvoyFilter ішінде gateway/бағдарламасының орнына күрделі WAF/бизнес логикасын жасауға тырысыңыз.
Egress саясаты жоқ - Интернетке/комплаенсті тексеріп шығу.
с ': 15000' debug прокси сыртқа ашық.

15) Енгізу чек-парағы (0-60 күн)

0-15 күн

Модельді таңдау: Sidecar vs Ambient (Istio )/Linkerd жүктеме бейіні бойынша.
mTLS STRICT, 1-2 сындарлы сервистер үшін негізгі авторизация саясатын қосу.
Базалық бағыттар (timeout/retries), RED/SLO дашбордтары.

16-30 күн

Canary/TrafficSplit, outlier detection/circuit breaking ыстық жолдарда.
OTEL интеграциясы: трейдерлер + Exemplars; burn-rate алерті.
Egress-gateways және домендердің ақ тізімдері; deny-by-default.

31-60 күн

Көп кластерлі линк (егер қажет болса), federation trust.
Policy as Code на AuthorizationPolicy/ServerAuthorization.
Game-day: оқиғаны симуляциялау және бағыттарды/саясатты қайтару.

16) Жетілу метрикасы

mTLS (STRICT/auto-rotate) жабыны сервистердің 95% -ын ≥.
Канареялық/прогрессивтік релиздер арқылы трафиктің үлесі 80% ≥.
Орташа overhead p95 <+ базалық сызықтан 5% (оңтайландырылғаннан кейін).
0 рұқсатсыз ашық egress, базалық AuthZ бар 100% сервистер.
RCA «кестеден трассаға» ≤ 2 минут (p50).

17) «Саясат коды ретінде» мысалдары

Gatekeeper (өнімдегі 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 (VS/DR үшін міндетті labels)

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) Пайдалану кеңестері

GitOps арқылы насихатталатын саясат пен бағыттарды (semver) нұсқалаңыз.
Проксидің байқалуы: жеке дашбордтар «proxy saturation» (CPU/heap, retries, 429/503).
Түбегейлі бюджет: 'route', 'code', 'destination' белгілері - тек үлгілік.
Желілік лимиттер/namespace деңгейіне квоталар (NetworkPolicy/LimitRange).
Команданың құжаттамасы: runbook «mTLS бағыттарын/саясатын/кілттерін қалай сырғыту керек».

19) Қорытынды

Istio және Linkerd бір міндетті шешеді - сервистік коммуникациялардың қауіпсіздігін, сенімділігін және көрінуін стандарттау - бірақ оларды иеленудің тереңдігі мен құны әртүрлі.

Бай L7 мүмкіндіктері мен икемді саясаттары қажет - Istio-ны алыңыз (жүкқұжаттарды азайту үшін Ambient қараңыз).
Қарапайым және шағын overhead қажет - Linkerd алыңыз.

Қандай mesh таңдап алсаңыз да: әдепкі mTLS-ті қосыңыз, бағдарды код ретінде басқарыңыз, метриканы трейстермен байланыстырыңыз, egress-ті жауып, SLO-гейтингті релиздерге қосыңыз. Сонда желілік қабат «қара жәшік» болуын тоқтатады және өзгерістердің тұрақтылығы мен жылдамдығының болжамды құралына айналады.