लाइवनेस/तत्परता के नमूने

2) डिजाइन सिद्धांत

1. अलग शब्दार्थ।

तत्परता: सेवा अनुरोधों के लिए बाहरी क्षमता (महत्वपूर्ण निर्भरता को ध्यान में रख

जीवंतता: प्रक्रिया की "लाइलाज" स्थिति का पता लगाने की क्षमता।

2. फेल-फास्ट, लेकिन गलत-फास्ट नहीं। टाइमआउट/थ्रेशोल्ड 'थ्रेशोल्ड' को समायोजित करें ताकि छोटे फटने से अनावश्यक पुनरारंभ न हो।

3. नमूनों में कोई भारी ऑपरेशन नहीं। चेक तेज (≤100 -200 ms) और साइड इफेक्ट्स के बिना होना चाहिए।

4. सुंदर गिरावट। निर्भरता की आंशिक अनुपलब्धता के मामले में - तैयारी = ठीक है, अगर एक सुरक्षित फॉलबैक (कैश/मोटे) है।

5. नियतात्मक I/O. स्टेटस केवल वर्तमान स्थिति पर निर्भर करता है, न कि "यादृच्छिक" बाहरी परीक्षणों पर।

3) हेल्थ-एंडपॉइंट के शब्दार्थ

3. 1 HTTP दृष्टिकोण (अनुशंसित)

'GET/healtz/livence' → 200 यदि प्रक्रिया "जीवित" है (इवेंट-लूप घूम रहा है, जीसी अटक नहीं रहा है, वॉचडॉग "दिल" धड़ क रहा है)।

'GET/healtz/तत्परता' → 200 यदि उदाहरण महत्वपूर्ण वर्ग यातायात के लिए तैया जाँच: कनेक्शन पूल, स्थानीय कैश, व्यवसाय तर्क कर्नेल उपलब्धता।

प्रारंभिक (प्रवासन/कैश वार्म-अप/लोडिंग मॉडल) के बाद 'GET/healtz/startup' → 200।

नियम:

आप जीवन में बाहरी डेटाबेस/एपीआई में नहीं जा सकते हैं - इससे निर्भरता की घटनाओं के दौरान "आत्महत्या" हो जाएगी।
तत्परता में, आप महत्वपूर्ण निर्भरता की जांच कर सकते हैं, लेकिन समय और गिरावट के साथ: यदि कोई वैध फॉलबैक है, तो इसे नीचे न लाएं।

3. 2 जीआरपीसी स्वास्थ्य जांच

'grpc' मानक का उपयोग करें। स्वास्थ्य। v1। स्वास्थ्य/जाँच 'सेवा-स्कोप वाले राज्यों (' सर्विंग ',' नॉट _ सर्विंग ') के साथ। Kubernetes के लिए - grpc जांच (या http प्रॉक्सी)।

3. 3 आंतरिक ट्रिगर

वॉचडॉग "सॉफ्ट" स्टॉप: SIGTERM सेट रेडीनेस = FAIL के साथ - 'टर्मिनेशनग्रेसहियरसेकंड्स' के लिए इंतजार करें, कतारों से बाहर काम करें।

4) टाइमिंग और थ्रेसहोल्ड (ट्यूनिंग)

Kubernetes नमूनों के मुख्य क्षेत्र:

'Initial Seconds', 'होम सेकंड्स', 'टाइमआउट सेकंड्स', 'सफल थ्रेशोल्ड', ' थ्रेशोल्ड'।

प्रारंभ प्रोफाइल के लिए सिफारिशें: वेब/एपीआई तेजी से प्रारंभ के साथ:

तत्परता: 'अवधि = 5s, टाइमआउट = 0। 2–0. 5 एस, विफलता = 2 '
लाइवनेस: 'अवधि = 10s, टाइमआउट = 0। 2–0. 5 एस, विफलता = 3 '

कठिन शुरुआत (JIT/मॉडल/वार्म-अप):

स्टार्टअप: 'अवधि = 5s, विफलता = 60' (~ 5 मिनट तक)
स्टार्टअप सफलता के बाद तत्परता/जीवंतता सक्रिय हुई

बैच/उपभोक्ता:

तत्परता प्रसंस्करण के लिए तत्परता को दर्शाती है (एक दलाल से कनेक्शन, चाहे डीएलक्यू गिरावट हो),
जीवंतता - आंतरिक दिल की धड़ कन लूप।

विफलताओं पर बैकऑफ: आवेदन में, निर्भरता के लिए फिर से जुड़ ने के लिए घातीय बैकऑफ का उपयोग करें, अन्यथा तत्परता "देखी जाएगी।"

5) कॉन्फ़िगरेशन (टुकड़े)

5. 1 कुबर्नेट्स, HTTP जांच

yaml livenessProbe:
httpGet: { path: /healthz/liveness, port: 8080 }
periodSeconds: 10 timeoutSeconds: 1 failureThreshold: 3

readinessProbe:
httpGet: { path: /healthz/readiness, port: 8080 }
periodSeconds: 5 timeoutSeconds: 1 failureThreshold: 2

startupProbe:
httpGet: { path: /healthz/startup, port: 8080 }
periodSeconds: 5 failureThreshold: 60

5. 2 कुबर्नेट्स, जीआरपीसी नमूना

yaml readinessProbe:
grpc:
port: 9090 service: my. app. Service periodSeconds: 5 timeoutSeconds: 1

5. 3 सुंदर बंद

yaml terminationGracePeriodSeconds: 30 lifecycle:
preStop:
exec:
command: ["/bin/sh","-c","curl -s localhost:8080/healthz/drain && sleep 5"]

सेवा के अंदर '/healthz/drain 'रेडीनेस = FAIL (स्टॉप-स्वीकृति) का अनुवाद करता है, सक्रिय अनुरोधों को पूरा करने का समय देता है।

6) निर्भरता और गिरावट

क्रिटिकल (उनके बिना सेवित नहीं किया जा सकता): '/लॉगिन 'के लिए प्राधिकरण डेटाबेस, '/पे' के लिए भुगतान प्रवेश द्वार। टाइमआउट ≤80% 'टाइमआउट सेकंड' नमूनों के साथ तत्परता से जाँचा जा सकता है।

गैर-महत्वपूर्ण: एनालिटिक्स, ईमेल, कैश परत यदि कोई भार है। उन्हें तत्परता में शामिल न करें; एक follbeck का उपयोग करें।

फ़ीचर-फ्लैग्स: यदि आंशिक रूप से अपमानित किया जाता है, तो तत्परता बनाए रखते हुए निर्भर सुविधाएँ अक्षम करें = ठीक है।

7) कतारें और बैकग्राउंड हैंडलर

उपभोक्ता/श्रमिक:

तत्परता = ठीक है यदि दलाल के लिए सदस्यता/कनेक्शन संस्थापित है और प्रक्रिया के लिए एक संसाधन है।
जब डीएलक्यू/लैग ओवरफ्लो होता है → तत्परता ठीक रह सकती है (यदि हम स्वीकार करते हैं और जोड़ ते हैं), लेकिन एसएलआई "ताजगी/अंतराल" डेटा के अनुसार सतर्क रहता है।
लाइवनेस: पोल चक्र/दिल की धड़ कन, डेथडेटेक्टर को नियंत्रित करें।

Idempotence: पुनः आरंभ करने से वसूली में तेजी आती है।

8) सिडकर/मेष/इंग्रेस

सेवा जाल (इस्तियो/लिंकर्ड) का उपयोग करते समय, जांच साइडकार के माध्यम से जा सकती है:

साइडकार स्थिति के लिए खाते में 'रीडनेसगेट' (K8s) सक्षम करें,
यह सुनिश्चित करें कि नमूने एमटीएलएस बाधाओं के भीतर न गिरें (या अपवाद जोड़ें)।
Ingress/Envoy/Nginx: Prox '/healthz/' स्थानीय रूप से, आंतरिक भागों को "बाहर नहीं लाओ"।

9) सुरक्षा और गोपनीयता

स्वास्थ्य समापन बिंदुओं को कॉन्फ़िग, लाइब्रेरी संस्करण, त्रुटि स्ट्रिंग्स का खुलासा नहीं करना चाहिए - केवल "ओके/फेल" + न्यूनतम कारण कोड।

बाहरी पहुँच को प्रतिबंधित करें (नेटवर्कपॉलिसी/एसीएल)। सार्वजनिक के लिए - चलो विवरण के बिना सिर्फ जीवंतता-पिंग।

स्वास्थ्य जांच के लॉग - DEBUG स्तर पर, थ्रॉटलिंग के साथ।

10) अवलोकन और एसएलओ

मेट्रिक्स निर्यात करें: 'health _ readiness {state}', 'health _ liveness {state}', नमूना प्रक्रमण समय।

उपलब्धता SLO (एंडपॉइंट्स → 5xx/कनेक्शन रीसेट से ड्रॉप) के साथ तैयारी के झंडे।

अलर्ट:

"बार-बार जीवंतता> एन/घंटे द्वारा पुनरारंभ होता है" - गतिरोध/लीक का एक लक्षण।
"फ्लैप रेडीनेस> X/15 मिनट" - लत/नेटवर्क समस्याओं का एक लक्षण।
तैनाती के साथ सहसंबंध ('सेवा। संस्करण ')।

11) परीक्षण

इकाई/अनुबंध: प्रत्येक निर्भरता अक्षम होने पर एंडपॉइंट्स/हेल्थज ़/' रिटर्न सही स्थिति है।

अराजकता: डेटाबेस/कैश/ब्रोकर को अक्षम करना: तत्परता को गिरना चाहिए या मॉडल के अनुसार सख्ती से फॉलबैक सक्षम करना चाहिए। लाइवनेस - अगर प्रक्रिया "जीवित" है तो ट्रिगर नहीं करती है।

लोड/सोक: लोड के तहत, स्वास्थ्य समापन बिंदुओं को तेजी से रहना चाहिए (सामग्री को धक्का न दें)।

कैनरी: यातायात बढ़ाने से पहले तत्परता स्थिरता की जाँच करें।

12) बार-बार गलतियाँ और उनसे कैसे बचें

लाइवनेस डेटाबेस/बाहरी एपीआई की जांच करता है। परिणाम घटनाओं के लिए अंतहीन पुनर्स्थापन है। समाधान: "जीवन को संसाधित करने" के लिए जीवंतता को सीमित करें।

नमूनों में भारी जांच। झूठी असफलताओं की ओर ले जाता है। समाधान: प्रकाश की जाँच + व्यक्तिगत पृष्ठभूमि-स्वास्थ्य मॉनि

कोई स्टार्टअप जांच नहीं। धीमी शुरुआत को जीवंतता से "मार दिया जाता है"। समाधान: एक विस्तृत विंडो के साथ स्टार्टअप जोड़

कोई सुंदर बंद नहीं। डेप्ला में दुर्लभ 5xx। समाधान: प्रीस्टॉप + असंतुलन।

फ्लैप तूफान। बहुत आक्रामक थ्रेसहोल्ड। समाधान: ' थ्रेशोल्ड' उठाएं, 'टाइमआउट सेकंड' बढ़ाएं, बैकऑफ़जोड़ें।

सब कुछ के लिए एक ही समापन बिंदु। शब्दार्थ का मिश्रण। समाधान: व्यक्तिगत 'लाइवनेस/तत्परता/स्टार्टअप'।

13) मिनी कार्यान्वयन पैटर्न

सरल HTTP हैंडलर (स्यूडोकोड):

python
@app. get("/healthz/liveness")
def liveness():
return 200

@app. get("/healthz/readiness")
def readiness():
ok_core = core_is_ready () # local pools/caches/initialization ok_db = db. ping (timeout = 50 _ ms) # only if the DB is critical return 200 if (ok_core and ok_db) else 503

@app. get("/healthz/startup")
def startup():
return 200 if INIT_DONE else 503

@app. post("/healthz/drain")
def drain():
set_readiness(False); return 200

जीआरपीसी स्वास्थ्य (विचार):

go
// use google. golang. org/grpc/health/grpc_health_v1 healthServer. SetServingStatus("my. app. Service", SERVING) // or NOT_SERVING

ReadinsGate (जाल के साथ सही):

yaml spec:
readinessGates:
- conditionType: "proxy. istio. io/ready"

14) चेकलिस्ट

बेचने से पहले

लाइवनेस/तत्परता/स्टार्टअप एंडपॉइंट अलग हो गए हैं, उनके शब्दार्थ वर्णित हैं।
निर्भरता बाहरी निर्भरता को नहीं छूती है; तत्परता केवल टाइमआउट और फॉलबेक के साथ महत्वपूर्ण परीक्षण करती है।
सेवा प्रोफ़ाइल के लिए कॉन्फ़िगर 'initialDelear/अवधि/समय-सीमा/ थ्रेशोल्ड'।
सुंदर शटडाउन सक्षम: 'प्रीस्टॉप' + असंतुलन।
स्वास्थ्य मैट्रिक्स/लॉग जुड़े हुए हैं; पुनः आरंभ/फ्लैप करने के लिए अलर्ट।
निर्भरता विफलता और धीमी शुरुआत परीक्षण पास हुए।

ऑपरेशन

पुनरारंभ और तत्परता झंडे पर साप्ताहिक रिपोर्ट।
घटनाओं के बाद ट्यूनिंग थ्रेसहोल्ड; रिलीज के साथ संबंध।
अक्षम निर्भरता के नियमित अराजकता परीक्षण।
शब्दार्थ की प्रासंगिकता जब निर्भरता आलोचना बदलती है।

15) एफएक्यू

प्रश्न: क्या एक टूटने के साथ सब कुछ बंद करना संभव है?

A: अवांछनीय। अलग 'स्टार्टअप', 'तत्परता', 'जीवंतता' - यह झूठी सकारात्मकता को कम करता है और आरसीए को गति देता है।

प्रश्न: क्या मैं तत्परता से कैश की जांच करता हूं?

A: यदि कैश के बिना एक सही (यद्यपि धीमा) मोड है, तो तत्परता को कम न करें, बस गिरावट को चालू करें।

प्रश्न: जीवंतता के लिए लगातार पुनरारंभ के साथ क्या करना है?

A: पहले एक dektor/रिसाव का नियम; फिर थ्रेसहोल्ड को ढीला करें और आवेदन में एक वॉचडॉग जोड़ें।

प्रश्न: हम बहु-किरायेदारी के लिए कैसे जिम्मेदार हैं?

A: तत्परता को किसी भी किराये के यातायात की सेवा करने की क्षमता को प्रतिबिंबित करना चाहिए किसी विशेष किरायेदार की निजी समस्याओं के लिए - तत्परता न बदलें, लेकिन अलग SLI/अलर्ट के साथ संकेत दें।

संबंधित सामग्री:

"अवलोकन: लॉग, मैट्रिक्स, निशान"
"वितरित निशान"
"एसएलओ/एसएलए और मेट्रिक्स"
"वेबहुक डिलीवरी गारंटी"
"ट्रांजिट एन्क्रिप्शन में"
"गुप्त प्रबंधन"

लाइवनेस/तत्परता के नमूने

ऑपरेशन

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

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

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

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