मैं इस्तियो और दूत के व्यवहार को समझने की कोशिश कर रहा हूँ और प्रॉक्सी कैसे काम करता है!

आइए मान लें कि मैंने एक ऐसा एप्लिकेशन बनाया है जो Google खोज एपीआई को अनुरोध भेजता रहता है। जब मैं इसे अपने k8s क्लस्टर में istio और दूत के साथ साइडकार कंटेनर के रूप में तैनात करता हूं, तो यह कहा जाता है कि सभी अनुरोध प्रॉक्सी/साइडकार कंटेनर के माध्यम से रूट किए जाते हैं।

मेरा प्रश्न है - एप्लिकेशन और प्रॉक्सी/साइडकार दोनों एक ही पॉड में चल रहे हैं और एक ही आईपी साझा कर रहे हैं। ऐप को साइडकार को अनुरोध भेजने के लिए, इसे स्थानीयहोस्ट (यानी प्रॉक्सी सर्वर पोर्ट) को अनुरोध भेजने के लिए संशोधित किया जाना चाहिए ताकि यह Google को अग्रेषित कर सके। लेकिन कैसे एक एप्लिकेशन के आउटबाउंड अनुरोध दूसरे एप्लिकेशन को रूट किए जाते हैं। यह कॉन्फ़िगरेशन कहाँ बनाए रखा जाता है?

क्या कोई इसे अच्छी तरह समझ सकता है कृपया समझाएं?

1
RamPrakash 16 अप्रैल 2020, 07:03

1 उत्तर

सबसे बढ़िया उत्तर

istio-init init कंटेनर का उपयोग iptables नियमों को सेट अप करने के लिए किया जाता है ताकि इनबाउंड/आउटबाउंड ट्रैफ़िक साइडकार प्रॉक्सी से गुजरे। एक इनिट कंटेनर निम्नलिखित तरीकों से एक ऐप कंटेनर से अलग होता है:

यह ऐप कंटेनर शुरू होने से पहले चलता है और यह हमेशा पूरा होने तक चलता है। यदि कई init कंटेनर हैं, तो अगले कंटेनर को शुरू करने से पहले प्रत्येक को सफलतापूर्वक पूरा करना चाहिए।

तो, आप देख सकते हैं कि इस प्रकार का कंटेनर सेट-अप या इनिशियलाइज़ेशन जॉब के लिए कैसे सही है, जिसे वास्तविक एप्लिकेशन कंटेनर का हिस्सा होने की आवश्यकता नहीं है। इस मामले में, istio-init बस यही करता है और iptables नियम सेट करता है।

Istio-proxy यह वास्तविक साइडकार प्रॉक्सी (दूत पर आधारित) है।

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

$ docker inspect b8de099d3510 --format '{{ .State.Pid }}'
4125

$ nsenter -t 4215 -n iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N ISTIO_INBOUND
-N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-N ISTIO_REDIRECT
-A PREROUTING -p tcp -j ISTIO_INBOUND
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_INBOUND -p tcp -m tcp --dport 80 -j ISTIO_IN_REDIRECT
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15001
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -j ISTIO_REDIRECT
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001

उपरोक्त आउटपुट स्पष्ट रूप से दिखाता है कि पोर्ट 80 पर आने वाले सभी ट्रैफ़िक, जो कि वह पोर्ट है जिसे एप्लिकेशन सुन रहा है, अब पोर्ट 15001 पर रीडायरेक्ट किया गया है, जो कि पोर्ट है जिसे istio-proxy, एक Envoy प्रॉक्सी, सुन रहा है। आउटगोइंग ट्रैफिक के लिए भी यही सच है।

अपडेट: istio-init के स्थान पर, अब नए CNI का उपयोग करने का एक विकल्प प्रतीत होता है, जो init कंटेनर और संबंधित विशेषाधिकारों की आवश्यकता को हटा देता है। यह istio-cni प्लगइन वर्तमान Istio इंजेक्टेड पॉड istio-init दृष्टिकोण के स्थान पर इस आवश्यकता को पूरा करने के लिए पॉड्स की नेटवर्किंग सेट करता है।

https://istio.io/blog/2019/data-plane-setup/#traffic-flow-from-application-container-to-sidecar-proxy

1
Arghya Sadhu 16 अप्रैल 2020, 04:16