Service Mesh және трафик саясаты

1) Service Mesh не үшін қажет

• Әдепкі қауіпсіздік: mTLS, сертификаттарды автоматты түрде беру/ауыстыру, сервистердің сәйкестігі.
• Трафик саясаты: L7 маршруттау, канареялық/АВ-тесттер, тозу және тұрақтылық.
• Бақылануы: метрика, логия, трассировка, әрбір шақырудағы алтын сигналдар.
• Операциялар: барлық тілдер/фреймворктер үшін бірыңғай саясат.

API-шлюзден айырмашылығы: шлюз - north-south периметрі; mesh - кластер/ұйым ішіндегі east-west. Жиі бірге жұмыс істейді.

2) Сәулет: жазықтықтар мен паттерндер

Data Plane: sidecar-прокси (Envoy/Linkerd-proxy/haproxy).
Control Plane: конфигурацияларды (бағыттарды, саясаттарды, сертификаттарды) бөледі, жай-күйін сақтайды, сервис-дискілерін жариялайды.
Identity: әдетте SPIFFE ID және автоматты X.509 сертификаттары (SPIRE/кіріктірілген CA).
Кіру/шығу нүктелері: шекара ағындарын бақылау үшін ingress/egress-gateway.
Енгізу режимдері: әрқайсысына sidecar; жаңа іске асырулардағы пер-тораптық/ambient-сән.

3) Қауіпсіздік саясаты және zero-trust

1. mTLS by default: шифрлау және өзара аутентификация сервисі - сервис.

• AuthN: CA mesh 'a (SPIFFE) берген сәйкестіктерге ғана сенеміз.
• AuthZ: декларативтік ережелер «кім кімге және қалай алады» (RBAC/ABAC).

3. Оқшаулау және egress-бақылау:

• Рұқсат етілген домендер/кіші желілер; egress-gateway арқылы мәжбүрлі шығу.
• Табаннан тікелей шығуларды бұғаттау.

4. Құпияларды ротациялау: қысқа мерзімдік сертификаттар, проксиді автоматты түрде қайта конфигурациялау.

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) Трафик саясаты: тұрақтылық және бағыттау

4. 1 Таймауттар мен ретрациялар

Timeouts: міндетті түрде шақыруға беріледі (connect/read/overall).
Retries: тек қана демпотенттік операциялар үшін; backoff + джиттер; 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 и outlier detection

CB: бір уақыттағы сұрауларды/қосылымдарды шектейді.
Outlier: қателер/жасырындылық бойынша «жаман» инстанцияларды лақтырады.

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 Канареялық және шарттар бойынша

Weighted: трафикті таразылар бойынша бөлу v1/v2.
Header-based: жалаушалар/cookie/tenant → жаңа нұсқасына аудару.
Session affinity: кілт бойынша хэш (масштабтауды ұқыпты түрде).

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 Fault Injection және тозу

Тұрақтылық тесті және SLO үшін кідірістер/қателер инъекциясы.

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

5) Желілік шекаралар: ingress/egress және сыртқы сервистер

Ingress-gateway: mesh сыртқы клиенттер үшін жалғыз кіру нүктесі; WAF/OIDC/ratelimits.
Egress-gateway: рұқсат етілген хосттар тізімі бар орталық шығу, TLS инспекциясы, телеметрия жазбасы.
ServiceEntry: mesh бөлігі ретінде сыртқы SNI/host жариялайды (саясаттар мен 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 және гибрид

Жалпы PKI/траст-домен: кластерлер арасындағы бірыңғай SPIFFE-сәйкестік.
Endpoint discovery: аймақтар арасындағы сервистік шарлар; жергілікті артықшылық және failover.
Аймақтық оқшаулау: пер-аймақтық саясат, лимиттер мен басымдықтар.
ВМ в mesh: legacy/Stateful жүйелерін прокси және сол саясаттарға қосу.

7) Бақылау, SLO және пайдалану

Метрики: `requests_total`, `request_duration_ms{p50,p95,p99}`, `5xx_rate`, `retry_attempts`, `cb_state`, `mTLS_authz_denied`.
Қатынасу логтары: құрылымдық, 'traceparent', 'user/tenant', 'response _ flags'.
Трейсинг: тақырыптарды авто-инъекциялау (W3C Trace Context), самплирлеу, hop-деңгейінде ұйықтау.
SLO: маршруттағы р99/қателер бойынша мақсаттар (service → service).
Алерталар: '5xx', 'reset', 'outlier _ ejections', mTLS (handshake failures) деградациясы.

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

• Түйіршіктілік: қажет болған жерде саясатты қосу; барлық жерде ауыр сүзгілерді қосуға болмайды.
• Пулдар: жолдарды (сындарлы/фондық) әртүрлі маршруттар мен лимиттерге бөлу.
• Профильдеу: p99 «суық» бағыттарда, телеметрия көлемі (rate-limit логтар/трейстер).
• ambient/sidecarless режимдерін қарау, егер қолдау көрсетілсе және талаптарға сай келсе.

9) Қауіпсіздік және комплаенс

Ең аз қажетті қолжетімділік: бағыттар мен әдістерді анық шешу.
Неймспейстер/тенанттар жөніндегі саясат: желілік/авторизациялық шекаралар.
Кілттердің/СА ротациясы: жоспарлы және авариялық; қысқа TTL сертификаттары.
PII/құпиялар: логтарда/трестерде бүркемелеу; сымда/тыныштықта шифрлау.
Аудит: кім, қашан және қандай саясатты өзгертті; екі кезеңді апрувалар.

10) K8s деңгейімен интеграциялау

Mesh саясаты NetworkPolicy емес, толықтырады.
ingress/egress-gateway бағдарламасында PodSecurity/PSA төмен деңгейде ілуге болады.
НРА/автоскейлинг: ретрацияны/СВ ескеріңіз - олар жүктемені өзгертеді.
Шығарылым жоспарлары: VirtualService арқылы канареялық салмақтар + SLO бойынша автоматты жылжыту.

11) Енгізу чек-парағы

• Сенім шегі анықталған және STRICT mTLS қосылған.
• AuthZ-саясаты қосылған: кім кімге, қандай порттарда/әдістерде.
• timeouts/retries және outlier detection бапталған, демпотенттік жолдар анықталған.
• Канареялық маршруттар мен rollback-жоспар жазылған; fault-injection - тек өнімсіз.
• egress-gateway және ServiceEntry арқылы сыртқы тәуелділіктер шығарылды.
• Метриктер, логтар, трассалар теңшелген; p99/5xx/CB дашбордтар мен алерталар.
• per-tenant/namespace квоталары/лимиттері көзделген.
• Runbooks дайындалды: сертификаттың жылыстауы, CA істен шығуы, апстримнің тозуы, жаппай 503/RESET.
• Multi-cluster жоспары (жалпы PKI, жергілікті басымдықтар, DR-сценарийлер).
• Сынақ күндері (game days): control plane құлауы, sidecar тоқтауы, желі үзілуі, «улы» апстрим.

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

Mesh «барлық жерде және бірден» маршруттарды түгендеусіз және SLO → қымбат күрделілік.
Барлық әдістер үшін әдепкі ретрайлер → дубль эффекттері және трафик көшкіні.
Ажыратылған mTLS «уақытша» → мәңгі қалады.
Шлюз жоқ Egress → деректердің жылыстауы/есепке алынбаған тәуелділіктер.
Барлық сервистер үшін бір жаһандық саясат → жалған қауіпсіздік және жалған іске қосулар.
Нөлдік observability: mesh қосылған, бірақ метриканы/трейдерді жинамаймыз - мағынасын жоғалтамыз.

13) Жылдам рецепттер

Linkerd: mTLS және policy серверге қосу

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

Шағын топқа mesh керек пе?
Егер 3-5 сервис болса - жиі болмайды. Жақсы ingress және тұрақтылық кітапханаларынан бастаңыз. mTLS әдепкі керек болғанда, кодты өзгертпей бірыңғай саясаттар мен трассировканы қосыңыз.

Құнын қалай бақылауға болады?
Қауіпті жолдарда жүкқұжаттарды (CPU/RAM/latency) өлшеңіз, артық сүзгілерді өшіріңіз, логтардың/трестердің көлемін азайтыңыз, қауіпсіз жерде sidecarсыз режимдерді пайдаланыңыз.

Mesh пен қолмен теңшелетін проксидерді араластыруға бола ма?
Иә, бірақ қосарлы/қайталанатын ретрансляциялардан аулақ болыңыз. Бір орын ақиқат - control plane.

Не маңызды: қауіпсіздік немесе өнімділік?
Әдепкі - қауіпсіздік (mTLS, AuthZ). Өнімділікке connection pools, outlier detection тюнингі, мақсатты бағыттар қол жеткізеді.

15) Қорытынды

Service Mesh сервистер арасындағы желіні бірыңғай саясаты бар бағдарламаланатын қабатқа айналдырады: шифрлау және сәйкестендіру, жіңішке бағыттау және тұрақтылық, телеметрия және квота. Сындарлы жолдардан бастаңыз, STRICT mTLS және айқын AuthZ қосыңыз, таймауттар/ретрациялар/СВ белгілеңіз, egress бақылаңыз, p99 және 5xx өлшеңіз, game days өткізіңіз. Сонда mesh сенімділік пен жылдамдықты күшейткіш болады.