Google कंटेनर इंजन पर लोड बैलेंसर के बिना पोर्ट 80 और 443 को बेनकाब करें

23

वर्तमान में मैं एक छोटे से हॉबी प्रोजेक्ट पर काम कर रहा हूं, जिसके तैयार होने के बाद मैं ओपन सोर्स बनाऊंगा। यह सेवा Google कंटेनर इंजन पर चल रही है। मैंने कॉन्फ़िगरेशन परेशानी से बचने के लिए GCE को चुना, लागत सस्ती है और नया सामान सीखना है।

मेरी पॉड्स ठीक चल रही हैं और मैंने LoadBalancerपोर्ट 80 और 443 पर सर्विस का खुलासा करने के लिए टाइप के साथ एक सर्विस बनाई । यह पूरी तरह से काम करता है।

हालाँकि, मुझे पता चला कि प्रत्येक LoadBalancerसेवा के लिए, एक नया Google कंप्यूट इंजन लोड बैलेंसर बनाया जाता है। यह लोड बैलेंसर काफी महंगा है और वास्तव में एक उदाहरण पर एक शौक परियोजना के लिए किया गया है।

लागत में कटौती के लिए मैं लोड बैलेंसर के बिना बंदरगाहों को उजागर करने का एक तरीका ढूंढ रहा हूं।

मैंने अब तक क्या प्रयास किया है:

एक NodePortसेवा तैनात करें । दुर्भाग्य से यह 30000 से नीचे एक बंदरगाह का पर्दाफाश करने के लिए अस्वीकृत है।
एक इन्ग्रेड को तैनात करें लेकिन यह एक लोड बैलेंसर भी बनाता है।
अक्षम करने की कोशिश की गई HttpLoadBalancing( https://cloud.google.com/container-engine/reference/rest/v1/projects.zones.clusters#HttpLoadBalancing ) लेकिन यह अभी भी एक लोड बैलेंसर बनाता है।

क्या एक लोड बैलेंसर के बिना Google कंटेनर इंजन पर एकल उदाहरण के लिए पोर्ट 80 और 443 को उजागर करने का एक तरीका है?

google-cloud-platform google-compute-engine kubernetes

— रूबेन अर्नस्ट
स्रोत

10

हाँ, बाह्य सेवा के माध्यम से। उदाहरण सेवा मैंने उपयोग किया है:

apiVersion: v1
kind: Service
metadata:
  name: bind
  labels:
    app: bind
    version: 3.0.0
spec:
  ports:
    - port: 53
      protocol: UDP
  selector:
    app: bind
    version: 3.0.0
  externalIPs:
    - a.b.c.d
    - a.b.c.e

कृपया ध्यान रखें कि कॉन्फ़िगर फ़ाइल में सूचीबद्ध IP GCE पर आंतरिक IP होनी चाहिए।

— ConnorJC
स्रोत

धन्यवाद! लेकिन मुझे लगता है कि मुझे कुछ याद आया। सेवा तैनात है, लेकिन इंटरनेट से असमर्थ है। मैंने सही फ़ायरवॉल नियम निर्धारित किए हैं। सेवा सही प्रदर्शित कर रही हैexternalIp

— Ruben Ernst

देर से जवाब के लिए क्षमा करें, भूल गए कि मैंने ठीक उसी मुद्दे पर समय बिताया है। सूचीबद्ध IP को आंतरिक IP होने की आवश्यकता है , बाहरी नहीं (कम से कम GCE पर)।

— कॉनरजैक

धन्यवाद, यही समाधान था! दुर्भाग्य से मुझे अभी तक उत्थान की अनुमति नहीं है ... मैंने आपको यह टिप्पणी करने के लिए छोड़ दिया कि आपको यह उत्तर ऊपर की टिप्पणी के साथ संयुक्त है (जो कि कुंजी थी) ने मेरा मुद्दा हल कर दिया!

— रुबेन अर्न्स्ट

1

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

— ब्रेट

@ ग्रेट: मेरी देर से प्रतिक्रिया के लिए क्षमा करें। क्या इस बीच आपके सवाल का पहले ही जवाब दे दिया गया है?

— रुबेन अर्न्स्ट

4

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

"InternalIp" का तात्पर्य कंप्यूट इंस्टेंस (उर्फ द नोड) के आंतरिक आईपी (जैसा कि Google क्लाउड प्लेटफ़ॉर्म पर देखा गया है -> Google कंप्यूट इंजन -> वीएम इंस्टेंस) से है

यह टिप्पणी संकेत देती है कि आंतरिक और बाहरी आईपी को कॉन्फ़िगर क्यों नहीं किया जाना चाहिए।

इसके अलावा, पोर्ट 80 और 443 के लिए सेवा को कॉन्फ़िगर करने के बाद, मुझे अपने उदाहरण नोड पर ट्रैफ़िक की अनुमति देने वाला फ़ायरवॉल नियम बनाना पड़ा:

gcloud compute firewall-rules create your-name-for-this-fw-rule --allow tcp:80,tcp:443 --source-ranges=0.0.0.0/0

इस सेटअप के बाद, मैं http (s): // externalIp के माध्यम से अपनी सेवा का उपयोग कर सकता हूं

— derMikey
स्रोत

नोड आंतरिक आईपी का उपयोग कर चाल किया। ! नामकरण के साथ ऐसी उलझन!

— जेम्स

1

यदि आपके पास केवल एक पॉड है, तो आप इसे hostNetwork: trueप्राप्त करने के लिए उपयोग कर सकते हैं :

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: caddy
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: caddy
    spec:
      hostNetwork: true # <---------
      containers:
      - name: caddy
        image: your_image
        env:
        - name: STATIC_BACKEND # example env in my custom image
          value: $(STATIC_SERVICE_HOST):80

ध्यान दें कि ऐसा करने से आपका पॉड होस्ट के DNS रिज़ॉल्वर को प्राप्त करेगा और कुबेरनेट्स को नहीं। ' इसका मतलब है कि अब आप DNS नाम से क्लस्टर सेवाओं को हल नहीं कर सकते हैं। उदाहरण के लिए, ऊपर दिए गए उदाहरण में आप http: // staticstatic पर सेवा तक नहीं पहुँच सकते । आप अभी भी उनके क्लस्टर IP द्वारा सेवाओं तक पहुँच सकते हैं, जिन्हें पर्यावरण चर द्वारा इंजेक्ट किया जाता है ।

यह समाधान सेवा के एक्सटीआईपी का उपयोग करने से बेहतर है क्योंकि यह क्यूब-प्रॉक्सी को बायपास करता है, और आपको सही स्रोत आईपी प्राप्त होगा।

— होगा
स्रोत

1

@ConnorJC @ derMikey के जवाबों को मेरे लिए काम करने के लिए संश्लेषित करने के लिए:

कम्प्यूट इंजन इंस्टेंस पर चल रहे क्लस्टर पूल को देखते हुए :

gce vm name: gke-my-app-cluster-pool-blah`
internal ip: 10.123.0.1
external ip: 34.56.7.001 # will be publically exposed

मैंने सेवा की:

apiVersion: v1
kind: Service
metadata:
  labels:
    app: my-app
  name: my-app-service
spec:
  clusterIP: 10.22.222.222
  externalIPs:
  - 10.123.0.1 # the instance internal ip
  ports:
  - port: 80
    protocol: TCP
  selector:
    app: my-app
  type: ClusterIP

और फिर परियोजना में सभी (?) ips के लिए फ़ायरवॉल खोला:

gcloud compute firewall-rules create open-my-app --allow tcp:80,tcp:443 --source-ranges=0.0.0.0/0

और फिर GCE इंस्टेंस पब्लिक आईपी (क्लस्टर आईपी नहीं) के my-appमाध्यम से सुलभ था34.56.7.001

— micimize
स्रोत

0

मैं लागत और विक्रेता लॉक-इन के कारण, आवश्यक होने तक क्लाउड लोड बैलेन्सर्स का उपयोग नहीं करना पसंद करता हूं।

इसके बजाय मैं इसका उपयोग करता हूं: https://kubernetes.github.io/ingress-nginx/deploy/

यह एक फली है जो आपके लिए एक लोड बैलेंसर चलाता है। उस पृष्ठ में GKE के विशिष्ट इंस्टॉलेशन नोट्स हैं।

— माइकल कोल
स्रोत