सेवा मेश: इस्तियो, लिंकर्ड

सेवा मेश: इस्तियो, लिंकर्ड

1) सेवा जाल क्या है और इसकी कब जरूरत है

सर्विस मेश एक नेटवर्क डेटा/कंट्रोल प्लेन लेयर है जो एंड-टू-एंड एमटीएलएस, रूटिंग, फॉल्ट टॉलरेंस और कोड रीराइटिंग के बिना सेवाओं के बीच अवलोकन प्रदान करता है।

• डिफ़ॉल्ट सुरक्षा (शून्य-विश्वास, सेवा पहचान, पहुंच नीति)।
• यातायात प्रबंधन (कैनरी/ब्लू-ग्रीन, ए/बी, छायांकन)।
• विश्वसनीयता (रेट्रास, टाइमआउट, सर्किट ब्रेकिंग)।
• अवलोकन (मैट्रिक्स, लॉग, ट्रेल्स)।
• परिचालन मानकीकरण (कोड के रूप में नीतियां, GitOps)।

• बहुभाषा और mTLS आवश्यकता के साथ कई microservices।
• अनुप्रयोग को बदले बिना उन्नत रूटिंग/प्रयोग परिदृश्यों की आवश्यकता है।
• नेटवर्क स्तर पर लेखा परीक्षा/नीति आवश्यकताएं हैं।

2) इस्तियो बनाम लिंकर्ड - एक संक्षिप्त तुलना

3) वास्तुकला और तैनाती मॉडल

3. 1 सिडकर जाल (क्लासिक)

प्रत्येक पॉड को एक प्रॉक्सी साइडकार प्राप्त होता है।

पेशेवरों: परिपक्वता, पूर्ण L7 नियंत्रण।

विपक्ष: सीपीयू/रैम ओवरहेड, कमी/डिबगिंग की जटिलता।

3. 2 इस्तियो एम्बिएंट मेश

आवश्यकतानुसार नोड + वेपॉइंट प्रॉक्सी (L7) पर ztunnel (L4)।

पेशेवरों: कम लागत और जटिलता, L7 का क्रमिक समावेश।

विपक्ष: नए, सभी L7 मामले बिना रास्ते के उपलब्ध नहीं हैं।

4) पहचान और एमटीएलएस (शून्य-विश्वास)

4. 1 SPIFFE/SPIRE और प्रमाणपत्र

प्रत्येक कसरत को एक SPIFFE ID सौंपा जाता है: 'spiffe ://cluster। स्थानीय/nS/NS/sa/SA '।

सत्यापन: सेवाओं के बीच आपसी टीएलएस।

कुंजी घुमाव - स्वतः (छोटा टीटीएल)।

4. 2 इस्तियो (PeerAthentication + DestationRoul)

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 लिंकर्ड - एमटीएलएस डिफ़ॉल्ट

'लिंकर्ड इंस्टॉल' + 'लिंकर्ड इंजेक्ट' के बाद सक्षम।

समूह - खुद के ट्रस्ट-एंकर, स्वचालित रोटेशन।

5) यातायात प्रबंधन

5. 1 इस्तियो: 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 लिंकर्ड: सर्विस प्रोफाइल + ड्यूक स्प्लिट

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) इंग्रेस/एग्रेस और एपीआई गेटवे

इस्तियो गेटवे (इंग्रेस/एग्रेस) - आने वाले/आउटगोइंग ट्रैफिक, टीएलएस समाप्ति, एमटीएलएस पासथ्रो को नियंत्रित करता है।

लिंकर मौजूदा इंग्रेस नियंत्रकों (NGINX/Contour/Traefik) के साथ काम करता है; Egress - नेटवर्किंग पॉलिसी/एग्रेस-गेटवे-पैटर्न के माध्यम से।

एग्रेस नीतियां: डोमेन व्हाइटलिस्ट, एसएनआई-नीति, प्रत्यक्ष इंटरनेट प्रतिबंध।

7) प्राधिकरण और नीति

7. 1 इस्तियो आधिकारिक नीति (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 लिंकर नीति (सर्वर + सर्ववेरथोराइजेशन)

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 _ tomal', 'istio _ requestion _ dercation _ miliseconds _ balket', 'istio _ tcp _ peated _ bytes _ total'।

लिंकर्ड अर्थात्: 'अनुरोध _ कुल', विलंबता p50/p95/p99, 'सफलता _ दर'।

8. 2 ट्रेल्स और लॉग

पुश W3C ट्रेस संदर्भ।

इस्तियो/दूत → OTLP в OpenTelemetry कलेक्टर; लिंकर्ड - साइडकार लॉगर/ऐप एसडीके के माध्यम से।

8. 3 उदाहरण

जंप-टू-ट्रेस के लिए अवधि हिस्टोग्राम में ट्रेस _ आईडी जोड़ें।

9) दर सीमा, WAF, कस्टम फिल्टर

Istio: स्थानीय दर सीमा के लिए EnvoyFilter/WASM, eksnal-rate-Lame service (Redis), साथ ही WAF तर्क (Lua/WASM)।

लिंकर्ड: सीमित देशी समर्थन; दर सीमा - इंग्रेस/गेटवे स्तर पर।

10) मल्टी-क्लस्टर

इस्तियो: पूर्व-पश्चिम प्रवेश द्वार, साझा पीकेआई या ट्रस्ट-बंडल, सर्विसएंट्री, फेडरेशन के माध्यम से सेवा खोज।

लिंकर्ड: 'लिंकर मल्टीक्लस्टर लिंक', गेटवे प्रति क्लस्टर, सेवा-दर्पण контроллер।

उपयोग के मामले: परिसंपत्ति-क्षेत्र, यातायात स्थानीयकरण, शून्य-विश्वास।

11) प्रदर्शन और लागत

Sidecar जाल: CPU/RAM ओवरहेड प्रति पॉड, बढ़ी हुई विलंबता (आमतौर पर स्थिर-अवस्था में प्रति हॉप + 1-3 एमएस)।

परिवेश (इस्तियो): L4 के लिए कम खपत, L7 बिंदु पर बदल जाता है।

लिंकर्ड: लाइटवेट प्रॉक्सी आम तौर पर कम ओवरहेड होता है, लेकिन कम चरम एल 7 क्षमताएं होती हैं।

अभ्यास: मापने से पहले/बाद में, एसएलओ द्वार को गिरावट के लिए रखें।

12) सुरक्षा

एमटीएलएस हर जगह, छोटा टीटीएल, स्वचालित रोटेशन।

पॉलिसी के लिए कोड (OPA/गेटकीपर, Kyverno) के रूप में नीति: सभी 'prohibitions।

रहस्य - सीएसआई/वॉल्ट के माध्यम से, घोषणापत्र में नहीं।

Egress नियंत्रण: इनकार-दर-डिफ़ॉल्ट, स्पष्ट अनुमति-सूची।

वातावरण के लिए अलग ट्रस्ट डोमेन (prod/stage)।

13) रिलीज और एसएलओ गेटिंग के साथ एकीकरण

कैनरी/ब्लू-ग्रीन को जाल मार्गों द्वारा लागू किया जाता है (उदाहरण देखें)।

Argo Rollouts Template में मेट्रिक्स एनालिसिस (Prometheus/SpanMetrics) - बर्न-रेट/p95/5xx पर हिचहाइकिंग/रोलबैक।

ग्राफाना में रिलीज की घोषणा: तुलना 'संस्करण = स्थिर' कैनरी '।

14) एंटी-पैटर्न

जाल "हर जगह और एक बार में" शामिल करें - बुनियादी ढांचा झटका।

TSDB/लॉग भंडारण को ओवरलोड करने वाले प्रॉक्सी से मेट्रिक्स/लॉग की कार्डिनैलिटी को अनदेखा करें।

MTLS को PERMISIVE/अपारदर्शी मोड में हमेशा के लिए छोड़ दें।

गेटवे/एप्लिकेशन के बजाय EnvoyFilter के अंदर जटिल WAF/व्यावसायिक तर्क बनाने की कोशिश करें।

कोई नीति नहीं - इंटरनेट लीक/अनुपालन बाईपास।

': 15000' डिबग के साथ प्रॉक्सी बाहर के लिए खुला।

15) कार्यान्वयन चेकलिस्ट (0-60 दिन)

0-15 दिन

मॉडल चयन: लोड प्रोफाइल द्वारा Sidecar बनाम Ambient (Istio )/Linkerd।

1-2 महत्वपूर्ण सेवाओं के लिए mTLS STRICT, मूल प्राधिकरण नीतियों को सक्षम करें।

बुनियादी मार्ग (टाइमआउट/रिट्रीज़), RED/SLO डैशबोर्ड।

16-30 दिन

कैनरी/ड्यूक स्प्लिट, हॉट ट्रैक पर आउटलेयर डिटेक्शन/सर्किट ब्रेकिंग।

OTEL एकीकरण: ट्रेल्स + Exemplars; अलर्ट बर्न-रेट।

एग्रेस-गेटवे और डोमेन व्हाइटलिस्ट; इनकार-दर-डिफ़ॉल्ट।

31-60 दिन

मल्टी-क्लस्टर लिंक (यदि आवश्यक हो), फेडरेशन ट्रस्ट।

संहिता के रूप में नीति на प्राधिकृत नीति/सर्वप्राधिकरण।

खेल-दिवस: घटना और मार्ग/नीति रोलबैक का अनुकरण।

16) परिपक्वता मैट्रिक्स

mTLS (STRIST/ऑटो-रोटेट) कवरेज ≥ 95% सेवाएं।

कैनरी/प्रगतिशील रिलीज के माध्यम से यातायात का हिस्सा ≥ 80% है।

औसत ओवरहेड p95 <+ 5% बेसलाइन (अनुकूलन के बाद)।

0 खुली अनुमति के बिना, मूल AuthZ के साथ 100% सेवाएं।

आरसीए "शेड्यूल से ट्रैक" ≤ 2 मिनट (p50)।

17) "कोड के रूप में राजनीति" के उदाहरण

गेटकीपर (प्रोड में निषेध PERMISIVE)

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 के लिए आवश्यक लेबल)

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 के माध्यम से पदोन्नति।

प्रॉक्सी अवलोकन: व्यक्तिगत "प्रॉक्सी संतृप्ति" डैशबोर्ड (सीपीयू/ढेर, रेट्रीज़, 429/503)।

कार्डिनैलिटी बजट: लेबल 'रूट', 'कोड', 'गंतव्य' - केवल टेम्पलेट।

नेटवर्क सीमा/नेमस्पेस कोटा (नेटवर्किंग पॉलिसी/ Range)।

कमांड प्रलेखन: रनबुक "एमटीएलएस मार्गों/नीति/कुंजियों को कैसे रोल करें।"

19) निष्कर्ष

इस्तियो और लिंकर्ड एक ही काम करते हैं - क्रॉस-सर्विस संचार की सुरक्षा, विश्वसनीयता और दृश्यता का मानकीकरण करते हैं - लेकिन ऐसा विभिन्न गहराई और स्वामित्व की लागत पर करते हैं।

आपको समृद्ध एल 7 क्षमताओं और लचीली नीतियों की आवश्यकता है - इस्तियो को लें (ओवरहेड को कम करने के लिए एम्बिएंट पर विचार करें)।

सादगी और छोटे ओवरहेड की आवश्यकता है - लिंकर्ड लें।

आप जो भी जाल चुनें: डिफ़ॉल्ट रूप से एमटीएलएस सक्षम करें, कोड के रूप में रूटिंग का प्रबंधन करें, ट्रैक के साथ मैट्रिक्स को जोड़ें, क्लोज एग्रेस करें, और रिलीज़ करने के लिए एसएलओ गेटिंग जोड़ें। फिर नेटवर्क परत एक "ब्लैक बॉक्स" बन जाएगी और परिवर्तन की स्थिरता और गति के लिए एक पूर्वानुमानित उपकरण बन जाएगी।