इस्तियो को लॉन्च करने के लिए लाइकबेज़

इस्तियो सेवा जाल

हम नामली में अब एक साल से इस्तियो का उपयोग कर रहे हैं। वह तो बस छोड़ दिया। कुबेरनेट्स क्लस्टर में प्रदर्शन में हमारी बड़ी गिरावट थी, हम ट्रेसिंग वितरित करना चाहते थे और जेटियर को चलाने के लिए इस्तियो को ले गए और इसका पता लगाया। सेवा जाल हमारे बुनियादी ढांचे में इतनी अच्छी तरह से फिट है कि हमने इस उपकरण में निवेश करने का फैसला किया।

मुझे नुकसान उठाना पड़ा, लेकिन हमने इसका दूर-दूर तक अध्ययन किया। यह एक श्रृंखला की पहली पोस्ट है जहां मैं वर्णन करूंगा कि कैसे इस्तियो कुबेरनेट्स के साथ एकीकृत करता है और हमने इसके काम के बारे में क्या सीखा। कभी-कभी हम तकनीकी विकलों में भटकेंगे, लेकिन बहुत दूर नहीं। आगे और भी पद होंगे।

इस्तियो क्या है?

इस्तियो एक सेवा जाल विन्यास उपकरण है। यह Kubernetes क्लस्टर की स्थिति और L7 प्रॉक्सी (HTTP और gRPC) में अपग्रेड करता है, जिसे कुबेरनेट्स पॉड्स में साइडकार के रूप में लागू किया जाता है। ये साइडकार Envoy कंटेनर हैं जो Istio Pilot API (और gRPC सेवा) से कॉन्फ़िगरेशन को पढ़ते हैं और इसके माध्यम से मार्ग यातायात करते हैं। हुड के तहत शक्तिशाली एल 7 प्रॉक्सी के साथ, हम मैट्रिक्स, निशान, रिट्री लॉजिक, सर्किट ब्रेकर, लोड संतुलन और कैनरी तैनाती का उपयोग कर सकते हैं।

आइए शुरुआत से शुरू करें: कुबेरनेट्स

Kubernetes में, हम एक परिनियोजन या StatefulSet का उपयोग करके बनाते हैं। या यह सिर्फ उच्च स्तर के नियंत्रक के बिना "वेनिला" हो सकता है। तब कुबेरनेट्स वांछित स्थिति बनाए रखने के लिए अपनी पूरी कोशिश करता है - यह नोड पर क्लस्टर में पॉड्स बनाता है, यह सुनिश्चित करता है कि वे शुरू और पुनरारंभ करें। जब एक अंडर बनाया जाता है, तो कुबेरनेट्स एपीआई जीवन चक्र के माध्यम से जाता है, यह सुनिश्चित करता है कि प्रत्येक चरण सफल है, और केवल अंत में क्लस्टर पर अंडर बनाता है।

एपीआई जीवनचक्र चरण:

ठंडी तस्वीर के लिए बंजई बादल का शुक्रिया।

चरणों में से एक प्रवेश webhooks को संशोधित कर रहा है। यह कुबेरनेट्स में जीवन चक्र का एक अलग हिस्सा है, जहां संसाधनों को कूबर्नेट्स विन्यास के लिए सत्य के स्रोत, आदि रिपॉजिटरी में करने से पहले अनुकूलित किया जाता है। और यहाँ इस्तियो अपना जादू करती है।

प्रवेश webhooks को संशोधित करना

जब एक सब बनाया जाता है ( kubectl या Deployment माध्यम से), तो यह इस जीवन चक्र के माध्यम से जाता है, और इसे संशोधित करने से पहले वेबहूक को एक्सेस करके इसे बड़ी दुनिया में जारी करने से पहले बदल देते हैं।

Istio की स्थापना के दौरान, istio-sidecar-इंजेक्टर webhooks को संशोधित करने के लिए एक कॉन्फ़िगरेशन संसाधन के रूप में जोड़ा जाता है:

 $ kubectl get mutatingwebhookconfiguration NAME AGE istio-sidecar-injector 87d 

और विन्यास:

 apiVersion: admissionregistration.k8s.io/v1beta1 kind: MutatingWebhookConfiguration metadata: labels: app: istio-sidecar-injector chart: sidecarInjectorWebhook-1.0.4 heritage: Tiller name: istio-sidecar-injector webhooks: - clientConfig: caBundle: redacted service: name: istio-sidecar-injector namespace: istio-system path: /inject failurePolicy: Fail name: sidecar-injector.istio.io namespaceSelector: matchLabels: istio-injection: enabled rules: - apiGroups: - "" apiVersions: - v1 operations: - CREATE resources: - pods 

इसमें कहा गया है कि कुबेरनेट को सभी चूल्हा निर्माण की घटनाओं को istio-sidecar-injector में istio-system नाम स्थान पर istio-injection=enabled अगर नामस्थान istio-injection=enabled । इंजेक्टर में पॉडस्पीक में दो और कंटेनर शामिल हैं: प्रॉक्सी नियमों को स्थापित करने के लिए एक अस्थायी और खुद के लिए एक प्रॉक्सी। साइडकार इंजेक्टर इन कंटेनरों को istio-sidecar-injector कॉन्फ़िगरेशन मानचित्र से टेम्पलेट के अनुसार सम्मिलित करता है। इस प्रक्रिया को साइडकैरिंग भी कहा जाता है।

सिदकर फली

सिडकर हमारे जादूगर इस्तियो की चाल हैं। इस्तियो ने इतनी चतुराई से सब कुछ क्रैंक किया कि बाहर से यह सिर्फ जादू है, यदि आप विवरण नहीं जानते हैं। और अगर आपको अचानक नेटवर्क अनुरोधों को डीबग करने की आवश्यकता है, तो उन्हें जानना उपयोगी है।

Init और प्रॉक्सी कंटेनर

कुबेरनेट्स में अस्थायी एक बार के इनइट कंटेनर होते हैं जिन्हें मुख्य लोगों के सामने चलाया जा सकता है। वे पूल संसाधन, डेटाबेस को माइग्रेट करते हैं, या, जैसा कि इस्तियो के साथ होता है, नेटवर्क नियमों को कॉन्फ़िगर करते हैं।

इस्तियो वांछित मार्गों के साथ सबमिशन के लिए सभी अनुरोधों को प्रॉक्सी करने के लिए दूत का उपयोग करता है। ऐसा करने के लिए, इस्टियो iptables नियम बनाता है, और वे आने वाले और बाहर जाने वाले ट्रैफ़िक को सीधे दूत को भेजते हैं, और यह बड़े करीने से ट्रैफ़िक को उसके गंतव्य तक पहुँचाता है। ट्रैफ़िक एक छोटा चक्कर लगाता है, लेकिन आपने ट्रेसिंग, क्वेरी मेट्रिक्स और नीति प्रवर्तन वितरित किए हैं। इस फ़ाइल में, Istio रिपॉजिटरी से आप देख सकते हैं कि कैसे Istio iptables नियम बनाता है।

@jimmysongio ने iptables नियमों और Envoy प्रॉक्सी के बीच एक उत्कृष्ट कनेक्शन आरेख बनाया:

दूत - दूत यातायात

Envoy को आने वाले और बाहर जाने वाले सभी ट्रैफ़िक प्राप्त होते हैं, इसलिए सभी ट्रैफ़िक आमतौर पर Envoy के अंदर जाते हैं, जैसे कि आरेख में। इस्तियो प्रॉक्सी एक और कंटेनर है जो सभी फली में जोड़ा जाता है जो कि इस्तियो साइडकार इंजेक्टर द्वारा संशोधित होते हैं। इस कंटेनर में, दूत प्रक्रिया शुरू होती है, जो चूल्हा से कुछ ट्रैफ़िक प्राप्त करती है (कुछ अपवादों के साथ, जैसे आपके कुबेरनेट क्लस्टर से ट्रैफ़िक)।

Envoy प्रक्रिया Envoy v2 API के माध्यम से सभी मार्गों का पता लगाती है, जो Istio को लागू करता है।

दूत और पायलट

किसी समूह में फली और सेवाओं का पता लगाने के लिए दूत के पास कोई तर्क नहीं है। यह एक डाटा प्लेन है और इसे गाइड करने के लिए एक कंट्रोल प्लेन की जरूरत होती है। एनवोय कॉन्फ़िगरेशन पैरामीटर मेजबान या सेवा पोर्ट को जीआरपीसी एपीआई के माध्यम से इस कॉन्फ़िगरेशन को प्राप्त करने का अनुरोध करता है। Istio, अपनी पायलट सेवा के माध्यम से, gRPC एपीआई के लिए आवश्यकताओं को पूरा करता है। दूत इस एपीआई को एक संशोधित webhook के माध्यम से कार्यान्वित एक साइडकार विन्यास के आधार पर जोड़ता है। एपीआई में यातायात के सभी नियम हैं जो दूत को खोजने और क्लस्टर के लिए मार्ग की आवश्यकता है। यह सेवा जाल है।

डेटा विनिमय "के तहत <-> पायलट"

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

पायलट से कुबेरनेट्स तक

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

क्या कॉन्फ़िगरेशन भेजा जा रहा है?

Istio Pilot से Envoy को क्या कॉन्फ़िगरेशन मिलता है?

डिफ़ॉल्ट रूप से, Kubernetes आपके नेटवर्क मुद्दों को एक sevice (सेवा) के साथ हल करता है जो endpoint प्रबंधन करता है। एंडपॉइंट की सूची कमांड के साथ खोली जा सकती है:

 kubectl get endpoints 

यह क्लस्टर में सभी आईपी और बंदरगाहों की सूची है और उनके पते (आमतौर पर ये एक तैनाती से बनाई गई फली हैं)। Envoy को रूट डेटा कॉन्फ़िगर करने और भेजने के लिए Istio जानना महत्वपूर्ण है।

सेवाएँ, श्रोता और मार्ग

जब आप कुबेरनेट क्लस्टर में एक सेवा बनाते हैं, तो आप शॉर्टकट शामिल करते हैं जिसके द्वारा सभी उपयुक्त पॉड्स का चयन किया जाएगा। जब आप सेवा के IP पर ट्रैफ़िक भेजते हैं, तो Kubernetes इस ट्रैफ़िक के लिए ट्रैफ़िक का चयन करता है। उदाहरण के लिए, कमांड

 curl my-service.default.svc.cluster.local:3000 

सबसे पहले, यह default नामस्थान में my-service को असाइन किए गए वर्चुअल IP को ढूंढेगा, और यह IP सर्विस लेबल से मेल खाने वाले ट्रैफ़िक को उप को अग्रेषित करेगा।

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

Kubernetes, Istio और Envoy शब्द थोड़ा अलग हैं, और यह तुरंत स्पष्ट नहीं है कि वे क्या खाते हैं।

सेवाएं

Kubernetes में एक सेवा Envoy में एक क्लस्टर के लिए मैप करती है। Envoy क्लस्टर में एंडपॉइंट की एक सूची होती है, अर्थात, प्रसंस्करण अनुरोधों के लिए इंस्टेंस का IP (या होस्टनाम)। Istio sidecar-pod में कॉन्फ़िगर किए गए समूहों की सूची देखने के लिए, istioctl proxy-config cluster < > चलाएँ। यह कमांड चूल्हा के संदर्भ में मामलों की वर्तमान स्थिति को दर्शाता है। यहाँ हमारे वातावरण में से एक से एक उदाहरण है:

 $ istioctl proxy-config cluster taxparams-6777cf899c-wwhr7 -n applications SERVICE FQDN PORT SUBSET DIRECTION TYPE BlackHoleCluster - - - STATIC accounts-grpc-gw.applications.svc.cluster.local 80 - outbound EDS accounts-grpc-public.applications.svc.cluster.local 50051 - outbound EDS addressvalidator.applications.svc.cluster.local 50051 - outbound EDS 

सभी समान सेवाएँ इस नामस्थान में हैं:

 $ kubectl get services NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) accounts-grpc-gw ClusterIP 10.3.0.91 <none> 80/TCP accounts-grpc-public ClusterIP 10.3.0.202 <none> 50051/TCP addressvalidator ClusterIP 10.3.0.56 <none> 50051/TCP 

Istio कैसे जानता है कि कौन सा प्रोटोकॉल सेवा का उपयोग करता है? पोर्ट प्रविष्टि में name फ़ील्ड द्वारा सेवा मैनिफ़ेस्ट के लिए प्रोटोकॉल कॉन्फ़िगर करता है।

 $ kubectl get service accounts-grpc-public -o yaml apiVersion: v1 kind: Service metadata: name: accounts-grpc-public spec: ports: - name: grpc port: 50051 protocol: TCP targetPort: 50051 

अगर वहाँ grpc या grpc- उपसर्ग है, तो Istio सेवा के लिए HTTP2 प्रोटोकॉल को कॉन्फ़िगर करेगा। हमें कड़वा अनुभव के माध्यम से पता चला कि कैसे प्रॉक्सी नाम का उपयोग करते समय आईआईएसओ पोर्ट नाम भ्रष्ट हो जाता है क्योंकि उन्होंने http या grpc उपसर्ग निर्दिष्ट नहीं किया था ...

यदि आप Envoy में kubectl और व्यवस्थापक पोर्ट फ़ॉरवर्डिंग पृष्ठ का उपयोग करते हैं, तो आप देख सकते हैं कि खाते-जीपीसी-सार्वजनिक एंडपॉइंट्स को पायलट द्वारा Envoy में क्लस्टर के रूप में HTTP2 प्रोटोकॉल के साथ लागू किया गया है। यह हमारी धारणाओं की पुष्टि करता है:

 $ kubectl -n applications port-forward otherpod-dc56885ff-dqc6t 15000:15000 & $ curl http://localhost:15000/config_dump | yq r - ... - cluster: circuit_breakers: thresholds: - {} connect_timeout: 1s eds_cluster_config: eds_config: ads: {} service_name: outbound|50051||accounts-grpc-public.applications.svc.cluster.local http2_protocol_options: max_concurrent_streams: 1073741824 name: outbound|50051||accounts-grpc-public.applications.svc.cluster.local type: EDS ... 

पोर्ट 15000 एनवॉय एडमिन पेज है , जो हर साइड पर उपलब्ध है।

श्रोताओं

श्रोता ट्रैफ़िक पास करने के लिए कुबेरनेट्स एंडपॉइंट्स को पहचानते हैं। पता सत्यापन सेवा का एक समापन बिंदु यहाँ है:

 $ kubectl get ep addressvalidator -o yaml apiVersion: v1 kind: Endpoints metadata: name: addressvalidator subsets: - addresses: - ip: 10.2.26.243 nodeName: ip-10-205-35-230.ec2.internal targetRef: kind: Pod name: addressvalidator-64885ccb76-87l4d namespace: applications ports: - name: grpc port: 50051 protocol: TCP 

इसलिए, पता सत्यापन चूल्हा पोर्ट 50051 पर एक श्रोता है:

 $ kubectl -n applications port-forward addressvalidator-64885ccb76-87l4d 15000:15000 & $ curl http://localhost:15000/config_dump | yq r - ... dynamic_active_listeners: - version_info: 2019-01-13T18:39:43Z/651 listener: name: 10.2.26.243_50051 address: socket_address: address: 10.2.26.243 port_value: 50051 filter_chains: - filter_chain_match: transport_protocol: raw_buffer ... 

मार्गों

इस्तियो में, मानक कुबेरनेट्स इनग्रेड ऑब्जेक्ट के बजाय, एक अधिक सार और कुशल कस्टम संसाधन VirtualService - VirtualService । वर्चुअल्स सर्विस गेटवे को बांधकर अपस्ट्रीम क्लस्टर को रूट करता है। यह है कि इनबर्न कंट्रोलर के साथ कुबेरनेट्स इनग्रेड का उपयोग कैसे करें।

अर्थात्, हम सभी आंतरिक GRPC ट्रैफ़िक के लिए Istio Ingress-Gateway का उपयोग करते हैं:

 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: grpc-gateway spec: selector: istio: ingressgateway servers: - hosts: - '*' port: name: http2 number: 80 protocol: HTTP2 --- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: grpc-gateway spec: gateways: - grpc-gateway hosts: - '*' http: - match: - uri: prefix: /namely.address_validator.AddressValidator retries: attempts: 3 perTryTimeout: 2s route: - destination: host: addressvalidator port: number: 50051 

पहली नज़र में, आप उदाहरण में कुछ भी नहीं समझेंगे। यह यहां दिखाई नहीं दे रहा है, लेकिन इस्तियो-इनग्रेगेटवे परिनियोजन रिकॉर्ड्स जो कि एंडपॉइंट्स के लिए आवश्यक है जो कि istio: ingressgateway आधार पर आवश्यक है istio: ingressgateway इस उदाहरण में, IngressGateway HTTP 80 पर पोर्ट 80 से अधिक सभी डोमेन के लिए ट्रैफ़िक को रूट करता है। VirtualService इस गेटवे के लिए मार्गों को कार्यान्वित करता है, /namely.address_validator.AddressValidator उपसर्ग से मेल खाता है और दो सेकेण्ड में पुनर्प्रयास नियम के addressvalidator अपस्ट्रीम सेवा के लिए पोर्ट addressvalidator माध्यम से addressvalidator गुजरता है।

यदि हम Istio-IngressGateway पॉड पोर्ट को रीडायरेक्ट करते हैं और Envoy कॉन्फ़िगरेशन देखते हैं, तो हम देखेंगे कि VirtualService:

 $ kubectl -n istio-system port-forward istio-ingressgateway-7477597868-rldb5 15000 ... - match: prefix: /namely.address_validator.AddressValidator route: cluster: outbound|50051||addressvalidator.applications.svc.cluster.local timeout: 0s retry_policy: retry_on: 5xx,connect-failure,refused-stream num_retries: 3 per_try_timeout: 2s max_grpc_timeout: 0s decorator: operation: addressvalidator.applications.svc.cluster.local:50051/namely.address_validator.AddressValidator* ... 

इस्तियो में खुदाई करते समय हमने जो गुगली की थी

त्रुटि 503 या 404 होती है

कारण अलग हैं, लेकिन आमतौर पर ये हैं:

• Sidecar एप्लिकेशन पायलट से संपर्क नहीं कर सकते हैं (जांचें कि पायलट चल रहा है)।
• कुबेरनेट्स सेवा मेनिफेस्ट में एक अमान्य प्रोटोकॉल है।
• VirtualService / Envoy कॉन्फ़िगरेशन गलत अपस्ट्रीम क्लस्टर के लिए मार्ग लिखता है। किनारे सेवा से शुरू करें, जहां आप आने वाले ट्रैफ़िक की अपेक्षा करते हैं, और दूत लॉग की जांच करते हैं। या त्रुटियों को खोजने के लिए Jaeger जैसी किसी चीज़ का उपयोग करें।

Istio प्रॉक्सी लॉग्स में NR / UH / UF का क्या अर्थ है?

• एनआर - कोई रूट नहीं।
• UH - अपस्ट्रीम अस्वस्थ (अपस्ट्रीम अपस्ट्रीम)।
• यूएफ - अपस्ट्रीम विफलता (अपस्ट्रीम विफलता)।

Envoy वेबसाइट पर और पढ़ें।

Istio के साथ उच्च उपलब्धता के बारे में

• Istio घटकों के लिए NodeAffinity को अलग-अलग एक्सेस ज़ोन में समान रूप से चूल्हा वितरित करने और प्रतिकृतियों की न्यूनतम संख्या बढ़ाने के लिए जोड़ें।
• कुबेरनेट्स के नए संस्करण को क्षैतिज पॉड ऑटोस्केलिंग सुविधा के साथ लॉन्च करें। सबसे महत्वपूर्ण चूल्हा लोड के आधार पर पैमाने पर होगा।

क्रोनजोब अंत क्यों नहीं करता है?

जब मुख्य कार्यभार पूरा हो जाता है, तो साइडकार कंटेनर काम करना जारी रखता है। समस्या के इर्द-गिर्द काम करने के लिए, क्रोनोजर में साइडकार को एनोटेशन sidecar.istio.io/inject को जोड़कर अक्षम करें sidecar.istio.io/inject: “false” पॉडस्पीक के लिए।

इस्टियो कैसे स्थापित करें?

हम स्पिनेंकर को तैनाती के लिए उपयोग करते हैं, लेकिन हम आमतौर पर नवीनतम हेल्म चार्ट लेते हैं, उन्हें helm template -f values.yml हैं, helm template -f values.yml उपयोग करते हैं। helm template -f values.yml पर फाइल को kubectl apply -f - माध्यम से लागू करने से पहले परिवर्तनों को देखने के लिए प्रतिबद्ध करते हैं kubectl apply -f - । यह विभिन्न संस्करणों में सीआरडी या एपीआई को गलती से नहीं बदलने के लिए है।

इस पोस्ट को लिखने में मदद करने के लिए बॉबी टेबल्स और माइकल हमरा का धन्यवाद।