सेवा जाल और यातायात नीति

1) सेवा मेष क्यों

सेवा मेश पूर्व-पश्चिम यातायात (अंतर-सेवा संचार) के लिए एक बुनियादी ढांचा परत है, जो कोड को फिर से लिखे बिना समान क्षमताएं प्रदान करता है:

डिफ़ॉल्ट सुरक्षा: mTLS, प्रमाणपत्रों का स्वचालित जारी/घुमाव, सेवा पहचान.
यातायात नीति: L7 रूटिंग, कैनरी/एवी परीक्षण, गिरावट और स्थिरता।
अवलोकन: प्रत्येक कॉल पर मैट्रिक्स, लॉग, निशान, सोने के संकेत।
संचालन: सभी भाषाओं/रूपरेखाओं के लिए समान नीतियां।

एपीआई प्रवेश द्वार से अंतर: प्रवेश द्वार - उत्तर-दक्षिण परिधि; जाल - समूह/संगठन के भीतर पूर्व-पश्चिम। अक्सर एक साथ काम करते हैं।

2) वास्तुकला: योजनाएँ और पैटर्न

डेटा प्लेन: साइडकार प्रॉक्सी (दूत/लिंकर्ड-प्रॉक्सी/हैप्रॉक्सी), जो पॉड/वीएम ट्रैफिक को इंटरसेप्ट करता है।

नियंत्रण विमान: विन्यास (मार्ग, नीतियां, प्रमाणपत्र), भंडार की स्थिति, सेवा ड्राइव प्रकाशित करता है।

पहचान: आमतौर पर SPIFFE ID और स्वचालित X.509 प्रमाणपत्र (SPIRE/बिल्ट-इन CA)।

प्रविष्टि/निकास बिंदु: सीमा प्रवाह की निगरानी के लिए इंग्रेस/एग्रेस-गेटवे।

कार्यान्वयन मोड: प्रत्येक के लिए साइडकार; नए कार्यान्वयन में प्रति-नोड/परिवेश-मोड।

3) सुरक्षा नीति और शून्य-विश्वास

1. mTLS डिफ़ॉल्ट द्वारा - servis↔servis एन्क्रिप्शन और पारस्परिक सत्यापन।

2. AuthN/AuthZ:

AuthN: केवल CA mesh' a (SPIFFE) द्वारा जारी की गई पहचान पर भरोसा करें।
AuthZ: घोषणात्मक "कौन और कैसे" नियम (RBAC/ABAC) कर सकता है।

3. अलगाव और नियंत्रण नियंत्रण:

अनुमत डोमेन/सबनेट; Egress-गेटवे के माध्यम से मजबूर।
चूल्हों से प्रत्यक्ष परिणामों को अवरुद्ध करना।

4. गुप्त रोटेशन: अल्पकालिक प्रमाणपत्र, स्वचालित प्रॉक्सी पुनर्संयोजन।

इस्तियो (उदाहरण: वैश्विक एमटीएलएस सख्त):

yaml apiVersion: security. istio. io/v1beta1 kind: PeerAuthentication metadata: { name: default, namespace: istio-system }
spec:
mtls: { mode: STRICT }

इस्तियो (उदाहरण: केवल gRPC inventory→billing की अनुमति दें):

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 टाइमआउट और रिट्रीट

टाइमआउट: कॉल पर सेट किया जाना चाहिए (कनेक्ट/रीड/ओवरऑल)।

रेट्रीज़: केवल पहचान संचालन के लिए; बैकऑफ + जिटर; प्रति-कोशिश समय सीमा।

इस्तियो (VirtualService):

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 सर्किट ब्रेकर и बाहरी पहचान

CB: अपस्ट्रीम की रक्षा करते हुए, एक साथ अनुरोध/कनेक्शन को प्रतिबंधित करता है।

बाहरी: त्रुटि/विलंबता द्वारा "बुरा" उदाहरण फेंकता है।

इस्तियो (गंतव्य नियम):

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 कैनरी और शर्तों के अनुसार

भारित - ट्रैफिक को v1/v2 भार से विभाजित किया गया है।

शीर्षिका आधारित: फ्लैग्स/कुकी/किरायेदार - नए संस्करण में स्थानांतरित किया जाए.

सत्र आत्मीयता: कुंजी द्वारा हैश (बड़ेकरीने से)।

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 दोष इंजेक्शन और क्षरण

मजबूती परीक्षण और एसएलओ के लिए विलंब/त्रुटि इंजेक्शन।

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

5) नेटवर्क सीमाएं: इंग्रेस/एग्रेस और बाहरी सेवाएं

इंग्रेस-गेटवे: जाल में बाहरी ग्राहकों के लिए एकमात्र प्रवेश बिंदु; WAF/OIDC/ratelimits के साथ एकीकरण।

एग्रेस-गेटवे: अनुमत मेजबानों, टीएलएस निरीक्षण, टेलीमेट्री रिकॉर्ड की सूची के साथ केंद्रीय आउटपुट।

सर्विसएंट्री: बाहरी एसएनआई/होस्ट को मेष (नीतियों और एमटीएलएस-उत्पत्ति लागू) के हिस्से के रूप में घोषित करता है।

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) मल्टी-क्लस्टर, मल्टी-नेटवर्क और हाइब्रिड

साझा PKI/ट्रस्ट डोमेन: समूहों के बीच एकल SPIFFE पहचान।

एंडपॉइंट खोज: क्षेत्रों के बीच सेवा गेंदें; स्थानीय प्राथमिकता और विफलता।

जोनल अलगाव: प्रति-क्षेत्रीय नीतियां, सीमा और प्राथमिकताएं।

जाल में वीएम: विरासत/राज्यपूर्ण प्रणालियों को प्रॉक्सी और समान नीतियों से जोड़ ना।

7) अवलोकन, एसएलओ और संचालन

Метрики: 'अनुरोध _ कुल', 'अनुरोध _ अवधि _ ms {p50, p95, p99}', '5xx _ दर', 'पुनरावृत्ति _ प्रयास', 'cb _ state', 'mTLS _ authz _ इनकार'।

अभिगम लॉग: संरचनात्मक, 'ट्रेसपेरेंट', 'उपयोगकर्ता/किरायेदार', 'प्रतिक्रिया _ फ्लैग्स' के साथ।

ट्रेसिंग: हेडर का ऑटो-इंजेक्शन (W3C ट्रेस कॉन्सेप्ट), नमूना, हॉप स्तर पर फैला हुआ है।

SLO: मार्ग (service→service) पर p99/त्रुटियों द्वारा लक्ष्य।

अलर्ट: '5xx' स्पाइक, 'रीसेट' वृद्धि, 'आउटलेयर _ ejections', mTLS गिरावट (हैंडशेक विफलताएं)।

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

Sidecar चालान जोड़ ता है (CPU/RAM/विलंबता)। अनुकूलन:

दानेदारी: जहां जरूरत हो राजनीति शामिल करें; हर जगह भारी फिल्टर चालू न करें।
पूल: विभिन्न मार्गों और सीमाओं में विभाजित पथ (महत्वपूर्ण/पृष्ठभूमि)।
प्रोफाइलिंग: "कोल्ड" मार्गों पर p99, टेलीमेट्री वॉल्यूम (दर-सीमा लॉग/ट्रेल्स)।
यदि समर्थित और उपयुक्त हो तो परिवेश/साइडकारलेस मोड पर विचार करें।

9) सुरक्षा और अनुपालन

न्यूनतम आवश्यक पहुँच: स्पष्ट रूप से दिशाओं और विधियों की अनुमति दें।

neimspaces/किरायेदारों पर नीतियां: नेटवर्क/प्राधिकरण सीमाएँ।

प्रमुख रोटेशन/एसी: नियोजित और आपातकाल; छोटा टीटीएल प्रमाणपत्र।

PII/रहस्य: लॉग/ट्रैक में मास्किंग; तार पर एन्क्रिप्शन/आराम पर।

ऑडिट: कौन, कब और क्या नीति बदल गई; दो-चरण हंगामा।

10) परत के साथ एकीकरण

मेष नीतियां पूरक, प्रतिस्थापित नहीं, नेटवर्कपॉलिसी।

इंग्रेस/एग्रेस-गेटवे में, आप नीचे दिए गए स्तर पर पॉड सिक्योरिटी/पीएसए लटका सकते हैं।

एनआरए/ऑटोस्कलिंग: रिट्रे/सीबी पर विचार करें - वे लोड बदलते हैं।

रिलीज की योजना: VirtualService + स्वचालित SLO प्रचार के माध्यम से कैनरी वजन।

11) कार्यान्वयन चेकलिस्ट

ट्रस्ट सीमा परिभाषित और STRIST mTLS सक्षम।
AuthZ नीतियों ने सक्षम किया: किसके लिए, किन बंदरगाहों/तरीकों पर।
टाइमआउट/रेट्रीज़और आउटलेयर डिटेक्शन कॉन्फ़िगर किए गए हैं, पहचान पथ परिभाषित किए गए हैं।
कैनरी मार्ग और रोलबैक योजना पंजीकृत हैं; फॉल्ट-इंजेक्शन - केवल गैर-प्रोड में।
बाहरी निर्भरताएं एग्रेस-गेटवे और सर्विसएंट्री के माध्यम से प्राप्त की जाती हैं।
मेट्रिक्स, लॉग, ट्रेस कॉन्फ़िगर किए गए हैं; डैशबोर्ड और p99/5xx/CB पर अलर्ट।
कोटा/लिमिट प्रति-किरायेदार/नेमस्पेस उपलब्ध हैं।
तैयार रनबुक: प्रमाणपत्र लीक, सीए विफलता, अपस्ट्रीम क्षरण, द्रव्यमान।
मल्टी-क्लस्टर प्लान (साझा पीकेआई, स्थानीय प्राथमिकताएं, डीआर परिदृश्य)।
टेस्ट डे (खेल के दिन): ड्रॉप कंट्रोल प्लेन, साइडकार, नेटवर्क ब्रेक, जहरीला अपस्ट्रीम।

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

मार्ग इन्वेंट्री और एसएलओ के बिना मेश "हर जगह और एक बार" महंगी जटिलता।

सभी विधियों के लिए डिफ़ॉल्ट रिट्रे - प्रभाव डुप्लिकेट और ट्रैफिक हिमस्खलन।

एक अक्षम एमटीएलएस "अस्थायी रूप से" - स्थायी रूप से रहता है।

गेटवे के बिना egress → डेटा रिसाव/बेहिसाब निर्भरता।

सभी सेवाओं के लिए एक वैश्विक नीति - झूठी सुरक्षा और झूठी सकारात्मकता।

शून्य अवलोकन: जाल शामिल है, लेकिन मेट्रिक्स/ट्रेल्स एकत्र न करें - अर्थ खो दें।

13) त्वरित व्यंजनों

लिंकर्ड: 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"]

कांसुल (L7 इरादे + विभाजक)

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) एफएक्यू

क्या मेश को एक छोटी टीम की जरूरत है?

यदि 3-5 सेवाएं - अधिक बार नहीं। अच्छी इंग्रेस और लचीलापन पुस्तकालयों के साथ शुरू करें। जब एमटीएलएस-डिफ़ॉल्ट, समान नीतियों और कोड परिवर्तन के बिना ट्रेसिंग की आवश्यकता हो तो जाल कनेक्ट करें।

लागत को कैसे नियंत्रित करें?

क्रिटिकल रास्तों पर ओवरहेड (सीपीयू/रैम/लेटेंसी) मापना, अनावश्यक फिल्टर बंद करना, लॉग/ट्रेल्स की मात्रा कम करना, बिना साइडकार के मोड का उपयोग करना जहां यह सुरक्षित है।

क्या जाल और मैन्युअल रूप से कॉन्फ़िगर प्रॉक्सी के साथ हस्तक्षेप करना संभव है?

हां, लेकिन डबल रूटिंग/डुप्लिकेट रिट्रे से बचें। एक ही जगह सच है - नियंत्रण विमान।

अधिक महत्वपूर्ण क्या है: सुरक्षा या प्रदर्शन?

डिफ़ॉल्ट सुरक्षा है (mTLS, AuthZ). ट्यूनिंग कनेक्शन पूल, बाहरी पहचान, लक्ष्य मार्गों द्वारा प्रदर्शन प्राप्त किया

15) कुल

सेवा मेश सेवाओं के बीच नेटवर्क को एक समान नीतियों के साथ एक प्रोग्रामेबल परत में बदल देता है: एन्क्रिप्शन और पहचान, ठीक रूटिंग और लचीलापन, टेलीमेट्री और कोटा। महत्वपूर्ण रास्तों के साथ शुरू करें, STRICT mTLS चालू करें और स्पष्ट AuthZ, सेट टाइमआउट/रिट्रे/सीबी, कंट्रोल एग्रेस, माप p99 और 5xx, खेल के दिन बिताएं। तब मेष विश्वसनीयता और रिलीज की गति का एक एम्पलीफायर बन जाएगा, न कि आश्चर्य का स्रोत।

सेवा जाल और यातायात नीति

कांसुल (L7 इरादे + विभाजक)

हमसे संपर्क करें

त्वरित संपर्क

वीडियो जल्द ही अपडेट किया जाएगा

हम इस समय परियोजनाओं में बहुत व्यस्त हैं