ठंडा! मुझे लगता है कि हमें इसे निश्चित रूप से विलय करना चाहिए। एक अलग नोट पर, मैं प्रॉक्सी को भारी भार के तहत ~ 30% कोर खा रहा था, मुझे विश्वास करना होगा कि iptables हमें इससे बेहतर प्रदर्शन देगा।

हमें इसे प्राथमिकता देनी होगी - यह लगभग क्यूब-प्रॉक्सी का कुल पुनर्लेखन है और
उसके सभी परीक्षण। इसमें बैक-कम्पेट समस्याएं भी हैं (इस पर काम नहीं करेगा
पुराने कर्नेल या पुराने iptables बायनेरिज़)।

सोम, 26 जनवरी, 2015 पूर्वाह्न 11:06 बजे, ब्रेंडन बर्न्स नोटिफिकेशन @github.com
लिखा था:

ठंडा! मुझे लगता है कि हमें निश्चित रूप से इसमें विलय कर देना चाहिए। एक अलग नोट पर,
मैं देख रहा था कि प्रॉक्सी भारी भार के तहत ~ 30% कोर खा रहा है, मुझे करना है
विश्वास है कि iptables हमें इससे बेहतर प्रदर्शन देगा।

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -71517501
.

शायद इसे समानांतर विकल्प के रूप में लागू करना और धीरे-धीरे माइग्रेट करना समझ में आता है?

सोम, 26 जनवरी 2015 को दोपहर 12:01 बजे टिम होकिन नोटिफिकेशन @github.com
लिखा था:

हमें इसे प्राथमिकता देनी होगी - यह लगभग क्यूब-प्रॉक्सी का कुल पुनर्लेखन है और
उसके सभी परीक्षण। इसमें बैक-कम्पेट समस्याएं भी हैं (इस पर काम नहीं करेगा
पुराने कर्नेल या पुराने iptables बायनेरिज़)।

सोम, 26 जनवरी, 2015 पूर्वाह्न 11:06 बजे, ब्रेंडन बर्न्स नोटिफिकेशन @github.com
लिखा था:

ठंडा! मुझे लगता है कि हमें निश्चित रूप से इसमें विलय कर देना चाहिए। एक अलग पर
ध्यान दें,
मैं देख रहा था कि प्रॉक्सी भारी भार के तहत ~ 30% कोर खा रहा है, मुझे करना है
विश्वास है कि iptables हमें इससे बेहतर प्रदर्शन देगा।

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -71517501

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -71527216
.

मैं किसी और को मनाने की कोशिश कर रहा हूं जो इस कोड को अच्छी तरह से नहीं जानता है
और इसे ले लो। मैं वास्तव में इससे निपटना चाहता हूं, लेकिन यह बेहतर होगा यदि
किसी और ने यह स्थान सीखा (आप नहीं! :)

उस ने कहा, आपने विशाल P1 सूची के बारे में (अच्छा) ईमेल भी भेजा - और I
मत सोचो कि यह अभी तक उस सूची में है।

सोम, 26 जनवरी, 2015 दोपहर 1:06 बजे, ब्रेंडन बर्न्स सूचनाएं @github.com
लिखा था:

शायद इसे समानांतर विकल्प के रूप में लागू करना और धीरे-धीरे माइग्रेट करना बनाता है
समझ?

सोम, 26 जनवरी 2015 को दोपहर 12:01 बजे टिम होकिन नोटिफिकेशन @github.com
लिखा था:

हमें इसे प्राथमिकता देनी होगी - यह लगभग क्यूब-प्रॉक्सी का कुल पुनर्लेखन है
तथा
उसके सभी परीक्षण। इसमें बैक-कम्पैट समस्याएं भी हैं (काम नहीं करेगा
पर
पुराने कर्नेल या पुराने iptables बायनेरिज़)।

सोम, 26 जनवरी, 2015 पूर्वाह्न 11:06 बजे, ब्रेंडन बर्न्स <
सूचनाएं@github.com>
लिखा था:

ठंडा! मुझे लगता है कि हमें निश्चित रूप से इसमें विलय कर देना चाहिए। एक अलग पर
ध्यान दें,
मैं देख रहा था कि प्रॉक्सी भारी भार के तहत ~ 30% कोर खा रहा है, मुझे करना है
विश्वास है कि iptables हमें इससे बेहतर प्रदर्शन देगा।

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -71517501

.

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment-71527216>

.

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -71538256
.

क्या यह P2 है? क्या यह अभी के लिए इसे P3 बनाने लायक हो सकता है?

मैं इसे काम करने की उम्मीद कर रहा हूं, लेकिन हम इसे अभी भी अवनत कर सकते हैं

बुधवार, 11 फरवरी, 2015 दोपहर 2:49 बजे, सतनाम सिंह नोटिफिकेशन @github.com
लिखा था:

क्या यह P2 है? क्या यह अभी के लिए इसे P3 बनाने लायक हो सकता है?

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -73982161
.

क्या "उम्मीद" एक P3 के बराबर नहीं है जो हम कर सकते हैं तो हम प्राप्त करेंगे?

@thockin के साथ चर्चा से: सर्विस पोर्ट रेंज का समर्थन करने के लिए यह एक आवश्यकता है, जो 1.0 के लिए आवश्यक नहीं है, लेकिन हम अंततः समर्थन करना चाहेंगे।

@thockin "यह पुराने iptables और गुठली के साथ संगत नहीं होने का नकारात्मक पक्ष है।" कर्नेल को 'नया' कैसे होना चाहिए?

बहुत नया नहीं है, लेकिन हमारे पास कुछ उपयोगकर्ता हैं जो वास्तव में 2012 से iptables चाहते हैं
काम।

सोम, 23 फरवरी, 2015 अपराह्न 2:44 बजे, सिद्धार्थ सीताना < नोटिफिकेशन @github.com

लिखा था:

@thockin https://github.com/thockin "यह न होने का नकारात्मक पक्ष है
पुराने iptables और गुठली के साथ संगत।" कर्नेल कितना 'नया' होगा?
होना है?

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -75654187
.

@thockin धन्यवाद। हम आरएचईएल/सेंटोस 6 के साथ प्रयोग/परीक्षण कर रहे हैं, उदाहरण के लिए - इसलिए यह अच्छा होगा यदि हमारे पास हाल के 3.x कर्नेल पर कठोर निर्भरता नहीं है।

@pweil- हम दूसरे दिन इस पर चर्चा कर रहे थे
सोम, 23 फरवरी 2015 अपराह्न 11:40 बजे सिद्धार्थ सीताना नोटिफिकेशन @github.com
लिखा था:

@thockin https://github.com/thockin धन्यवाद। हम के साथ प्रयोग/परीक्षण कर रहे हैं
आरएचईएल/सेंटोस 6, उदाहरण के लिए - तो यह अच्छा होगा यदि हमारे पास हार्ड नहीं है
हाल ही में 3.x गुठली पर निर्भरता।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -75698480
.

ठीक है, आपको चलाने के लिए डॉकर की आवश्यकता है, और किसी बिंदु पर हमें इसे काटना होगा।
बैक-रेव iptables समर्थन मुझे (अंततः) बनाने से नहीं रोकेगा
यह परिवर्तन, और यह कुछ लोगों के लिए डंक मारने वाला है।

सोम, 23 फरवरी, 2015 को रात 8:40 बजे, सिद्धार्थ सीताना < नोटिफिकेशन @github.com

लिखा था:

@thockin https://github.com/thockin धन्यवाद। हम के साथ प्रयोग/परीक्षण कर रहे हैं
आरएचईएल/सेंटोस 6, उदाहरण के लिए - तो यह अच्छा होगा यदि हमारे पास हार्ड नहीं है
हाल ही में 3.x गुठली पर निर्भरता।

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -75698480
.

@thockin की मदद से, हमने udp के साथ भी ऐसा ही करने की कोशिश की।

हमने 3 स्काई-डीएनएस प्रतिकृति नियंत्रकों के साथ एक GCE Kubernetes क्लस्टर बनाया है।
कुबेरनेट्स-मास्टर पर, हम निम्नलिखित को iptables में सेट करते हैं:
डीएनएस सेवा आईपी 10.0.0.10 था, और डीएनएस चलने वाले पॉड एंडपॉइंट्स 10.244.0.5:53, 10.244.3.6:53, 10.244.0.6:53 थे।

iptables -t nat -N TESTSVC
iptables -t nat -F TESTSVC
iptables -t nat -N TESTSVC_A
iptables -t nat -F TESTSVC_A
iptables -t nat -N TESTSVC_B
iptables -t nat -F TESTSVC_B
iptables -t nat -N TESTSVC_C
iptables -t nat -F TESTSVC_C
iptables -t nat -N KUBE-PORTALS-HOST
iptables -t nat -F KUBE-PORTALS-HOST

iptables -t nat -A TESTSVC -m हाल ही में --name hostA --rcheck --seconds 1 --reap -j TESTSVC_A
iptables -t nat -A TESTSVC -m हाल ही में --name hostB --rcheck --seconds 1 --reap -j TESTSVC_B
iptables -t nat -A TESTSVC -m हाल ही में --name hostC --rcheck --seconds 1 --reap -j TESTSVC_C

iptables -t nat -A TESTSVC -m आँकड़ा --मोड यादृच्छिक --प्रायिकता 0.333 -j TESTSVC_A
iptables -t nat -A TESTSVC -m आँकड़ा - मोड यादृच्छिक - प्रायिकता 0.5 -j TESTSVC_B
iptables -t nat -A TESTSVC -m आँकड़ा --मोड यादृच्छिक --प्रायिकता 1.000 -j TESTSVC_C

iptables -t nat -A TESTSVC_A -m हाल ही में --name hostA --set -j DNAT -p udp --to-destination 10.244.0.5:53
iptables -t nat -A TESTSVC_B -m हाल ही में --name hostB --set -j DNAT -p udp --to-destination 10.244.3.6:53
iptables -t nat -A TESTSVC_C -m हाल ही में --name hostC --set -j DNAT -p udp --to-destination 10.244.0.6:53
iptables -t nat -A KUBE-PORTALS-HOST -d 10.0.0.10/32 -p udp -m udp --dport 53 -j TESTSVC
iptables -t nat -A OUTPUT -j KUBE-PORTALS-HOST

Kubernetes-master>nsलुकअप Kubernetes.default.kuberenetes.local 10.0.0.10

हमें वापस प्रतिक्रिया मिलती है!

महान सामान! बस FYI करें (हमारी आमने-सामने की बातचीत से पुष्टि करते हुए), सामान्य रूप से कई समवर्ती iptables कमांड चलाना सुरक्षित नहीं है (विभिन्न श्रृंखलाओं को लगता है कि यह ठीक हो सकता है)। iptables libiptc के चारों ओर एक आवरण है, और iptc_commit पर टिप्पणी देखें: http://www.tldp.org/HOWTO/Querying-libiptc-HOWTO/mfunction.html

यह स्पष्ट रूप से 2013 में तय किया गया था, लेकिन शायद तभी जब आप --wait (?) पास करते हैं: http://git.netfilter.org/iptables/commit/?id=93587a04d0f2511e108bbc4d87a8b9d28a5c5dd8

इसका मूल कारण यह है कि iptables प्रभावी रूप से iptables-save / iptables-restore (कम से कम प्रति श्रृंखला) को कॉल करता है; मैंने बहुत सारे कोड देखे हैं जो सिर्फ इसलिए कहते हैं iptables-save & iptables-restore चीजों को जोड़ने और हटाने के बजाय। मेरे पास ऐसा करने के लिए कुछ कोड भी हो सकता है कि अगर यह मददगार हो तो मैं खुदाई कर सकता हूं।

यह मेरे दिमाग को चकरा देता है कि CAS या LL/SC प्रकार के ऑप्स करने का कोई तरीका नहीं है।

हमें --wait के लिए समर्थन जोड़ना चाहिए, हालांकि यह हाल ही में पर्याप्त है कि GCE's
डेबियन-बैकपोर्ट में यह नहीं है।

हो सकता है कि कम से कम हमें रोकने के लिए हमें अपने कोड के अंदर अपना लॉकिंग करना चाहिए
खुद पर कदम रखने से।

गुरु, 26 फरवरी, 2015 दोपहर 1:56 बजे, जस्टिन सांता बारबरा <
सूचनाएं@github.com> ने लिखा:

महान सामान! बस FYI करें (हमारी आमने-सामने की बातचीत से पुष्टि करते हुए),
सामान्य रूप से कई समवर्ती iptables कमांड चलाना सुरक्षित नहीं है
(विभिन्न श्रृंखलाओं को लगता है कि यह ठीक हो सकता है)। iptables चारों ओर एक आवरण है
libiptc, और iptc_commit पर टिप्पणी देखें:
http://www.tldp.org/HOWTO/Querying-libiptc-HOWTO/mfunction.html

यह स्पष्ट रूप से 2013 में तय किया गया था, लेकिन शायद तभी जब आप --wait (?) पास करते हैं:
http://git.netfilter.org/iptables/commit/?id=93587a04d0f2511e108bbc4d87a8b9d28a5c5dd8

इसका मूल कारण यह है कि iptables प्रभावी रूप से iptables-save /
iptables-पुनर्स्थापना (कम से कम प्रति श्रृंखला); मैंने बहुत सारे कोड देखे हैं जो बस
इसलिए चीजों को करने के बजाय iptables-save & iptables-restore कहते हैं
जोड़ने और हटाने के माध्यम से। मेरे पास ऐसा करने के लिए कुछ कोड भी हो सकता है जिसे मैं खोद सकता हूं
ऊपर अगर वह मददगार है।

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -76282629
.

नियमों का एक गुच्छा बनाने के बीच में विफलताओं के मामले में क्या होता है?

उचित प्रश्न - हमें शायद इस बारे में बहुत गंभीरता से सोचना चाहिए कि इसका क्या अर्थ है
इसके बीच में एक त्रुटि का सामना करें

गुरु, 26 फरवरी, 2015 को रात 8:47 बजे, ब्रायन ग्रांट नोटिफिकेशन @github.com
लिखा था:

का एक गुच्छा बनाने के बीच में विफलताओं के मामले में क्या होता है
नियम?

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -76331174
.

@thockin आज आईआरसी से:

net.ipv4.conf.all.route_localnet 127.0.0.1 को DNAT नियमों का लक्ष्य बनने की अनुमति देता है। डॉक्स से :

route_localnet - बूलियन

लूपबैक पतों को मंगल ग्रह का स्रोत या गंतव्य न समझें
रूट करते समय। यह स्थानीय रूटिंग उद्देश्यों के लिए 127/8 के उपयोग को सक्षम बनाता है।
डिफ़ॉल्ट FALSE

क्या हम इसे क्यूबलेट में एकीकृत करेंगे, या इसे एक अलग डेमॉन में रखेंगे? Kubelet पहले से ही env vars को पॉप्युलेट करने के लिए सेवाओं को देखता है।

मैं इसे एक अलग बाइनरी के रूप में रखना चाहता हूं। ऐसे कारण हैं जिनकी वजह से आप
k8s . के बाहर अन्य मशीनों (जैसे पालतू VMs) पर इसे चलाना चाह सकते हैं
k8s सेवाओं तक पहुँच प्राप्त करने के लिए क्लस्टर।

--ब्रेंडन

शुक्रवार, 13 मार्च, 2015 को पूर्वाह्न 11:37 बजे, ब्रायन ग्रांट नोटिफिकेशन @github.com
लिखा था:

क्या हम इसे क्यूबलेट में एकीकृत करेंगे, या इसे एक अलग डेमॉन में रखेंगे?
Kubelet पहले से ही env vars को पॉप्युलेट करने के लिए सेवाओं को देखता है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -79230747
.

पकड़ना। विफलताओं के मामले में क्या होता है (जिनमें से कई होंगे, मुझ पर विश्वास करें) के बारे में, मैं एंटी-एंट्रॉपी दृष्टिकोण का एक बड़ा प्रशंसक हूं - वांछित स्थिति कहीं स्टोर करें, और समय-समय पर वांछित और वास्तविक स्थिति को समेटें (वास्तविक स्थिति को बदलकर ) इस मामले में, शायद उतना ही सरल:

जबकि (सच) {
वास्तविकस्टेट = iptablesSave ()
अगर वास्तविक स्थिति! = वांछित स्थिति {iptablesRestore (वांछित राज्य))
स्लीप_ए_जबकि ()
}

100% सहमत हैं कि iptables लिखने में विफलता से निपटने का यह सही तरीका है
नियम।

शुक्र, मार्च 13, 2015 अपराह्न 1:16 बजे, क्विंटन हूल नोटिफिकेशन @github.com
लिखा था:

पकड़ना। विफलताओं के मामले में क्या होता है (जिनमें से
कई होंगे, मुझ पर विश्वास करें), मैं एंटी-एंट्रॉपी दृष्टिकोण का बहुत बड़ा प्रशंसक हूं

• वांछित स्थिति को कहीं स्टोर करें, और समय-समय पर वांछित मेल करें और
  वास्तविक स्थिति (वास्तविक स्थिति को बदलकर)। इस मामले में, शायद उतना ही सरल:

जबकि (सच) {
वास्तविकस्टेट = iptablesSave ()
अगर वास्तविक स्थिति! = वांछित स्थिति {iptablesRestore (वांछित राज्य))
स्लीप_ए_जबकि ()
}

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -79336296
.

कमोबेश यही अब होता है, है ना? प्रत्येक अपेक्षित नियम के लिए,
जांचें कि क्या यह मौजूद है और यदि नहीं, तो इसे बनाएं।

शुक्र, मार्च 13, 2015 अपराह्न 2:02 बजे, ब्रेंडन बर्न्स नोटिफ़िकेशन @github.com
लिखा था:

100% सहमत हैं कि iptables लिखने में विफलता से निपटने का यह सही तरीका है
नियम।

शुक्र, मार्च 13, 2015 अपराह्न 1:16 बजे, क्विंटन हूल नोटिफिकेशन @github.com
लिखा था:

पकड़ना। विफलताओं के मामले में क्या होता है (जिनमें से
बहुत सारे होंगे, मेरा विश्वास करो), मैं एंटी-एंट्रॉपी का बहुत बड़ा प्रशंसक हूं
पहुंचना

• वांछित स्थिति को कहीं स्टोर करें, और समय-समय पर वांछित मेल करें और
  वास्तविक स्थिति (वास्तविक स्थिति को बदलकर)। इस मामले में, शायद उतना ही सरल
  जैसा:

जबकि (सच) {
वास्तविकस्टेट = iptablesSave ()
अगर वास्तविक स्थिति! = वांछित स्थिति {iptablesRestore (वांछित राज्य))
स्लीप_ए_जबकि ()
}

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -79336296

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -79392626
.

मैं सहमत हूं कि एक अलग बाइनरी में उपयोगिता है, लेकिन हो सकता है कि हम इसे इसमें लिंक करें
क्यूबलेट (उसी तरह cAdvisor जा रहा है) और इसे एक स्टैंडअलोन बनाएं
उसी समय।

शुक्र, मार्च 13, 2015 अपराह्न 12:03 बजे, ब्रेंडन बर्न्स नोटिफिकेशन @github.com
लिखा था:

मैं इसे एक अलग बाइनरी के रूप में रखना चाहता हूं। ऐसे कारण हैं जिनकी वजह से आप
k8s . के बाहर अन्य मशीनों (जैसे पालतू VMs) पर इसे चलाना चाह सकते हैं
k8s सेवाओं तक पहुँच प्राप्त करने के लिए क्लस्टर।

--ब्रेंडन

शुक्रवार, 13 मार्च, 2015 को पूर्वाह्न 11:37 बजे, ब्रायन ग्रांट नोटिफिकेशन @github.com
लिखा था:

क्या हम इसे क्यूबलेट में एकीकृत करेंगे, या इसे एक अलग डेमॉन में रखेंगे?
Kubelet पहले से ही env vars को पॉप्युलेट करने के लिए सेवाओं को देखता है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -79230747

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -79257059
.

मुझे यह जानने के लिए उत्सुकता होगी कि कुबेरनेट्स-मेसोस के लोगों का क्या कहना है कि क्या नोड घटकों को अधिक एकीकृत या मॉड्यूलर होना चाहिए। @jdef?

[[संपादित]] मुझे वास्तव में k8s घटकों की प्रतिरूपकता पसंद है, उदाहरण के लिए क्यूबलेट प्रक्रिया से अलग प्रॉक्सी प्रक्रिया चलाना। यदि प्रॉक्सी किसी भी कारण से विफल हो जाता है तो यह क्यूबलेट को नीचे नहीं ले जाता है। यह बहुत अच्छा है क्योंकि मेसोस निष्पादकों के पास अभी बहुत सुंदर विफलता मॉडल नहीं है - और कुबेरनेट्स-मेसोस फ्रेमवर्क का निष्पादक एक क्यूबलेट/निष्पादक हाइब्रिड है। यह मॉडल मुझे मेसोस मास्टर पर एक प्रॉक्सी सेवा चलाने देता है और बाहरी क्लाइंट के लिए राउंड-रॉबिन बैलेंसर के रूप में इसका उपयोग करता है (जैसा कि हमारे द्वारा सबमिट की गई आरंभिक मार्गदर्शिका में)।

पैकिंग/शिपिंग बायनेरिज़ के संदर्भ में, मुझे लगता है कि हाइपरक्यूब के रूप में कार्यक्षमता को एक साथ पैक करना बहुत उपयोगी है। मैंने यह भी सोचा है कि कुबेरनेट्स-मेसोस फ्रेमवर्क घटकों को न्यूनतम डॉकर कंटेनरों में कैसे पैकेज किया जाए। Iptables में बाहरी पुस्तकालय निर्भरताएं हैं और यह चीजों को जटिल बनाती है। तो एक अच्छा समझौता k8sm ढांचे को एक डॉकर के रूप में शिप करना हो सकता है जिसमें एकल हाइपरक्यूब छवि होती है - लेकिन जब वह ढांचा निष्पादित होता है और क्लस्टर में क्यूबलेट-निष्पादक वितरित करना शुरू करता है, तो यह मूल रूप से एक हाइपरक्यूब छवि को शिप करता है जो या तो क्यूबलेट में रूपांतरित हो सकता है- निष्पादक या प्रॉक्सी - और प्रत्येक प्रक्रिया सीधे होस्ट पर चल सकती है। यह मूल रूप से iptables- {बायनेरिज़, लाइब्रेरी}-इन-डॉकर निर्भरता समस्या के आसपास एक एंड-रन करता है।

मॉड्यूलर कार्यक्षमता के लिए +1, एकल बाइनरी छवि के लिए +1

@thockin पुन: एंटी-एन्ट्रॉपी: आह हाँ। मैं प्रॉक्सीयर देखता हूं। सिंकलूप() ऐसा करता है। किस मामले में 26 फरवरी के @bgrant0607 के प्रश्न का उत्तर नहीं है कि त्रुटियों को अनदेखा किया जा सकता है और SyncLoop() (वर्तमान में 1 मिनट) के अगले पुनरावृत्ति पर मरम्मत की जाएगी? या शायद मुझे कुछ याद आ रहा है?

@thockin

1. क्या हम ब्लैक होल-आईएनजी नेटवर्क ट्रैफ़िक के बारे में चिंतित हैं या यह कुछ ऐसा है जिसे सेवा/पॉड लेखक को ध्यान रखने की आवश्यकता है?

यूजरस्पेस प्रॉक्सी के साथ
मान लें कि वर्चुअल आईपी 10.0.0.11 में 3 समापन बिंदु हैं, 10.240.1.1, 10.240.1.2, 10.240.1.3
उपयोगकर्ता-स्थान प्रॉक्सी के साथ, यदि एक समापन बिंदु कहता है, 10.240.1.1 ने काम नहीं किया, तो प्रॉक्सी को पता चल जाएगा कि tcp कनेक्शन 10.240.1.1 के साथ स्थापित नहीं किया गया था, और यह अन्य 2 समापन बिंदुओं में से एक पर वापस आ सकता है।

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

या हो सकता है, गैर-उत्तरदायी समापन बिंदुओं के बारे में चिंता करना कुबेरनेट्स सिस्टम की जिम्मेदारी नहीं है और क्या पॉड लेखक की जिम्मेदारी है?

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

मैं इसे जीएसओसी के लिए देख रहा हूं, और मैं सोच रहा हूं:

तो आदर्श रूप से हम गीले iptables का उपयोग करने के लिए पर्याप्त रूप से नया है और अन्यथा क्यूब-प्रॉक्सी का उपयोग जारी रखेंगे?

https://github.com/GoogleCloudPlatform/kubernetes/issues/5419 से ऐसा लगता है कि यह आदर्श दृष्टिकोण होगा; क्यूबलेट के साथ आईपी-टेबल का उपयोग करने या क्यूब-प्रॉक्सी शुरू करने के लिए गीलेर का निर्धारण।

मुझे जीएसओसी में भी थोड़ी देर हो गई है (वसंत की छुट्टी पर था ....), इसलिए मैं यह भी सोच रहा हूं कि क्या मैं कल/बाद में आज भी इसके लिए जीएसओसी प्रस्ताव जमा कर सकता हूं (निश्चित रूप से 27 वीं समय सीमा के अलावा, है यह अभी भी खुला है)?

@BenTheElder हां, आपके पास प्रस्ताव जमा करने के लिए शुक्रवार तक का समय है। इस विषय में संभावित रूप से एक अन्य व्यक्ति की दिलचस्पी है, लेकिन इसके लिए अभी तक कोई विशिष्ट प्रस्ताव नहीं है।

मैं 2012 से पुराने कर्नेल के बारे में उतना चिंतित नहीं हूं जितना कि मैं पूरी तरह से iptables के बिना OSes के बारे में हूं, हालांकि वे पहले से ही कुछ हद तक टूट चुके हैं।

@ bgrant0607 धन्यवाद!
मुझे लगता है कि मैं तब इस मुद्दे को चुन सकता हूं। दिलचस्प लगता है।

एप्लिकेशन स्टार्टअप के लिए तैयारी जांच अच्छी तरह से काम करेगी लेकिन मुझे यकीन नहीं है कि तैयारी एप्लिकेशन विफलता को कम करने के लिए उपयुक्त है। पॉड के विफल होने पर, सिग्नल को एप्लिकेशन से पास होना चाहिए -> क्यूबलेट -> एपिसर्वर -> एंडपॉइंट्स_कंट्रोलर -> एपिसर्वर -> क्यूब-प्रॉक्सी। मुझे एप्लिकेशन विफलता और क्यूब-प्रॉक्सी रोटेशन से एंडपॉइंट हटाने के बीच विलंबता को समझने में दिलचस्पी होगी। इस अवधि के दौरान, अनुरोधों को एक गैर-प्रतिक्रियात्मक समापन बिंदु पर प्रॉक्सी किया जाएगा।

कनेक्शन विफलता पर पुन: प्रयास करना एक सामान्य रणनीति है, और कई लोकप्रिय लोड बैलेंसर्स (जैसे हैप्रोक्सी, एडब्ल्यूएस ईएलबी) की यथोचित उपयोगी विशेषता है और इसे क्यूब-प्रॉक्सी के वर्तमान कार्यान्वयन द्वारा नियंत्रित किया जाता है। क्या इस जिम्मेदारी को बाहरी एलबी में स्थानांतरित कर दिया जाना चाहिए? इंट्रा-क्लस्टर ट्रैफ़िक के बारे में क्या?

एक और विचार, iptables के साथ हम संभावित रूप से वास्तविक एलबी बनाम पुन: संयोजन पर इनायत से कनेक्शन की निकासी के मुद्दों का सामना करेंगे।

माइक अच्छे अंक उठाता है।

सोम, मार्च 23, 2015 अपराह्न 11:00 बजे, माइक डैनी नोटिफिकेशन @github.com
लिखा था:

एक और विचार, हम संभावित रूप से इनायत से मुद्दों का सामना करेंगे कनेक्शन
एक वास्तविक एलबी बनाम पुन: संयोजन पर जल निकासी।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -85354865
.

मैं क्यूब-प्रॉक्सी और प्रॉक्सी पीकेजी के स्रोत के माध्यम से पढ़ रहा हूं; क्या वर्तमान संशोधन में iptables का पहले से उपयोग नहीं किया जा रहा है?

इस पर वास्तव में क्या करने की आवश्यकता है? वर्तमान मास्टर स्रोत से ऐसा लगता है कि iptables पहले से ही प्रॉक्सी में काफी व्यापक रूप से उपयोग किया जा रहा है।

@mikedanese @thockin तैयारी नियोजित आउटेज के लिए सबसे उपयोगी है। अनियोजित आउटेज हमेशा कुछ नमूदार त्रुटियों का कारण बनेगा। मतदान अंतराल आम तौर पर अद्यतन विलंबता के सापेक्ष लंबा होना चाहिए, लेकिन हम क्यूबलेट और क्यूब-प्रॉक्सी के बीच सीधे संचार के माध्यम से गंतव्य नोड पर पुन: अग्रेषण नियम भी डाल सकते हैं, अगर एपिसर्वर और आदि के माध्यम से विलंबता बहुत लंबी है और/या वह पथ पर्याप्त विश्वसनीय नहीं है।

@BenTheElder मौजूदा नियम प्रॉक्सी के माध्यम से ट्रैफ़िक को रूट करते हैं। यहाँ विचार प्रॉक्सी को बायपास करने के लिए नियमों का उपयोग करना है।

@ bgrant0607 धन्यवाद, यह अब पूरी तरह से समझ में आता है। स्रोत और डिज़ाइन दस्तावेज़ों के माध्यम से एक और पढ़ा गया और मैं लगभग एक मसौदा प्रस्ताव लिख रहा हूं।

मसौदा जीएसओसी प्रस्ताव: https://gist.github.com/BenTheElder/ac61900595a7ea9ea9b5

मैं विशेष रूप से शेड्यूल अनुभाग पर प्रतिक्रिया की सराहना करता हूं। मुझे इस पर पूरा यकीन नहीं है।
क्या मुझे जल्दी खत्म कर देना चाहिए मैं कुछ अन्य (छोटे?) गैर-ले गए जीएसओसी मुद्दों पर काम करना पसंद करूंगा जैसे:
https://github.com/GoogleCloudPlatform/kubernetes/issues/1651।

फिर से धन्यवाद, कुबेरनेट्स सबसे दोस्ताना समूह के लिए केक लेता है।

मैं केवल यह कहना चाहता हूं कि मुझे यह कहते हुए बहुत खुशी हो रही है कि मेरा प्रस्ताव स्वीकार कर लिया गया है और मैं गर्मियों में इस पर काम करूंगा। :स्माइली:

मै बहुत उत्तेजित हूँ। दुर्भाग्य से मैं अभी अपने फाइनल के बीच में हूं, लेकिन इस सप्ताह के अंत में कुछ समय से मुझे बहुत अधिक होना चाहिए और इस पर काम करना चाहिए, सबसे अधिक संभावना https://github.com/GoogleCloudPlatform/kubernetes/pull/7032 प्राप्त करने के साथ शुरू हो रही है ख़त्म होना।

@thockin @brendanburns क्या कोई भी गीलेर पर वजन कर सकता है हम इसे उपयोगकर्ता स्पेस प्रॉक्सी के समानांतर करना चाहते हैं या

ऐसा लगता है कि हम पहले से ही iptables> = 1.4.11 (2011-मई -26 जारी) पसंद करते हैं।

// Executes the rule check without using the "-C" flag, instead parsing iptables-save.
// Present for compatibility with <1.4.11 versions of iptables.  This is full
// of hack and half-measures.  We should nix this ASAP.
func (runner *runner) checkRuleWithoutCheck(table Table, chain Chain, args ...string) (bool, error) {

स्रोत: https://github.com/GoogleCloudPlatform/kubernetes/blob/aec41967416cf3463b188d72c97e71465e00719d/pkg/util/iptables/iptables.go#L206

क्या हम वास्तव में मेजबानों को उससे अधिक उम्र के देखते हैं?

एक दृष्टिकोण स्पष्ट रूप से रन टाइम पर पता लगाना होगा कि हम किस iptables का संस्करण चला रहे हैं, और "सबसे अच्छी बात" करें जिसे हम संस्करण दे सकते हैं जैसे कुछ:

अगर (पुराना संस्करण) {
लोड यूजर स्पेस प्रॉक्सीइंग मॉड्यूल
}
अन्यथा {
लोड iptables प्रॉक्सी मॉड्यूल
}

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

उपरोक्त दृष्टिकोण कितना व्यवहार्य है, यह जानने के लिए मैंने कोड के माध्यम से विस्तार से नहीं निकाला है।

साथ ही, क्या सभी नोड्स को एक ही रणनीति (उपयोगकर्ता स्थान बनाम iptables प्रॉक्सीइंग) को लागू करने की आवश्यकता है, या क्या प्रत्येक स्वतंत्र रूप से निर्णय ले सकता है?

यदि प्रत्येक नोड स्वतंत्र रूप से निर्णय लेता है, तो हम संभावित रूप से परीक्षण सतह क्षेत्र को उपरोक्त में शाखाओं की संख्या के वर्ग के अनुपात में बढ़ाते हैं यदि कथन (यानी स्रोत_मोड x dest_mode), लेकिन अगर हम मोड की संख्या 2 तक रख सकते हैं, तो मुझे लगता है कि यह ठीक है .

क्यू

ओह, और आपके प्रश्न का उत्तर कि क्या हम पुराने नोड्स देखते हैं, दुर्भाग्य से "हां" है।

उपरोक्त के बारे में एक अलग अंक में बहुत चर्चा है।, मैं इसे आपके लिए खोदने की कोशिश करूंगा।

@ क्विंटन-हूल धन्यवाद!

इसके अलावा, मुझे पूरा यकीन है कि हम एक नोड पर यूजर स्पेस और दूसरे पर iptables चला सकते हैं।

जब हमारे पास -C नहीं है, तो उस हैक को छोड़कर मोड की संख्या केवल 2 होनी चाहिए, लेकिन जिन नोड्स में -C है, वे शुद्ध iptables संस्करण (मुझे लगता है) को चलाने में सक्षम होना चाहिए।

आह हाँ, #7528 कर्नेल संस्करणों और इस तरह की चर्चा करता है।

धन्यवाद।
मैंने यह नहीं देखा कि जब मैंने कुबेरनेट्स के लिए आवश्यकताओं की तलाश की। मुझे मिली एकमात्र आवश्यकताएं नेटवर्किंग दस्तावेज़ों में चर्चा कर रही थीं कि हम अद्वितीय आईपी कैसे मानते हैं।

एक बार हमारे पास बेहतर विचार होने के बाद कि वे क्या हैं, हमें शायद आवश्यकताओं के लिए कुछ दस्तावेज लिखे जाने चाहिए।

मैंने यहां इस पर हैकिंग शुरू कर दी है: https://github.com/BenTheElder/kubernetes/tree/iptables_proxy

विशेष रूप से मैंने यहां एक इंटरफ़ेस के पीछे उपयोगकर्ता-स्थान कार्यान्वयन को स्थानांतरित कर दिया है:
https://github.com/BenTheElder/kubernetes/commit/4e5d24bb74aca43b0dd37cf5cfee8a34f8eff2bf

मुझे अब यकीन नहीं है कि अगर कार्यान्वयन चयन cmd/kube-proxy या pkg/proxy में होना चाहिए, तो मैं इसे हटा सकता हूं और इसके बजाय क्यूब-प्रॉक्सी द्वारा कार्यान्वयन का चयन किया जा सकता है।

संपादित करें: मुझे लगता है कि पूर्व-निरीक्षण में यह शायद क्यूब-प्रॉक्सी से कार्यान्वयन का चयन करने के लिए और अधिक समझ में आता है।

@BenTheElder मैंने कैलिको के साथ टिम के नियमों का परीक्षण किया और वे ठीक काम करते हैं। हम अपना सारा काम फिल्टर टेबल में करते हैं, इसलिए यहां डीएनएटी नियमों ने उस बिंदु से उपयुक्त स्रोत आईपी निर्धारित किया है।

अधिक सामान्यतः, यह परिभाषित करने के लिए चर्चा करना अच्छा होगा कि कैसे नेटवर्क प्लगइन्स iptables को सुरक्षित रूप से बदल सकते हैं यदि कुबेरनेट्स भी वहां नियम डालने जा रहे हैं। कुबेरनेट्स नियमों को रौंदना (या रौंदना) नहीं चाहते हैं यदि वे सड़क को बदलते हैं।

@ सममित हाँ। मैं अभी तक प्लगइन्स भाग के बारे में निश्चित नहीं हूं, लेकिन यह बहुत महत्वपूर्ण प्रतीत होता है।

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

क्या आपको इस बात का कोई अंदाजा है कि आप इसे कैसा दिखना चाहते हैं/इसे कैसे काम करना चाहिए?

एफडब्ल्यूआईडब्ल्यू, मैंने कुछ ऐसा किया जो हमारे लिए काम करता है क्योंकि क्यूब-प्रॉक्सी लगभग अनुत्तरदायी होता जा रहा था। यह यहाँ है: https://github.com/MikaelCluseau/kubernetes-iptables-proxy/blob/master/iptables-routing.rb।

मैंने इस धागे को पहले नहीं देखा था, लेकिन मैं कुछ करीब से समाप्त होता हूं, सिवाय इसके कि मैंने अपने यादृच्छिक आंकड़े मिलान वजन के साथ गलती की :-)

मैं यह भी साझा करना चाहूंगा कि हमने nf_conntrack_max को शीघ्रता से प्राप्त कर लिया है। शायद इसे बढ़ाया जाना चाहिए।

# cat /etc/sysctl.d/nf_conntrack.conf 
net.netfilter.nf_conntrack_max = 1000000
net.nf_conntrack_max           = 1000000

हो सकता है कि मैं iptables की सभी ज़रूरतों को नहीं समझता, लेकिन इसके बजाय IPVS का उपयोग क्यों नहीं कर रहा हूं?
यह iptables की तुलना में प्रॉक्सी के लिए अधिक प्रासंगिक प्रतीत होता है ...
यहाँ एक सरल कार्यान्वयन है: https://github.com/noxioz/go-ipvs
और सिर्फ #561 को पूरा करने के लिए ktcpvs प्रोजेक्ट भी है।

IPVS भी नेटफिल्टर (जैसे iptables) पर एक अमूर्तता प्रतीत होता है। हम iptables का उपयोग करके मौजूदा कोड के साथ कुछ कार्यक्षमता साझा करने में सक्षम हैं; और iptables नेटफिल्टर के प्रबंधन के लिए अधिक लचीले/सामान्य समाधान की तरह लगता है।

जहाँ तक #561 और ktcpvs का प्रश्न है: ktcpvs का 2004 के बाद से कोई विकास नहीं हुआ है और ऐसा प्रतीत नहीं होता है कि उपयोगकर्ता URL पुनर्लेखन जैसी सुविधाएँ चाहते हैं। भले ही #561 प्लग करने योग्य बैलेंसर्स के साथ प्रयोग करने योग्य होने के लिए एक सामान्य समाधान की तलाश में है।

साइड नोट: उस गो प्रोजेक्ट के पास लाइसेंस नहीं है।

iptables को nftables ( nft cli) के पक्ष में "एक दिन" हटा दिया जाएगा।
नियम बनाने के लिए iptables CLI का उपयोग करना भी काफी मजबूत नहीं लगता है ...

एक त्वरित खोज मुझे यह अन्य एमआईटी परियोजना ढूंढती है: https://github.com/vieux/go-libipvs
लेकिन ऐसा लगता है कि एक साधारण कामकाजी बनाना वास्तव में काफी आसान है क्योंकि कर्नेल कोड के अंदर सभी जटिलता पहले से ही बुलेटप्रूफ है।

मुझे संदेह है कि iptables को किसी भी प्रमुख डिस्ट्रोस से जल्द ही हटा दिया जाएगा, और iptables CLI विशेष रूप से netfilter के लिए नियम बनाने और प्रबंधित करने के लिए है ...?

लिंक किए गए की तरह एक अधूरा cgo रैपर iptables और iptables-restore लिए खोलने की तुलना में बहुत कम सुरक्षित लगता है और हमें पहले से ही अन्य नियमों (जैसे नोडपोर्ट्स) के लिए और iptables-restore साथ iptables की आवश्यकता है। हम कुछ परमाणु के साथ बल्क अपडेट कर सकते हैं।

ऐसा लगता है कि आईपीवीएस को "वास्तविक" सर्वर से अलग लोड बैलेंसिंग होस्ट मशीन पर इस्तेमाल करने के लिए डिज़ाइन किया गया है।
इससे पता चलता है कि केवल समर्थित उपयोग होना:

2.2. Gotchas: आपको बाहरी क्लाइंट की आवश्यकता है (निर्देशक और रीयलसर्वर वर्चुअल सेवा तक नहीं पहुंच सकते हैं)

LVS को स्थापित और परीक्षण/चलाने के लिए, आपको कम से कम 3 मशीनों की आवश्यकता होगी: क्लाइंट, डायरेक्टर, रियलसर्वर।

बाहर से, LVS एक मशीन के रूप में कार्य करता है। क्लाइंट एलवीएस (निदेशक, या रीयलसर्वर) में मशीनों में से एक नहीं हो सकता है। आपको एक बाहरी ग्राहक की आवश्यकता है। यदि आप LVS की किसी भी मशीन से LVS नियंत्रित सेवा (जैसे http, smtp, टेलनेट) तक पहुँचने का प्रयास करते हैं; डायरेक्टर से एक्सेस हैंग हो जाएगा, रियलसर्वर से एक्सेस LVS को दरकिनार करते हुए लोकल सर्विस से कनेक्ट हो जाएगा।

ऐसा भी लगता है कि आईपीवीएस/एलवीएस कुछ अतिरिक्त आवश्यकताओं को जोड़ता है जैसे दिल की धड़कन डेमॉन और अतिरिक्त निगरानी प्रक्रियाएं। हम पहले से ही कुबेरनेट्स के भीतर से समापन बिंदु जानकारी और पॉड स्वास्थ्य निगरानी आदि को संभालते हैं।

iptables दृष्टिकोण के लिए +1। हम कैलिको में बड़े पैमाने पर iptables का उपयोग करते हैं और वे मजबूत साबित हुए हैं और वे अच्छा प्रदर्शन करते हैं और स्केल करते हैं (यह मानते हुए कि आप अपने नियमों को अच्छी तरह से डिजाइन करते हैं)। @BenTheElder , क्या आपको iptables के किसी भी काम में मदद की ज़रूरत है, तो कृपया हमें बताएं, क्योंकि हमें इसमें चिप करने में खुशी होगी।

iptables और iptables-restore के लिए +1, यह बहुत कम भारी-भरकम दृष्टिकोण है
आईपीवीएस/एलवीएस की तुलना में और कम सिस्टम आवश्यकताओं को निर्धारित करता है (दिल की धड़कन डेमन,
आदि।)

शनिवार, 13 जून, 2015 पूर्वाह्न 11:27 बजे, एलेक्स पोलिट नोटिफिकेशन @github.com
लिखा था:

iptables दृष्टिकोण के लिए +1। हम कैलिको में बड़े पैमाने पर iptables का उपयोग करते हैं और
वे मजबूत साबित हुए हैं और वे अच्छा प्रदर्शन करते हैं और बड़े पैमाने पर (आपको मानते हुए)
अपने नियमों को अच्छी तरह से डिजाइन करें)। @BenTheElder https://github.com/BenTheElder ,
क्या आपको iptables काम करने में किसी भी मदद की ज़रूरत है तो कृपया जाने दें
हमें पता है, क्योंकि हमें इसमें शामिल होने में खुशी होगी।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -111719474
.

धन्यवाद एलेक्स, अगर मैं करता हूं तो मैं आपको बता दूंगा।

यदि किसी के पास समय है तो मैं वर्तमान कार्यान्वयन पर कुछ प्रतिक्रिया/इनपुट का उपयोग कर सकता हूं (https://github.com/GoogleCloudPlatform/kubernetes/pull/9210)।

यह अधिकतर पूर्ण है और वर्तमान में अपस्ट्रीम मास्टर के साथ अद्यतित है, मुझे कोड लिखना समाप्त करना होगा जो जेनरेट किए गए नियमों की तुलना iptables-save से करता है और काउंटर इत्यादि को पुनर्स्थापित करता है, लेकिन नियम उत्पन्न होते हैं और (ज्यादातर) काम करते हैं, ओपी में उल्लिखित नियमों का बहुत पालन करते हुए यहां सबसे बड़ा बदलाव सिर्फ चेन नाम है, जो कि iptables स्वीकार किए जाने वाले नामों की स्वचालित पीढ़ी के लिए आवश्यक था।

यहां एक किनारे का मामला बताया गया है: https://github.com/BenTheElder/kubernetes/issues/3 जिसे पॉड्स को खुद से जोड़ने के लिए बदलाव की आवश्यकता हो सकती है।

मेरे पास @MikaelCluseau और @Symmetric के साथ कुछ उत्कृष्ट प्रतिक्रिया और चर्चा है, विशेष रूप से इसे और अन्य चीजों को संभालने के लिए कुछ नया स्वरूप करने के बारे में (धन्यवाद फिर से!); लेकिन हम विशेष रूप से नियम डिजाइन पर कुछ और इनपुट का उपयोग कर सकते हैं। अगर किसी और के पास देखने का समय है तो इसकी बहुत सराहना की जाएगी क्योंकि मुझे यकीन नहीं है कि सबसे अच्छा मार्ग क्या है और मैं अधिक इनपुट के बिना कोई बड़ा बदलाव करने से बचना चाहता हूं।

पीआर अपने आप में बहुत बड़ा है लेकिन प्रासंगिक नियम निर्माण pkg/proxy/proxieriptables.go syncProxyRules() में है: https://github.com/BenTheElder/kubernetes/blob/iptables_proxy/pkg/proxy/proxieriptables। जाओ#L286

मौजूदा चर्चा (यहां निश्चित रूप से) और साथ ही पीआर टिप्पणी में और में देखा जा सकता https://github.com/BenTheElder/kubernetes/issues/3 रूप में अच्छी तरह थोड़ा के रूप में अधिक से https://github.com/ BenTheElder/kubernetes/issues/4.

एक अन्य मुद्दा जिसमें इनपुट की आवश्यकता है:

वर्तमान कोड में क्यूब-प्रॉक्सी अभी भी शामिल है, केवल नोडपोर्ट मामले को संभालने के लिए। मुझे लगता है कि हम इस मामले में भी क्यूब-प्रॉक्सी से दूर हो सकते हैं, और बेन के पीआर पर ऐसा करने के लिए कुछ सरल iptables नियम प्रस्तावित किए हैं।

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

मुझे संदेह है कि HTTP प्रॉक्सी को खुश रखने के लिए हम कुछ जादू कर सकते हैं, लेकिन मुझे एल 4 पर इसे सामान्य बनाने का कोई तरीका नहीं दिख रहा है।

मैं आपके पीआर से काला जादू करने की कोशिश कर रहा हूं, लेकिन यह मेरे लिए कुछ भी उत्पन्न नहीं करता है, ऐसा लगता है कि नियमों को iptables पर कॉल के साथ उत्पन्न किया जाना शुरू हुआ, फिर एक iptables-restore फ़ाइल तैयार की जाती है।

उत्पादित फ़ाइल में हेडर भाग में एक मिस है, आमतौर पर जिन्हें iptables कॉल के साथ पॉप्युलेट किया गया है, लॉग का प्रासंगिक हिस्सा है:

I0807 11:41:24.560063 8369 iptables.go:327] चल रहे iptables -N [KUBE-PORTALS-CONTAINER -t nat]
I0807 11:41:24.562361 8369 iptables.go:327] iptables -C चल रहा है [PREROUTING -t nat -m comment --comment handle ClusterIPs; नोट: यह NodePort नियमों से पहले होना चाहिए -j KUBE-PORTALS-CONTAINER]
I0807 11:41:24.563469 8369 iptables.go:327] रनिंग iptables -N [KUBE-PORTALS-HOST -t nat]
I0807 11:41:24.565452 8369 iptables.go:327] iptables -C चल रहा है [OUTPUT -t nat -m comment --comment handle ClusterIPs; नोट: यह NodePort नियमों से पहले होना चाहिए -j KUBE-PORTALS-HOST]
I0807 11:41:24.566552 8369 iptables.go:327] चल रहे iptables -N [KUBE-NODEPORT-CONTAINER -t nat]
I0807 11:41:24.568363 8369 iptables.go:327] iptables -C चल रहा है [PREROUTING -t nat -m addrtype --dst-type LOCAL -m comment --comment handle service NodePorts; नोट: यह श्रृंखला में अंतिम नियम होना चाहिए -j KUBE-NODEPORT-CONTAINER]
I0807 11:41:24.569564 8369 iptables.go:327] रनिंग iptables -N [KUBE-NODEPORT-HOST -t nat]
I0807 11:41:24.571458 8369 iptables.go:327] चल रहे iptables -C [OUTPUT -t nat -m addrtype --dst-type LOCAL -m comment --comment handle service NodePorts; नोट: यह श्रृंखला में अंतिम नियम होना चाहिए -j KUBE-NODEPORT-HOST]
I0807 11:41:24.573392 8369 iptables.go:327] रनिंग iptables -C [POSTROUTING -t nat -m comment --comment हैंडल पॉड को सेल्फ-एस 10.240.240.78/32 -d 10.240.240.78/32 -j MASQUERADE से कनेक्ट करना ]
I0807 11:41:24.574447 8369 proxier.go:349] iptables नियमों को सिंक करना।
I0807 11:41:24.575592 8369 proxier.go:399] चेन: PREROUTING, नियम: :PREROUTING ACCEPT [0:0]
I0807 11:41:24.575615 8369 proxier.go:401] नियम: -एक PREROUTING -m comment --comment "ClusterIPs को हैंडल करें; नोट: यह NodePort नियमों से पहले होना चाहिए" -j KUBE-PORTALS-CONTAINER
I0807 11:41:24.575625 8369 proxier.go:401] नियम: -एक PREROUTING -m addrtype --dst-type LOCAL -m comment --comment "हैंडल सर्विस नोडपोर्ट्स; नोट: यह श्रृंखला में अंतिम नियम होना चाहिए" -जे क्यूब-नोडपोर्ट-कंटेनर
I0807 11:41:24.575633 8369 proxier.go:399] चेन: इनपुट, नियम:: इनपुट स्वीकार करें [0:0]
I0807 11:41:24.575646 8369 proxier.go:399] चेन: OUTPUT, नियम: :OUTPUT ACCEPT [0:0]
I0807 11:41:24.575658 8369 proxier.go:401] नियम: -A OUTPUT -m comment --comment "ClusterIPs को हैंडल करें; नोट: यह NodePort नियमों से पहले होना चाहिए" -j KUBE-PORTALS-HOST
I0807 11:41:24.575670 8369 proxier.go:401] नियम: -A OUTPUT -m addrtype --dst-type LOCAL -m comment --comment "हैंडल सर्विस NodePorts; नोट: यह श्रृंखला में अंतिम नियम होना चाहिए" -जे क्यूब-नोडेपोर्ट-होस्ट
I0807 11:41:24.575683 8369 proxier.go:399] चेन: पोस्टिंग, नियम:: पोस्टरूटिंग स्वीकार [0:0]
I0807 11:41:24.575691 8369 proxier.go:401] नियम: -एक पोस्टिंग! -d 10.0.0.0/8 -o eth0 -j MASQUERADE
I0807 11:41:24.575699 8369 proxier.go:401] नियम: -एक पोस्टिंग -s 10.240.240.78/32 -d 10.240.240.78/32 -m टिप्पणी --comment "हैंडल पॉड कनेक्टिंग सेल्फ" -j MASQUERADE
I0807 11:41:24.575709 8369 proxier.go:399] चेन: KUBE-NODEPORT-कंटेनर, नियम: :KUBE-NODEPORT-CONTAINER - [0:0]
I0807 11:41:24.575720 8369 proxier.go:399] चेन: KUBE-NODEPORT-HOST, नियम: :KUBE-NODEPORT-HOST - [0:0]
I0807 11:41:24.575729 8369 proxier.go:399] चेन: क्यूब-पोर्टल्स-कंटेनर, नियम:: क्यूब-पोर्टल्स-कंटेनर - [0:0]
I0807 11:41:24.575740 8369 proxier.go:399] चेन: KUBE-PORTALS-HOST, नियम: :KUBE-PORTALS-HOST - [0:0]
I0807 11:41:24.581897 8369 proxier.go:603] सिंकिंग नियम: :KUBE-PORTALS-HOST - [0:0]
:क्यूब-पोर्टल्स-कंटेनर - [0:0]
:कुबे-नोडेपोर्ट-होस्ट - [0:0]
:कुबे-नोडेपोर्ट-कंटेनर - [0:0]
:KUBE-SVC-VO8JL93ZeRSf8cnsLpl - [0:0]
:KUBE-SVC-L26cB3JYuxdW5TF84ct - [0:0]
:KUBE-SVC-j2SF8q3nUajS8vOx2qL - [0:0]
:KUBE-SVC-shln2urO8W1aBiB2bWJ - [0:0]
:KUBE-SVC-8jQ3IvijvhJ4ppFj3Ui - [0:0]
[... एसएनआईपी ...]

वर्बोज़ मोड में उत्पादित परिणाम के साथ एक iptable-save को मर्ज करके आयात किया जा सकता है और अच्छी चीजें कर सकता है।

@bnprss रिपोर्ट के लिए धन्यवाद, समीक्षा प्रक्रिया के लिए कुछ पुनर्लेखन के दौरान एक अस्थायी फ़ाइल का उपयोग करने और iptables-restore के लिए "-T तालिका" ध्वज का उपयोग करने सहित हाल ही में कई अप्रयुक्त परिवर्तन हुए। एक बार जब मुझे पता चल जाएगा कि प्रतिगमन (ओं) का कारण क्या है, तो मैं इसे ठीक कर दूंगा।

@bnprss जैसा आपने कहा था कि टेबल हेडर गायब है ("* नेट" पहली पंक्ति होनी चाहिए), इसे गलती से हटा दिया गया था और इसे वापस सब कुछ में डालने के बाद प्रतीत होता है कि कोई अन्य बग नहीं है (छोड़कर: https: / /github.com/BenTheElder/kubernetes/issues/3)। फिर से धन्यवाद, इसके लिए खेद है। मैंने फिक्स को धक्का दिया है।

अच्छा काम, नियम लोड हो रहे हैं और अंदर से काम करने लगते हैं लेकिन बाहरी लोड बैलेंसर के साथ कोई भाग्य नहीं है, बाहर से कोई संचार जवाब नहीं देता है।

हुह। क्या आप जनसंपर्क में जा सकते हैं और कुछ और विवरण प्रदान कर सकते हैं? अब तक
यह अच्छी तरह से काम कर रहा है लेकिन मैं स्थानीय परीक्षण से परे खुद को तैनात नहीं करता हूं और मैं
ऐसा नहीं लगता कि कोई भी अन्य परीक्षक बाहरी लोड बैलेंसर का उपयोग कर रहा था।
अगस्त 7, 2015 1:29 पीएम, "bnprss" [email protected] लिखा है:

अच्छा काम, नियम लोड हो रहे हैं और अंदर से काम करने लगता है लेकिन कोई भाग्य नहीं
बाहरी लोड बैलेंसर के साथ बाहर से कोई संचार उत्तर नहीं देता है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -128772763
.

हां, विवरण के लिए मैं और पूछताछ करूंगा और पीआर पर कुछ लॉग या लीड तैयार करूंगा, लेकिन कल से पहले नहीं, मैं संभावित रूप से कुछ तोड़ने से पहले चलाने के लिए कुछ अच्छा बैकअप कार्य करना चाहता हूं।

क्या आप विभाजक "-_" के बिना नियमों के टोकन की गणना कर सकते हैं?

@bnprss , बढ़िया।
सेवाओं के लिए जेनरेट की गई नियम श्रृंखलाएं सर्विस पोर्ट/एंडपॉइंट का हैश हैं और फिर बेस 64 यूआरएल एन्कोडेड और छोटा कर दिया गया है। क्यूब-एसवीसी-. कोड यहाँ है: https://github.com/GoogleCloudPlatform/kubernetes/pull/9210/files#diff -d51765b83fe795b469e8a86276b12dc9R321
हमने इसे वैध श्रृंखला नाम उत्पन्न करने के तरीके के रूप में चुना है जो अभी भी नियतात्मक होते हुए भी iptables में वर्ण सीमा को पूरा करेगा।
इसलिए इसे बाहरी रूप से दोहराना संभव होना चाहिए।
यदि आपका मतलब है, क्या हम विभाजकों का उपयोग करना बंद कर सकते हैं, तो शायद हम कर सकते हैं लेकिन "_" कुछ एन्कोडेड हैश से आते हैं और "-" सभी मौजूदा यूजरस्पेस प्रॉक्सी से नियम नामों में पैटर्न का पालन कर रहे हैं।
यदि आवश्यक हो तो हम बहुत अधिक परेशानी के बिना शायद कुछ और इस्तेमाल कर सकते हैं।

मैं इसके साथ ठीक हूँ, और यह वास्तव में कॉस्मेटिक है! :)
लेकिन यह उन चीजों से अलग है जिन्हें मैंने पहले देखा था:
जीसीई एलबी नियम: a07f76b3b2ec311e59e2642010af0479
gce fw नियम: k8s-fw-a7ecad94f3ba511e59e2642010af0479
जीसीई रूटिंग नियम: डिफ़ॉल्ट-मार्ग-6973e029b504a0e8
नोड के लिए gce रूटिंग: obfuscated_cluster_node-43506797-2eb2-11e5-9e26-42010af04793

यह एक अच्छा है:
KUBE-SVC-6ADi2TVfn7mFPvBjC56
वे मजाकिया हैं:
KUBE-SVC-zU6ParcQ-UfW_LdRDUc
KUBE-SVC-y--z1xTUpHPT6sgAUCC

हाँ, मैं उनका बिल्कुल भी प्रशंसक नहीं हूँ, हम शायद हैश को बदल सकते हैं
एन्कोडिंग।

शुक्र, अगस्त 7, 2015 में 2:16 प्रधानमंत्री पर bnprss [email protected] लिखा है:

मैं इसके साथ ठीक हूँ, और यह वास्तव में कॉस्मेटिक है! :)
लेकिन यह उन चीजों से अलग है जिन्हें मैंने पहले देखा था:
जीसीई एलबी नियम: a07f76b3b2ec311e59e2642010af0479
gce fw नियम: k8s-fw-a7ecad94f3ba511e59e2642010af0479
जीसीई रूटिंग नियम: डिफ़ॉल्ट-मार्ग-6973e029b504a0e8
नोड के लिए जीसीई रूटिंग:
obfuscated_cluster_node-43506797-2eb2-11e5-9e26-42010af04793

यह एक अच्छा है:
KUBE-SVC-6ADi2TVfn7mFPvBjC56
वे मजाकिया हैं:
KUBE-SVC-zU6ParcQ-UfW_LdRDUc
KUBE-SVC-y--z1xTUpHPT6sgAUCC

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -128785914
.

हां, यह केवल SHA के काटे गए हिस्से का उपयोग करना संभव हो सकता है, git इसके साथ ठीक है, docker भी, और ऐसा लगता है कि क्यूब संस्थाओं के अन्य संदर्भ बनाए गए हैं। उत्पन्न हैश बेस 64 में टक्कर के मामले में मदद नहीं करेगा। ;)
मुझे लगता है कि @thockin उस बिंदु पर सलाह दे सकता है।

मैं iptables में मान्य वर्णों से अधिक चिंतित था, जिसके लिए मुझे एक अच्छा संदर्भ खोजने में कठिनाई हुई। मैं जल्द ही इस पर और गौर करूंगा।

शुक्र, अगस्त 7, 2015 में 2:29 प्रधानमंत्री पर bnprss [email protected] लिखा है:

हां, यह संभव हो सकता है केवल SHA के काटे गए हिस्से का उपयोग करें, git ठीक है
वह, डॉकटर भी, और ऐसा लगता है कि क्यूब का दूसरा संदर्भ है
निकाय बनते हैं। उत्पन्न हैश बेस 64 में टक्कर के मामले में नहीं होगा
मदद। ;)
मुझे लगता है कि @thockin https://github.com/thockin उस बिंदु पर सलाह दे सकता है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -128788454
.

@bnprss fyi पीआर बहुत अस्थिर है और प्रति थॉकिन को फिर से किया जा रहा है, हम अभी के लिए नोडपोर्ट इत्यादि को ट्रिम कर रहे हैं और पोर्टल्स के समर्थन के साथ एक सरल, क्लीनर संस्करण प्राप्त करने पर ध्यान केंद्रित कर रहे हैं, फिर पूर्ण समानता तक काम कर रहे हैं।

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

आप में से जो घर पर खेल रहे हैं, मुझे विश्वास है कि हम इसे पूरा कर सकते हैं
समता, लेकिन चरणों में समीक्षा करना बहुत आसान होगा :)

शुक्र, अगस्त 7, 2015 को रात 9:35 बजे, बेंजामिन एल्डर नोटिफिकेशन @github.com
लिखा था:

उपरोक्त टिप्पणी के लिए मेरा उत्तर, जल्द ही समाप्त होने वाला है:

आईआरसी में चर्चा:

• अभी भी काउंटरों को संभालने की आवश्यकता होगी, लेकिन पार्स करना जारी रखना चाहते हैं
  उपयोग/iptables पैकेज में राज्य।
• अभी भी हैशिंग की आवश्यकता है या श्रृंखला की लंबाई सीमा को संभालने के लिए समान है

अन्यथा एक बहुत ही साफ सरलीकरण की तरह लगता है, बाद में लागू होगा
कुछ और चर्चा।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment-128912169
.

स्थिति: "मुख्य" तर्क की जाँच की जाती है और ध्वजांकित किया जाता है।

मैं अब नोड पोर्ट पर काम कर रहा हूं। बहुत सारे अजीबोगरीब मामले हैं जिन्हें विशेष हैंडलिंग की आवश्यकता होती है। मेरे अब तक के नोट्स:

# Basic node ports:
iptables -t nat -N KUBE-NODEPORTS
iptables -t nat -A PREROUTING -j KUBE-NODEPORTS
iptables -t nat -A OUTPUT -j KUBE-NODEPORTS
iptables -t nat -A KUBE-NODEPORTS -p tcp -m comment --comment "TEST: default/nodeport:p" -m tcp --dport 30241 -j KUBE-SVC-EQKU6GMUKRXBR6NWW53

# To get traffic from node to localhost:nodeport to the service:
echo 1 > /proc/sys/net/ipv4/conf/all/route_localnet
# Mark packets that are destined for services from localhost, then masquerade those
iptables -t nat -I KUBE-SVC-EQKU6GMUKRXBR6NWW53 -s 127.0.0.0/16 -j MARK --set-mark 0x4b000001;
iptables -t nat -A POSTROUTING -m mark --mark 0x4b000001 -j MASQUERADE

# To get traffic from a pod to itself via a service:
for intf in $(ip link list | grep veth | cut -f2 -d:); do brctl hairpin cbr0 $intf on; done
# Mark packets that are destined for each endpoint from the same endpoint, then masquerade those.
# This is hacky, but I don't really know which pods are "local" and I don't really want to right now. (but I will eventually)
iptables -t nat -I KUBE-SEP-HHNEQBOLY57T5MQCFIY -s 10.244.1.6 -j MARK --set-mark 0x4b000001

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

बुध, अगस्त 12, 2015 अपराह्न 8:48 बजे, टिम होकिन सूचनाएं @github.com
लिखा था:

स्थिति: "मुख्य" तर्क की जाँच की जाती है और ध्वजांकित किया जाता है।

मैं अब नोड पोर्ट पर काम कर रहा हूं। बहुत सारे अजीबोगरीब मामले हैं जिनकी आवश्यकता है
विशेष हैंडलिंग। मेरे अब तक के नोट्स:

मूल नोड पोर्ट:

iptables -t nat -N KUBE-NODEPORTS
iptables -t nat -A PREROUTING -j KUBE-NODEPORTS
iptables -t nat -A OUTPUT -j KUBE-NODEPORTS
iptables -t nat -A KUBE-NODEPORTS -p tcp -m comment --comment "TEST: default/ nodeport:p " -m tcp --dport 30241 -j KUBE-SVC-EQKU6GMUKRXBR6NWW53

नोड से लोकलहोस्ट पर ट्रैफ़िक प्राप्त करने के लिए

इको 1 > /proc/sys/net/ipv4/conf/all/route_localnet

स्थानीयहोस्ट से सेवाओं के लिए नियत पैकेटों को चिह्नित करें, फिर उनका मुखौटा लगाएं

iptables -t nat -I KUBE-SVC-EQKU6GMUKRXBR6NWW53 -s 127.0.0.0/16 -j MARK --set-mark 0x4b000001;
iptables -t nat -A पोस्टराउटिंग -m मार्क --mark 0x4b000001 -j MASQUERADE

किसी सेवा के माध्यम से पॉड से स्वयं तक ट्रैफ़िक प्राप्त करने के लिए:

$ में intf के लिए (आईपी लिंक सूची | grep veth | कट -f2 -d:); brctl हेयरपिन cbr0 $intf ऑन करें; किया हुआ

एक ही समापन बिंदु से प्रत्येक समापन बिंदु के लिए नियत पैकेटों को चिह्नित करें, फिर उनका मुखौटा लगाएं।

यह हैकी है, लेकिन मैं वास्तव में नहीं जानता कि कौन से पॉड "स्थानीय" हैं और मैं वास्तव में अभी नहीं चाहता। (लेकिन मैं अंततः करूँगा)

iptables -t nat -I KUBE-SEP-HHNEQBOLY57T5MQCFIY -s 10.244.1.6 -j MARK --set-mark 0x4b000001

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130492394
.

@BenTheElder मैंने अभी GCE पर कुछ यथोचित विस्तृत नेटवर्क perf मापन किया है - मैं netperf पर एक नज़र डालने की सलाह देता हूँ (qperf विलंबता माप भी देता है)।

netperf एक क्लाइंट/सर्वर perf टूल है, मैंने क्लाइंट और सर्वर दोनों को docker कंटेनर paultilady/ netserver:ubuntu.2 में पैक किया है। नेटपरफ पर बहुत सारे विकल्प हैं, लेकिन दो नेटसर्वर पॉड्स को स्पिन करने और चलाने जैसा कुछ है

kubectl exec  -t $netserver-pod-1 -- netperf –l 30 -i 10 -I 99,1 -c -j -H $netserver-pod-2-ip -t OMNI --  -T tcp -D -O THROUGHPUT,THROUGHPUT_UNITS,MEAN_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,STDDEV_LATENCY,LOCAL_CPU_UTIL

आपको विलंबता और थ्रूपुट सहित आँकड़ों का एक अच्छा प्रसार देना चाहिए। आप नोड-> पॉड परीक्षण भी करने के लिए docker run --net=host का उपयोग करके नेटसर्वर कंटेनर चला सकते हैं।

इस कंटेनर के लिए dockerfile बहुत आसान है, अगर आप इसे कुछ दुबला (उदाहरण के लिए तेजी से खींचने के लिए अल्पाइनलिनक्स-आधारित कंटेनर) में विस्तारित करना चाहते हैं तो मैं इसे आग लगा सकता हूं।

धन्यवाद मैं उसमें देख लूंगा।

इस टिप्पणी से हालांकि मुझे लगता है कि हम किसी प्रकार का सेवा अनुरोध विलंबता करना चाहते हैं। अभी मैं मानक nginx कंटेनर को नोड एक्स के रूप में उपयोग करने की कोशिश कर रहा हूं और परीक्षण पॉड समय को बार-बार मारने पर काम कर रहा हूं ताकि हम नोड वाई पर एक ग्राफ बना सकें।

हालांकि मैं netperf/qperf को देखूंगा, और हमारे पास हमेशा कई परीक्षण हो सकते हैं।
मैं उस ग्राफ को पहले प्राप्त करना चाहता हूं, हालांकि पिछली चर्चा के अनुसार @thockin

गुरु, अगस्त 13, 2015 पूर्वाह्न 12:02 बजे, पॉल टिपलाडी नोटिफिकेशन @github.com
लिखा था:

@BenTheElder https://github.com/BenTheElder मैंने अभी कुछ उचित किया है
जीसीई पर विस्तृत नेटवर्क पूर्ण माप - मैं एक नज़र डालने की सलाह देता हूं
netperf (qperf विलंबता माप भी देता है)।

netperf एक क्लाइंट/सर्वर perf टूल है, मैंने क्लाइंट और दोनों को पैक किया है
डोकर कंटेनर में सर्वर पॉलीप्लाडी/ नेटसर्वर: ubuntu.2। वहां
netperf पर बहुत सारे विकल्प हैं, लेकिन दो को स्पिन करने जैसा कुछ है
नेटसर्वर पॉड्स और रनिंग

kubectl exec -t $netserver-pod-1 -- netperf -l 30 -i 10 -I 99,1 -c -j -H $netserver-pod-2-ip -t OMNI -- -T tcp -D -O THROUGHPUT,THROUGHPUT_UNITS,MEAN_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,STDDEV_LATENCY,LOCAL_CPU_UTIL

आपको विलंबता और थ्रूपुट सहित आँकड़ों का एक अच्छा प्रसार देना चाहिए।
आप docker run --net=host to do का उपयोग करके netserver कंटेनर चला सकते हैं
नोड-> पॉड परीक्षण भी।

इस कंटेनर के लिए डॉकरफाइल बहुत आसान है, मैं इसे आग लगा सकता हूं अगर
आप इसे कुछ दुबले-पतले में विस्तारित करना चाहते हैं (उदाहरण के लिए एक अल्पाइनलिनक्स-आधारित
जल्दी खींचने के लिए कंटेनर)।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130524576
.

नोड पोर्ट के संबंध में: #9210 में @Symmetric इस मामले को लाया:

यदि यातायात बहता है:
LB -> node1:nodePort
और सर्विस पॉड नोड 2 पर है, तो पूरा प्रवाह होगा:
LB -> node1:nodePort -> node2 -> pod:svcPort
srcIP अभी भी LB होगा, इसलिए प्रतिक्रिया जाएगी
pod -> node2 -> LB
चूंकि नोड 2 सीधे एलबी को रूट कर सकता है।

अब हम रिटर्न पैकेट के लिए सही स्रोत आईपी को पुनर्स्थापित करने के लिए अन-डीएनएटी का अवसर खो देते हैं (जो केवल नोड 1 पर हो सकता है)।

मैंने समस्या का पुनरुत्पादन किया है। एसीके कि यह एक वास्तविक समस्या है। tcpdump दिखाता है कि पैकेटों को (ऑफ-मशीन) पॉड IP: पोर्ट में DNAT'ed किया जा रहा है, src बरकरार है, लेकिन गंतव्य मशीन पर tcpdump कुछ भी नहीं दिखाता है। मुझे यकीन नहीं है कि पैकेट वहां पहुंचने पर भी मैं क्या होने की उम्मीद करूंगा।

मुझे लगता है कि SNAT का एकमात्र समाधान है। कम से कम प्रभावशाली समाधान LB से _only_ SNAT पैकेट होगा जो कि ऑफ-नोड के लिए नियत हैं, लेकिन a) मेरे पास क्यूब-प्रॉक्सी में वह जानकारी नहीं है (इसे कोड की कीमत पर प्राप्त किया जा सकता है) और b) चूंकि कोई भी नीति को एसएनएटी मामले पर वैसे भी विचार करना होगा, मैं हमेशा बाहरी एलबी पैकेट को एसएनएटी करके सरल बना सकता हूं। नीति इंजनों के लिए यह कितना बुरा है?

अंततः एलबी काफी स्मार्ट होंगे जो केवल पॉड्स वाले मेजबानों को लक्षित करेंगे और यातायात स्थानीय रहेगा, और फिर यह विवादास्पद होगा।

हालांकि यह और जटिल हो जाता है। हमारे पास deprecatedPublicIPs फ़ील्ड है जिसे हम व्यवहार में कुछ बदलावों के साथ शायद हटा देंगे। मुझे लगता है कि हमें उनके लिए भी ऐसा ही करने की जरूरत है। लेकिन यह और भी जटिल हो जाता है - मैं वास्तव में सभी सार्वजनिक आईपी नहीं जानता (उदाहरण के लिए वीएम में 1-से-1 एनएटी बाहरी आईपी है)। आसान उत्तर - हमेशा SNAT नोड-पोर्ट पैकेट। क्या सोचा?

मैं कल और परीक्षण करूंगा।

@BenTheElder आप नेटसर्वर पॉड को एक सेवा बना सकते हैं, ताकि परफ़ से ट्रैफ़िक <->
सर्वर वीआईपी सेवा के माध्यम से जा रहा है। इस तरह आपको ऐसा करने की ज़रूरत नहीं है
नमूनाकरण/विलंबता गणना स्वयं ...

बुध, अगस्त 12, 2015 को रात 9:20 बजे, बेंजामिन एल्डर नोटिफिकेशन @github.com
लिखा था:

धन्यवाद मैं उसमें देख लूंगा।

इस टिप्पणी से
हालांकि मुझे लगता है कि हम किसी प्रकार का सेवा अनुरोध विलंबता करना चाहते हैं। सही
अब मैं मानक nginx कंटेनर को नोड X के रूप में उपयोग करने की कोशिश कर रहा हूं और काम कर रहा हूं
एक परीक्षण पॉड समय इसे बार-बार मार रहा है ताकि हम एक ग्राफ बना सकें
नोड वाई.

हालांकि मैं netperf/qperf को देखूंगा, और हमारे पास हमेशा कई परीक्षण हो सकते हैं।
मैं उस ग्राफ को पहले प्राप्त करना चाहता हूं, हालांकि पिछली चर्चा के अनुसार
@thockin

गुरु, अगस्त 13, 2015 पूर्वाह्न 12:02 बजे, पॉल टिपलाडी नोटिफिकेशन @github.com
लिखा था:

@BenTheElder https://github.com/BenTheElder मैंने अभी कुछ उचित किया है
जीसीई पर विस्तृत नेटवर्क पूर्ण माप - मैं एक नज़र डालने की सलाह देता हूं
netperf (qperf विलंबता माप भी देता है)।

netperf एक क्लाइंट/सर्वर perf टूल है, मैंने क्लाइंट और दोनों को पैक किया है
डोकर कंटेनर में सर्वर पॉलीप्लाडी/ नेटसर्वर: ubuntu.2। वहां
netperf पर बहुत सारे विकल्प हैं, लेकिन दो को स्पिन करने जैसा कुछ है
नेटसर्वर पॉड्स और रनिंग

kubectl exec -t $netserver-pod-1 -- netperf -l 30 -i 10 -I 99,1 -c -j -H
$netserver-pod-2-ip -t OMNI -- -T tcp -D -O
THROUGHPUT,THROUGHPUT_UNITS,MEAN_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,STDDEV_LATENCY,LOCAL_CPU_UTIL

आपको विलंबता सहित आँकड़ों का एक अच्छा प्रसार देना चाहिए और
थ्रूपुट
आप docker run --net=host to do का उपयोग करके netserver कंटेनर चला सकते हैं
नोड-> पॉड परीक्षण भी।

इस कंटेनर के लिए डॉकरफाइल बहुत आसान है, मैं इसे आग लगा सकता हूं अगर
आप इसे कुछ दुबले-पतले में विस्तारित करना चाहते हैं (उदाहरण के लिए एक अल्पाइनलिनक्स-आधारित
जल्दी खींचने के लिए कंटेनर)।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130524576

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130527558
.

सत्य। मुझे लगता है कि @thockin ने अंततः एक e2e विलंबता परीक्षण के रूप में उल्लेख किया है
कुंआ। समय की अनुमति देने के लिए कई अलग-अलग परीक्षण होंगे और हम करेंगे
शायद जीसीई बनाम एडब्ल्यूएस आदि का हिसाब देना होगा।
13 अगस्त 2015 को दोपहर 1:47 बजे, "पॉल टिप्लाडी" नोटिफिकेशन @github.com ने लिखा:

आप नेटसर्वर पॉड को एक सेवा बना सकते हैं, ताकि पर्फ़ से ट्रैफ़िक <->
सर्वर वीआईपी सेवा के माध्यम से जा रहा है। इस तरह आपको ऐसा करने की ज़रूरत नहीं है
नमूनाकरण/विलंबता गणना स्वयं ...

बुध, अगस्त 12, 2015 को रात 9:20 बजे, बेंजामिन एल्डर नोटिफिकेशन @github.com
लिखा था:

धन्यवाद मैं उसमें देख लूंगा।

[इस टिप्पणी] से (

https://github.com/kubernetes/kubernetes/pull/9210#issuecomment-130154261)
हालांकि मुझे लगता है कि हम किसी प्रकार का सेवा अनुरोध विलंबता करना चाहते हैं। सही
अब मैं मानक nginx कंटेनर को नोड X के रूप में उपयोग करने की कोशिश कर रहा हूं और काम कर रहा हूं
पर
एक परीक्षण पॉड समय इसे बार-बार मार रहा है ताकि हम एक ग्राफ बना सकें
नोड वाई.

हालांकि मैं netperf/qperf को देखूंगा, और हमारे पास हमेशा कई परीक्षण हो सकते हैं।
मैं उस ग्राफ को पहले प्राप्त करना चाहता हूं, हालांकि पिछली चर्चा के अनुसार
@thockin

गुरु, अगस्त 13, 2015 को दोपहर 12:02 बजे, पॉल टिपलाडी < सूचनाएँ @github.com

लिखा था:

@BenTheElder https://github.com/BenTheElder मैंने अभी कुछ किया है
यथोचित
जीसीई पर विस्तृत नेटवर्क पूर्ण माप - मैं एक नज़र डालने की सलाह देता हूं
पर
netperf (qperf विलंबता माप भी देता है)।

netperf एक क्लाइंट/सर्वर perf टूल है, मैंने दोनों क्लाइंट को पैक किया है
तथा
डोकर कंटेनर में सर्वर पॉलीप्लाडी/ नेटसर्वर: ubuntu.2।
वहां
netperf पर बहुत सारे विकल्प हैं, लेकिन दो को स्पिन करने जैसा कुछ है
नेटसर्वर पॉड्स और रनिंग

kubectl निष्पादन -t $netserver-pod-1 -- netperf –l 30 -i 10 -I 99,1 -c -j
-एच
$netserver-pod-2-ip -t OMNI -- -T tcp -D -O

THROUGHPUT,THROUGHPUT_UNITS,MEAN_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,STDDEV_LATENCY,LOCAL_CPU_UTIL

आपको विलंबता सहित आँकड़ों का एक अच्छा प्रसार देना चाहिए और
थ्रूपुट
आप docker run --net=host to do का उपयोग करके netserver कंटेनर चला सकते हैं
नोड-> पॉड परीक्षण भी।

इस कंटेनर के लिए dockerfile बहुत आसान है, मैं इसे आग लगा सकता हूँ
अगर
आप इसे कुछ दुबले-पतले में विस्तारित करना चाहते हैं (उदाहरण के लिए एक अल्पाइनलिनक्स-आधारित
जल्दी खींचने के लिए कंटेनर)।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<

https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130524576

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130527558

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130776866
.

@Symmetric netperf परीक्षण अच्छी तरह से काम कर रहे हैं। सलाह के लिये धन्यवाद :-)

मैं बाद में संभवतः एक वेब-सेवा जैसे "वास्तविक" लोड के लिए परीक्षण को संशोधित करना चाहता हूं, लेकिन तर्कों को सही करने के बाद, यह अब तक बहुत अच्छा डेटा दे रहा है। मैं बाद में परिणाम पोस्ट करूंगा जब मैं चीजों को साफ कर दूंगा।

यह जानकर खुशी हुई कि यह आपके लिए काम कर रहा है -- इसमें चौंकाने वाली संख्या है
उस उपकरण पर विकल्प, लेकिन यह मेरे प्रोफाइलिंग कार्य के लिए बहुत उपयोगी साबित हुआ है।
निश्चित रूप से iperf से बेहतर...

गुरु, अगस्त 13, 2015 अपराह्न 2:32 बजे, बेंजामिन एल्डर नोटिफिकेशन @github.com
लिखा था:

@Symmetric https://github.com/Symmetric netperf परीक्षण काम कर रहे हैं
अच्छी तरह से। सलाह के लिये धन्यवाद :-)

मैं बाद में वेब-सेवा जैसे "वास्तविक" लोड के लिए परीक्षण को संशोधित करना चाहता हूं
संभवतः, लेकिन सही तर्क प्राप्त करने के बाद, यह बहुत अच्छा डेटा दे रहा है इसलिए
दूर। मैं बाद में परिणाम पोस्ट करूंगा जब मैं चीजों को साफ कर दूंगा।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130850398
.

@thockin मुझे लगता है कि हम LB ट्रैफ़िक के लिए SNAT के साथ रह सकते हैं। मेरी वर्तमान सोच यह है कि आपको पॉड की एक्सेस नीति को इनमें से एक के रूप में निर्दिष्ट करना होगा:

• डिफ़ॉल्ट '[मेरे नामस्थान] से अनुमति दें' है, जिस स्थिति में एलबी पैकेट गिराए जाते हैं
• '[नामस्थानों की सूची] से अनुमति दें', या '[क्लस्टर में सभी नामस्थानों से अनुमति दें]', फिर से एलबी पैकेट हमेशा गिराए जाते हैं
• 'सभी से अनुमति दें', इस मामले में हमें परवाह नहीं है कि यह एलबी, अन्य नोड, या कहीं भी है या नहीं

इसलिए केवल एलबी के लिए स्रोत आईपी खोना वास्तव में हमें ज्यादा खर्च नहीं करता है।

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

पब्लिकआईपी के संबंध में, मुझे लगता है कि उनके पास नोडपोर्ट के समान विचार होंगे, और इसलिए हमें उन्हें तब तक एसएनएटी करने की आवश्यकता होगी जब तक कि एलबी सही मेजबानों को हिट नहीं कर लेते। उपरोक्त में से कौन सा ठीक है, जब तक कि मुझे कोई रास्ता याद नहीं आ रहा है कि वे नोडपोर्ट से अधिक दुष्ट हैं ...

एक सुरक्षा उपाय के रूप में, वास्तव में MASQUERADE सब कुछ करने के लिए प्रॉक्सी के लिए एक ध्वज शामिल करना बहुत उपयोगी हो सकता है (उपयोगकर्ता स्पेस प्रॉक्सी के बहुत करीब अभिनय)। मुझे लगता है कि यह करना बहुत कठिन नहीं है और समस्या के मामले में निदान या कमबैक करने का एक बहुत अच्छा तरीका है (मैं vxlan मामलों के बारे में सोच रहा हूं)।

-------- संदेश डी ओरिजिन --------
डी: पॉल टिपलडी नोटिफिकेशन @github.com
दिनांक: 14/08/2015 12:50 (जीएमटी+11:00)
पता: Kubernetes/kubernetes [email protected]
सीसी: मिकेल क्लूसो [email protected]
Objet : पुन: [kubernetes] उपयोगकर्ता स्थान के बजाय प्रॉक्सी करने के लिए iptables का उपयोग करें
(#3760)

@thockin मुझे लगता है कि हम LB ट्रैफ़िक के लिए SNAT के साथ रह सकते हैं। मेरी वर्तमान सोच यह है कि आपको पॉड की एक्सेस नीति को इनमें से एक के रूप में निर्दिष्ट करना होगा:

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

इसलिए केवल एलबी के लिए स्रोत आईपी खोना वास्तव में हमें ज्यादा खर्च नहीं करता है।

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

पब्लिकआईपी के संबंध में, मुझे लगता है कि उनके पास नोडपोर्ट के समान विचार होंगे, और इसलिए हमें उन्हें तब तक एसएनएटी करने की आवश्यकता होगी जब तक कि एलबी सही मेजबानों को हिट नहीं कर लेते। उपरोक्त में से कौन सा ठीक है, जब तक कि मुझे कोई रास्ता याद नहीं आ रहा है कि वे नोडपोर्ट से अधिक दुष्ट हैं ...

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

@MikaelCluseau यह एक बुरा विचार नहीं है - क्या आप कृपया उस पर एक नया मुद्दा खोल सकते हैं, इसलिए मैं इसका ट्रैक नहीं खोता?

अभी भी TODO: हेयरपिन ठीक करें, e2e, डिफ़ॉल्ट रूप से सक्षम करें

हाय टिम, आपके पास वापस नहीं आने के लिए खेद है, लेकिन हमें यहां कुछ गड़बड़ करनी थी... मुझे लगता है कि मैं अगले शनिवार को फिक्स हेयरपिन चुनूंगा।

यह मेरे लिए एक नोट था - क्या आप इनमें से कुछ से निपटने की योजना बना रहे थे? :)

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

AFAIK इसे करने के लिए छोड़ दिया गया एकमात्र हिस्सा इसे डिफ़ॉल्ट बना देता है जो v1.1 के कुछ समय बाद हो सकता है (कोई झटका नहीं लगता) और इसमें कुछ मील है।

वाह!

थू, 24 सितंबर 2015 को पूर्वाह्न 11:21 बजे टिम हॉकिन नोटिफिकेशन @github.com
लिखा था:

AFAIK इसे करने के लिए छोड़ दिया गया एकमात्र हिस्सा इसे डिफ़ॉल्ट बना देता है जो कर सकता है
v1.1 के कुछ समय बाद (बिना ब्लो-अप मानकर) होता है और इसमें कुछ मील होते हैं
इस पर।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -142960614
.

v1.1 के कुछ समय बाद और इस पर कुछ मील है।

आउच। हम वास्तव में इस पर 1.1 के लिए भरोसा कर रहे थे ....
https://github.com/kubernetes/kubernetes/blob/master/docs/roadmap.md

@bgrieder आप अभी भी इसे पैरामीटर के माध्यम से सक्षम कर सकते हैं।

यह IN है लेकिन डिफ़ॉल्ट रूप से चालू नहीं है। आप प्रति एक एनोटेशन के साथ ऑप्ट-इन कर सकते हैं
नोड (और एक क्यूब-प्रॉक्सी पुनरारंभ)

थू, 24 सितंबर, 2015 को सुबह 8:27 बजे, ब्रूनो जी. नोटिफिकेशन @github.com ने लिखा:

v1.1 के कुछ समय बाद और इस पर कुछ मील है।

आउच। हम वास्तव में इस पर 1.1 के लिए भरोसा कर रहे थे ....
https://github.com/kubernetes/kubernetes/blob/master/docs/roadmap.md

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -142962932
.

@thockin @bnprss ठीक है, लेकिन हम संस्करण 1.1 के रिलीज़ होने के बाद Google कंटेनर इंजन पर चलने की उम्मीद करते हैं। मुझे आश्चर्य है कि हमें किस प्रकार का लचीलापन 'प्रति नोड एक एनोटेशन के साथ ऑप्ट-इन' करना होगा। क्या आप कृपया हमें इस बारे में कुछ विवरण दे सकते हैं कि प्रक्रिया क्या होगी या हमें कुछ दस्तावेज़ीकरण की ओर संकेत कर सकते हैं?

एक बार 1.1 में अपग्रेड करने के बाद:

$ for node in $(kubectl get nodes -o name); do kubectl annotate $node net.beta.kubernetes.io/proxy-mode=iptables; done

फिर प्रत्येक नोड के लिए SSH और क्यूब-प्रॉक्सी को पुनरारंभ करें (या प्रत्येक नोड को रिबूट करें)।

यदि आप अधिक सतर्क रहना चाहते हैं, तो एक या दो नोड्स करें और फिर इसे आज़माएं :)

मैंने इस मुद्दे को "रिलीज़-नोट" के रूप में चिह्नित किया है ताकि हम अपने 1.1 दस्तावेज़ में उस मैजिक लूप को शामिल करना न भूलें।

@RichieEscarez

(बस पॉप करना चाहता था और कहना चाहता था कि हम एक हफ्ते के लिए प्रॉक्सीइंग iptables का उपयोग कर रहे हैं और यह ठीक लगता है!)

@thockin क्या इसे बंद कर दिया जाना चाहिए, या 1.1 मील के पत्थर से हटा दिया जाना चाहिए?

मैं इसे केवल डिफ़ॉल्ट सक्षम करने के लिए 1.2 पर ले जाऊँगा।

संभावित रूप से गूंगा प्रश्न के लिए खेद है, लेकिन क्लाइंट आईपी के संरक्षण के संबंध में:

@thockin मैंने 2 सितंबर को एक अन्य अंक में देखा कि "केवल इंट्रा-क्लस्टर ट्रैफिक क्लाइंट आईपी को बरकरार रखता है" - क्या यह 1.2 अल्फा के लिए अभी भी सच है?

हमने एक नया 1.2 क्लस्टर लॉन्च किया, नोड एनोटेशन लागू किया, फिर से शुरू किया, और अभी भी HAProxy चलाने वाले पॉड के लिए किए गए सभी अनुरोधों के स्रोत पते के रूप में 10.244.0.1 देखते हैं।

इस बिंदु पर मैं सिर्फ यह पता लगाने की कोशिश कर रहा हूं कि क्या हमने एक सेटिंग को याद किया है या मैं कुछ ऐसा हासिल करने की कोशिश कर रहा हूं जो अभी तक संभव नहीं है - वह वास्तविक क्लाइंट का सार्वजनिक आईपी पता देख रहा है जो अनुरोध कर रहा है क्लस्टर के बाहर।

डिफ़ॉल्ट अभी भी उपयोगकर्ता स्थान मोड का उपयोग करता है। आपको एक एनोटेशन सेट करना होगा
नोड (net.beta.kubernetes. io/proxy-mode=iptables) और पुनरारंभ करें
प्रॉक्सी। लेकिन यह बाहरी क्लाइंट आईपी को उजागर नहीं करेगा, केवल इंट्रा क्लस्टर
आईपी
23 अक्टूबर 2015 को शाम 5:09 बजे, "बेन हंडले" नोटिफिकेशन @github.com ने लिखा:

संभावित रूप से गूंगा प्रश्न के लिए खेद है, लेकिन संरक्षण के संबंध में
क्लाइंट आईपी की:

@thockin https://github.com/thockin मैंने 2 सितंबर को एक अन्य अंक में देखा
कि "केवल इंट्रा-क्लस्टर ट्रैफिक क्लाइंट आईपी को बरकरार रखता है" - क्या यह अभी भी है
1.2 अल्फा के लिए सच है?

हमने एक नया 1.2 क्लस्टर लॉन्च किया, नोड एनोटेशन लागू किया, फिर से शुरू किया,
और अभी भी 10.244.0.1 को a . को किए गए सभी अनुरोधों के स्रोत पते के रूप में देखें
पॉड रनिंग HAProxy.

इस बिंदु पर मैं सिर्फ यह पता लगाने की कोशिश कर रहा हूं कि हम चूक गए हैं या नहीं
सेटिंग या मैं कुछ ऐसा हासिल करने की कोशिश कर रहा हूं जो अभी तक संभव नहीं है -- कि
अनुरोध करने वाले वास्तविक ग्राहक का सार्वजनिक आईपी पता देख रहा है
क्लस्टर के बाहर से।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150725513
.

मैं एक क्यूब-प्रॉक्सी के माध्यम से बाहरी ट्रैफ़िक + रूटिंग को डीएनएट करके बाहरी क्लाइंट आईपी रखने में सक्षम हूं। उदाहरण के लिए, यदि आपका सेवा नेटवर्क 10.42.0.0/16 है और आपके पास IP 10.10.1.1 पर अत्यधिक उपलब्ध क्यूब-प्रॉक्सी है, तो आपके पास निम्न iptable नियम हो सकता है:

-A PREROUTING -i public -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.42.12.34

और निम्नलिखित मार्ग:

10.42.0.0/16 via 10.10.1.1 dev edge 

पॉड पीछे असली आईपी देखता है:

Oct 24 02:41:39 email-0yr7n mail.info postfix/smtpd[469]: connect from zed.yyy.ru.[94.102.51.96]

आपको निश्चित रूप से पैकेट के वापसी पथ का अधिकार होना चाहिए।

हाँ, यदि यह DNAT एक ऑफ-मशीन बैकएंड से जुड़ता है, तो आप बिना त्रिभुज के एक त्रिभुज बनाते हैं
SNAT। यह मूलभूत समस्या है।

शुक्र, 23 अक्टूबर, 2015 को रात 8:12 बजे, मिकाएल क्लूसो नोटिफिकेशन @github.com
लिखा था:

मैं बाहरी ट्रैफ़िक को DNAT'ing करके बाहरी क्लाइंट IP रखने में सक्षम हूँ +
क्यूब-प्रॉक्सी के माध्यम से रूटिंग। उदाहरण के लिए, यदि आपका सेवा नेटवर्क है
10.42.0.0/16 और आपके पास आईपी पर अत्यधिक उपलब्ध क्यूब-प्रॉक्सी है
10.10.1.1, आपके पास निम्नलिखित iptable नियम हो सकते हैं:

-ए प्रीआउटिंग-आई पब्लिक-पी टीसीपी-एम टीसीपी--डीपोर्ट 25-जे डीएनएटी-टू-डेस्टिनेशन 10.42.12.34

और निम्नलिखित मार्ग:

10.42.0.0/16 से 10.10.1.1 देव किनारे

पॉड पीछे असली आईपी देखता है:

24 अक्टूबर 02:41:39 ईमेल-0yr7n mail.info पोस्टफिक्स/smtpd[469]: zed.yyy.ru से कनेक्ट करें।[94.102.51.96]

आपको निश्चित रूप से पैकेट के वापसी पथ का अधिकार होना चाहिए।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150747217
.

दिलचस्प लग रहा है, कोई लिंक? :-) मैं यह सुनिश्चित करने का एक तरीका खोजने की कोशिश कर रहा हूं कि पैकेट सही कॉन्ट्रैक नियम से गुजरेगा। मैं क्लस्टर के माध्यम से कॉनट्रैक स्टेट को दोहराने के बारे में सोच रहा था।

आप जो हासिल करने की कोशिश कर रहे हैं उससे मैं थोड़ा सा खो गया हूं।

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

शुक्र, 23 अक्टूबर, 2015 को रात 9:32 बजे, मिकाएल क्लूसो नोटिफिकेशन @github.com
लिखा था:

दिलचस्प लग रहा है, कोई लिंक? :-) मैं यह सुनिश्चित करने का एक तरीका खोजने की कोशिश कर रहा हूँ
पैकेट सही कॉन्ट्रैक नियम से गुजरेगा। मैं सोच रहा था
क्लस्टर के माध्यम से कॉनट्रैक राज्य की प्रतिकृति बनाना।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150753147
.

ओह, क्षमा करें अगर मैं स्पष्ट नहीं हूँ। मैं SNAT-रहित मामले की बात कर रहा था। यदि प्रत्येक क्यूब-प्रॉक्सी की समान कॉन्ट्रैक सूची है, तो कंटेनर ग्राहक को जवाब देने पर उनमें से कोई भी सही ढंग से अन-डीएनएटी करने में सक्षम होना चाहिए।

मैं एक प्रतिकृति के बिना नहीं देख सकता था जिसमें इस तरह की रेखा के आकार की संरचना रखने के लिए एचए शामिल नहीं है:

[client] ----- [proxy in HA] ------ [node1]
                           `------- [node2]

लेकिन अगर त्रिकोण के आकार की चीज काम कर सकती है, तो उसे और संभावनाएं खोलनी चाहिए।

[client] ----- [proxy1] ------ [node1]
       `------ [proxy2] ------ [node2]

यह प्यारा होगा लेकिन पागल जटिल लगता है

सूर्य, 25 अक्टूबर, 2015 में 11:20 बजे पर, माइकल Cluseau [email protected]
लिखा था:

ओह, क्षमा करें अगर मैं स्पष्ट नहीं हूँ। मैं SNAT-रहित मामले की बात कर रहा था। अगर
प्रत्येक क्यूब-प्रॉक्सी की समान कॉन्ट्रैक सूची होती है, उनमें से कोई भी सक्षम होना चाहिए
जब कंटेनर ग्राहक को जवाब देता है तो अन-डीएनएटी सही ढंग से।

मैं नहीं देख सकता था कि एक प्रतिकृति के बिना था जिसमें एचए को रखने के लिए शामिल नहीं है
इस तरह की रेखा के आकार की संरचना:

[क्लाइंट] ----- [हा में प्रॉक्सी] ------ [नोड1]
`------- [नोड 2]

लेकिन अगर त्रिकोण के आकार की चीज काम कर सकती है, तो उसे और संभावनाएं खोलनी चाहिए।

[क्लाइंट] ----- [प्रॉक्सी 1] ------ [नोड 1]
`------ [प्रॉक्सी2] ------ [नोड2]

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -151037663
.

जिस तरह से मुझे अन्वेषण करना है (मुझे उचित शोध से पहले पूछना पसंद नहीं है लेकिन चूंकि सबजेट अब खुला है ...) "असममित बहु-पथ रूटिंग" है जिसे आप यहां देख सकते हैं: http:// conntrack-tools.netfilter.org/manual.html#sync-aa । और हाँ, यह वास्तव में बहुत अच्छा होगा :-)

सबसे आसान चीज जो संभवतः काम कर सकती है ...

1. प्रॉक्सी 1 को iptables हुक के माध्यम से एक नया कनेक्शन प्राप्त होता है (मुझे लगता है कि मैंने इसे कहीं देखा है), और इसका एलबी इसे प्रॉक्सी 2 के नोड को असाइन करता है।
2. प्रॉक्सी1 एक अनुरोध भेजता है जैसे "{src-ip}:{src-port} -> {pod-ip}:{pod-port} के लिए एक कॉन्ट्रैक प्रविष्टि सेट करें"
3. प्रॉक्सी 2 अनुरोध प्राप्त करता है, कॉन्ट्रैक प्रविष्टि सेट करता है, और इसे प्रॉक्सी 1 पर एसीके करता है
4. प्रॉक्सी1 पैकेट को डीएनएटी नियम के माध्यम से जाने देता है (जो प्रॉक्सी 1 में भी एक कॉन्ट्रैक प्रविष्टि डालता है)।
5. जब पॉड जवाब देता है, तो प्रॉक्सी 2 का होस्ट उसी के अनुसार unDNATs करता है।
6. जब क्लाइंट प्रॉक्सी1 के माध्यम से इस प्रवाह पर एक और पैकेट भेजता है, तो कॉनट्रैक प्रविष्टि सही DNAT भी करती है।

इस तरह, ओवरहेड 2 पैकेट प्रति नया कनेक्शन है, और अन-एसएनएटी + अतिरिक्त रूटिंग से बचकर तेजी से वापस भुगतान किया जाता है (अन्यथा पैकेट को प्रॉक्सी 1 के माध्यम से वापस जाना पड़ता है)।

मैं नेटवर्क वाला नहीं हूं इसलिए मैं बहुत अधिक मान सकता हूं, लेकिन यह उचित लगता है।

मेरे मामले में, मेरा लक्ष्य प्रति NodePort सेवा के लिए फ़ायरवॉल नियम स्थापित करना था।

ऐसा लगता है कि मैं INPUT श्रृंखला में अन्य सभी नियमों को सरल ALLOW IP / DROP जोड़ सकता हूं, जैसे:

iptables -A INPUT -s $WHITELISTED_IP -p tcp --dport $CONTAINER_PORT -j ACCEPT
iptables -A INPUT -p tcp --dport $CONTAINER_PORT -j DROP

इन नियमों को लागू करने के लिए, मैं जो कल्पना कर रहा था, वह NodePort सेवाओं पर एनोटेशन का उपयोग कर रहा था। एनोटेशन में श्वेतसूची वाले आईपी होंगे।

चूंकि मैं इन नियमों के लागू होने के लिए थोड़ा इंतजार कर सकता हूं, इसलिए मैंने सभी सर्विस एनोटेशन से मिनियन की INPUT श्रृंखला को अपडेट करने और अपडेट करने वाले प्रत्येक मिनियन पर एक सूक्ष्म क्रॉन कार्य की कल्पना की।

क्या ऐसा कुछ है जो यहां समस्या पैदा कर सकता है? क्या मैं पागल हूं?

@thockin के पास मुझसे बेहतर दृष्टिकोण है, लेकिन मैं इसके लिए एनोटेशन का उपयोग नहीं करूंगा। मुझे लगता है कि सुरक्षा ऑर्थोगोनल है और इसे एक सिस्टम में अलग रखा जाना चाहिए, या शायद एक नेटवर्क/प्रॉक्सी प्लगइन। यदि आपके पास Kubernetes है, तो आपके पास etcd है, इसलिए आप बस एक नियम सेट को एक कुंजी में संग्रहीत कर सकते हैं और etcdctl घड़ी/निष्पादन के साथ अपडेट कर सकते हैं:

# while true; do etcdctl watch "/iptables/$(hostname)" && etcdctl get /iptables/$(hostname) |iptables-restore --noflush; done &
# iptables -F my-filter
# iptables -nvL my-filter
Chain my-filter (0 references)
 pkts bytes target     prot opt in     out     source               destination      
# ~nwrk/go/bin/etcdctl set /iptables/$(hostname) >/dev/null <<EOF
*filter
:my-filter -
-A my-filter -j ACCEPT -s 1.2.3.4 -p tcp --dport 80
-A my-filter -j DROP -p tcp --dport 80
COMMIT
EOF
# iptables -nvL my-filter
Chain my-filter (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  *      *       1.2.3.4              0.0.0.0/0            tcp dpt:80
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80

मुझे लगता है कि आप चाहते हैं #14505

सोम, 26 अक्टूबर 2015 को सुबह 8:53 बजे, बेन हंडले नोटिफिकेशन @github.com
लिखा था:

मेरे मामले में, मेरा लक्ष्य प्रति NodePort सेवा के लिए फ़ायरवॉल नियम स्थापित करना था।

ऐसा लगता है कि मैं साधारण ALLOW IP / DROP को अन्य सभी नियमों में जोड़ सकता हूं
INPUT श्रृंखला, जैसे:

iptables -A INPUT -s $WHITELISTED_IP -p tcp --dport $CONTAINER_PORT -j ACCEPT
iptables -एक इनपुट -पी टीसीपी --dport $CONTAINER_PORT -j ड्रॉप

इन नियमों को लागू करने के लिए, जो मैं कल्पना कर रहा था, उस पर एनोटेशन का उपयोग कर रहा था
नोडपोर्ट सेवाएं। एनोटेशन में श्वेतसूची वाले आईपी होंगे।

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

क्या ऐसा कुछ है जो यहां समस्या पैदा कर सकता है? क्या मैं पागल हूं?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -151181267
.

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

सौभाग्य से हम एक बेहतर समाधान पर हैं जिसमें iptables के साथ पंगा लेना शामिल नहीं है।

यदि आप अभी शामिल हुए हैं, तो मुझे इसे संक्षेप में प्रस्तुत करने दें। क्लाइंट आईपी प्राप्त करने में असमर्थता के सभी मुद्दों को इस मुद्दे में मिला दिया गया था, हालांकि प्रस्तावित समाधान (और कार्यान्वित) इसे हल नहीं करता है। वर्तमान में आपके पास क्लाइंट के आईपी तक पहुंचने का कोई तरीका नहीं है। हा.

@ shaylevi2 क्लाउड एलबी और नोडपोर्ट पर बाउंस करते समय क्लाइंट आईपी प्राप्त करने के लिए वर्तमान में कोई अच्छा तरीका नहीं है। एक बार क्लाउड एलबी के पकड़ने के बाद, मैं उस पर कूद जाऊंगा। लेकिन यह क्लाइंट आईपी को क्लस्टर के भीतर सुरक्षित रखता है

लेकिन यह क्लाइंट आईपी को क्लस्टर के भीतर सुरक्षित रखता है

यह इस बात पर निर्भर करता है कि क्लस्टर नेटवर्किंग कैसे स्थापित की जाती है; उदाहरण के लिए, यह इस समय OpenShift में ठीक से काम नहीं करता है, क्योंकि iptables नियम OVS-आंतरिक ट्रैफ़िक पर नहीं चलते हैं। तो पैकेट डीएनएटीड सेवा समापन बिंदु में जा रहे हैं, लेकिन चूंकि स्रोत आईपी क्लस्टर-आंतरिक है, प्रतिक्रिया ओवीएस के भीतर रहेगी, इसलिए यह फिर से iptables हिट नहीं करता है, इसलिए DNAT'ing उलट नहीं मिलता है, इसलिए क्लाइंट पॉड पैकेट को नहीं पहचानता है। फिलहाल, इसके लिए सबसे सरल उपाय यह है कि समापन बिंदु में जाने वाले पैकेटों को पूरी तरह से ढकेल दिया जाए, जिससे उन्हें बाहर जाने पर फिर से OVS से बाउंस होने के लिए मजबूर होना पड़े। (मैं इसके आसपास कोई रास्ता निकालने पर काम कर रहा हूं।)

क्या ओवीएस की आंतरिक रूप से वीआईपी धारणा है? आप बस से छुटकारा पा सकते हैं
क्यूब-प्रॉक्सी (cf opencontrail)

शुक्र, 20 नवंबर, 2015 को सुबह 7:09 बजे, डैन विनशिप नोटिफिकेशन @github.com
लिखा था:

लेकिन यह क्लाइंट आईपी को क्लस्टर के भीतर सुरक्षित रखता है

यह इस बात पर निर्भर करता है कि क्लस्टर नेटवर्किंग कैसे स्थापित की जाती है; उदाहरण के लिए, यह नहीं है
इस समय OpenShift में सही काम करें, क्योंकि iptables नियम नहीं चलते हैं
ओवीएस-आंतरिक यातायात पर। तो पैकेट को सेवा में जाने के लिए DNAT'ed किया जाता है
समापन बिंदु, लेकिन चूंकि स्रोत आईपी क्लस्टर-आंतरिक है, प्रतिक्रिया होगी
ओवीएस के भीतर रहें, इसलिए यह फिर से iptables को हिट नहीं करता है, इसलिए DNAT'ing नहीं करता है
उल्टा हो जाता है, इसलिए क्लाइंट पॉड पैकेट को नहीं पहचानता है। पर
पल, इसके लिए सबसे सरल उपाय पैकेटों को पूरी तरह से छिपाना है
एंडपॉइंट में जाकर, उन्हें फिर से ओवीएस से बाउंस होने के लिए मजबूर करना
बाहर का रास्ता। (मैं इसके आसपास कोई रास्ता निकालने पर काम कर रहा हूं।)

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -158426296
.

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

(अभी के लिए ऐसा लगता है कि हम एक स्रोत आईपी + पोर्ट के साथ पैकेट के लिए ओवीएस से एक अतिरिक्त अतिरिक्त हॉप जोड़कर इसे काम कर सकते हैं जो एक ज्ञात सेवा समापन बिंदु से मेल खाता है जो एक कंटेनर इंटरफ़ेस से आ रहा है; नोड संभवतः इसे अन-डीएनएटी करेगा , और फिर इसे वापस OVS में उछाल दें जहां इसे क्लाइंट पॉड में सही तरीके से वापस पहुंचाया जा सके।)

मैं सेवा वीआईपी अमूर्तता के बारे में एक दस्तावेज़ लिखने और इसे बनाने की उम्मीद कर रहा हूं
स्पष्ट है कि यह एक अमूर्त है जिसे बदला जा सकता है (और कुछ में होना चाहिए
मामले)।

सोम, नवंबर 23, 2015 को सुबह 6:54 बजे, डैन विनशिप नोटिफिकेशन @github.com
लिखा था:

हमने अनिवार्य रूप से बराबर करने की बात की थी
Pure-iptables-proxying पूरी तरह से OVS के अंदर है, लेकिन इसके लिए OVS conntrack की आवश्यकता है
समर्थन, जिसके लिए बहुत हाल के कर्नेल की आवश्यकता होती है, जिस पर हम निर्भर नहीं होना चाहते हैं
अभी तक। हालांकि यह शायद लंबी अवधि की योजना है।

(अभी के लिए ऐसा लगता है कि हम एक अतिरिक्त अतिरिक्त जोड़कर इसे काम कर सकते हैं
एक ज्ञात सेवा से मेल खाने वाले स्रोत आईपी + पोर्ट वाले पैकेट के लिए ओवीएस से बाहर निकलें
समापन बिंदु जो एक कंटेनर इंटरफ़ेस से आ रहा है; नोड तब होगा
संभवतः इसे अन-डीएनएटी, और फिर इसे वापस ओवीएस में उछाल दें जहां इसे मिल सकता है
क्लाइंट पॉड को सही तरीके से वापस डिलीवर किया गया।)

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -158959014
.

हालाँकि iptables/nftables दोनों TCP और UDP लोड बैलेंसिंग उपयोग के मामलों को हल करेंगे, मुझे व्यक्तिगत रूप से लगता है कि IPVS https://github.com/kubernetes/kubernetes/issues/17470 एक बेहतर फिट होगा क्योंकि यह लोड संतुलन के लिए उद्देश्य-निर्मित है (पढ़ें: k8s टीम के लिए कम चल रहे परिवर्तन/रखरखाव), लोड संतुलन एल्गोरिदम का एक समृद्ध सेट प्रदान करता है, निकट-रेखा-दर गति पर स्थिरता साबित हुई है, एएमडी में नियमों में हेरफेर करने के लिए गोलंग पुस्तकालय भी तैयार हैं।

@thockin , अन्य, https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150743158 के अनुसार, मैंने एनोटेशन किया था, लेकिन जैसा कि ठीक ही उल्लेख किया गया है, बाहरी क्लाइंट आईपी अभी भी एक कंटेनर में बैठे ऐप द्वारा नहीं देखा जाता है .

इसे कैसे प्राप्त करें यानी बाहरी क्लाइंट आईपी प्राप्त करें? मेरे सेटअप में, कोई बाहरी एलबी नहीं है, सेवा को नोडपोर्ट के रूप में उजागर किया गया है और क्लाइंट मेरे कंटेनरीकृत एप्लिकेशन से सादा टीसीपी (http/वेबसोकेट नहीं) कनेक्शन बना रहा है।

@ashishvyas आप क्यूब-प्रॉक्सी का कौन सा संस्करण चला रहे हैं?

मैं v1.1.3 . चला रहा हूँ

https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -143280584 और https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150743158 में निर्देशों का पालन करें, लेकिन इसके बजाय नाम के एनोटेशन का उपयोग करें net.beta.kubernetes.io/proxy-mode , net.experimental.kubernetes.io/proxy-mode नामक एनोटेशन का उपयोग करें।

for node in $(kubectl get nodes -o name); do
  kubectl annotate $node net.experimental.kubernetes.io/proxy-mode=iptables;
done

आपको क्यूब-प्रॉक्सी स्टार्टअप की शुरुआत में लॉग स्टेटमेंट देखना चाहिए जैसे 'प्रयोगात्मक एनोटेशन मिला' और 'एनोटेशन iptables प्रॉक्सी की अनुमति देता है'

पहली रिलीज़ जिसे https://github.com/kubernetes/kubernetes/commit/da9a9a94d804c5bfdf3cc86ee76a2bc1a2742d16 ने बनाया था वह 1.1.4 थी इसलिए net.beta.kubernetes.io/proxy-mode कई लोगों के लिए काम नहीं कर रहा है। आप इसमें भाग लेने वाले पहले व्यक्ति नहीं हैं।

जिस तरह से प्रॉक्सी काम करता है, हम क्लाइंट आईपी खो देते हैं जब यह आता है
एक नोड पोर्ट। मुझे पता है कि यह बहुत अच्छा नहीं है। यह मेरे दिमाग में बहुत है कि कैसे
इसे ठीक से ठीक करें, लेकिन यह ज्यादातर की क्षमताओं के लिए नीचे आता है
लोड-बैलेंसर (या अन्य तरीके जिससे ट्रैफ़िक किसी नोड पर आता है, जैसे
डीएनएस-आरआर के रूप में)

बुध, 13 जनवरी 2016 को सुबह 10:25 बजे, माइक डैनी नोटिफिकेशन @github.com
लिखा था:

#3760 में निर्देशों का पालन करें (टिप्पणी)
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -143280584
और #3760 (टिप्पणी)
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150743158
लेकिन नामित एनोटेशन का उपयोग करने के बजाय
net.beta.kubernetes.io/proxy-mode, नाम के एनोटेशन का उपयोग करें
net.experimental.kubernetes.io/proxy-mode।

$ में नोड के लिए (kubectl नोड्स -o नाम प्राप्त करें); करना
kubectl एनोटेट $node net.experimental.kubernetes.io/proxy-mode=iptables;
किया हुआ

आपको क्यूब-प्रॉक्सी स्टार्टअप की शुरुआत में लॉग स्टेटमेंट देखना चाहिए
जैसे 'प्रयोगात्मक एनोटेशन मिला' और 'एनोटेशन iptables प्रॉक्सी की अनुमति देता है'

पहली रिलीज़ जो da9a9a9
https://github.com/kubernetes/kubernetes/commit/da9a9a94d804c5bfdf3cc86ee76a2bc1a2742d16
1.1.4 में बनाया गया था। आप इसमें भाग लेने वाले पहले व्यक्ति नहीं हैं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -171387997
.

@thockin , अस्थायी रूप से इसे संबोधित करने के लिए कोई कामकाज अभी संभव है? यदि हां, तो मैं अपने लिए विस्तृत कदम प्रदान करने की सलाह दूंगा और इस धागे पर अन्य लोगों को मदद मिलेगी।

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

"फिक्स" _only_ सेवा एस के लिए उन नोड्स पर ट्रैफ़िक भेजना है जिनके पास है
S _and_ के लिए कम से कम 1 बैकएंड कितने के अनुपात में ट्रैफ़िक भेजने के लिए
बैकएंड प्रत्येक नोड है। क्यूब-प्रॉक्सी तब स्थानीय बैकएंड चुन सकता है
विशेष रूप से।

2 नोड्स और 3 बैकएंड पर विचार करें। एक नोड अनिवार्य रूप से 2 . के साथ समाप्त होता है
बैकएंड। जो भी मार्ग यातायात को एक नोड के रूप में 2x जितना अधिक भेजना है
दूसरे नोड के लिए करता है। हमने अभी तक उस समस्या का समाधान नहीं किया है - इनमें से कोई नहीं
क्लाउड लोड-बैलेंसर इसका समर्थन करते हैं, इसलिए यह एक तरह का सट्टा है और
इसलिए काम शुरू करना बहुत जोखिम भरा है।

बुधवार, 13 जनवरी, 2016 दोपहर 12:17 बजे, आशीष व्यास सूचनाएं @github.com
लिखा था:

@thockin https://github.com/thockin , अस्थायी रूप से कोई समाधान
पता यह अभी संभव है? यदि हां, तो मैं प्रदान करने की अनुशंसा करता हूं
इस धागे पर मेरे और अन्य लोगों के लिए विस्तृत कदम मदद करेंगे।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -171420567
.

@mikedanese , मुझे gcr.io पर 1.1.4 नहीं मिल रहा है:

$ sudo docker pull gcr.io/google_containers/ hyperkube:v1.1.4
रिपोजिटरी खींचना gcr.io/google_containers/hyperkube
टैग v1.1.4 रिपॉजिटरी gcr.io/google_containers/hyperkube में नहीं मिला
$ sudo docker pull gcr.io/google_containers/ hyperkube:v1.1.3
v1.1.3: google_containers/hyperkube . से खींचना
डाइजेस्ट: sha256:004dde049951a4004d99e12846e1fc7274fdc5855752d50288e3be4748778ca2
स्थिति: gcr.io/google_containers/ hyperkube:v1.1.3 के लिए चित्र अप टू डेट है

@thockin लंबी प्रतिक्रिया के लिए क्षमा याचना, मैं उन दोनों तरीकों को कवर करना चाहता था जिन्हें हमने हल करने की कोशिश की थी ताकि अन्य उन चुनौतियों को समझ सकें जिनका हम दोनों के साथ सामना कर रहे हैं।

थोड़ी सी पृष्ठभूमि के रूप में, हमारा मुख्य एप्लिकेशन एक बहुत ही उच्च प्रदर्शन वाला स्मार्ट डीएनएस प्लेटफॉर्म है (यानी इसे यूडीपी की जरूरत है और प्रति पॉड में कम से कम 100k+ अनुरोध/सेकंड करने की जरूरत है), और एसएनआई प्रॉक्सी में इसका सहायक एप्लिकेशन जिसे ग्राहकों को वास्तविक देखने की जरूरत है आईपी ​​एड्रेस (यह हमारे लिए शो स्टॉपर है)। हम अलग-अलग अनुप्रयोगों के लिए अलग-अलग नेटवर्किंग दृष्टिकोणों का उपयोग नहीं करना चाहते थे, इसलिए हमने सभी के लिए एकल नेटवर्क पद्धति पर मानकीकरण करने का निर्णय लिया, और हमने ऊपर बताए गए कारणों के लिए आईपीवीएस का उपयोग करना चुना (प्रदर्शन/स्थिरता/लचीलापन/उद्देश्य एसएलबी का निर्माण) , लेकिन आप शायद इन्हीं पंक्तियों के साथ केवल iptables का उपयोग करके एक साथ कुछ हैक कर सकते हैं। हम vxlan (तेज़, आसान, साइटों के बीच काम करता है) का उपयोग करते हैं, लेकिन इन दोनों विधियों को OVS के साथ GRE/VXLAN के साथ या मानक लेयर 2 होस्ट नेटवर्किंग के साथ भी काम करना चाहिए (यह मानते हुए कि आपके होस्ट सभी एक ही L2 नेटवर्क पर हैं)।

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

हमने इसे संबोधित करने के लिए दो मॉडलों का प्रयास किया:

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

Consumer >> (over L3) >> External VIP node >> (1) >> Internal VIP node >> (2) >> Container >> (any which way you want) >> Consumer

(1) आईपीवीएस (डीएसआर मोड में) एक बाहरी वीआईपी के साथ मेजबान पर एक _node_ चुनता है (आईपीवीएस शर्तों में एक "वास्तविक सर्वर"), और केवल पैकेट के डीएसटी मैक पते को बदलता है (यानी आईपी पैकेट अपरिवर्तित आता है k8s नोड)। यह नोड पर उस सेवा को चलाने वाले पॉड्स की संख्या के आधार पर नोड्स में संतुलन लोड करता है।
(2) आईपीवीएस (डीएसआर मोड में भी) k8s नोड लोड पर पॉड्स में ट्रैफिक को संतुलित करता है (वेथ से नोड तक)। कंटेनरों (टीसीपी और यूडीपी) से उत्तर सीधे सेवा के उपभोक्ता के पास जाते हैं।

इस मॉडल का उल्टा, क्या यह वास्तव में जाना आसान था और नियम को प्रबंधित करना बहुत आसान था। इस मॉडल का नकारात्मक पक्ष यह है कि यह बाहरी वीआईपी चलाने वाले कई नोड्स के माध्यम से हमारे सभी सेवा अनुरोधों (लेकिन उत्तरों को नहीं) को केंद्रित करता है। हमें "साझा-कुछ नहीं" पसंद है, इसलिए, संस्करण 2 दर्ज करें:

दूसरा मॉडल अब मनोरंजक हो रहा है जो कि स्मार्ट आईपीवीएस और आईपीटेबल्स कॉन्फ़िगरेशन के साथ वीआईपी की एक परत है।

Consumer >> Any node/local node >> (1) >> Container >> (any which way you want) >> Consumer
या, यह किसी अन्य नोड पर जा सकता है:
Consumer >> Any node/local node >> (1) >> Remote Node >> (2) >> Container >> (any which way you want) >> Consumer

(1) ट्रैफ़िक प्राथमिक वीआईपी से टकराता है, ट्रैफ़िक क्लस्टर में सभी पॉड्स में संतुलित होता है।
(2) ट्रैफिक सेकेंडरी वीआईपी से टकराता है, ट्रैफिक केवल सभी स्थानीय पॉड्स में संतुलित होता है। यह द्वितीयक वीआईपी केवल नेटवर्क पर अन्य होस्ट से आने वाले ट्रैफ़िक के लिए उपयोग किया जाता है (यह एक FWMARK VIP है)। हम FWMARK=1234 के साथ किसी भी बाहरी इंटरफ़ेस में आने वाले ट्रैफ़िक को चिह्नित करते हैं, और यह ट्रैफ़िक को एक अलग नियम पर जाने के लिए मजबूर करता है, जो नोड्स के बीच लूप को रोकता है।

प्राथमिक वीआईपी में पॉड्स के साथ स्थानीय पॉड्स और रिमोट होस्ट की सूची होती है (वजन प्रत्येक स्थानीय पॉड के लिए 100 और रिमोट नोड्स के लिए 100 * पॉड्स की संख्या के साथ)। तो उदाहरण के लिए यदि नोडए पर 3 पॉड स्थानीय रूप से चल रहे हैं, और नोडबी पर दो पॉड चल रहे हैं, तो नोडए पर नियम इस तरह दिखेगा:

Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP service.ip.address:0 rr persistent 360
-> pod1.on.nodeA.ip:80 Route 100 0 0
-> pod2.on.nodeA.ip:80 Route 100 0 0
-> pod2.on.nodeA.ip:80 Route 100 0 0
-> interfaceip.of.nodeB:80 Route 200 0 0
FWM 1234 rr
-> pod1.on.nodeA.ip:80 Route 100 0 0
-> pod2.on.nodeA.ip:80 Route 100 0 0
-> pod3.on.nodeA.ip:80 Route 100 0 0

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

Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP service.ip.address:0 rr persistent 360
-> pod1.on.nodeB.ip:80 Route 100 0 0
-> pod2.on.nodeB.ip:80 Route 100 0 0
-> interfaceip.of.nodeA:80 Route 300 0 0
FWM 1234 rr
-> pod1.on.nodeB.ip:80 Route 100 0 0
-> pod2.on.nodeB.ip:80 Route 100 0 0

दूसरा तरीका यह होगा कि FWMARK को इधर-उधर करें, और iptables का उपयोग FWMARK में veth+ इंटरफेस (वाइल्डकार्ड मैच) में कुछ भी करें और FWMARK मैच का उपयोग केवल स्थानीय लोड संतुलन के लिए किया जाए।

क्योंकि यहां कोई NAT शामिल नहीं है, जब आप प्रत्येक पॉड को प्रारंभ करते हैं, तो आपको परिवेश में SVC_XXX_YYY IP को लूपबैक या डमी इंटरफ़ेस में जोड़ने की आवश्यकता होती है, लेकिन आप संभवतः IPVS VIP को भी DNAT करने के लिए बदल सकते हैं, मुझे नहीं दिख रहा है यह काम क्यों नहीं करेगा।

अंतिम परिणाम सबसे प्रत्यक्ष नेटवर्किंग है, अनुरोध प्रसंस्करण/रूटिंग को केंद्रीकृत करने की आवश्यकता नहीं है, इसलिए यह बहुत बेहतर है। आईपीवीएस नियम बनाते समय कुछ अतिरिक्त स्मार्ट नुकसान हैं। हम यह सब करने के लिए थोड़ा (गोलंग) डेमॉन का उपयोग करते हैं, लेकिन मैं इसके लिए एक k8s मॉड्यूल लिखने पर विचार करूंगा यदि मेरे पास समय हो और पर्याप्त रुचि हो।

मैं इस मुद्दे में देर से डुबकी लगा रहा हूं, और शायद पूरी जानकारी को पर्याप्त विस्तार से नहीं पढ़ा है, लेकिन अगर यह मदद करता है: अगर मुझे ऊपर @qoke की पोस्ट समझ में आ

@lxpollitt सही,

मेरी तरफ, मेरे कंटेनर नेटवर्क को प्रबंधित करने वाले फलालैन (vxlan मोड में) के साथ, मैं अपने रूटिंग नोड्स पर एक नामस्थान में क्यूब-प्रॉक्सी (iptables मोड में और मास्करेडिंग नहीं) + फलालैन का उपयोग करता हूं। बाहरी अनुरोधों को IPs की सेवा के लिए DNATed किया जाता है और फिर क्यूब-प्रॉक्सी के साथ नेमस्पेस के माध्यम से अग्रेषित किया जाता है। मैंने सक्रिय/सक्रिय राउटर क्लस्टर परीक्षण नहीं किया है, लेकिन यह सेटअप मुझे बाहरी आईपी रखने की अनुमति देता है। मैं इसका उल्लेख एफडब्ल्यूआईडब्ल्यू करता हूं, लेकिन मैं समझता हूं कि यह "सबसे प्रत्यक्ष नेटवर्किंग" नहीं है।

मैं समझता हूं कि यदि क्यूब-प्रॉक्सी इसे प्रबंधित कर सकता है तो यह अच्छा होगा, लेकिन आपकी विशिष्ट आवश्यकताओं और विशेष रूप से तथ्य यह है कि लोड-बैलेंसिंग पहले से ही क्यूब-प्रॉक्सी के बाहर है, क्या यह ग्राहक iptables-नियम प्रबंधक को कोड करने के लिए समझ में नहीं आता है Kubernetes क्लस्टर स्थिति देख रहे हैं और केवल चल रहे होस्ट के पॉड्स के लिए DNAT VIP के लिए नियम स्थापित कर रहे हैं? यह क्यूब-प्रॉक्सी के लिए एक मोड भी हो सकता है, हालांकि, जैसे... ठीक है.. मैं नामों में अच्छा नहीं हूं... --proxy-mode=iptables-to-node-pods-only।

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

कुबेरनेट्स के मूल के साथ चुनौती अपने को संभालने के तरीके ढूंढ रही है
सामान्य रूप से स्थिति की तरह या अपने रास्ते से हटने और आपको सशक्त बनाने के लिए
इसे स्वयं सेट करें। हो सकता है कि हम ipvs एनकैप मोड के साथ कुछ कर सकें,
लेकिन मैं इसके पूर्ण प्रभाव को नहीं जानता।

गुरु, पर 3:37 महिला 14 जनवरी, 2016 पर qoke [email protected] लिखा है:

@thockin https://github.com/thockin लंबी प्रतिक्रिया के लिए क्षमा याचना, मैं
दोनों तरीकों को कवर करना चाहते थे, हमने इसे हल करने का प्रयास किया ताकि अन्य कर सकें
हम दोनों के सामने आने वाली चुनौतियों को समझें।

थोड़ी सी पृष्ठभूमि के रूप में, हमारा मुख्य एप्लिकेशन बहुत ही उच्च प्रदर्शन है
स्मार्ट डीएनएस प्लेटफॉर्म (यानी इसे यूडीपी की जरूरत है और कम से कम 100k+ . करने की जरूरत है)
अनुरोध/सेकंड प्रति पॉड), और एसएनआई प्रॉक्सी में इसका सहायक अनुप्रयोग
जिसे ग्राहकों को वास्तविक आईपी पता देखने की जरूरत है (यह एक शो स्टॉपर है
हम)। हम अलग-अलग के लिए अलग-अलग नेटवर्किंग दृष्टिकोणों का उपयोग नहीं करना चाहते थे
अनुप्रयोगों, इसलिए हमने के लिए एकल नेटवर्क पद्धति पर मानकीकरण करने का निर्णय लिया
सभी, और हमने ऊपर बताए गए कारणों के लिए आईपीवीएस का उपयोग करना चुना
(प्रदर्शन/स्थिरता/लचीलापन/उद्देश्य SLB का निर्माण), लेकिन आप कर सकते थे
शायद इन्हीं पंक्तियों के साथ सिर्फ iptables का उपयोग करके एक साथ कुछ हैक करें
बहुत। हम vxlan का उपयोग करते हैं (तेज़, आसान, साइटों के बीच काम करता है) लेकिन ये दोनों
विधियों को GRE/VXLAN के साथ OVS या मानक परत 2 के साथ भी काम करना चाहिए
होस्ट नेटवर्किंग भी (यह मानते हुए कि आपके होस्ट सभी एक ही L2 नेटवर्क पर हैं)।

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

हमने इसे संबोधित करने के लिए दो मॉडलों का प्रयास किया:

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

उपभोक्ता >> (L3 से अधिक) >> बाहरी वीआईपी नोड >> (1) >> आंतरिक वीआईपी नोड >>
(2) >> कंटेनर >> (जिस तरह से आप चाहते हैं) >> उपभोक्ता

(1) आईपीवीएस (डीएसआर मोड में) एक बाहरी वीआईपी के साथ मेजबान पर एक _node_ to . चुनता है
(आईपीवीएस शर्तों में एक "असली सर्वर") को ट्रैफ़िक भेजें, और केवल डीएसटी मैक को बदलता है
पैकेट का पता (यानी आईपी पैकेट k8s नोड पर अपरिवर्तित आता है)। यह लोड
उस सेवा को चलाने वाले पॉड्स की संख्या के आधार पर नोड्स में संतुलन
नोड.
(2) k8s नोड लोड पर IPVS (DSR मोड में भी) ट्रैफिक को संतुलित करता है
पॉड्स (वेथ से नोड तक)। कंटेनरों से उत्तर (टीसीपी और यूडीपी) जाओ
सीधे सेवा के उपभोक्ता को वापस।

इस मॉडल का लाभ यह है कि क्या यह वास्तव में आसान था और क्या
नियम सेट को प्रबंधित करना बहुत आसान था। इस मॉडल का नकारात्मक पक्ष यह है कि यह
हमारे सभी सेवा अनुरोधों (लेकिन उत्तरों को नहीं) को a . के माध्यम से केंद्रित करता है
बाहरी वीआईपी चलाने वाले नोड्स की संख्या। हमें "साझा-कुछ नहीं" पसंद है, इसलिए,
संस्करण 2 दर्ज करें:

दूसरा मॉडल अब मनोरंजन कर रहा है जिसमें वीआईपी की एक परत है
स्मार्ट IPVS और iptables कॉन्फ़िगरेशन।

उपभोक्ता >> कोई भी नोड/स्थानीय नोड >> (1) >> कंटेनर >> (किसी भी तरह से आप
चाहते हैं) >> उपभोक्ता
या, यह किसी अन्य नोड पर जा सकता है:
उपभोक्ता >> कोई नोड/स्थानीय नोड >> (1) >> रिमोट नोड >> (2) >> कंटेनर

(जिस तरह से आप चाहते हैं) >> उपभोक्ता

(1) ट्रैफ़िक प्राथमिक वीआईपी से टकराता है, ट्रैफ़िक सभी पॉड्स में संतुलित होता है
क्लस्टर।
(2) ट्रैफिक सेकेंडरी वीआईपी से टकराता है, ट्रैफिक केवल सभी में संतुलित होता है
स्थानीय फली। यह द्वितीयक वीआईपी केवल यहां से आने वाले ट्रैफ़िक के लिए उपयोग किया जाता है
नेटवर्क पर अन्य होस्ट (इसका एक FWMARK VIP)। हम आने वाले ट्रैफ़िक को चिह्नित करते हैं
FWMARK=1234 के साथ कोई भी बाहरी इंटरफ़ेस, और जो ट्रैफ़िक को जाने के लिए बाध्य करता है
एक अलग नियम के लिए, जो नोड्स के बीच लूप को रोकता है।

प्राथमिक वीआईपी में पॉड्स के साथ स्थानीय पॉड्स और रिमोट होस्ट की सूची होती है (साथ .)
प्रत्येक स्थानीय पॉड के लिए वजन 100 है, और 100 * पॉड्स की संख्या
रिमोट नोड्स)। तो उदाहरण के लिए यदि 3 पॉड स्थानीय रूप से नोडए पर चल रहे हैं, और
नोडबी पर दो पॉड चल रहे हैं, नोडए पर नियम इस तरह दिखेगा
यह:

विरोध स्थानीय पता: पोर्ट अनुसूचक ध्वज
-> रिमोटएड्रेस: ​​पोर्ट फॉरवर्ड वेट एक्टिवकॉन इनएक्टकॉन
TCP service.ip.address:0 rr लगातार 360
-> pod1.on.nodeA.ip:80 रूट 100 0 0
-> pod2.on.nodeA.ip:80 रूट 100 0 0
-> pod2.on.nodeA.ip:80 रूट 100 0 0
-> interfaceip.of.nodeB:80 रूट 200 0 0
एफडब्ल्यूएम 1234 आरआर
-> pod1.on.nodeA.ip:80 रूट 100 0 0
-> pod2.on.nodeA.ip:80 रूट 100 0 0
-> pod3.on.nodeA.ip:80 रूट 100 0 0

हालांकि नोडबी पर, आईपीवीएस कॉन्फ़िगरेशन थोड़ा अलग दिखाई देगा क्योंकि यह
नोडए पर केवल दो स्थानीय पॉड और तीन रिमोट पॉड हैं:

विरोध स्थानीय पता: पोर्ट अनुसूचक ध्वज
-> रिमोटएड्रेस: ​​पोर्ट फॉरवर्ड वेट एक्टिवकॉन इनएक्टकॉन
TCP service.ip.address:0 rr लगातार 360
-> pod1.on.nodeB.ip:80 रूट 100 0 0
-> pod2.on.nodeB.ip:80 रूट 100 0 0
-> interfaceip.of.nodeA:80 रूट 300 0 0
एफडब्ल्यूएम 1234 आरआर
-> pod1.on.nodeB.ip:80 रूट 100 0 0
-> pod2.on.nodeB.ip:80 रूट 100 0 0

एक और तरीका यह होगा कि FWMARKs को इधर-उधर कर दिया जाए, और iptables का उपयोग किया जाए
veth+ इंटरफेस (वाइल्डकार्ड मैच) में FWMARK कुछ भी और FWMARK
मैच केवल स्थानीय लोड संतुलन के लिए उपयोग किया जाता है।

अंतिम परिणाम सबसे प्रत्यक्ष नेटवर्किंग है, जिसे केंद्रीकृत करने की आवश्यकता नहीं है
प्रसंस्करण/रूटिंग का अनुरोध करें ताकि स्केल बहुत बेहतर हो। नकारात्मक पक्ष कुछ है
IPVS नियम बनाते समय अतिरिक्त स्मार्ट।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -171619663
.

मुझे लगता है कि iptables-to-node-pods-only मोड को आजमाना दिलचस्प होगा,
लेकिन इसमें बहुत तरंग है। असंतुलन की संभावना बहुत वास्तविक है और
कम से कम सेवा नियंत्रक को यह जानना होगा कि प्रोग्राम कैसे करें
बाहरी लोड-बैलेंसर।

गुरु, जनवरी 14, 2016 अपराह्न 3:59 बजे, मिकाएल क्लूसो नोटिफिकेशन @github.com
लिखा था:

मेरी ओर से, मेरे कंटेनर नेटवर्क को प्रबंधित करने वाले फलालैन (vxlan मोड में) के साथ, I
क्यूब-प्रॉक्सी (iptables मोड में और बहाना नहीं) + फलालैन का उपयोग करें
मेरे रूटिंग नोड्स पर नेमस्पेस। बाहरी अनुरोध सेवा के लिए DNATed हैं
आईपी ​​और फिर क्यूब-प्रॉक्सी के साथ नेमस्पेस के माध्यम से अग्रेषित किया गया। मैंने नहीं किया
सक्रिय/सक्रिय राउटर क्लस्टर परीक्षण किया, लेकिन यह सेटअप मुझे रखने की अनुमति देता है
बाहरी आई.पी. मैं इसका उल्लेख एफडब्ल्यूआईडब्ल्यू करता हूं, लेकिन मैं समझता हूं कि यह "सबसे अधिक" नहीं है
प्रत्यक्ष नेटवर्किंग"।

मैं समझता हूं कि अगर क्यूब-प्रॉक्सी इसे प्रबंधित कर सकता है तो यह अच्छा होगा, लेकिन
आपकी विशिष्ट आवश्यकताओं और विशेष रूप से इस तथ्य को देखते हुए कि लोड-बैलेंसिंग
पहले से ही क्यूब-प्रॉक्सी के बाहर है, क्या ग्राहक को कोड करने का कोई मतलब नहीं होगा
iptables-नियम प्रबंधक कुबेरनेट क्लस्टर स्थिति देख रहा है और सेट कर रहा है
डीएनएटी वीआईपी के लिए नियम केवल रनिंग होस्ट के पॉड्स के लिए? यह कर सकता है
क्यूब-प्रॉक्सी के लिए भी एक मोड हो, हालाँकि, जैसे... ठीक है .. मैं अच्छा नहीं हूँ
नाम... --proxy-mode=iptables-to-node-pods-only.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -171821603
.

@thockin आपका मतलब है कि उदाहरण के लिए 2 प्रतिकृतियां एक ही नोड पर हैं? मुझे लगता है कि हम क्यूब-प्रॉक्सी के दायरे से बाहर "बाहरी लोड-बैलेंसर प्रोग्राम" कर सकते हैं, क्योंकि इसमें कई उदाहरण हैं और बाहरी एलबी प्रोग्रामर शायद "सिंगल मास्टर" मोड में होना चाहिए। इस प्रकार, क्यूब-प्रॉक्सी मोड "iptables-to-node-pods-only" की अनुमति देना केवल 2 चरणों की प्रक्रिया में से पहला है।

मुझे लगता है कि मैं कल ऐसा कुछ लागू करने का प्रयास कर सकता हूं: क्यूब-प्रॉक्सी में "आईपीटेबल्स-टू-नोड-पॉड्स-ओनली" मोड, साथ ही एक कॉन्ट्रिब/आईपी-रूट-एल्ब जो प्रति सेवा एक रूट के साथ एक लिनक्स रूटिंग टेबल बनाए रखेगा , किसी दिए गए सेवा के लिए नोड के कितने एंडपॉइंट के आधार पर प्रत्येक नोड के लिए सही वजन के साथ।

@thockin आपका मतलब है कि 2 प्रतिकृतियां उदाहरण के लिए एक ही नोड पर हैं? मुझे लगता है कि हम मामले को "कार्यक्रम" रख सकते हैं
बाहरी लोड-बैलेंसर" क्यूब-प्रॉक्सी के दायरे से बाहर है, क्योंकि इसमें कई उदाहरण हैं और एक बाहरी एलबी है
प्रोग्रामर शायद "सिंगल मास्टर" मोड में होना चाहिए। इस प्रकार, क्यूब-प्रॉक्सी मोड "iptables-to-node-
पॉड्स-ओनली" 2 चरणों वाली प्रक्रिया में से केवल पहली प्रक्रिया है।

"केवल स्थानीय पॉड्स के लिए प्रॉक्सी" प्रक्रिया का चरण 2 होना चाहिए। चरण 1
केवल लोड-बैलेंसर भेजने के लिए सेवा नियंत्रक को बदलना होगा
किसी दिए गए सेवा के लिए 1 या अधिक बैकएंड वाले नोड्स के लिए। वह कदम
अकेला संभवतः उचित है, लेकिन इसके लिए बहुत सारे परीक्षण की आवश्यकता होगी
सुनिश्चित करें कि हम इसे ठीक कर रहे हैं। मुझे लगता है कि हम अंततः ऐसा करना चाहते हैं,
वैसे भी।

एक बार ऐसा करने के बाद, हम नोड-पोर्ट को स्थानीय पसंद करने के बारे में बात कर सकते हैं
यदि संभव हो तो बैकएंड, लेकिन इस कदम के लिए बहुत अधिक सावधानी की आवश्यकता है
सोचा.. क्या इसका मतलब _हमेशा_ (यानी कभी भी रिमोट न चुनें .)
बैकएंड यदि कोई स्थानीय उपलब्ध है) या संभाव्य? क्या हमें करना चाहिए
कि एक ही नोड पोर्ट के माध्यम से (विभिन्न नोड्स बहुत मिलेंगे
अलग-अलग व्यवहार) या क्या हम एक अलग पोर्ट आवंटित करते हैं जिसका उपयोग किया जाता है
अगर और केवल अगर इस नोड में 1 या अधिक बैकएंड हैं? हम कैसे संभालते हैं
असंतुलन की समस्या?

मुझे लगता है कि मैं कल की तरह कुछ लागू करने की कोशिश कर सकता हूं: क्यूब-प्रॉक्सी में "iptables-to-node-pods-only" मोड,
साथ ही एक contrib/ip-route-elb जो सही वजन के साथ प्रति सेवा एक मार्ग के साथ एक लिनक्स रूटिंग टेबल बनाए रखेगा
किसी दिए गए सेवा के लिए नोड के कितने समापन बिंदु हैं, इसके आधार पर प्रत्येक नोड के लिए।

अगर ईएलबी वजन का समर्थन करता है तो यह कुछ मामलों में बेहतर काम करेगा
जीसीई, जो नहीं करता है। यह ठीक है, मुझे नहीं लगा कि यह समर्थित है
वजन। मुझे नहीं लगता कि यह योगदान हो सकता है, हालांकि - यह एक सुंदर है
प्रणाली का मौलिक हिस्सा।

01/16/2016 05:19 AM पर, टिम होकिन ने लिखा:

"केवल स्थानीय पॉड्स के लिए प्रॉक्सी" प्रक्रिया का चरण 2 होना चाहिए। चरण 1
केवल लोड-बैलेंसर भेजने के लिए सेवा नियंत्रक को बदलना होगा
किसी दिए गए सेवा के लिए 1 या अधिक बैकएंड वाले नोड्स के लिए। वह कदम
अकेला संभवतः उचित है, लेकिन इसके लिए बहुत सारे परीक्षण की आवश्यकता होगी
सुनिश्चित करें कि हम इसे ठीक कर रहे हैं। मुझे लगता है कि हम अंततः ऐसा करना चाहते हैं,
वैसे भी।

यह समझ आता है।

एक बार ऐसा करने के बाद, [...]

तो चलिए देखते हैं एक बार यह हो गया :-)

अगर ईएलबी वजन का समर्थन करता है तो यह कुछ मामलों में बेहतर काम करेगा
जीसीई, जो नहीं करता है। यह ठीक है, मुझे नहीं लगा कि यह समर्थित है
वजन।

चूंकि यह मैनुअल से है और आपके पास शायद 10x my . से अधिक है
इस तरह की नेटवर्किंग में अनुभव, मुझे एक कैच को पूरी तरह से नजरअंदाज करना चाहिए।
मैन आईपी-रूट यह कहता है:

           nexthop NEXTHOP
                  the nexthop of a multipath route.  NEXTHOP is a 

शीर्ष स्तर तर्क सूचियों के समान अपने स्वयं के सिंटैक्स के साथ जटिल मान:

                          via [ FAMILY ] ADDRESS - is the nexthop 

राउटर।

                          dev NAME - is the output device.

                          weight NUMBER - is a weight for this 

एक बहुपथ मार्ग का तत्व जो उसके सापेक्ष बैंडविड्थ या गुणवत्ता को दर्शाता है।

मुझे नहीं लगता कि यह योगदान हो सकता है, हालांकि - यह एक सुंदर है
प्रणाली का मौलिक हिस्सा।

चूंकि "ई" का अर्थ "बाहरी" है, मुझे लगा कि यह वहां से शुरू हो सकता है,
विचारों का समर्थन करने के लिए कम से कम कुछ कोड प्राप्त करने के लिए।

शुक्र, जनवरी 15, 2016 अपराह्न 2:55 बजे, मिकाइल क्लूसो
सूचनाएं @

01/16/2016 05:19 AM पर, टिम होकिन ने लिखा:

"केवल स्थानीय पॉड्स के लिए प्रॉक्सी" प्रक्रिया का चरण 2 होना चाहिए। चरण 1
केवल लोड-बैलेंसर भेजने के लिए सेवा नियंत्रक को बदलना होगा
किसी दिए गए सेवा के लिए 1 या अधिक बैकएंड वाले नोड्स के लिए। वह कदम
अकेला संभवतः उचित है, लेकिन इसके लिए बहुत सारे परीक्षण की आवश्यकता होगी
सुनिश्चित करें कि हम इसे ठीक कर रहे हैं। मुझे लगता है कि हम अंततः ऐसा करना चाहते हैं,
वैसे भी।

यह समझ आता है।

मैंने आज इस बारे में और सोचा, मुझे नहीं लगता कि यह बहुत कठिन होगा।
बस मध्यम कठिन।

एक बार ऐसा करने के बाद, [...]

तो चलिए देखते हैं एक बार यह हो गया :-)

काफी उचित, मुझे यह जानना अच्छा लगता है कि परिवर्तनों का एक सेट कहां जा रहा है :)

अगर ईएलबी वजन का समर्थन करता है तो यह कुछ मामलों में बेहतर काम करेगा
जीसीई, जो नहीं करता है। यह ठीक है, मुझे नहीं लगा कि यह समर्थित है
वजन।

चूंकि यह मैनुअल से है और आपके पास शायद 10x my . से अधिक है
इस तरह की नेटवर्किंग में अनुभव, मुझे एक कैच को पूरी तरह से नजरअंदाज करना चाहिए।
मैन आईपी-रूट यह कहता है:

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

[ परिवार ] के माध्यम से पता - अगला स्थान है
राउटर।

देव नाम - आउटपुट डिवाइस है।

वजन NUMBER - इसके लिए एक भार है
एक बहुपथ मार्ग का तत्व जो उसके सापेक्ष बैंडविड्थ या गुणवत्ता को दर्शाता है।

हालांकि हम वास्तव में लिनक्स की आईपी रूटिंग की धारणा का उपयोग नहीं करते हैं। इनमें से कोई नहीं
एलबी कार्यान्वयन मैं इसे वैसे भी उपयोग करने के बारे में जानता हूं। GCE Google के क्लाउड का उपयोग करता है
बैलेंसर, जिसमें वजन नहीं होता है। मुझे नहीं पता कि अमेज़न ईएलबी है
करता है।

मुझे नहीं लगता कि यह योगदान हो सकता है, हालांकि - यह एक सुंदर है
प्रणाली का मौलिक हिस्सा।

चूंकि "ई" का अर्थ "बाहरी" है, मुझे लगा कि यह वहां से शुरू हो सकता है,
विचारों का समर्थन करने के लिए कम से कम कुछ कोड प्राप्त करने के लिए।

ज़रूर, हम योगदान में शुरू कर सकते हैं :)

साथ ही, यदि आप इसे आगे बढ़ाना चाहते हैं तो आपको 2 बग खोलनी चाहिए, जैसे कुछ:

1) किसी सेवा के लिए लोड-बैलेंसर को केवल उन नोड्स को लक्षित करना चाहिए जो वास्तव में
उस सेवा के लिए एक बैकएंड है

2) क्लाइंट आईपी को लोड-बैलेंसर में संरक्षित करने के लिए, क्यूब-प्रॉक्सी को चाहिए
मौजूद होने पर हमेशा स्थानीय बैकएंड को प्राथमिकता दें (xref #1)

और फिर इरादा और दिशा की व्याख्या करें

शुक्र, 15 जनवरी, 2016 को शाम 5:11 बजे टिम होकिन [email protected] ने लिखा:

शुक्र, जनवरी 15, 2016 अपराह्न 2:55 बजे, मिकाइल क्लूसो
सूचनाएं @

01/16/2016 05:19 AM पर, टिम होकिन ने लिखा:

"केवल स्थानीय पॉड्स के लिए प्रॉक्सी" प्रक्रिया का चरण 2 होना चाहिए। चरण 1
केवल लोड-बैलेंसर भेजने के लिए सेवा नियंत्रक को बदलना होगा
किसी दिए गए सेवा के लिए 1 या अधिक बैकएंड वाले नोड्स के लिए। वह कदम
अकेला संभवतः उचित है, लेकिन इसके लिए बहुत सारे परीक्षण की आवश्यकता होगी
सुनिश्चित करें कि हम इसे ठीक कर रहे हैं। मुझे लगता है कि हम अंततः ऐसा करना चाहते हैं,
वैसे भी।

यह समझ आता है।

मैंने आज इस बारे में और सोचा, मुझे नहीं लगता कि यह बहुत कठिन होगा।
बस मध्यम कठिन।

एक बार ऐसा करने के बाद, [...]

तो चलिए देखते हैं एक बार यह हो गया :-)

काफी उचित, मुझे यह जानना अच्छा लगता है कि परिवर्तनों का एक सेट कहां जा रहा है :)

अगर ईएलबी वजन का समर्थन करता है तो यह कुछ मामलों में बेहतर काम करेगा
जीसीई, जो नहीं करता है। यह ठीक है, मुझे नहीं लगा कि यह समर्थित है
वजन।

चूंकि यह मैनुअल से है और आपके पास शायद 10x my . से अधिक है
इस तरह की नेटवर्किंग में अनुभव, मुझे एक कैच को पूरी तरह से नजरअंदाज करना चाहिए।
मैन आईपी-रूट यह कहता है:

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

[ परिवार ] के माध्यम से पता - अगला स्थान है
राउटर।

देव नाम - आउटपुट डिवाइस है।

वजन NUMBER - इसके लिए एक भार है
एक बहुपथ मार्ग का तत्व जो उसके सापेक्ष बैंडविड्थ या गुणवत्ता को दर्शाता है।

हालांकि हम वास्तव में लिनक्स की आईपी रूटिंग की धारणा का उपयोग नहीं करते हैं। इनमें से कोई नहीं
एलबी कार्यान्वयन मैं इसे वैसे भी उपयोग करने के बारे में जानता हूं। GCE Google के क्लाउड का उपयोग करता है
बैलेंसर, जिसमें वजन नहीं होता है। मुझे नहीं पता कि अमेज़न ईएलबी है
करता है।

मुझे नहीं लगता कि यह योगदान हो सकता है, हालांकि - यह एक सुंदर है
प्रणाली का मौलिक हिस्सा।

चूंकि "ई" का अर्थ "बाहरी" है, मुझे लगा कि यह वहां से शुरू हो सकता है,
विचारों का समर्थन करने के लिए कम से कम कुछ कोड प्राप्त करने के लिए।

ज़रूर, हम योगदान में शुरू कर सकते हैं :)

बिना डॉक्स के पीआर का जोखिम यह है कि यह गलत दिशा में है। यह है
प्रस्ताव के रूप में किसी चीज़ की समीक्षा करना बहुत आसान है। मैं आपके पर एक नज़र डालेगा
पीआर जब मुझे मौका मिलता है, जल्द ही मुझे उम्मीद है।
15 जनवरी 2016 को शाम 7:02 बजे, "मिकाल क्लूसो" नोटिफिकेशन @github.com ने लिखा:

क्या इस नाम से सीधे (1) के लिए पुल-अनुरोध खोलना ठीक है और कुछ
स्पष्टीकरण?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172149777
.

दुर्भाग्य से आप बहुत विशिष्ट क्षेत्र में आ गए हैं जो सामान्य अर्थों में काम नहीं करता है।
रूट किए गए नेटवर्क के कारण GCE जैसे क्लाउड IPVS गेटवेिंग मोड का उपयोग नहीं कर सकते हैं। भले ही गेटवेिंग ने काम किया हो, यह पोर्ट रीमैपिंग का समर्थन नहीं करता है, जो कुबेरनेट्स करता है, इसलिए यह केवल तभी लागू होता है जब सर्विस पोर्ट == लक्ष्य पोर्ट।

गेटवे की तरफ, यह लेयर 3 नेटवर्क पर ठीक काम करता है (हम एक ओवरले का उपयोग करते हैं), और भले ही हम ओवरले नेटवर्क के बिना दूर हो सकते थे, हमने इसे इस तरह से बनाया क्योंकि हम चाहते थे कि जिस दृष्टिकोण का हम उपयोग करते हैं वह पोर्टेबल हो और काम करे तीसरे पक्ष के बादलों में (जैसे GCE)।

डीएसआर मोड के साथ सीमा को ठीक करना यह है कि सर्विस पोर्ट == लक्ष्य पोर्ट, लेकिन यह वास्तव में कोई समस्या नहीं है जब तक कि आपके पास एक ही कंटेनर में दो एप्लिकेशन _in एक ही पोर्ट पर चलने की आवश्यकता न हो (हमने सोचने में बहुत समय बिताया यह, और "प्रति कंटेनर 1 आवेदन" दिशानिर्देश मानते हुए, हम इसके लिए एक भी उपयोग केस नहीं ढूंढ सके)। हमारे पास कई कंटेनर हैं जो सभी एक ही नोड्स पर चल रहे हैं, उन सभी के अंदर एक ही पोर्ट पर सेवाएं हैं, और सभी संतुलित फाइन लोड करते हैं। यदि आपको _really_ बंदरगाहों को फिर से मैप करने की आवश्यकता है (हालांकि मैं इसके पीछे के वास्तविक कारणों को समझना चाहता हूं), तो आप "रूट" मोड के बजाय आईपीवीएस एनएटी मोड का उपयोग कर सकते हैं।

कुबेरनेट्स के मूल के साथ चुनौती यह है कि आप अपनी स्थिति को सामान्य रूप से संभालने के तरीके खोज रहे हैं या अपने रास्ते से हटकर आपको इसे स्वयं स्थापित करने के लिए सशक्त बना रहे हैं। हो सकता है कि हम ipvs एनकैप मोड के साथ कुछ कर सकें, लेकिन मुझे इसके पूर्ण प्रभाव का पता नहीं है।

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

अब उस ने कहा, यदि आप समीकरण से डीएसआर (आईपीवीएस रूट मोड) को हटाते हैं, और इसके बजाय आईपीवीएस के "एनएटी मोड" का उपयोग करते हैं, तो बंदरगाहों को रीमैप किया जा सकता है और आपको अभी भी आईपीवीएस सुविधाएं/प्रदर्शन/आदि प्राप्त करने का लाभ मिलता है। केवल नकारात्मक पक्ष यह है कि एनएटी कुछ प्रदर्शन कर जोड़ता है लेकिन (ए) यह यूडीपी का समर्थन करता है, और (बी) उपयोगकर्ता अंतरिक्ष समाधान की तुलना में इसकी अभी भी बिजली तेज है।

@brendandburns @thockin इससे पहले धागे में आपने कुछ प्रदर्शन संख्याएं मांगी

https://docs.google.com/presentation/d/1vv5Zszt4HDGbuyVlvOe76unHskxPuZQseQnarNbhQVc

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

धन्यवाद!

मुझे यकीन नहीं है कि यह विचार कहां से आता है कि क्यूब-प्रॉक्सी यूडीपी नहीं करता है - it
बिल्कुल करता है, हालांकि शायद पूरी तरह से नहीं (एक कनेक्शन के बिना यह आता है
डाउन टू टाइमआउट)।

यह iptables (नया) क्यूब-प्रॉक्सी बनाम यूजरस्पेस को स्पष्ट करने लायक भी है
(विरासत का अंदाज।

पर 09:45 शनि, 16 जनवरी, 2016 को, qoke [email protected] लिखा है:

@thockin https://github.com/thockin इससे पहले थ्रेड में आपने मांगा था
कुछ प्रदर्शन संख्या। मैं इसे सबसे व्यापक सेट नहीं कहूंगा
परीक्षणों की, लेकिन मुझे उम्मीद है कि HTTP अधिक सामान्य कार्यभार में से एक है
कंटेनर, इसलिए शुरुआती बिंदु के रूप में यहां कुछ अपाचे-बेंच नंबर दिए गए हैं:

https://docs.google.com/presentation/d/1vv5Zszt4HDGbuyVlvOe76unHskxPuZQseQnarNbhQVc

अन्य दो समाधानों की तुलना में निष्पक्ष तुलना के लिए IPVS पर DNAT सक्षम किया गया था
(इसका मतलब यह भी है कि सर्विस पोर्ट टारगेट सर्विस पोर्ट के लिए अलग हो सकता है)। हमारी
कुछ लोगों को कार्यभार थोड़ा असामान्य लग सकता है, लेकिन हमारा प्रदर्शन लक्ष्य
शायद दूसरों के लिए भिन्न नहीं हैं (यानी सभी के लिए हार्डवेयर निचोड़ें
आप प्राप्त कर सकते हैं)।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172293881
.

नए बनाम लीगेसी मोड पर अच्छी कॉल - विख्यात और अद्यतन।

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

iptables और किसी भी उच्च-दर UDP सेवा के साथ प्रमुख मुद्दा नेटफिल्टर कॉनट्रैक टेबल भरना है। यहां तक ​​​​कि अगर आप कॉनट्रैक आकार को 1 मिलियन तक बढ़ा देते हैं, तो कुछ मैलवेयर-संक्रमित एंड-यूज़र डीडीओएस आप हैं या डीएनएस एम्पलीफिकेशन अटैक के लिए आपका उपयोग करने की कोशिश करते हैं और फिर आपकी कॉन्ट्रैक टेबल फिर से भर जाती है। सामान्यतया, DNS सर्वरों (या किसी भी उच्च-दर UDP सेवाओं) के लिए सबसे अच्छा अभ्यास है कॉनट्रैक को अक्षम करना (कच्ची तालिका में -j NOTRACK का उपयोग करना), और यदि आप कॉनट्रैक, iptables NAT और स्टेटफुल स्टफ (-m स्टेट) ब्रेक को अक्षम करते हैं।

जीआईटी रेपो के अलावा, "k8s.io/kubernetes/pkg/proxy/ipvs" मॉड्यूल/पैकेज बनाने का प्रयास करने से पहले देखने के लिए सबसे अच्छी जगह कहां होगी? या यह किसी ऐसे व्यक्ति के लिए सबसे अच्छा है जो कोड आधार को बेहतर जानता है?

साथ ही, यदि आप कोई विशिष्ट बेंचमार्क चलाना चाहते हैं तो मुझे बताएं और मैं देखूंगा कि मैं क्या कर सकता हूं।

01/17/2016 08:50 अपराह्न को, qoke ने लिखा:

जीआईटी रेपो के अलावा, पहले देखने के लिए सबसे अच्छी जगह कहां होगी
"k8s.io/kubernetes/pkg/proxy/ipvs" मॉड्यूल/पैकेज बनाने का प्रयास कर रहे हैं?

मुझे विश्वास है कि आप योगदान में भी शुरुआत कर सकते हैं।

एफडब्ल्यूआईडब्ल्यू... मैंने एक स्वतंत्र बनाने के लिए सूची घड़ियों और अनडेल्टा स्टोर का इस्तेमाल किया
बिनय क्लस्टर की स्थिति पर प्रतिक्रिया दे रहा है
https://github.com/kubernetes/kubernetes/pull/19755. अगर जानकारी
में
https://github.com/kubernetes/kubernetes/pull/19755/files#diff -0becc97ac222c3f2838fbfe8446d5375R26
पर्याप्त है, आपको केवल नीचे दी गई कुछ पंक्तियों में कॉल को बदलना होगा
(https://github.com/kubernetes/kubernetes/pull/19755/files#diff-0becc97ac222c3f2838fbfe8446d5375R44)।

कृपया ध्यान दें कि मैं इस पीओसी में केवल क्लस्टरआईपी सेवाओं का समर्थन करता हूं।

दुर्भाग्य से आप बहुत विशिष्ट क्षेत्र में आ गए हैं जो सामान्य अर्थों में काम नहीं करता है।
रूट किए गए नेटवर्क के कारण GCE जैसे क्लाउड IPVS गेटवेिंग मोड का उपयोग नहीं कर सकते हैं। भले ही गेटवे ने काम किया हो, यह नहीं है
समर्थन पोर्ट रीमैपिंग, जो कुबेरनेट्स करता है, इसलिए यह केवल तभी लागू होता है जब सर्विस पोर्ट == लक्ष्य पोर्ट।

प्रवेश द्वार पर, यह परत 3 नेटवर्क पर ठीक काम करता है (हम एक ओवरले का उपयोग करते हैं), और भले ही हम दूर हो सकते थे
ओवरले नेटवर्क के बिना, हमने इसे इस तरह बनाया क्योंकि हम चाहते थे कि जिस दृष्टिकोण का हम उपयोग करते हैं वह पोर्टेबल हो और तीसरे पक्ष में काम करे
बादल (जैसे GCE)।

मुझे यकीन नहीं है कि यह कैसे काम कर सकता है। मशीन-स्तरीय स्थिर मार्ग काम नहीं करते
जीसीई में। शायद मुझे कुछ तकनीक याद आ रही है जिसे आपने लागू किया है। मैं
स्वतंत्र रूप से स्वीकार करें कि मैं इसमें विशेषज्ञ नहीं हूं :)

सीमा को ठीक करें कि सर्विस पोर्ट == लक्ष्य पोर्ट, लेकिन यह वास्तव में कोई समस्या नहीं है जब तक कि आपके पास दो एप्लिकेशन न हों
वही कंटेनर जिसे उसी पोर्ट पर चलाने की आवश्यकता है (हमने इस बारे में सोचने में बहुत समय बिताया, और "1 एप्लिकेशन" मानकर
प्रति कंटेनर" दिशानिर्देश, हमें इसके लिए एक भी उपयोग का मामला नहीं मिला। हमारे पास एक ही नोड पर चलने वाले कई कंटेनर हैं
उन सभी के अंदर सेवाओं के साथ एक ही बंदरगाह पर, और सभी संतुलित जुर्माना लोड करते हैं। संक्षेप में, हम जिस दृष्टिकोण का उपयोग करते हैं वह आपको रोकता नहीं है
एक ही नोड पर एक ही पोर्ट पर कई सेवाओं को चलाने से।

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

कुबेरनेट्स के मूल के साथ चुनौती आपकी स्थिति को सामान्य रूप से संभालने या अपने रास्ते से हटने के तरीके ढूंढ रही है
और आपको इसे स्वयं स्थापित करने के लिए सशक्त बनाता है। हो सकता है कि हम ipvs encap मोड के साथ कुछ कर सकें, लेकिन मुझे perf . का पता नहीं है
इसके निहितार्थ।

हमने जो किया है वह उतना ही सामान्य है जितना हम संभवतः इसे बना सकते हैं (यहां काम करता है, अमेज़ॅन में काम करता है, और मुझे यकीन है कि यह काम करेगा
जीसीई जब हमें विस्तार करने की आवश्यकता होती है), केवल एक सीमा के साथ पॉड/कंटेनर में चल रहे एप्लिकेशन को सेवा के समान पोर्ट पर चलाने की आवश्यकता होती है, जो कि बहुत सारी आंतरिक चर्चा के बाद, कोई भी नहीं ढूंढ पाया है। परिदृश्य जहां
यह एक E2E अनुप्रयोग स्टैक परिप्रेक्ष्य से सीमित होगा।

मैं वास्तव में समझना चाहता हूं कि कैसे। क्या आपके पास कुछ और कदम-दर-कदम है?

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

iptables और किसी भी उच्च-दर UDP सेवा के साथ प्रमुख मुद्दा नेटफिल्टर कॉनट्रैक टेबल भरना है। भले ही आप बढ़ा दें
आकार को 1 मिलियन तक बढ़ाएं, फिर कुछ मैलवेयर-संक्रमित अंतिम-उपयोगकर्ता DDoS आप हैं या DNS प्रवर्धन के लिए आपका उपयोग करने का प्रयास करते हैं
हमला और फिर आपकी कॉनट्रैक टेबल फिर से भर जाती है। सामान्यतया, DNS सर्वरों के लिए सर्वोत्तम अभ्यास (या कोई उच्च दर
UDP सेवाएं) कॉनट्रैक को अक्षम करना है (कच्ची तालिका में -j NOTRACK का उपयोग करके), और यदि आप कॉनट्रैक, iptables NAT और अक्षम करते हैं
स्टेटफुल स्टफ (-एम स्टेट) टूट जाता है।

हाँ, यूडीपी के लिए एनएटी वास्तव में दुर्भाग्यपूर्ण है। एक गैर-कॉन्ट्रैक ढूँढना
समाधान बहुत अच्छा होगा, लेकिन इसे या तो सभी पर लागू करना होगा
वातावरण या प्लेटफ़ॉर्म द्वारा पैरामीटरयुक्त होना (जो अपने आप में कठिन है
रास्ता)।

GIT रेपो के अलावा, a बनाने का प्रयास करने से पहले देखने के लिए सबसे अच्छी जगह कहाँ होगी?
"k8s.io/kubernetes/pkg/proxy/ipvs" मॉड्यूल/पैकेज? या यह किसी ऐसे व्यक्ति के लिए सबसे अच्छा है जो कोड आधार को बेहतर जानता है?

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

हमें इस कॉनवो को वहां ले जाना चाहिए - यह यहां खो जाएगा।

01/18/2016 को दोपहर 12:34 बजे टिम होकिन ने लिखा:

हाँ, यूडीपी के लिए एनएटी वास्तव में दुर्भाग्यपूर्ण है। एक गैर-कॉन्ट्रैक ढूँढना
समाधान बहुत अच्छा होगा, लेकिन इसे या तो सभी पर लागू करना होगा
वातावरण या प्लेटफ़ॉर्म द्वारा पैरामीटरयुक्त होना (जो अपने आप में कठिन है
रास्ता)।

स्टेटलेस एनएटी उस मामले के लिए काम कर सकता है जहां एक (पॉड, पोर्ट) जोड़े के पास है
अधिकांश एक सेवा (एक सेवा के लिए कई फली)?

यह इस तरह दिखेगा:

{से: क्लाइंटआईपी: क्लाइंटपोर्ट, से: एक्सटर्नलआईपी: एक्सटर्नलपोर्ट} --- [प्रॉक्सी एक यादृच्छिक पॉड का चयन करता है] ---> {से: क्लाइंटआईपी: क्लाइंटपोर्ट, से: पॉडआईपी: टारगेटपोर्ट} ---> [सही होस्ट के माध्यम से रूट किया गया ...]

रास्ते में, फ़ायरवॉल में एक पैकेट {from:
podIP:targetPort , to: any} को {from:
e xternalIP:externalPort , से: अपरिवर्तित}।

इसे iptables बोली में बताने के लिए:

iptables -t nat -N stateless-svc-in

iptables -t nat -N stateless-svc-out

iptables -t nat -A stateless-svc-in  -j DNAT -s 1.2.3.4  -p udp --dport 53 --to-destination 10.1.0.1 -m statistic --mode random --probability 0.3333

iptables -t nat -A stateless-svc-in  -j DNAT -s 1.2.3.4  -p udp --dport 53 --to-destination 10.2.0.1 -m statistic --mode random --probability 0.5

iptables -t nat -A stateless-svc-in  -j DNAT -s 1.2.3.4  -p udp --dport 53 --to-destination 10.2.0.2 -m statistic --mode random --probability 1

iptables -t nat -A stateless-svc-out -j SNAT -s 10.1.0.1 -p udp --sport 53 --to-source 1.2.3.4

iptables -t nat -A stateless-svc-out -j SNAT -s 10.2.0.1 -p udp --sport 53 --to-source 1.2.3.4

iptables -t nat -A stateless-svc-out -j SNAT -s 10.2.0.2 -p udp --sport 53 --to-source 1.2.3.4

जब पैकेट बाहर से आता है तो मैं नहीं देखता कि यह कहाँ काम नहीं करता है
क्लस्टर।

जिस तरह से कुबेरनेट्स में सेवाओं को व्यक्त किया जाता है, वह एक एकल पॉड की अनुमति देता है
किसी भी संख्या में सेवाओं के सामने, इसलिए यह टूट जाता है - हम नहीं जानते कि क्या
SNAT को.

सूर्य, 17 जनवरी 2016 को शाम 6:13 बजे, मिकाएल क्लूसो नोटिफिकेशन @github.com
लिखा था:

01/18/2016 को दोपहर 12:34 बजे टिम होकिन ने लिखा:

हाँ, यूडीपी के लिए एनएटी वास्तव में दुर्भाग्यपूर्ण है। एक गैर-कॉन्ट्रैक ढूँढना
समाधान बहुत अच्छा होगा, लेकिन इसे या तो सभी पर लागू करना होगा
वातावरण या प्लेटफ़ॉर्म द्वारा पैरामीटरयुक्त होना (जो अपने आप में कठिन है
रास्ता)।

स्टेटलेस एनएटी उस मामले के लिए काम कर सकता है जहां एक (पॉड, पोर्ट) जोड़े के पास है
अधिकांश एक सेवा (एक सेवा के लिए कई फली)?

यह इस तरह दिखेगा:

{से: क्लाइंटआईपी: क्लाइंटपोर्ट, टू: एक्सटर्नलआईपी: एक्सटर्नलपोर्ट} --- [प्रॉक्सी चयन
एक रैंडम पॉड] ---> {से: क्लाइंटआईपी: क्लाइंटपोर्ट, से: पॉडआईपी: टारगेटपोर्ट} --->
[सही मेजबान के माध्यम से भेजा गया ...]

रास्ते में, फ़ायरवॉल में एक पैकेट {from:
podIP:targetPort , to: any} को {from:
e xternalIP:externalPort , से: अपरिवर्तित}।

इसे iptables बोली में बताने के लिए:

iptables -t nat -N stateless-svc-in

iptables -t nat -N stateless-svc-out

iptables -t nat -A stateless-svc-in -j DNAT -s 1.2.3.4 -p udp --dport 53
--to-destination 10.1.0.1 -m statistic --mode random --probability 0.3333

iptables -t nat -A stateless-svc-in -j DNAT -s 1.2.3.4 -p udp --dport 53
--to-destination 10.2.0.1 -m statistic --mode random --probability 0.5

iptables -t nat -A stateless-svc-in -j DNAT -s 1.2.3.4 -p udp --dport 53
--to-destination 10.2.0.2 -m statistic --mode random --probability 1

iptables -t nat -A stateless-svc-out -j SNAT -s 10.1.0.1 -p udp --sport 53
--to-source 1.2.3.4

iptables -t nat -A stateless-svc-out -j SNAT -s 10.2.0.1 -p udp --sport 53
--to-source 1.2.3.4

iptables -t nat -A stateless-svc-out -j SNAT -s 10.2.0.2 -p udp --sport 53
--to-source 1.2.3.4

जब पैकेट बाहर से आता है तो मैं नहीं देखता कि यह कहाँ काम नहीं करता है
क्लस्टर।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172408290
.

01/18/2016 03:31 अपराह्न को, टिम होकिन ने लिखा:

जिस तरह से कुबेरनेट्स में सेवाओं को व्यक्त किया जाता है, वह एक एकल पॉड की अनुमति देता है
होने वाला
किसी भी संख्या में सेवाओं के सामने, इसलिए यह टूट जाता है - हम नहीं जानते
क्या
SNAT को.

इसलिए मैंने मामले को कई-से-एक तक सीमित कर दिया (मेरा पहला वाक्य :-))।
मैं सिर्फ एक रेखा खींचने की कोशिश कर रहा हूं कि क्या किया जा सकता है या नहीं।

निश्चित रूप से, मेरे पास यह इंगित करने का दुर्भाग्यपूर्ण काम है कि यह क्यों नहीं है
सामान्य पर्याप्त समाधान :(

रविवार, 17 जनवरी 2016 को रात 8:34 बजे, मिकाएल क्लूसो नोटिफिकेशन @github.com
लिखा था:

01/18/2016 03:31 अपराह्न को, टिम होकिन ने लिखा:

जिस तरह से कुबेरनेट्स में सेवाओं को व्यक्त किया जाता है, वह एक एकल पॉड की अनुमति देता है
होने वाला
किसी भी संख्या में सेवाओं के सामने, इसलिए यह टूट जाता है - हम नहीं जानते
क्या
SNAT को.

इसलिए मैंने मामले को कई-से-एक तक सीमित कर दिया (मेरा पहला वाक्य :-))।
मैं सिर्फ एक रेखा खींचने की कोशिश कर रहा हूं कि क्या किया जा सकता है या नहीं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172421828
.

01/18/2016 03:46 अपराह्न को, टिम होकिन ने लिखा:

निश्चित रूप से, मेरे पास यह इंगित करने का दुर्भाग्यपूर्ण काम है कि यह क्यों नहीं है
सामान्य पर्याप्त समाधान :(

हाँ... लेकिन यह अक्सर पूछे जाने वाले प्रश्न हैं। हम यह भी कह सकते हैं, कहीं, "अगर लेन (सेवा)
== 1 {स्टेटलेस लागू करें} और {स्टेटफुल लागू करें}"। लेकिन यह हो सकता है
नौसिखियों के लिए एक गड़बड़ की तरह देखो। मैं एक योगदान/एल्ब्स/कुछ भी हो सकता हूं ...

यह कुछ ऐसा भी नहीं है जिसे हम वर्तमान में ट्रैक करते हैं (सेवाओं की संख्या जो
किसी दिए गए पॉड के सामने)। हम कर सकते थे, मुझे लगता है। मैं इसके खिलाफ नहीं हूं (भले ही यह)
आला लगता है)। ऐसा करने के लिए यह एक महत्वपूर्ण बदलाव की तरह लगता है
कई चेतावनी। मैं अभी भी बेहतर उत्तरों के बारे में सोचना चाहता हूं।

सूर्य, 17 जनवरी 2016 को रात 8:51 बजे, मिकाएल क्लूसो नोटिफिकेशन @github.com
लिखा था:

01/18/2016 03:46 अपराह्न को, टिम होकिन ने लिखा:

निश्चित रूप से, मेरे पास यह इंगित करने का दुर्भाग्यपूर्ण काम है कि यह क्यों नहीं है
सामान्य पर्याप्त समाधान :(

हाँ... लेकिन यह अक्सर पूछे जाने वाले प्रश्न हैं। हम यह भी कह सकते हैं, कहीं, "अगर लेन (सेवा)
== 1 {स्टेटलेस लागू करें} और {स्टेटफुल लागू करें}"। लेकिन यह हो सकता है
नौसिखियों के लिए एक गड़बड़ की तरह देखो। मैं भी हो सकता हूँ
योगदान/एल्ब्स/कुछ...

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172425404
.

01/18/2016 04:07 अपराह्न को, टिम होकिन ने लिखा:

यह कुछ ऐसा भी नहीं है जिसे हम वर्तमान में ट्रैक करते हैं (सेवाओं की संख्या जो
किसी दिए गए पॉड के सामने)। हम कर सकते थे, मुझे लगता है। मैं इसके खिलाफ नहीं हूं (भले ही यह)
आला लगता है)। ऐसा करने के लिए यह एक महत्वपूर्ण बदलाव की तरह लगता है
कई चेतावनी। मैं अभी भी बेहतर उत्तरों के बारे में सोचना चाहता हूं।

मैं सहमत हूं, लेकिन अभी के लिए कोई बेहतर विचार नहीं है :-(

यहां तक ​​​​कि एक उद्देश्य से निर्मित एसडीएन को कुछ ऐसा ट्रैक करने की आवश्यकता होगी जो मुझे लगता है। शायद
एमपीएलएस जैसे लेबल-आधारित समाधान ..?

01/18/2016 को 04:18 अपराह्न को, मिकेल क्लूसो ने लिखा:

यहां तक ​​​​कि एक उद्देश्य से निर्मित एसडीएन को कुछ ऐसा ट्रैक करने की आवश्यकता होगी जो मुझे लगता है।
शायद एमपीएलएस जैसे लेबल-आधारित समाधान ..?

चीजों को लेबल करने के विचार में... यदि हम प्रति सेवा एक आईपी + एक असाइन करते हैं
आईपी ​​प्रति एंडपॉइंट (सेवा + पॉड युगल), और इन एंडपॉइंट आईपी को जोड़ें
पॉड्स, इसे पूरी तरह से स्टेटलेस काम करना चाहिए:

``````

• होस्ट करने के लिए बाहरी: {से: क्लाइंटआईपी: क्लाइंटपोर्ट, से: बाहरी आईपी: सर्विसपोर्ट} ----- [ईएलबी
  एक समापन बिंदु का चयन करता है] ---------> {से: क्लाइंटआईपी: क्लाइंटपोर्ट, से:
  endpointServiceIP:podPort} -> मेजबान के लिए मार्ग

• पॉड को होस्ट करें: {से: क्लाइंटआईपी: क्लाइंटपोर्ट, टू: एंडपॉइंट सर्विसआईपी: पॉडपोर्ट} - [मानक
  कंटेनरों के लिए रूटिंग] -> {से: क्लाइंटआईपी: क्लाइंटपोर्ट , से:
  एंडपॉइंट सर्विसआईपी:पॉडपोर्ट }

• होस्ट करने के लिए पॉड: {से: एंडपॉइंट सर्विसआईपी: पॉडपोर्ट, क्लाइंटआईपी: क्लाइंटपोर्ट}
  -------- [राउटर के लिए मानक रूटिंग]-----> {से:
  एंडपॉइंट सर्विसआईपी: पॉडपोर्ट, टू: क्लाइंटआईपी: क्लाइंटपोर्ट} - होस्ट टू एक्सटर्नल: {से: एंडपॉइंट सर्विसआईपी: पॉडपोर्ट, टू: क्लाइंटआईपी: क्लाइंटपोर्ट} -------- [ईएलबी
  SNATs वापस]------------------> {से: क्लाइंटआईपी: क्लाइंटपोर्ट , से:
  ई xternalIP:servicePort } ```

ऐसा लगता है कि हम यह काम क्लस्टरआईपी के लिए भी कर सकते हैं।
``````

मैं जीसीई पर यह काम नहीं कर सकता, और मुझे एडब्ल्यूएस के बारे में निश्चित नहीं है - एक है
उपलब्ध स्थिर मार्गों की सीमित संख्या।

मुझे आश्चर्य है कि क्या मैं इसे एक ही में 2 आईपी श्रेणियों को एक साथ पिग्गीबैक करके कर सकता हूं
मार्ग। यह खर्च करने के लिए बहुत सारे आईपी हैं, लेकिन मुझे लगता है कि यह केवल यूडीपी के लिए मायने रखता है।
मुझे इसे आजमाना होगा।

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

मुझे फिर कभी कोशिश करनी होगी।

सूर्य, 17 जनवरी 2016 को रात 10:22 बजे, मिकाएल क्लूसो नोटिफिकेशन @github.com
लिखा था:

01/18/2016 को 04:18 अपराह्न को, मिकेल क्लूसो ने लिखा:

यहां तक ​​​​कि एक उद्देश्य से निर्मित एसडीएन को कुछ ऐसा ट्रैक करने की आवश्यकता होगी जो मुझे लगता है।
शायद एमपीएलएस जैसे लेबल-आधारित समाधान ..?

चीजों को लेबल करने के विचार में... यदि हम प्रति सेवा एक आईपी + एक असाइन करते हैं
आईपी ​​प्रति एंडपॉइंट (सेवा + पॉड युगल), और इन एंडपॉइंट आईपी को जोड़ें
पॉड्स, इसे पूरी तरह से स्टेटलेस काम करना चाहिए:

``````

• होस्ट करने के लिए बाहरी: {से: क्लाइंटआईपी: क्लाइंटपोर्ट, से: बाहरी आईपी: सर्विसपोर्ट}
  -----[ईएलबी
  एक समापन बिंदु का चयन करता है] ---------> {से: क्लाइंटआईपी: क्लाइंटपोर्ट, से:
  endpointServiceIP:podPort} -> मेजबान के लिए मार्ग

• पॉड को होस्ट करें: {से: क्लाइंटआईपी: क्लाइंटपोर्ट, से: एंडपॉइंट सर्विसआईपी: पॉडपोर्ट}
  --[मानक
  कंटेनरों के लिए रूटिंग] -> {से: क्लाइंटआईपी: क्लाइंटपोर्ट , से:
  एंडपॉइंट सर्विसआईपी:पॉडपोर्ट }

• होस्ट करने के लिए पॉड: {से: एंडपॉइंट सर्विसआईपी: पॉडपोर्ट, क्लाइंटआईपी: क्लाइंटपोर्ट}
  -------- [राउटर के लिए मानक रूटिंग]-----> {से:
  एंडपॉइंट सर्विसआईपी:पॉडपोर्ट, टू: क्लाइंटआईपी:क्लाइंटपोर्ट} - होस्ट टू
  बाहरी: {से: एंडपॉइंट सर्विसआईपी: पॉडपोर्ट, से: क्लाइंटआईपी: क्लाइंटपोर्ट}
  --------[ईएलबी
  SNATs वापस]------------------> {से: क्लाइंटआईपी: क्लाइंटपोर्ट , से:
  ई xternalIP:servicePort } ```

ऐसा लगता है कि हम यह काम क्लस्टरआईपी के लिए भी कर सकते हैं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment-172438133
.

``````

मैं कुछ पाने के लिए अपनी तरफ से कोशिश कर रहा हूं (मेरे स्थानीय होस्ट पर शुद्ध नेटन्स के साथ)
अभी के लिए)।

मैं एक दृष्टिकोण की कोशिश कर रहा हूं जहां मैं सेवा आईपी श्रेणियों को मेजबानों को प्रभावित करता हूं
रूटिंग प्रविष्टियों की संख्या कम करें:

क्ली -- एल्ब -- h1 -- c1

| `--- c2

`--- h2 -- c2

h1_ep_ip_ranges=( 10.1.1.0/24 10.1.2.0/24 )
h2_ep_ip_ranges=( 10.1.3.0/24 )

कोई पिंग एटीएम नहीं (पैकेट जो PREROUTING श्रृंखला से नहीं गुजर रहे हैं...), और
सोने की जरूरत। इस पर कल;)

01/18/2016 06:28 अपराह्न को, टिम होकिन ने लिखा:

मैं जीसीई पर यह काम नहीं कर सकता, और मुझे एडब्ल्यूएस के बारे में निश्चित नहीं है - एक है
उपलब्ध स्थिर मार्गों की सीमित संख्या।

मुझे आश्चर्य है कि क्या मैं इसे एक ही में 2 आईपी श्रेणियों को एक साथ पिग्गीबैक करके कर सकता हूं
मार्ग। यह खर्च करने के लिए बहुत सारे आईपी हैं, लेकिन मुझे लगता है कि यह केवल यूडीपी के लिए मायने रखता है।
मुझे इसे आजमाना होगा।

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

मुझे फिर कभी कोशिश करनी होगी।

मैं थोड़ा आगे निकल गया, लेकिन कुछ ऐसा हुआ जिसकी मुझे भविष्यवाणी करनी चाहिए थी।

मैंने इसके मुख्य इंटरफ़ेस के रूप में 10.244.2.8/25 और 10.244.2.250/25 के साथ एक पॉड स्थापित किया
इसके "इन-ए-सर्विस" इंटरफ़ेस के रूप में। मैं उम्मीद कर रहा था कि मैं यूडीपी भेज सकता हूं
.250 और प्रतिक्रियाओं का पता लगाने, उन्हें SNAT करने के लिए। लेकिन निश्चित रूप से, यदि ग्राहक है
उसी में नहीं /25 (जो यह नहीं हो सकता) डिफ़ॉल्ट मार्ग शुरू होता है, जो
.8 पते से आता है। tcpdump पुष्टि करता है कि प्रतिक्रियाएँ .8 . से आती हैं
यूडीपी का उपयोग करते समय।

मैं फिर से एक ऐसी जगह पर हूं जहां मुझे यकीन नहीं है कि इसे कैसे काम करना है। सोचेंगे
उस पर अधिक।

सोम, 18 जनवरी, 2016 को दोपहर 2:59 बजे, मिकाएल क्लूसो नोटिफिकेशन @github.com
लिखा था:

मैं कुछ पाने के लिए अपनी तरफ से कोशिश कर रहा हूं (मेरे स्थानीय होस्ट पर शुद्ध नेटन्स के साथ)
अभी के लिए)।

मैं एक दृष्टिकोण की कोशिश कर रहा हूं जहां मैं सेवा आईपी श्रेणियों को मेजबानों को प्रभावित करता हूं
रूटिंग प्रविष्टियों की संख्या कम करें:

क्ली -- एल्ब -- h1 -- c1

| `--- c2

`--- h2 -- c2

h1_ep_ip_ranges=( 10.1.1.0/24 10.1.2.0/24 )
h2_ep_ip_ranges=( 10.1.3.0/24 )

कोई पिंग एटीएम नहीं (पैकेट जो PREROUTING श्रृंखला से नहीं गुजर रहे हैं...), और
सोने की जरूरत। इस पर कल;)

01/18/2016 06:28 अपराह्न को, टिम होकिन ने लिखा:

मैं जीसीई पर यह काम नहीं कर सकता, और मुझे एडब्ल्यूएस के बारे में निश्चित नहीं है - एक है
उपलब्ध स्थिर मार्गों की सीमित संख्या।

मुझे आश्चर्य है कि क्या मैं इसे 2 आईपी श्रेणियों को एक साथ पिग्गीबैक करके कर सकता हूं
एक
मार्ग। यह खर्च करने के लिए बहुत सारे आईपी हैं, लेकिन मुझे लगता है कि यह केवल यूडीपी के लिए मायने रखता है।
मुझे इसे आजमाना होगा।

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

मुझे फिर कभी कोशिश करनी होगी।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172497456
.

यह मुझ पर (अभिषेक के माध्यम से) आता है कि भले ही यह काम करता हो, हमें अभी भी करना होगा
ट्रैक कहीं बहता है, इसलिए यह अंत में वैसे भी स्टेटलेस नहीं है।

सोम, 18 जनवरी, 2016 को रात 9:50 बजे, टिम होकिन [email protected] ने लिखा:

मैं थोड़ा आगे निकल गया, लेकिन कुछ ऐसा हुआ जिसकी मुझे भविष्यवाणी करनी चाहिए थी।

मैंने इसके मुख्य इंटरफ़ेस के रूप में 10.244.2.8/25 के साथ एक पॉड स्थापित किया और
10.244.2.250/25 इसके "इन-ए-सर्विस" इंटरफ़ेस के रूप में। मैं उम्मीद कर रहा था कि मैं
यूडीपी को .250 पर भेज सकता है और प्रतिक्रियाओं का पता लगा सकता है, उन्हें एसएनएटी के लिए। लेकिन निश्चित रूप से,
यदि ग्राहक उसी /25 में नहीं है (जो यह नहीं हो सकता) डिफ़ॉल्ट
मार्ग शुरू होता है, जो .8 पते से आता है। tcpdump पुष्टि करता है कि
यूडीपी का उपयोग करते समय प्रतिक्रियाएं .8 से आती हैं।

मैं फिर से एक ऐसी जगह पर हूं जहां मुझे यकीन नहीं है कि इसे कैसे काम करना है। सोचेंगे
उस पर अधिक।

सोम, 18 जनवरी, 2016 को दोपहर 2:59 बजे, मिकाएल क्लूसो नोटिफिकेशन @github.com
लिखा था:

मैं कुछ पाने के लिए अपनी तरफ से कोशिश कर रहा हूं (मेरे स्थानीय होस्ट पर शुद्ध नेटन्स के साथ)
अभी के लिए)।

मैं एक दृष्टिकोण की कोशिश कर रहा हूं जहां मैं सेवा आईपी श्रेणियों को मेजबानों को प्रभावित करता हूं
रूटिंग प्रविष्टियों की संख्या कम करें:

क्ली -- एल्ब -- h1 -- c1

| `--- c2

`--- h2 -- c2

h1_ep_ip_ranges=( 10.1.1.0/24 10.1.2.0/24 )
h2_ep_ip_ranges=( 10.1.3.0/24 )

कोई पिंग एटीएम नहीं (पैकेट जो PREROUTING श्रृंखला से नहीं गुजर रहे हैं...), और
सोने की जरूरत। इस पर कल;)

01/18/2016 06:28 अपराह्न को, टिम होकिन ने लिखा:

मैं जीसीई पर यह काम नहीं कर सकता, और मुझे एडब्ल्यूएस के बारे में निश्चित नहीं है - एक है
उपलब्ध स्थिर मार्गों की सीमित संख्या।

मुझे आश्चर्य है कि क्या मैं इसे 2 आईपी श्रेणियों को एक साथ पिग्गीबैक करके कर सकता हूं
एक
मार्ग। यह खर्च करने के लिए बहुत सारे आईपी हैं, लेकिन मुझे लगता है कि यह केवल यूडीपी के लिए मायने रखता है।
मुझे इसे आजमाना होगा।

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

मुझे फिर कभी कोशिश करनी होगी।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172497456
.

यह दुर्भाग्यपूर्ण है :-( यकीन नहीं क्यों वैसे। मैं एमपीएलएस के साथ कुछ करने की कोशिश करूंगा, मैं इसे वैसे भी सीखना चाहता हूं।

यदि आपके पास सेवा के लिए 2 बैकएंड हैं और आप एक से अधिक भेजना चाहते हैं
पैकेट, आपको किसी तरह प्रवाह को ट्रैक करने की आवश्यकता है, है ना? या आप हैं
यह मानते हुए कि अलग-अलग बैकएंड पर पैकेट स्प्रे करना सुरक्षित है?

बुध, 20 जनवरी 2016 को दोपहर 12:24 बजे, मिकाएल क्लूसो नोटिफिकेशन @github.com
लिखा था:

यह दुर्भाग्यपूर्ण है :-( यकीन नहीं है कि क्यों। मैं इसके साथ कुछ करने की कोशिश करूंगा
एमपीएलएस तो, मैं इसे वैसे भी सीखना चाहता हूं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -173348973
.

मुझे लगता है कि यूडीपी वर्कलोड के लिए, हाँ। यूडीपी के लिए भी स्टेटलेस जाना वैकल्पिक हो सकता है। @qoke इस पर कोई टिप्पणी?

साथ ही, हम क्लाइंट आईपी हैशिंग जैसी चीजों का उपयोग प्रवाह को और अधिक स्थिर बनाने के लिए कर सकते हैं जबकि अभी भी संतुलित है (मुझे नहीं पता कि हम इसे "किसी प्रकार की ट्रैकिंग" :-) कह सकते हैं)।

@MikaelCluseau हम डिफ़ॉल्ट

यूडीपी डेटाग्राम शेड्यूल करने के लिए, आईपीवीएस लोड बैलेंसर कॉन्फ़िगर करने योग्य टाइमआउट के साथ यूडीपी डेटाग्राम शेड्यूलिंग रिकॉर्ड करता है, और डिफ़ॉल्ट यूडीपी टाइमआउट 300 सेकंड है। यूडीपी कनेक्शन टाइमआउट से पहले, एक ही सॉकेट (प्रोटोकॉल, आईपी एड्रेस और पोर्ट) से सभी यूडीपी डेटाग्राम एक ही सर्वर पर निर्देशित किए जाएंगे।

-- http://kb.linuxvirtualserver.org/wiki/IPVS . से उद्धरित

बेशक, यह केवल तभी काम करता है जब आपके पास एक ही सेवा से बात करने वाले कई क्लाइंट हों, या अलग-अलग स्रोत पोर्ट वाले एकल क्लाइंट हों। यदि आपके पास एक ही उच्च-मात्रा वाला क्लाइंट है, सभी एक ही स्रोत पोर्ट से ट्रैफ़िक भेज रहे हैं, और आप इसे कई बैकएंड पर लोड करना चाहते हैं, तो आप स्टेटलेस/स्प्रे-एंड-प्रार्थना दृष्टिकोण का उपयोग करना पसंद कर सकते हैं।

हम बहुत सारे DNS और RADIUS ट्रैफ़िक को संतुलित करते हैं - DNS आमतौर पर पहली श्रेणी में आता है (बहुत सारे क्लाइंट, या बहुत सारे सोर्स पोर्ट वाले क्लाइंट), और RADIUS आमतौर पर बाद की श्रेणी में आता है (कुछ क्लाइंट, बहुत सारे पैकेट सभी से एक ही आईपी/पोर्ट)। RADIUS के लिए एक स्टेटलेस हैश का उपयोग करने के बजाय हमने एक समान प्रसार प्राप्त करने के लिए स्रोत पोर्ट को यादृच्छिक बनाने का निर्णय लिया।

पूरे धागे को पढ़ने के बाद भी मैं यह पता नहीं लगा सकता कि क्यूब-प्रॉक्सी के लिए iptables मोड को सक्रिय करने से बाहरी आईपी के छिपे होने की समस्या (#10921) ठीक होनी चाहिए या नहीं। जैसा कि यहां सुझाया गया है, हमने v1.1 के साथ iptables मोड को सक्षम किया है लेकिन हम अभी भी क्लस्टर से आईपी देख रहे हैं, उपयोगकर्ताओं से वास्तविक नहीं।

हमारा क्लस्टर GCE में है और लाइव होने से पहले हमें केवल HTTPS सपोर्ट के साथ लोड बैलेंसर की आवश्यकता है। चूंकि जीसीई v.1.2 अल्फा का समर्थन नहीं करता है, इसलिए हम नए इनग्रेड (जो AFAIK HTTPS लोड बैलेंसर्स का समर्थन करता है) का उपयोग नहीं कर सकते हैं, इसलिए नेटवर्क लोड बैलेंसर ही हमारा एकमात्र विकल्प है। लेकिन स्पष्ट रूप से हम अपने उपयोगकर्ताओं से वास्तविक आईपी लॉगिंग करने की क्षमता के बिना लाइव नहीं हो सकते।

इस पर नए उपयोगकर्ताओं के लिए कुछ स्पष्टीकरण की सराहना की जाएगी। हम में से कई लोगों के लिए HTTPS को सपोर्ट करना अनिवार्य है। धन्यवाद!

मैं काफी समय से iptables प्रॉक्सी को चालू और बंद कर रहा हूं और पुष्टि कर सकता हूं कि क्लाइंट के बाहरी आईपी अभी भी छिपे हुए हैं/क्लस्टर आईपी दिखाते हैं।

हमने होस्ट नेटवर्क मोड में चल रहे हमारे फ्रंटएंड HTTP/HTTPS प्रॉक्सी को चलाकर अब तक इसे प्राप्त कर लिया है ताकि यह स्रोत आईपी पता देख सके।

@maclof प्रतिक्रिया के लिए धन्यवाद। क्या आप अपने कामकाज के तरीके के बारे में अधिक जानकारी साझा कर सकते हैं? होस्ट नेटवर्क में चल रहे आपके HTTP/HTTPS से आपका क्या तात्पर्य है?

@javiercr हम कुछ इस तरह से पॉड स्पेक का उपयोग करते हैं: http://pastie.org/private/zpdelblsob654zif7xus5g

होस्ट नेटवर्क का उपयोग करने का अर्थ है कि पॉड क्लस्टर IP असाइन किए जाने के बजाय होस्ट मशीन नेटवर्क में चलता है।

इसका मतलब है कि जब हमारा nginx सर्वर 80/443 पोर्ट से जुड़ता है तो वह होस्ट आईपी पर सुनेगा और स्रोत आईपी पते देखेगा।

मैं कुबेरनेट्स 1.1, /opt/bin/kube-proxy ... --proxy-mode=iptables --masquerade-all=false का उपयोग कर रहा हूं और क्यूब-प्रॉक्सी वाले होस्ट के माध्यम से क्लूसर आईपी नेटवर्क को रूट कर रहा हूं। इस सेटअप में, मेरी सेवाएं बाहरी आईपी देख रही हैं। मैं एक अत्यधिक उपलब्ध नेटवर्क नेमस्पेस का उपयोग करता हूं जिसमें बाहरी आईपी और मेजबानों के लिए मार्ग है:

I0221 01:20:32.695440       1 main.go:224] <A6GSXEKN> Connection from 202.22.xxx.yyy:51954 closed.

मैंने इस धागे को पढ़कर बहुत कुछ सीखा है!

एफवाईआई के रूप में यह दस्तावेज़ बताता है कि एडब्ल्यूएस ईएलबी टीसीपी कनेक्शन के लिए राउंड-रॉबिन का उपयोग करता है और http/https के लिए कम से कम कनेक्शन का उपयोग करता है: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/how-elb-works.html# अनुरोध - रूटिंग

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

लोड बैलेंसर के साथ काम करने के मामले में जो भार का समर्थन नहीं करता है, तो आप इसे अपने प्रतिकृति नियंत्रक के साथ एक नोड पर हमेशा समान संख्या में पॉड्स रखने की कोशिश करके हल कर सकते हैं (यदि प्रति नोड 1 से अधिक है) और फिर समान रूप से वितरित करना उन्हें, भले ही इसका मतलब कुछ स्थितियों में नोड से पॉड्स को स्थानांतरित करना हो और केवल कुछ प्रतिकृति की गणना की अनुमति देना हो। उदाहरण के लिए एक लोड बैलेंसर से जुड़ी सेवा के साथ 4 नोड क्लस्टर के लिए स्वीकार्य पॉड प्रतिकृतियों की एकमात्र संख्या 1,2,3,4,6,8,9,12,16,20, आदि होगी।

हम केवल स्थानीय पॉड्स के लिए मार्ग के लिए यातायात के लिए भी हल करना चाह रहे हैं। जब नोडपोर्ट किसी सेवा के लिए स्थानीय रूप से मौजूद नहीं होता है तो नोडपोर्ट पर नोड पर जाने के साथ मैं ठीक हो जाऊंगा। इस तरह एक साधारण लोड बैलेंसर टीसीपी स्वास्थ्य जांच अनुरोधों को उन नोड्स पर जाने से रोकेगी। मुझे लगता है कि अगर हम इसके iptables\kube-proxy भाग के लिए कम से कम हल कर सकते हैं, तो हम यह पता लगाएंगे कि जब पॉड्स क्लस्टर में संतुलित नहीं होते हैं तो लोड संतुलन के निहितार्थ क्या होते हैं। मुझे लगता है कि प्रत्येक नोड w/एपीआई कॉल के लिए वजन निर्धारित किए बिना लोड बैलेंसर्स पर इसे हल करने के तरीके हैं।

लोड बैलेंसर पहले से ही अन्य गतिशील विधियों का उपयोग करके w/इस का सौदा करते हैं। साथ ही, आपके द्वारा चलाई जा रही सेवा वास्तव में प्रत्येक एपीआई कॉल के लिए उस कंटेनर के अंदर क्या कर रही है, इस पर निर्भर करता है कि यह 2x यातायात का समर्थन करने में सक्षम नहीं हो सकता है जब किसी भी तरह से एक नोड पर 2 पॉड होते हैं। यदि कुबेरनेट्स सीमाएँ निर्धारित की जाती हैं और यदि पॉडनोड पर उपयोग के अधिकतम स्तर तक संपर्क किया जा रहा है तो यह भी खेल सकता है जो बाहरी लोड बैलेंसर पर सही वजन सेटिंग खोजने की कोशिश करने के लिए जटिलता की एक और परत जोड़ता है।

मैं कहूंगा, जटिलता के उस स्तर से दूर रहें और कुबेरनेट्स से लोड बैलेंसर वजन सेट करने का प्रयास न करें।

@yoshiwaan क्या मैं इंटर-नोड ट्रैफिक सुझाव के लिए एक नया मुद्दा खोलने का सुझाव दे सकता हूं, क्योंकि यह मुद्दा अब बंद हो गया है। व्यक्तिगत रूप से मुझे लगता है कि यह सुनिश्चित करने के लिए एक अच्छा पहला कदम होगा कि स्थानीय नोड पर _if_ एक पॉड चल रहा है, जिसे हम स्थानीय पॉड के लिए रूट करते हैं। मुझे संदेह है कि यह पर्याप्त होगा, क्योंकि तब आप अपने आरसी को स्केल कर सकते हैं ताकि प्रत्येक नोड पर पॉड हों।

@justinsb +1, हम भी अब एक समस्या में चल रहे हैं जहां हमें क्लाइंट आईपी देखने की जरूरत है और वर्तमान सेटअप के साथ यह मूल रूप से असंभव है।

यह बहुत भोला हो सकता है, फिर भी मैं सोच रहा था कि यूजरस्पेस मोड और iptables में क्या अंतर है? मैं वास्तव में उपयोगकर्ता दस्तावेज़ से नहीं बता सकता।

यूजरलैंड मोड का मतलब है कि क्यूब-प्रॉक्सी क्लाइंट से कनेक्शन अनुरोध प्राप्त करके और सर्वर के लिए एक सॉकेट खोलकर कनेक्शन को स्वयं संभालता है, जो (1) बहुत अधिक सीपीयू और मेमोरी का उपभोग करता है और (2) पोर्ट की संख्या तक सीमित है। खुला (<65k)। iptables मोड कर्नेल में निचले स्तर पर काम करता है, और इसके बजाय कनेक्शन ट्रैकिंग का उपयोग करता है, इसलिए यह बहुत हल्का है और बहुत अधिक कनेक्शन को संभालता है*।

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

@MikaelCluseau
अर्थ क्यूब-प्रॉक्सी केवल iptables नियमों को स्थापित करने और बनाए रखने के लिए जिम्मेदार है और अब हमें iptables मोड में प्रत्येक सेवा के लिए एक यादृच्छिक स्थानीय पोर्ट नहीं मिलता है, है ना?

04/19/2016 को 10:51 अपराह्न, एम्मा उन्होंने लिखा:

अर्थ क्यूब-प्रॉक्सी केवल स्थापित करने और बनाए रखने के लिए जिम्मेदार है
iptables और अब हमें प्रत्येक सेवा के लिए एक यादृच्छिक स्थानीय पोर्ट नहीं मिलता है
iptables मोड, है ना?

हां।

क्षमा करें, लेकिन मैं इससे पहले बिल्कुल चूक गया था।

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

@MikaelCluseau मैं सोच रहा था कि iptables SNAT और DNAT को अपनाता है, जो आपके अनुसार ऐसा नहीं है। क्या आप कृपया इसे मेरे लिए स्पष्ट कर सकते हैं?

04/20/2016 को 01:59 अपराह्न, एम्मा उन्होंने लिखा:

@MikaelCluseau https://github.com/MikaelCluseau मैं सोच रहा था
iptables SNAT और DNAT को अपनाता है, जो आपके अनुसार ऐसा नहीं है।
क्या आप कृपया इसे मेरे लिए स्पष्ट कर सकते हैं?

यह मुश्किल हिस्सा है।

(1) सेवा/बाहरी आईपी का उपयोग करने के लिए डीएनएटी की आवश्यकता होती है।
(2) यदि आप सुनिश्चित हैं कि उत्तर पैकेट उसी कॉन्ट्रैक से गुजरेंगे
नियम (यानी, एक ही नेटवर्क स्टैक या एक प्रतिकृति कॉनट्रैक टेबल), आप
SNAT भाग (यानी, MASQUERADE नियम) को छोड़ सकते हैं।

रूटेड एक्सेस नेटवर्क डिज़ाइन में (2) की स्थिति आमतौर पर ठीक होती है
(जो सबसे सरल डिजाइन है जिसके बारे में मैं सोच सकता हूं)।

उदाहरण के लिए, दिया गया

• एक ग्राहक 1.0.1.1,
• एक सेवा 1.0.2.1,
• 1.0.3.1 सेवा को लागू करने वाला एक पॉड।

फिर,

1. आपका राउटर/फ़ायरवॉल/लोडबैलेंसर/होस्ट/जो भी एक पैकेट प्राप्त करता है
   सेवा के लिए तो यह एक पैकेट "1.0.1.1 -> 1.0.2.1" देखता है;
2. यह इसे एंडपॉइंट (पॉड) पर डीएनए करता है इसलिए पैकेट "1.0.1.1 -> . होगा
   1.0.3.1" क्लस्टर नेटवर्क में;
3. पॉड "1.0.3.1 -> 1.0.1.1" पैकेट के साथ जवाब देता है;
4. पैकेट राउटर/फ़ायरवॉल/लोडबैलेंसर/होस्ट/जो कुछ भी हो जाता है
   कॉनट्रैक नियम होने पर, कॉनट्रैक सिस्टम पैकेट को फिर से लिखता है
   क्लाइंट को वापस भेजने से पहले "1.0.2.1 -> 1.0.1.1" पर।

यदि (2) की शर्त को पूरा नहीं किया जा सकता है, तो आपको SNAT/MASQUERADING . का उपयोग करना होगा
यह सुनिश्चित करने के लिए कि पैकेट वापस जाएगा
राउटर/फ़ायरवॉल/लोडबैलेंसर/होस्ट/जो भी कॉन्ट्रैक है।

@MikaelCluseau - google.com पर मेरे
कुछ तुम्हारे लिये

मंगलवार, 19 अप्रैल, 2016 को रात 8:20 बजे, मिकाएल क्लूसो नोटिफिकेशन @github.com
लिखा था:

04/20/2016 को 01:59 अपराह्न, एम्मा उन्होंने लिखा:

@MikaelCluseau https://github.com/MikaelCluseau मैं सोच रहा था
iptables SNAT और DNAT को अपनाता है, जो आपके अनुसार ऐसा नहीं है।
क्या आप कृपया इसे मेरे लिए स्पष्ट कर सकते हैं?

यह मुश्किल हिस्सा है।

(1) सेवा/बाहरी आईपी का उपयोग करने के लिए डीएनएटी की आवश्यकता होती है।
(2) यदि आप सुनिश्चित हैं कि उत्तर पैकेट उसी कॉन्ट्रैक से गुजरेंगे
नियम (यानी, एक ही नेटवर्क स्टैक या एक प्रतिकृति कॉनट्रैक टेबल), आप
SNAT भाग (यानी, MASQUERADE नियम) को छोड़ सकते हैं।

रूटेड एक्सेस नेटवर्क डिज़ाइन में (2) की स्थिति आमतौर पर ठीक होती है
(जो सबसे सरल डिजाइन है जिसके बारे में मैं सोच सकता हूं)।

उदाहरण के लिए, दिया गया

• एक ग्राहक 1.0.1.1,
• एक सेवा 1.0.2.1,
• 1.0.3.1 सेवा को लागू करने वाला एक पॉड।

फिर,

1. आपका राउटर/फ़ायरवॉल/लोडबैलेंसर/होस्ट/जो भी एक पैकेट प्राप्त करता है
   सेवा के लिए तो यह एक पैकेट "1.0.1.1 -> 1.0.2.1" देखता है;
2. यह इसे एंडपॉइंट (पॉड) पर डीएनए करता है इसलिए पैकेट "1.0.1.1 -> . होगा
   1.0.3.1" क्लस्टर नेटवर्क में;
3. पॉड "1.0.3.1 -> 1.0.1.1" पैकेट के साथ जवाब देता है;
4. पैकेट राउटर/फ़ायरवॉल/लोडबैलेंसर/होस्ट/जो कुछ भी हो जाता है
   कॉनट्रैक नियम होने पर, कॉनट्रैक सिस्टम पैकेट को फिर से लिखता है
   क्लाइंट को वापस भेजने से पहले "1.0.2.1 -> 1.0.1.1" पर।

यदि (2) की शर्त को पूरा नहीं किया जा सकता है, तो आपको SNAT/MASQUERADING . का उपयोग करना होगा
यह सुनिश्चित करने के लिए कि पैकेट वापस जाएगा
राउटर/फ़ायरवॉल/लोडबैलेंसर/होस्ट/जो भी कॉन्ट्रैक है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -212230959

@justinsb @yoshiwaan क्या कभी किसी ने इसके लिए कोई मुद्दा बनाया? मेरी खोज फू मुझे विफल कर रही है, और मुझे भी इसी तरह की आवश्यकता है।

क्या मैं इंटर-नोड ट्रैफिक सुझाव के लिए एक नया मुद्दा खोलने का सुझाव दे सकता हूं, क्योंकि यह मुद्दा अब बंद हो गया है। व्यक्तिगत रूप से मुझे लगता है कि एक अच्छा पहला कदम यह सुनिश्चित करना होगा कि यदि स्थानीय नोड पर कोई पॉड चल रहा है, तो हम स्थानीय पॉड के लिए रूट करते हैं। मुझे संदेह है कि यह पर्याप्त होगा, क्योंकि तब आप अपने आरसी को स्केल कर सकते हैं ताकि प्रत्येक नोड पर पॉड हों।

मैंने इसे खुद नहीं बढ़ाया

आह, मुझे लगता है कि मैंने इसे पाया, यह सुविधा/फिक्स प्रतीत होता है: https://github.com/kubernetes/features/issues/27

1.5.x के रूप में बीटा लगता है।