उत्पादन में कुबेरनेट: सेवाएं

छह महीने पहले, हमने अपनी सभी स्टेटलेस सेवाओं का प्रवास कुबेरनेट्स में पूरा किया। पहली नज़र में, कार्य काफी सरल है: आपको एक क्लस्टर तैनात करने, एप्लिकेशन विनिर्देशों को लिखने और जाने की आवश्यकता है। हमारी सेवा के काम में स्थिरता सुनिश्चित करने के जुनून के कारण, मुझे तुरंत यह समझना शुरू कर दिया कि k8 कैसे काम करता है और विभिन्न विफलता परिदृश्यों का परीक्षण करता है। अधिकांश प्रश्न मेरे पास नेटवर्क से संबंधित हर चीज के बारे में थे। इन फिसलन मुद्दों में से एक kubernetes में सेवाओं का संचालन है।

प्रलेखन हमें बताता है:

• एप्लिकेशन को रोल आउट करें
• सेट लीनिंग / तत्परता के नमूने
• एक सेवा बनाएँ
• फिर सब कुछ काम करेगा: लोड संतुलन, विफलता, आदि।

लेकिन व्यवहार में, सब कुछ कुछ अधिक जटिल है। आइए देखें कि यह वास्तव में कैसे काम करता है।

सिद्धांत की बिट

इसके अलावा, मेरा मतलब है कि पाठक पहले से ही कुबेरनेट्स डिवाइस और इसकी शब्दावली से परिचित है; हम केवल याद करते हैं कि एक सेवा क्या है।

सेवा k8s का सार है, जो उन्हें प्राप्त करने के लिए चूल्हा और विधियों का एक सेट का वर्णन करता है।

उदाहरण के लिए, हमने अपना एप्लिकेशन लॉन्च किया:

apiVersion: apps/v1 kind: Deployment metadata: name: webapp spec: selector: matchLabels: app: webapp replicas: 2 template: metadata: labels: app: webapp spec: containers: - name: webapp image: defaultxz/webapp command: ["/webapp", "0.0.0.0:80"] ports: - containerPort: 80 readinessProbe: httpGet: {path: /, port: 80} initialDelaySeconds: 1 periodSeconds: 1 

 $ kubectl get pods -l app=webapp NAME READY STATUS RESTARTS AGE webapp-5d5d96f786-b2jxb 1/1 Running 0 3h webapp-5d5d96f786-rt6j7 1/1 Running 0 3h 

अब, इसे एक्सेस करने के लिए, हमें एक सेवा बनानी होगी जिसमें हम यह निर्धारित करें कि हम किन चैनलों (एक्सेसर) तक पहुँचना चाहते हैं और किन पोर्ट्स पर हैं:

 kind: Service apiVersion: v1 metadata: name: webapp spec: selector: app: webapp ports: - protocol: TCP port: 80 targetPort: 80 

 $ kubectl get svc webapp NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE webapp ClusterIP 10.97.149.77 <none> 80/TCP 1d 

अब हम क्लस्टर में किसी भी मशीन से अपनी सेवा प्राप्त कर सकते हैं:

 curl -i http://10.97.149.77 HTTP/1.1 200 OK Date: Mon, 24 Sep 2018 11:55:14 GMT Content-Length: 2 Content-Type: text/plain; charset=utf-8 

यह सब कैसे काम करता है

बहुत सरलीकृत:

• आपने kubectl परिनियोजन चश्मा लागू किया था
• जादू होता है, जिसका विवरण इस संदर्भ में महत्वपूर्ण नहीं है
• नतीजतन, आवेदन के काम करने वाले नोड कुछ नोड्स पर निकले
• एक बार प्रत्येक क्यूबलेट अंतराल (प्रत्येक नोड पर k8s एजेंट) अपने नोड पर चलने वाले सभी पॉड्स की लीनिंग / तत्परता के नमूने का प्रदर्शन करता है, यह परिणामों को एपेसेवर (k8s दिमाग को इंटरफ़ेस) भेजता है
• प्रत्येक नोड पर क्यूब-प्रॉक्सी को सेवाओं और चूल्हा में सभी परिवर्तनों के बारे में एपसेवर से सूचनाएं मिलती हैं जो सेवाओं में भाग लेते हैं
• क्यूब-प्रॉक्सी अंतर्निहित सबसिस्टम के विन्यास में सभी परिवर्तनों को दर्शाता है (iptables, ipvs)

सरलता के लिए, डिफ़ॉल्ट प्रॉक्सी विधि पर विचार करें - iptables। Iptables में, हमारे पास हमारे वर्चुअल IP 10.97.149.77 के लिए है:

 -A KUBE-SERVICES -d 10.97.149.77/32 -p tcp -m comment --comment "default/webapp: cluster IP" -m tcp --dport 80 -j KUBE-SVC-BL7FHTIPVYJBLWZN 

ट्रैफ़िक KUBE-SVC-BL7FHTIPVYJBLWZN श्रृंखला में जाता है , जिसमें इसे 2 अन्य श्रृंखलाओं में वितरित किया जाता है

 -A KUBE-SVC-BL7FHTIPVYJBLWZN -m comment --comment "default/webapp:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-UPKHDYQWGW4MVMBS -A KUBE-SVC-BL7FHTIPVYJBLWZN -m comment --comment "default/webapp:" -j KUBE-SEP-FFCBJRUPEN3YPZQT 

ये हमारी फली हैं:

 -A KUBE-SEP-UPKHDYQWGW4MVMBS -p tcp -m comment --comment "default/webapp:" -m tcp -j DNAT --to-destination 10.244.0.10:80 -A KUBE-SEP-FFCBJRUPEN3YPZQT -p tcp -m comment --comment "default/webapp:" -m tcp -j DNAT --to-destination 10.244.0.11:80 

चूल्हों में से एक की विफलता का परीक्षण

मेरा वेबएप परीक्षण एप्लिकेशन "एरर रैश" मोड पर स्विच करने में सक्षम है, इसके लिए आपको "/ गलत" URL को खींचने की आवश्यकता है।

परीक्षा के बीच में ab -c 50 -n 20,000 का परिणाम एक श्रवण पर "/ गलत" निकाला गया:

 Complete requests: 20000 Failed requests: 3719 

यहां बिंदु विशिष्ट त्रुटियों की संख्या नहीं है (उनकी संख्या लोड के आधार पर अलग-अलग होगी), लेकिन वे हैं। सामान्य तौर पर, हमने "खराब" को संतुलन से बाहर फेंक दिया, लेकिन सेवा के क्लाइंट को स्विच करने के समय त्रुटियों को प्राप्त किया। त्रुटियों का कारण समझाने के लिए काफी आसान है: तत्परता परीक्षण प्रति सेकंड एक बार क्यूबलेट किया जाता है + यहां तक ​​कि जानकारी के प्रसार के लिए एक छोटा समय जो कि परीक्षण का जवाब नहीं दिया।

क्या आईपीवीएस क्यूब-प्रॉक्सी (प्रायोगिक) में मदद करेगा?

सच में नहीं! यह प्रॉक्सी अनुकूलन की समस्या को हल करता है, एक कस्टम बैलेंसिंग एल्गोरिथ्म प्रदान करता है, लेकिन यह विफलता प्रसंस्करण की समस्या को हल नहीं करता है।

कैसे हो?

इस समस्या को केवल एक बैलेंसर द्वारा हल किया जा सकता है जो पुन: प्रयास (पुनः प्रयास) कर सकता है। दूसरे शब्दों में, http के लिए हमें एक L7 बैलेंसर चाहिए। कुबेरनेट्स के लिए इस तरह के बैलेन्सर पहले से ही पूर्ण रूप से या तो इनग्रेस के रूप में उपयोग किए जाते हैं (क्लस्टर की चाल में एक बिंदु के रूप में निहित है, लेकिन बड़े पैमाने पर यह वास्तव में इसे इसकी आवश्यकता है), या एक अलग परत के कार्यान्वयन के रूप में - एक सेवा जाल, उदाहरण के लिए, istio ।

हमारे उत्पादन में, हमने अभी तक अतिरिक्त जटिलता की वजह से या तो इनग्रेस या सर्विस मेष का उपयोग करना शुरू नहीं किया है। इस तरह के सार, मेरी राय में, उन मामलों में मदद करते हैं जहां आपको अक्सर बड़ी संख्या में सेवाओं को कॉन्फ़िगर करने की आवश्यकता होती है। लेकिन एक ही समय में आप "भुगतान" नियंत्रणीयता और सरल बुनियादी ढांचे। आप यह जानने के लिए अतिरिक्त समय व्यतीत करेंगे कि किसी विशेष सेवा के लिए रिटर्न टाइमआउट कैसे सेट किया जाए।

हम कैसे?

हम हेडलेस k8s सेवाओं का उपयोग करते हैं। ऐसी सेवाओं में वर्चुअल आईपी नहीं होता है और तदनुसार, क्यूब-प्रॉक्सी और आईपीटेबल्स उनके काम में शामिल नहीं होते हैं। ऐसी प्रत्येक सेवा के लिए, आप DNS या एपीआई के माध्यम से लाइव चूल्हों की एक सूची प्राप्त कर सकते हैं।

अन्य सेवाओं के साथ बातचीत करने वाले अनुप्रयोगों के लिए, हम दूत के साथ एक फुटपाथ कंटेनर बनाते हैं। Evoy समय-समय पर DNS के माध्यम से सभी आवश्यक सेवाओं के लिए पॉड्स की एक अप-टू-डेट सूची प्राप्त करता है, और सबसे महत्वपूर्ण बात, यह एक त्रुटि के मामले में अन्य पॉड्स को क्वेरी करने के लिए बार-बार प्रयास करने में सक्षम है। आप इसे प्रत्येक नोड पर DaemonSet के रूप में चला सकते हैं, लेकिन फिर यदि यह आवृत्ति विफल हो जाती है, तो इसका उपयोग करने वाले सभी एप्लिकेशन काम करना बंद कर देंगे। चूंकि इस प्रॉक्सी द्वारा संसाधन की खपत काफी कम है, इसलिए हमने इसका उपयोग करने के लिए साइडकार कंटेनर संस्करण में उपयोग करने का निर्णय लिया।

यह अनिवार्य रूप से बिल्कुल वैसा ही है जैसा कि istio करता है, लेकिन हमारे मामले में संतुलन सादगी की ओर स्थानांतरित हो गया है (istio सीखने की आवश्यकता नहीं है, इसके कीड़े में भाग लें)। शायद यह संतुलन बदल जाएगा, और हम istio जैसी किसी चीज़ का उपयोग करना शुरू कर देंगे।

हम okmeter.io पर कुबेरनेट्स ने निश्चित रूप से रूट लिया है, और हम इसके आगे वितरण में विश्वास करते हैं। हमारी सेवा में k8 की निगरानी के लिए समर्थन रास्ते में है, देखते रहें!