เปิดเผยพอร์ต 80 และ 443 บน Google Container Engine โดยไม่มี load balancer

ขณะนี้ฉันกำลังทำโปรเจ็กต์งานอดิเรกขนาดเล็กซึ่งฉันจะทำโอเพ่นซอร์สเมื่อมันพร้อม บริการนี้ทำงานบน Google Container Engine ฉันเลือก GCE เพื่อหลีกเลี่ยงความยุ่งยากในการกำหนดค่าใช้จ่ายราคาไม่แพงและเพื่อเรียนรู้สิ่งใหม่ ๆ

พ็อดของฉันทำงานได้ดีและฉันสร้างบริการที่มีประเภทLoadBalancerเพื่อเปิดเผยบริการบนพอร์ต 80 และ 443 สิ่งนี้ใช้ได้อย่างสมบูรณ์แบบ

อย่างไรก็ตามฉันค้นพบว่าในแต่ละLoadBalancerบริการจะมีการสร้าง load balancer ของ Google Compute Engine ใหม่ขึ้นมา เครื่องถ่วงโหลดนี้ค่อนข้างแพงและทำไปจริงมากสำหรับโครงการงานอดิเรกในครั้งเดียว

เพื่อลดค่าใช้จ่ายฉันกำลังมองหาวิธีที่จะเปิดเผยพอร์ตโดยไม่มีตัวโหลดบาลานซ์

สิ่งที่ฉันได้ลองไปแล้ว:

• ปรับใช้NodePortบริการ น่าเสียดายที่ไม่อนุญาตให้แสดงพอร์ตต่ำกว่า 30000

• ปรับใช้ Ingress แต่สิ่งนี้จะสร้างตัวโหลดบาลานซ์ด้วย

• พยายามปิดการใช้งานHttpLoadBalancing( https://cloud.google.com/container-engine/reference/rest/v1/projects.zones.clusters#HttpLoadBalancing ) แต่ก็ยังสร้างตัวสร้างสมดุล

มีวิธีใดที่จะเปิดเผยพอร์ต 80 และ 443 สำหรับอินสแตนซ์เดียวบน Google Container Engine โดยไม่มีตัวโหลดบาลานซ์หรือไม่?

ใช่ผ่าน IP ภายนอกบนบริการ ตัวอย่างบริการที่ฉันใช้:

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 ที่อยู่ในไฟล์กำหนดค่าต้องเป็น IP ภายในบน GCE

นอกเหนือจากโซลูชันที่ยอดเยี่ยมและการทำงานของ ConnorJC แล้วยังมีการแก้ปัญหาแบบเดียวกันในคำถามนี้: Kubernetes - ฉันสามารถหลีกเลี่ยงการใช้ GCE Load Balancer เพื่อลดต้นทุนได้หรือไม่

"internalIp" หมายถึง ip ภายในของอินสแตนซ์ของการคำนวณ (หรือที่รู้จักในนามโหนด) (ดังที่เห็นในแพลตฟอร์ม Google Cloud -> Google Compute Engine -> VM Instances)

ความคิดเห็นนี้ให้คำแนะนำว่าทำไมภายในและไม่ควรกำหนดค่า ip ภายนอก

นอกจากนี้หลังจากกำหนดค่าบริการสำหรับพอร์ต 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

หากคุณมีเพียงหนึ่งฝักเท่านั้นคุณสามารถใช้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

โปรดทราบว่าการทำเช่นนี้จะทำให้ Pod ของคุณได้รับตัวแก้ไข DNS ของโฮสต์และไม่ใช่ Kubernetes ' ซึ่งหมายความว่าคุณไม่สามารถแก้ไขบริการคลัสเตอร์ด้วยชื่อ DNS ได้อีกต่อไป ยกตัวอย่างเช่นในตัวอย่างข้างต้นคุณจะไม่สามารถเข้าถึงstaticบริการที่http: // คงที่ คุณยังสามารถเข้าถึงบริการโดย IP คลัสเตอร์ของพวกเขาซึ่งจะฉีดโดยตัวแปรสภาพแวดล้อม

โซลูชันนี้ดีกว่าการใช้ externalIP ของบริการเนื่องจากข้าม kube-proxy และคุณจะได้รับ IP ต้นทางที่ถูกต้อง

หากต้องการสังเคราะห์คำตอบของ @ConnorJC @ derMikey ให้เป็นสิ่งที่ฉันทำงาน:

ให้กลุ่มคลัสเตอร์ทำงานบนCompute Engine Instance :

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

จากนั้นmy-appเข้าถึงได้ผ่านIP สาธารณะ GCE อินสแตนซ์34.56.7.001 (ไม่ใช่คลัสเตอร์ไอพี )

ฉันไม่ต้องการใช้ตัวโหลดบาลานซ์คลาวด์จนกว่าจะจำเป็นเนื่องจากค่าใช้จ่ายและการล็อคอินของผู้ขาย

ฉันใช้สิ่งนี้แทน: https://kubernetes.github.io/ingress-nginx/deploy/

มันเป็นพ็อดที่ให้โหลดบาลานเซอร์ให้คุณ หน้านั้นมีบันทึกการติดตั้งเฉพาะของ GKE