ฉันค่อนข้างสับสนเกี่ยวกับบทบาทของ Ingress และ Load Balancer ใน Kubernetes
เท่าที่ฉันเข้าใจ Ingress ถูกใช้เพื่อทำแผนที่การรับส่งข้อมูลจากอินเทอร์เน็ตไปยังบริการที่ทำงานในคลัสเตอร์
บทบาทของตัวโหลดบาลานซ์คือการส่งต่อทราฟฟิกไปยังโฮสต์ ในเรื่องที่ว่าทางเข้าแตกต่างจาก load balancer อย่างไร นอกจากนี้แนวคิดของ load balancer ภายใน kubernetes เมื่อเปรียบเทียบกับ Amazon ELB และ ALB คืออะไร
คำตอบ:
Load Balancer:บริการ kubernetes LoadBalancer เป็นบริการที่ชี้ไปยัง load balancer ภายนอกที่ไม่ได้อยู่ในคลัสเตอร์ kubernetes ของคุณ แต่มีอยู่ที่อื่น พวกเขาสามารถทำงานร่วมกับพ็อดของคุณโดยสมมติว่าพ็อดของคุณสามารถกำหนดเส้นทางจากภายนอกได้ Google และ AWS ให้ความสามารถนี้โดยกำเนิด ในแง่ของ Amazon แผนที่นี้โดยตรงกับ ELB และ kubernetes เมื่อทำงานใน AWS สามารถจัดเตรียมและกำหนดค่าอินสแตนซ์ ELB โดยอัตโนมัติสำหรับบริการ LoadBalancer แต่ละรายการที่ปรับใช้
Ingress:ทางเข้าเป็นเพียงชุดของกฎที่จะส่งผ่านไปยังตัวควบคุมที่กำลังฟังพวกเขาอยู่ คุณสามารถปรับใช้กฎการเข้าใช้จำนวนมาก แต่จะไม่มีอะไรเกิดขึ้นหากคุณไม่มีตัวควบคุมที่สามารถประมวลผลได้ บริการ LoadBalancer สามารถฟังกฎการเข้าใช้หากมีการกำหนดค่าให้ทำเช่นนั้น
คุณยังสามารถสร้างNodePortบริการซึ่งมี IP ที่กำหนดเส้นทางได้ภายนอกจากคลัสเตอร์ แต่ชี้ไปที่พ็อดที่มีอยู่ภายในคลัสเตอร์ของคุณ นี่อาจเป็น Ingress Controller
Ingress Controller เป็นเพียงแค่ฝักที่กำหนดค่าให้ตีความกฎทางเข้า หนึ่งในคอนโทรลเลอร์ที่ได้รับความนิยมสูงสุดที่รองรับโดย kubernetes คือ nginx ในแง่ของ Amazon, ALB สามารถใช้เป็นตัวควบคุมทางเข้า
สำหรับตัวอย่างนี้ควบคุม Nginx สามารถที่จะนำเข้าไปในร่างกายกฎการเข้าคุณได้กำหนดไว้และแปลพวกเขาไปยังแฟ้ม nginx.conf ว่ามันโหลดและเริ่มในฝักของมัน
ตัวอย่างเช่นสมมติว่าคุณกำหนดทางเข้าดังนี้:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
ingress.kubernetes.io/rewrite-target: /
name: web-ingress
spec:
rules:
- host: kubernetes.foo.bar
http:
paths:
- backend:
serviceName: appsvc
servicePort: 80
path: /app
หากคุณตรวจสอบตัวควบคุม nginx ของคุณแล้วคุณจะเห็นกฎต่อไปนี้กำหนดไว้ใน/etc/nginx.conf:
server {
server_name kubernetes.foo.bar;
listen 80;
listen [::]:80;
set $proxy_upstream_name "-";
location ~* ^/web2\/?(?<baseuri>.*) {
set $proxy_upstream_name "apps-web2svc-8080";
port_in_redirect off;
client_max_body_size "1m";
proxy_set_header Host $best_http_host;
# Pass the extracted client certificate to the backend
# Allow websocket connections
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header X-Real-IP $the_real_ip;
proxy_set_header X-Forwarded-For $the_x_forwarded_for;
proxy_set_header X-Forwarded-Host $best_http_host;
proxy_set_header X-Forwarded-Port $pass_port;
proxy_set_header X-Forwarded-Proto $pass_access_scheme;
proxy_set_header X-Original-URI $request_uri;
proxy_set_header X-Scheme $pass_access_scheme;
# mitigate HTTPoxy Vulnerability
# https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
proxy_set_header Proxy "";
# Custom headers
proxy_connect_timeout 5s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
proxy_redirect off;
proxy_buffering off;
proxy_buffer_size "4k";
proxy_buffers 4 "4k";
proxy_http_version 1.1;
proxy_cookie_domain off;
proxy_cookie_path off;
rewrite /app/(.*) /$1 break;
rewrite /app / break;
proxy_pass http://apps-appsvc-8080;
}
Nginx เพิ่งสร้างกฎเพื่อกำหนดเส้นทางhttp://kubernetes.foo.bar/appไปยังบริการappsvcในคลัสเตอร์ของคุณ
นี่คือตัวอย่างของวิธีการใช้งาน kubernetes กับตัวควบคุม nginx ingress หวังว่านี่จะช่วยได้!
ฉันพบบทความที่น่าสนใจซึ่งอธิบายความแตกต่างระหว่าง NodePort, LoadBalancer และ Ingress
จากเนื้อหาที่มีอยู่ในบทความ:
loadbalancer:
บริการ LoadBalancer เป็นวิธีมาตรฐานในการแสดงบริการกับอินเทอร์เน็ต ใน GKE จะเป็นการเพิ่ม Network Load Balancer ที่จะให้ที่อยู่ IP เดียวที่จะส่งต่อการรับส่งข้อมูลทั้งหมดไปยังบริการของคุณ
หากคุณต้องการเปิดเผยบริการโดยตรงนี่เป็นวิธีการเริ่มต้น การรับส่งข้อมูลทั้งหมดบนพอร์ตที่คุณระบุจะถูกส่งต่อไปยังบริการ ไม่มีการกรองไม่มีการกำหนดเส้นทางเป็นต้นซึ่งหมายความว่าคุณสามารถส่งทราฟฟิกได้เกือบทุกประเภทเช่น HTTP, TCP, UDP, Websockets, gRPC หรืออะไรก็ตาม
ข้อเสียที่สำคัญคือแต่ละบริการที่คุณเปิดรับ LoadBalancer จะได้รับที่อยู่ IP ของตัวเองและคุณต้องจ่ายค่าบริการ LoadBalancer ต่อบริการที่เปิดเผยซึ่งอาจมีราคาแพง!
Ingress:
Ingress ไม่ใช่บริการประเภทหนึ่ง แต่อยู่หน้าบริการหลาย ๆ อย่างและทำหน้าที่เป็น "เราเตอร์อัจฉริยะ" หรือจุดเข้าสู่คลัสเตอร์ของคุณ
คุณสามารถทำสิ่งต่าง ๆ มากมายด้วย Ingress และมีตัวควบคุม Ingress หลายประเภทที่มีความสามารถแตกต่างกัน
ตัวควบคุม GKE ที่เป็นค่าเริ่มต้นจะหมุนตัวโหลดบาลานซ์ HTTP (S) ให้คุณ สิ่งนี้จะช่วยให้คุณทำทั้งเส้นทางตามและโดเมนย่อยตามเส้นทางไปยังบริการด้านหลัง ตัวอย่างเช่นคุณสามารถส่งทุกอย่างใน foo.yourdomain.com ไปยังบริการ foo และทุกอย่างภายใต้ yourdomain.com/bar/ พา ธ ไปยังบริการบาร์
Ingress อาจเป็นวิธีที่ทรงพลังที่สุดในการเปิดเผยบริการของคุณ แต่อาจเป็นวิธีที่ซับซ้อนที่สุด มีตัวควบคุม Ingress หลายประเภทจาก Google Cloud Load Balancer, Nginx, Contour, Istio และอื่น ๆ นอกจากนี้ยังมีปลั๊กอินสำหรับ Ingress controllers เช่น cert-manager ซึ่งสามารถจัดเตรียมใบรับรอง SSL สำหรับบริการของคุณโดยอัตโนมัติ
Ingress มีประโยชน์มากที่สุดหากคุณต้องการแสดงหลายบริการภายใต้ที่อยู่ IP เดียวกันและบริการเหล่านี้ใช้โปรโตคอล L7 เดียวกัน (โดยทั่วไปคือ HTTP) คุณจ่ายเพียงหนึ่งบาลานเซอร์โหลดเท่านั้นหากคุณใช้การรวม GCP ดั้งเดิมและเนื่องจาก Ingress เป็น "สมาร์ท" คุณจึงสามารถรับฟีเจอร์มากมายได้นอกกรอบ (เช่น SSL, Auth, การกำหนดเส้นทาง ฯลฯ )
TL: DR
เริ่มจากกรณีการใช้งานจริง: คุณมีหลาย Apis ที่ได้รับการสนับสนุนโดยแพ็คเกจการใช้งานบริการ (ASIP สำหรับ clariy และความกะทัดรัด) เพื่อปรับใช้ภายใต้ชื่อโดเมนเดียว ในขณะที่คุณเป็นนักพัฒนาที่ล้ำสมัยคุณได้นำสถาปัตยกรรมไมโครเซอร์วิสที่ต้องการการปรับใช้แยกต่างหากสำหรับแต่ละ ASIP เพื่อให้พวกเขาสามารถอัพเกรดหรือปรับขนาดทีละรายการ แน่นอนว่า ASIPs เหล่านี้จะถูกห่อหุ้มในคอนเทนเนอร์ของนักเทียบท่าแต่ละคนและมีให้กับ Kubernetes (K8s) จากที่เก็บคอนเทนเนอร์
สมมติว่าตอนนี้คุณต้องการปรับใช้กับ GKE K8 ของ Google ในการใช้งานความพร้อมใช้งานอย่างยั่งยืนแต่ละอินสแตนซ์ ASIP (replica) จะถูกนำไปใช้งานบนโหนดที่แตกต่างกัน (VM) โดยที่แต่ละ VM มีที่อยู่ IP ของคลาวด์ภายใน การปรับใช้ ASIP แต่ละครั้งจะถูกกำหนดค่าในชื่อ "deployment.yaml" ไฟล์ที่คุณระบุไว้อย่างชัดเจนรวมถึงจำนวนแบบจำลองของ ASIP K8 ที่กำหนด
ขั้นตอนต่อไปคือการเปิดเผย API ไปยังโลก ouside และคำขอช่องทางไปยังหนึ่งในอินสแตนซ์ ASIP ที่ปรับใช้ เนื่องจากเรามีแบบจำลอง ASIP เดียวกันจำนวนมากที่ทำงานบนโหนดที่ต่างกันเราจึงต้องการบางสิ่งที่จะกระจายคำขอในแบบจำลองเหล่านั้น ในการแก้ไขปัญหานี้เราสามารถสร้างและใช้ไฟล์ "service.yaml" ที่จะกำหนดค่าบริการ K8s (KServ) ที่จะถูกเปิดเผยจากภายนอกและสามารถเข้าถึงได้ผ่านที่อยู่ IP KServ นี้จะรับผิดชอบการกระจายคำร้องขอของ API ท่ามกลาง ASIP ที่กำหนดค่าไว้ โปรดทราบว่า KServ จะได้รับการกำหนดค่าใหม่โดยอัตโนมัติโดยต้นแบบ K8s เมื่อโหนดของ ASIP ล้มเหลวและเริ่มต้นใหม่ ที่อยู่ IP ภายในจะไม่ถูกนำมาใช้ซ้ำในกรณีเช่นนี้และ KServ จะต้องได้รับคำแนะนำเกี่ยวกับตำแหน่งการปรับใช้ของ ASIP ใหม่
แต่เรามีแพ็คเกจบริการอื่น ๆ ของ Api ที่จะต้องเปิดเผยในชื่อโดเมนเดียวกัน การหมุน KServ ใหม่จะสร้างที่อยู่ IP ภายนอกใหม่และเราจะไม่สามารถเปิดเผยได้ในชื่อโดเมนเดียวกัน นี่คือสิ่งที่ Ingress เข้ามา
การนั่งของ Ingress อยู่ระหว่างอินเทอร์เน็ตและ KServices ทั้งหมดที่เราเปิดเผยสู่โลกภายนอก Ingress มีความสามารถในการให้โหลดบาลานซ์การเลิกจ้าง SSL และการโฮสต์เสมือนแบบใช้ชื่อ ความจุหลังสามารถกำหนดเส้นทางคำขอขาเข้าไปยังบริการที่เหมาะสมได้โดยการวิเคราะห์ URL แน่นอนว่าต้องกำหนดค่าและใช้ Ingress กับไฟล์ ... "ingress.yaml" ที่จะระบุการเขียนและเส้นทางที่จำเป็นในการส่งคำขอไปยัง KServ ที่ถูกต้อง
อินเทอร์เน็ต -> Ingress -> บริการ K8s -> แบบจำลอง
ดังนั้นด้วยการเข้าใช้งานที่ถูกต้องการกำหนดค่า KServices และ ASIPs ทำให้เราสามารถเปิดเผย API จำนวนมากได้อย่างปลอดภัยโดยใช้ชื่อโดเมนเดียวกัน
มี 4 วิธีในการอนุญาตให้
พ็อดในคลัสเตอร์ของคุณรับการรับส่งข้อมูลภายนอก:
1. ) พ็อดที่ใช้ HostNetworking: จริงและ (อนุญาต 1 พ็อดต่อโหนดเพื่อรับฟังพอร์ตโดยตรงบนโหนดโฮสต์มินิคิวบ์โลหะเปลือยและ rasberry pi บางครั้ง เส้นทางนี้ซึ่งสามารถอนุญาตให้โหนดโฮสต์รับฟังพอร์ต 80/443 ไม่อนุญาตให้ใช้โหลดบาลานเซอร์หรือคอนฟิกูเรชันคลาวด์โหลดบาลานเซอร์ขั้นสูงนอกจากนี้ยังข้ามบริการ Kubernetes ซึ่งสามารถเป็นประโยชน์ในการหลีกเลี่ยง SNAT / บรรลุผลที่คล้ายกันของ ไม่สนับสนุนเช่นที่ AWS)
2. ) บริการ NodePort
3. ) บริการ LoadBalancer (ซึ่งสร้างบนบริการ NodePort)
4. ) Ingress Controller + Ingress Objects (ซึ่งสร้างตามข้างบน)
สมมติว่าคุณมีเว็บไซต์ 10 แห่งที่โฮสต์อยู่ในคลัสเตอร์ของคุณและคุณต้องการให้เว็บไซต์เหล่านั้นได้รับการเข้าชมจากภายนอก
* ถ้าคุณใช้บริการพิมพ์ LoadBalancer คุณจะวางไข่ 10 HA โหลดบาลานซ์คลาวด์ (แต่ละค่าใช้จ่าย)
* หากคุณใช้พิมพ์ควบคุม Ingress คุณจะวางไข่ 1 สมดุลภาระเมฆ HA (ประหยัดเงิน) และมันจะชี้ไปที่ Ingress คอนโทรลเลอร์ทำงานในคลัสเตอร์ของคุณ
Ingress Controller คือ:
L7 LB / Ingress Controller ภายในคลัสเตอร์ของคุณโหลดบาลานซ์ / ย้อนกลับปริมาณพร็อกซี่ไปยังบริการ IP ของคลัสเตอร์ภายในคลัสเตอร์ของคุณมันยังสามารถยกเลิก HTTPS ถ้าคุณมี Kubernetes Secret ประเภท TLS ใบรับรองและวัตถุ Ingress ที่อ้างอิง)
Ingress: Ingress Object + Ingress Controller
วัตถุที่อยู่:
เช่นเดียวกับ Service Object ยกเว้นว่ามันจะไม่ทำอะไรด้วยตัวเอง Ingress Object อธิบายวิธีการส่งทราฟฟิกของเลเยอร์ 7 ในคลัสเตอร์ของคุณโดยการระบุสิ่งต่าง ๆ เช่นเส้นทางการร้องขอโดเมนคำขอและบริการ kubernetes เป้าหมายในขณะที่วัตถุบริการสร้างบริการจริง ๆ
ตัวควบคุม Ingress:
บริการที่:
1. listens on specific ports (usually 80 and 443) for web traffic
2. Listens for the creation, modification, or deletion of Ingress Objects
3. Creates internal L7 routing rules based on these Ingress Objects
ตัวอย่างเช่น Nginx Ingress Controller สามารถใช้บริการเพื่อฟังพอร์ต 80 และ 443 จากนั้นอ่าน Ingress Objects ใหม่และแยกวิเคราะห์ลงในเซิร์ฟเวอร์ใหม่ {} ส่วนซึ่งมันวางแบบไดนามิกเป็น nginx.conf
LoadBalancer: ผู้ให้บริการตัวโหลดบาลานซ์ภายนอก + ประเภทบริการ
ผู้ให้บริการโหลดบาลานซ์ภายนอก:
ผู้ให้บริการโหลดบาลานซ์ภายนอกมักจะกำหนดค่าในระบบคลาวด์เช่น AWS และ GKE และให้วิธีการกำหนด IP ภายนอกผ่านการสร้างโหลดบาลานซ์ภายนอก ฟังก์ชันนี้สามารถใช้งานได้โดยการกำหนดบริการเป็นประเภท "LoadBalancer"
ประเภทบริการ:
เมื่อชนิดของบริการถูกตั้งค่าเป็น LoadBalancer, Kubernetes จะพยายามสร้างและตั้งโปรแกรม load balancer ภายนอกพร้อมรายการสำหรับฝัก Kubernetes ดังนั้นจึงกำหนด IP ภายนอกเหล่านั้น
ตัวควบคุมบริการ Kubernetes ทำการสร้าง load balancer ภายนอกอัตโนมัติตรวจสอบสุขภาพ (ถ้าจำเป็น) กฎไฟร์วอลล์ (ถ้าจำเป็น) และดึง IP ภายนอกของ loadBalancer ที่สร้างขึ้นใหม่หรือกำหนดค่าซึ่งได้รับการจัดสรรโดยผู้ให้บริการคลาวด์ วัตถุบริการ
ความสัมพันธ์:
Ingress Controller Services มักจะได้รับการจัดเตรียมเป็นประเภท LoadBalancer ดังนั้นคำขอ http และ https สามารถพร็อกซี / ส่งไปยังบริการภายในที่เฉพาะเจาะจงผ่าน ip ภายนอก
อย่างไรก็ตาม LoadBalancer ไม่จำเป็นสำหรับสิ่งนี้อย่างเคร่งครัด ตั้งแต่ผ่านการใช้ hostNetwork หรือ hostPort คุณสามารถผูกพอร์ตบนโฮสต์กับบริการ (อนุญาตให้คุณเยี่ยมชมผ่านโฮสต์ภายนอก ip: พอร์ต) แม้ว่าจะไม่แนะนำอย่างเป็นทางการเนื่องจากมันใช้พอร์ตมากขึ้นในโหนดจริง
อ้างอิง:
https://kubernetes.io/docs/concepts/configuration/overview/#services
https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/
https://kubernetes.io/docs/concepts/services-networking/ingress/
ในคำง่าย ๆ load balancer กระจายคำร้องขอระหว่างเซอร์วิส backend หลายตัว (ชนิดเดียวกัน) ในขณะที่ ingress นั้นเป็นเหมือนเกตเวย์ API (reverse proxy) ซึ่งกำหนดเส้นทางการร้องขอไปยังบริการแบ็กเอนด์ที่เฉพาะเจาะจงเช่น URL