Service Mesh: Istio, Linkerd

Service Mesh: Istio, Linkerd

1) Кызмат Mesh деген эмне жана ал керек болгондо

Service Mesh - бул mTLS, багыттоо, бузулууга туруштук берүү жана кодду кайра жазуусуз кызматтардын ортосунда байкоо жүргүзүүнү камсыз кылган тармактык маалымат/башкаруу тегиздигинин катмары.

• демейки коопсуздук (zero-trust, кызматтардын идентификациясы, кирүү саясаты).
• Трафикти башкаруу (Canary/Blue-Green, A/B, shadowing).
• Ишенимдүүлүк (retrailer, таймауттар, circuit breaking).
• Байкалуучулук (метрика, логи, трейс).
• Операциялык стандартташтыруу (код катары саясат, GitOps).

• Көп билүү жана mTLS талабы менен микросервистер көп.
• Биз колдонмону өзгөртүүсүз өнүккөн багыттоо/эксперимент сценарийлерин керек.
• тармактык денгээлде аудит/саясат талаптары бар.

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

3) Архитектура жана жайгаштыруу моделдери

3. 1 Sidecar сетка (классикалык)

Ар бир 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) Traffic башкаруу

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-саясат, түздөн-түз интернет тыюу салуу.

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 аркылуу кызмат Discovery, 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.
Practice: чейин/кийин p95/CPU өлчөө, SLO гейтс деградация үчүн сактап.

12) Коопсуздук

mTLS бардык жерде, кыска TTL, автоматтык айлануу.
Policy as Code (OPA/Gatekeeper, Kyverno) тыюу салуу үчүн 'authorizationPolicy: ALLOW all'.
Сырлар - CSI/Vault аркылуу, манифесттерде эмес.
Egress-Control: deny-by-default, так allow-барактар.
Айлана-чөйрө үчүн өзүнчө trust domains (prod/stage).

13) релиздер жана SLO-Gating менен бириктирүү

Canary/Blue-Green тор жолдору менен ишке ашырылат (кара мисалдар).
Метрикалык талдоо (Prometheus/SpanMetrics) боюнча Argo Rollouts AnalysisTemplate - burn-rate/p95/5xx боюнча автостоп/артка кетүү.
Графанадагы релиздердин түшүндүрмөлөрү: салыштыруу 'version = stable' canary '.

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

"Бардык жерде жана дароо" сетка кирет → инфраструктура шок.
Proxy → TSDB/Log сактагычтан метриктер/логдордун кардиналдуулугун четке кагуу.
mTLS PERMISSIVE/opaque режиминде түбөлүккө калтыруу.
gateway/колдонмо ордуна EnvoyFilter ичинде татаал WAF/бизнес-логика кылууга аракет.
egress саясаты жок - Интернетте агып/комплаенс айланып.
менен Proxy ': 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.
HOTEL Integration: соода + Exemplars; alerty burn-rate.
Egress-gateways жана ак домен тизмелери; deny-by-default.

31-60 күн

Көп кластердик линк (керек болсо), федерация trust.
Policy as Code на AuthorizationPolicy/ServerAuthorization.
Game-day: окуя Simulation жана маршруттар/саясат кайра.

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

mTLS (STRICT/auto-rotate) ≥ 95% кызмат.
Канар/прогрессивдүү релиздер аркылуу трафиктин үлүшү 80% ≥.
Орточо overhead p95 <+ 5% базалык сызык (оптималдаштыруу кийин).
0 уруксатсыз ачык egress, 100% базалык AuthZ менен кызматтар.
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 алып.

Кандай гана тор тандап албаңыз: mTLSди демейки түрдө күйгүзүңүз, багыттоону код катары башкарыңыз, метриканы трейстерге байланыштырыңыз, egress 'ти жабыңыз жана релиздерге SLO-гейтинг кошуңуз. Анда тармак катмары мындан ары "кара куту" болуп калат жана туруктуулуктун жана өзгөрүүлөрдүн ылдамдыгынын болжолдуу куралы болуп калат.