Kubernetes सेवा निर्दिष्ट पोर्ट की तुलना में विभिन्न पोर्ट पर प्रतिक्रिया कर रही है

Dec 16 2020

मैंने कुछ सेवाओं को तैनात किया है और एक सेवा को दूसरों से अलग व्यवहार करने के लिए पाया है। मैंने इसे 8090 पोर्ट (जो आंतरिक रूप से 8443 पर मैप करता है) को सुनने के लिए कॉन्फ़िगर किया है, लेकिन अनुरोध केवल तभी काम करता है जब मैं पोर्ट 8080 पर भेजता हूं। यहां सेवा के लिए मेरी यमल फ़ाइल (आवश्यक के लिए छीन ली गई) है और एक तैनाती है जो सेवा को एन्क्रिप्ट करती है और कंटेनर

apiVersion: v1
kind: Service
metadata:
  name: uisvc
  namespace: default
  labels:
    helm.sh/chart: foo-1
    app.kubernetes.io/name: foo
    app.kubernetes.io/instance: rb-foo
spec:
  clusterIP: None
  ports:
    - name: http
      port: 8090
      targetPort: 8080
  selector:
    app.kubernetes.io/component: uisvc

हेल्म स्थापित करने के बाद, जब मैं चलता हूं, तो मुझे kubectl get svcनिम्न आउटपुट मिलता है

fooaccess       ClusterIP   None         <none>        8888/TCP   119m
fooset          ClusterIP   None         <none>        8080/TCP   119m
foobus          ClusterIP   None         <none>        6379/TCP   119m
uisvc           ClusterIP   None         <none>        8090/TCP   119m

हालांकि, जब मैं दूसरे चालू कंटेनरों में से एक में बोता हूं और 8090 पर कर्ल अनुरोध करता हूं, तो मुझे "कनेक्शन मना कर दिया जाता है"। अगर मैं "http: // uisvc: 8080" को कर्ल करता हूं, तो मुझे सही प्रतिक्रिया मिल रही है। कंटेनर एक स्प्रिंग बूट एप्लिकेशन चला रहा है, जो डिफ़ॉल्ट रूप से 8080 पर सुनता है। एकमात्र स्पष्टीकरण जो मैं आ सकता था, वह है किसी तरह पोर्ट / टारगेटपार्ट को इस कॉन्फ़िगरेशन में अनदेखा किया जा रहा है और अन्य पॉड्स सीधे वसंत सेवा के अंदर पहुंच रहे हैं।

क्या यह व्यवहार सही है? 8090 पर क्यों नहीं सुन रहा है? मुझे इसे इस तरह कैसे काम करना चाहिए?

संपादित करें: आउटपुट के लिए kubectl describe svc uisvc

Name:              uisvc
Namespace:         default
Labels:            app.kubernetes.io/instance=foo-rba
                   app.kubernetes.io/managed-by=Helm
                   app.kubernetes.io/name=rba
                   helm.sh/chart=rba-1
Annotations:       meta.helm.sh/release-name: foo
                   meta.helm.sh/release-namespace: default
Selector:          app.kubernetes.io/component=uisvc
Type:              ClusterIP
IP:                None
Port:              http  8090/TCP
TargetPort:        8080/TCP
Endpoints:         172.17.0.8:8080
Session Affinity:  None
Events:            <none>

जवाब

1 thomas Dec 16 2020 at 20:39

आपके द्वारा उपयोग किए जाने के बाद से यह अपेक्षित व्यवहार है headless service।

हेडलेस सर्विसेज का उपयोग सेवा खोज तंत्र के लिए किया जाता है इसलिए सिंगल लौटने के बजाय DNS A records, आपकी सेवा के लिए प्रत्येक को एक व्यक्तिगत पॉड्स के आईपी को इंगित करते हुए DNS serverवापस लौटाएगा जो सेवा को वापस करता है A records। तो आप साधारण DNS A recordsखोज करें और उन सभी पॉड्स का आईपी प्राप्त करें जो सेवा का हिस्सा हैं।

के बाद से headless serviceपैदा नहीं करता iptablesनियम लेकिन बनाता dns recordsबजाय, आप अपने बजाय फली एक प्रॉक्सी के साथ सीधे बातचीत कर सकते हैं। इसलिए यदि आप संकल्प <servicename:port>लेते हैं कि आप प्राप्त करेंगे <podN_IP:port>और फिर आपका कनेक्शन सीधे पॉड में जाएगा। जब तक यह सब एक ही नेमस्पेस में है तब तक आप इसे पूर्ण डीएनएस नाम से हल नहीं करेंगे।

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