Кызмат Mesh жана трафик саясаты

1) Эмне үчүн Service Mesh керек

• демейки коопсуздук: mTLS, автоматтык күбөлүк берүү/айлануу, кызматтардын идентификациясы.
• Трафик саясаты: L7 багыттоо, канарейка/АВ тесттери, деградация жана туруктуулук.
• Байкоо: метрика, Логи, жол, ар бир чакыруу боюнча алтын сигналдар.
• Операциялар: бардык тилдер/фреймворктор үчүн бирдиктүү саясат.

API шлюзден айырмаланып: шлюз - түндүк-түштүк периметри; mesh - кластердин/уюмдун ичинде чыгыш-батыш. Көбүнчө чогуу иштешет.

2) Архитектура: тегиздиктер жана үлгүлөр

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

3) Коопсуздук саясаты жана zero-trust

1. mTLS by default: шифрлөө жана өз ара аутентификация кызматы.

• AuthN: CA mesh 'a (SPIFFE) тарабынан берилген инсандыкка гана ишенебиз.
• AuthZ: декларативдик эрежелер "ким кимге жана кантип алат" (RBAC/ABAC).

3. Изоляция жана egress-control:

• Уруксат берилген домендер/көмөкчордондор; 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 үчүн Injection кечигүү/ката.

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

5) тармактык чек: ingress/egress жана тышкы кызматтар

Ingress-gateway: сетка тышкы кардарлар үчүн жалгыз кирүү пункту; WAF/OIDC/ratelimits менен бириктирүү.
Egress-gateway: уруксат ээсинин тизмеси менен борбордук чыгуу, TLS текшерүү, телеметрия жазуу.
ServiceEntry: тордун бир бөлүгү катары тышкы 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-тармак жана гибрид

Жалпы PKI/ишеним домени: кластерлердин ортосундагы бирдиктүү SPIFFE идентификациялары.
Endpoint discovery: региондор ортосундагы кызмат шарлары; жергиликтүү артыкчылык жана failover.
Зоналык изоляция: per-аймактык саясат, лимиттер жана артыкчылыктар.
WM mesh: proxy жана ошол эле саясатчылар үчүн 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'.
Trace: Auto-Enjeksiyon аталыштары (W3C Trace Context), үлгү, hop-деъгээлинде уктап.
SLO: p99 максаттары/каттамдагы каталар (service → service).
Alerts: '5xx', өсүш 'reset', 'outlier _ ejections', mTLS деградациясы (handshake failures).

8) аткаруу жана наркы

• Бүртүкчөлүк: керек жерде саясатты киргизүү; бардык жерде оор чыпкаларды камтыбайт.
• Көлмөлөр: жолдорду (критикалык/фондук) ар кандай жолдорго жана лимиттерге бөлүү.
• Профилирование: p99 "муздак" каттамдарда, телеметриянын көлөмү (rate-limit логдор/трейстер).
• ambient/sidecarless режимдерин карап, колдоо жана талаптарга жооп берет.

9) Коопсуздук жана комплаенс

Минималдуу зарыл жеткиликтүүлүк: багыттарды жана ыкмаларды так чечүү.
Неймспейс/тенант саясаты: тармактык/авторизациялык чек.
Ачкычтарды айлантуу/СА: пландуу жана авариялык; кыска TTL күбөлүктөрү.
PII/Secrets: Logs/Tracks жашыруу; зымда/тынч шифрлөө.
Аудит: ким, качан жана кандай саясатты өзгөрттү; эки баскычтуу апрувалар.

10) K8s-деңгээл менен бириктирүү

Сетка саясаты NetworkPolicy ордуна эмес, толуктайт.
ingress/egress-gateway сиз төмөнкү PodSecurity/PSA деңгээл илип алат.
NRA/автоскейлинг: retrais/SV эске алуу - алар жүктү өзгөртөт.
Release пландары: 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-жагдайлар).
• Test-days (оюн күн): күзүндө control plane, stop sidecar, тармак үзүлүшү, "уулуу" агымы.

12) Анти-үлгүлөрү

Сетка "бардык жерде жана дароо" маршруттарын жана SLO жок кымбат татаалдыгы.
бардык ыкмалары үчүн демейки Retray → дубль таасирлери жана көчкү жол.
өчүрүлгөн mTLS "убактылуу" → түбөлүккө калат.
шлюз жок Egress → маалыматтардын агуусу/эсепке алынбаган көз карандылык.
Бардык кызматтар үчүн бир глобалдык саясат → жалган коопсуздук жана жалган ишке ашыруу.
Нөл observability: меш күйгүзүлгөн, бирок метрика/соода чогултуу эмес, - маанисин жоготуп.

13) Тез Recipes

Linkerd: Server боюнча mTLS жана саясат киргизүү

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

Чакан командага сетка керекпи?
Эгерде 3-5 кызмат - көп учурда жок. жакшы ingress жана туруктуу китепканалар менен башталат. mTLS демейки, бирдиктүү саясат жана кодду өзгөртпөстөн издөө зарылчылыгы пайда болгондо торду туташтырыңыз.

Кантип чыгымдарды көзөмөлдөө керек?
критикалык жолдор боюнча жүк өлчөө (CPU/RAM/latency), ашыкча чыпкаларды өчүрүү, жүктөрдү/соода көлөмүн азайтуу, коопсуз жерде sidecar режимдерин колдонуу.

Мен сетка жана кол менен орнотулган прокси кийлигишүүгө болобу?
Ооба, бирок кош багыттоо/кайталап retrains качуу. Бир жер чындык - control plane.

Эмне маанилүү: коопсуздук же аткаруу?
демейки - коопсуздук (mTLS, AuthZ). Performance tuning connection pools, outlier detection, максаттуу жолдор менен жетишилет.

15) натыйжалары

Service Mesh бирдиктүү саясат менен программалануучу катмарга кызматтардын ортосундагы тармакты айлантат: коддоо жана идентификация, жука багыттоо жана туруктуулук, телеметрия жана квота. критикалык жолдор менен баштоо, STRICT mTLS жана ачык AuthZ кирет, убакыт/retraights/SV, egress көзөмөлдөө, p99 жана 5xx өлчөө, оюн күн өткөрөт. Ошондо Mesh ишенимдүүлүгүн күчөтүү жана бошотуу ылдамдыгы болуп калат, күтүлбөгөн булагы эмес.