Kubernetes: प्रवेश: एकाधिक मेजबानों के लिए अनुमति दें

इसके लिए भी +1। जैसा कि @klausenbusk और मेरे द्वारा https://github.com/kubernetes/kubernetes/issues/41881 पर संदर्भित किया गया है, यह एक लंबा रास्ता तय करेगा।

मैं वाइल्डकार्ड या सबडोमेन-ओनली विकल्प रखना पसंद करता हूं, इसलिए मैं host: web.* या host: api.web.* निर्दिष्ट कर सकता हूं और कुछ भी है जो _starts_ उस पैटर्न के साथ गुजरता है, सेवा को उसके अंतिम डोमेन के रूप में अनजान छोड़ देता है (क्या यह चल रहा है .example.com ? .prod.example.com ? .beta.example.com ? .it.internal ?), लेकिन कुछ भी जो इसे वर्तमान मोनोलिथिक से आगे ले जाता है "पूरे एकल डोमेन को सूचीबद्ध करना चाहिए host: में एक बड़ा कदम है।

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

एक और +1। मुझे लगता है कि गैर-तुच्छ प्रवेश उपयोग-मामले वाले लगभग किसी को भी इससे फायदा होगा।

+1

+1

90d निष्क्रियता के बाद मुद्दे पुराने हो जाते हैं।
/remove-lifecycle stale साथ समस्या को ताज़ा के रूप में चिह्नित करें।
अतिरिक्त 30d निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

/lifecycle frozen टिप्पणी के साथ समस्याओं को स्वतः बंद होने से रोकें।

अगर इस मुद्दे को अभी बंद करना सुरक्षित है तो कृपया इसे /close ।

सिग-टेस्टिंग, कुबेरनेट्स/टेस्ट-इन्फ्रा और/या @fejta को फीडबैक भेजें।
/जीवनचक्र बासी

/निकालें-जीवनचक्र बासी

जाहिर है, मैं इसे पुराने से नहीं हटा सकता...

ऐसा लगता है कि यह @deitch काम

मैं भी इस सुविधा को देखना चाहता हूं, लेकिन एक समाधान के रूप में, मैं वाईएएमएल आईडी का उपयोग करता हूं। यहां बताया गया है कि यह दिए गए उदाहरण के लिए कैसा दिखेगा।

spec:
  rules:
  - host: foobar.com
    http: &http_rules
      paths:
      - backend:
          serviceName: foobar
          servicePort: 80
  - host: api.foobar.com
    http: *http_rules
  - host: admin.foobar.com
    http: *http_rules
  - host: status.foobar.com
    http: *http_rules

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

यहाँ वही - एक से अधिक डोमेन जोड़ने होंगे अर्थात

*.foobar.com
*.foobar.net
*.foobar.biz

वर्तमान कार्यान्वयन में वास्तव में क्या सहज नहीं है ...

तो वोट करें...

90d निष्क्रियता के बाद मुद्दे पुराने हो जाते हैं।
/remove-lifecycle stale साथ समस्या को ताज़ा के रूप में चिह्नित करें।
अतिरिक्त 30d निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

अगर इस मुद्दे को अभी बंद करना सुरक्षित है तो कृपया इसे /close ।

सिग-टेस्टिंग, कुबेरनेट्स/टेस्ट-इंफ्रा और/या फेजटा को फीडबैक भेजें ।
/जीवनचक्र बासी

/निकालें-जीवनचक्र बासी

इसकी बहुत आवश्यकता है :(

इस सुविधा के लिए +1।

मैंने @kramarz सुझाए गए वर्कअराउंड की भी कोशिश की, और मुझे निम्न त्रुटि मिलती है:
Error: YAML parse error on mysite-web/templates/ingress.yaml: error converting YAML to JSON: yaml: line 4: mapping values are not allowed in this context

इस सुविधा के लिए +1।

90d निष्क्रियता के बाद मुद्दे पुराने हो जाते हैं।
/remove-lifecycle stale साथ समस्या को ताज़ा के रूप में चिह्नित करें।
अतिरिक्त 30d निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

अगर इस मुद्दे को अभी बंद करना सुरक्षित है तो कृपया इसे /close ।

सिग-टेस्टिंग, कुबेरनेट्स/टेस्ट-इंफ्रा और/या फेजटा को फीडबैक भेजें ।
/जीवनचक्र बासी

/निकालें-जीवनचक्र बासी

वास्तव में आवश्यक सुविधा

उपयोग केस मैंने अभी तक नहीं देखा है, हमारे पास कुछ डोमेन हैं जो api[0-9].domain.io जैसे दिखते हैं -- मौजूदा वाइल्डकार्ड डोमेन इस मामले को कवर नहीं करते हैं। yaml आईडी का उपयोग करके मैन्युअल रूप से प्रबंधित करने के लिए सेट काफी छोटा है, लेकिन उस फ़ॉलबैक की आवश्यकता नहीं होने के लिए आदर्श होगा (उदाहरण के लिए, रेगेक्स डोमेन नाम)

हमें वास्तव में इस सुविधा की आवश्यकता है

इस सुविधा के लिए एक और वोट

रेंज लूप का उपयोग करने के आसपास एक और काम:

rules:
          {{- range .Values.ingress.hosts }}
    - host: {{ . }}
      http:
        paths:
          - path: /
            backend:
              serviceName: {{ $fullName }}
              servicePort: 80
              {{- end }}

और मूल्यों में yaml:

ingress:
  hosts:
    - "bla.blub"
    - "foo.bar"

और एक चर पूर्ण नाम सेट करें ...

फिर भी मैं मेजबान तत्व के लिए एक सरणी या रेगेक्स या ... पसंद करूंगा

यह लगभग निश्चित रूप से इनग्रेड में नहीं हो रहा है, लेकिन हमें इसे ध्यान में रखना चाहिए ताकि एपीआई इनग्रेड का पालन करे (प्रस्ताव जल्द ही आ रहे हैं?)

एपीआई इनग्रेड, @thockin का पालन करने के लिए? क्या कार्यों में कोई प्रतिस्थापन है?

यह लगभग निश्चित रूप से प्रवेश में नहीं हो रहा है

नहीं? बहुत अधिक दोहराव से बचने के लिए अक्सर अनुरोधित विशेषता लगती है। - हमारे विकल्प क्या हैं?

किसी के लिए उपयोगी हो सकता है, मैं एक एकल प्रवेश के लिए कई डोमेन रखने के लिए nginx प्रवेश पर सर्वर-उपनाम विकल्प का उपयोग

किसी के लिए उपयोगी हो सकता है, मैं एक एकल प्रवेश के लिए कई डोमेन रखने के लिए nginx प्रवेश पर सर्वर-उपनाम विकल्प का उपयोग

@catalinpan यह आपके अंत में कैसे काम करता है? मेरा सर्वर-उपनाम इस कॉन्फ़िगरेशन के साथ काम नहीं करता है।

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: foobar-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/server-alias: "two-app.foobar.dev"
spec:
  tls:
  - secretName: tls-secret
  rules:
  - host: "one-app.foobar.dev"
    http:
      paths:
      - backend:
          serviceName: foobar
          servicePort: 80

@angelogwapo यह जांचने योग्य है कि आपके पास जो nginx प्रवेश संस्करण है वह उपनाम कार्यान्वयन का समर्थन करता है या नहीं। यदि संस्करण नया है तो यहां जांचें कि rewrite-target सिंटैक्स कैसा दिखना चाहिए।
एक मामला है जहां आपका उपनाम काम नहीं करेगा यदि कोई अन्य प्रवेश है जो समान डोमेन का उपयोग करता है, तो यहां स्पष्टीकरण दिया गया है।

जब तक उपरोक्त मामला आप पर लागू नहीं होता है और two-app.foobar.dev लिए DNS रिकॉर्ड उसी लोड बैलेंसर को इंगित करता है जैसे one-app.foobar.dev आपका उदाहरण काम करना चाहिए।

मैं अपने विशिष्ट उपयोग के मामले के कारण टेराफॉर्म का उपयोग करके रूट 53 में सर्वर उपनाम का प्रबंधन करता हूं, विभिन्न क्षेत्रों में कई तैनाती = कई सर्वर उपनाम CNAME स्वास्थ्य जांच और कुछ और विकल्पों के साथ कई मेजबानों की ओर इशारा करते हैं।

उदाहरण:
CNAME दो-app.foobar.dev -> one-app-ew1.foobar.dev
CNAME दो-app.foobar.dev -> one-app-ase1.foobar.dev

मेरे द्वारा उपयोग की जाने वाली किसी चीज़ का उदाहरण नीचे दिया गया है।

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/server-alias: public_url
  name: app1
spec:
  tls:
  - hosts:
    - public_region_url
      secretName: my_wildcard
  rules:
    - host: public_region_url
      http:
        paths:
          - path: /
            backend:
              serviceName: app1
              servicePort: 80

यह फीचर ट्रैफिक के उन यूजर्स के लिए बहुत अच्छा होगा जो ऑटोमेटेड लेट्स एनक्रिप्ट फीचर का भी इस्तेमाल कर रहे हैं। यहां, ट्रैफ़िक को होस्ट (https://docs.traefik.io/v1.7/configuration/acme/#onhostrule) के रूप में डोमेन की अल्पविराम से अलग सूची की उम्मीद है, जहां पहला डोमेन प्रमाणपत्र का मुख्य डोमेन बन जाएगा और अन्य सभी SAN s होंगे।

@catalinpan मैं सर्वर-उपनाम एनोटेशन से भी जूझ रहा हूं।
मेरे पास लगभग @angelogwapo जैसी ही कॉन्फ़िगरेशन है। मेरे पास दो डोमेन हैं:

• one-app.one-domain.dev
• दो-ऐप।दो-डोमेन.देव

दोनों एक ही लोडबैलेंसर की ओर इशारा कर रहे हैं। दोनों के पास एक वैध टीएलएस प्रमाणपत्र है।
मेरी कॉन्फ़िगरेशन के नीचे। मुझे सही पृष्ठ पर निर्देशित किया जाता है, लेकिन टीएलएस प्रमाणपत्र केवल मेजबान के रूप में उल्लिखित डोमेन के लिए मान्य है। जब मैं दूसरे डोमेन में ब्राउज़ करता हूं, तो मुझे Kubernetes Ingress Controller नकली प्रमाणपत्र प्रस्तुत किया जाता है। और इसके विपरीत। किसी भी मदद की सराहना की जाती है ...

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    app.kubernetes.io/instance: ngress-rules
    cert-manager.io/issuer: letsencrypt-prod
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/server-alias: two-app.two-domain.dev
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  name: ingress-rules
  namespace: default
spec:
  rules:
  - host: one-app.one-domain.dev
    http:
      paths:
      - backend:
          serviceName: service1
          servicePort: 80
        path: /
      - backend:
          serviceName: service2
          servicePort: 80
        path: /portal/
  tls:
  - hosts:
    - one-app.one-domain.dev
    secretName: one-app-tls
  - hosts:
    - two-app.two-domain.dev
    secretName: two-app-tls

बीटीडब्ल्यू, मैं संस्करण 0.27 का उपयोग कर रहा हूं जिसमें यह परिवर्तन होना चाहिए: https://github.com/kubernetes/ingress-nginx/pull/4472/files#diff -9bba411a7c28f1ef63c3a5339db109d5

@jacqinthebox : आपका Ingress कॉन्फ़िगरेशन वास्तव में केवल एक होस्ट ( one-app.one-domain.dev ) को कॉन्फ़िगर करता है। ज़रूर, आपका tls उन दोनों को कॉन्फ़िगर करता है, लेकिन आपको अभी भी प्रत्येक डोमेन के लिए एक नियम की आवश्यकता है। विशेष रूप से spec.rules अंतर्गत सरणी देखें। वर्तमान में, ऐसा कुछ भी नहीं है जो एनजीआईएनएक्स को बताता है कि दूसरे डोमेन को कौन सी सेवा प्रॉक्सी करनी चाहिए।

संपादित करें : मेरा बुरा, मैं बहुत जल्दी था। मुझे नहीं पता था कि आप सर्वर उपनाम एनोटेशन के बारे में बात कर रहे थे।

@jacqinthebox

दोनों एक ही लोडबैलेंसर की ओर इशारा कर रहे हैं। दोनों के पास एक वैध टीएलएस प्रमाणपत्र है।

आप एक टीएलएस सीक्रेट में कई स्वतंत्र डोमेन का उपयोग कर सकते हैं
``` टीएलएस:

• मेजबान:
  
  
  
  • one-app.one-domain.dev
  
  
  • दो-ऐप।दो-डोमेन.देव
    
    गुप्त नाम: सभी-ऐप-टीएलएस
    
    ```
  
  

आप किसी सरणी में प्रत्येक डोमेन के लिए dup config बनाने के लिए हमेशा एक हेल्म चार्ट का उपयोग कर सकते हैं। "अगर" आप निश्चित रूप से पतवार का उपयोग कर रहे हैं :)

+1

@kramarz , धन्यवाद, यह कामकाज मेरे लिए काम करता है।

वर्कअराउंड https://github.com/jetstack/cert-manager के साथ भी पूरी तरह से काम करता है।
यहाँ मेरा उदाहरण है

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
   name: site
   annotations:
      cert-manager.io/issuer: letsencrypt-prod
      nginx.ingress.kubernetes.io/server-alias: host2.com
spec:
   rules:
   - host: host1.com
     http:
      paths:
      - path: /
        backend:
           serviceName: site
           servicePort: 8080
   tls:
   - secretName: nice-name
     hosts:
     - host1.com
     - host2.com

@AndreKoepke इसके लिए धन्यवाद। इसने मेरे लिए कुछ हद तक काम किया लेकिन domain.com से spec.rules[0].host और www.domain.com,domain.se,www.domain.se से nginx.ingress.kubernetes.io/server-alias जोड़ने के बाद मुझे निम्न त्रुटि मिलती है: controller.go:1155] Conflicting hostname (domain.com) and alias (www.domain.se). Removing alias to avoid conflicts.

कोई सुझाव?