Tôi khá bối rối về vai trò của Ingress và Load Balancer trong Kubernetes.
Theo như tôi hiểu thì Ingress được sử dụng để ánh xạ lưu lượng truy cập đến từ internet đến các dịch vụ đang chạy trong cụm.
Vai trò của cân bằng tải là chuyển tiếp lưu lượng đến máy chủ. Về vấn đề xâm nhập khác với cân bằng tải như thế nào? Ngoài ra, khái niệm cân bằng tải bên trong kubernetes là gì so với Amazon ELB và ALB?
Câu trả lời:
Load Balancer: Dịch vụ LoadBalancer kubernetes là dịch vụ trỏ đến các bộ cân bằng tải bên ngoài KHÔNG có trong cụm kubernetes của bạn, nhưng tồn tại ở nơi khác. Họ có thể làm việc với các nhóm của bạn, giả sử rằng các nhóm của bạn có thể định tuyến bên ngoài. Google và AWS cung cấp khả năng này nguyên bản. Về mặt Amazon, bản đồ này trực tiếp với ELB và kubernetes khi chạy trong AWS có thể tự động cung cấp và định cấu hình phiên bản ELB cho mỗi dịch vụ LoadBalancer được triển khai.
Ingress: Một xâm nhập thực sự chỉ là một bộ quy tắc để truyền cho một bộ điều khiển đang lắng nghe chúng. Bạn có thể triển khai một loạt các quy tắc xâm nhập, nhưng sẽ không có gì xảy ra trừ khi bạn có một bộ điều khiển có thể xử lý chúng. Một dịch vụ LoadBalancer có thể lắng nghe các quy tắc xâm nhập, nếu nó được cấu hình để làm như vậy.
Bạn cũng có thể tạo một dịch vụ NodePort , có một IP có thể định tuyến bên ngoài bên ngoài cụm, nhưng trỏ đến một nhóm tồn tại trong cụm của bạn. Đây có thể là một bộ điều khiển Ingress.
Bộ điều khiển Ingress đơn giản là một nhóm được cấu hình để giải thích các quy tắc xâm nhập. Một trong những bộ điều khiển xâm nhập phổ biến nhất được hỗ trợ bởi kubernetes là nginx. Về mặt Amazon, ALB có thể được sử dụng như một bộ điều khiển xâm nhập.
Đối với một ví dụ, này điều khiển nginx có thể ăn nguyên tắc xâm nhập bạn đã xác định và dịch chúng vào một tập tin nginx.conf rằng nó tải và bắt đầu trong pod của nó.
Ví dụ, giả sử bạn đã xác định một mục nhập như sau:
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
Nếu sau đó bạn kiểm tra pod bộ điều khiển nginx của mình, bạn sẽ thấy quy tắc sau được xác định trong /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 vừa tạo một quy tắc định tuyến http://kubernetes.foo.bar/appđể trỏ đến dịch vụ appsvctrong cụm của bạn.
Dưới đây là một ví dụ về cách triển khai cụm kubernetes với bộ điều khiển xâm nhập nginx. Hi vọng điêu nay co ich!
Tôi tìm thấy bài viết rất thú vị này giải thích sự khác biệt giữa NodePort, LoadBalancer và Ingress.
Từ nội dung có mặt trong bài viết:
Cân bằng tải:
Dịch vụ LoadBalancer là cách tiêu chuẩn để đưa dịch vụ ra internet. Trên GKE, điều này sẽ tạo ra một Trình cân bằng tải mạng sẽ cung cấp cho bạn một địa chỉ IP duy nhất sẽ chuyển tiếp tất cả lưu lượng truy cập đến dịch vụ của bạn.
Nếu bạn muốn trực tiếp tiếp xúc với một dịch vụ, đây là phương pháp mặc định. Tất cả lưu lượng truy cập trên cổng bạn chỉ định sẽ được chuyển tiếp đến dịch vụ. Không có bộ lọc, không định tuyến, v.v. Điều này có nghĩa là bạn có thể gửi hầu hết mọi loại lưu lượng truy cập đến nó, như HTTP, TCP, UDP, Websockets, gRPC hoặc bất cứ thứ gì.
Nhược điểm lớn là mỗi dịch vụ bạn tiếp xúc với LoadBalancer sẽ có địa chỉ IP riêng và bạn phải trả tiền cho LoadBalancer cho mỗi dịch vụ được hiển thị, có thể tốn kém!
Nhập:
Ingress thực sự KHÔNG phải là một loại dịch vụ. Thay vào đó, nó nằm ở phía trước của nhiều dịch vụ và hoạt động như một bộ định tuyến thông minh, hay bộ định tuyến vào cụm của bạn.
Bạn có thể làm rất nhiều thứ khác nhau với một Ingress và có nhiều loại bộ điều khiển Ingress có khả năng khác nhau.
Bộ điều khiển xâm nhập GKE mặc định sẽ tạo ra Bộ cân bằng tải HTTP (S) cho bạn. Điều này sẽ cho phép bạn thực hiện cả định tuyến dựa trên đường dẫn và tên miền phụ đến các dịch vụ phụ trợ. Ví dụ: bạn có thể gửi mọi thứ trên foo.yourdomain.com đến dịch vụ foo và mọi thứ trong đường dẫn yourdomain.com/bar/ đến dịch vụ thanh.
Ingress có lẽ là cách mạnh mẽ nhất để thể hiện các dịch vụ của bạn, nhưng cũng có thể phức tạp nhất. Có nhiều loại bộ điều khiển Ingress, từ Google Cloud Load Balancer, Nginx, Contour, Istio, v.v. Ngoài ra còn có các plugin cho bộ điều khiển Ingress, như trình quản lý chứng chỉ, có thể tự động cung cấp chứng chỉ SSL cho các dịch vụ của bạn.
Ingress là hữu ích nhất nếu bạn muốn hiển thị nhiều dịch vụ dưới cùng một địa chỉ IP và tất cả các dịch vụ này đều sử dụng cùng một giao thức L7 (thường là HTTP). Bạn chỉ trả tiền cho một bộ cân bằng tải nếu bạn đang sử dụng tích hợp GCP riêng và vì Ingress là thông minh, bạn có thể nhận được rất nhiều tính năng ngoài hộp (như SSL, Auth, Routing, v.v.)
TL: DR
Hãy bắt đầu với trường hợp sử dụng thực tế: bạn có nhiều Apis được hỗ trợ bởi các gói triển khai dịch vụ (ASIP cho clariy và brevity) để triển khai dưới một tên miền duy nhất. Vì bạn là nhà phát triển tiên tiến, bạn đã triển khai kiến trúc dịch vụ vi mô yêu cầu triển khai riêng cho từng ASIP để chúng có thể được nâng cấp hoặc thu nhỏ riêng lẻ. Tất nhiên, các ASIP này được gói gọn trong thùng chứa docker riêng lẻ và có sẵn cho Kubernetes (K8) từ kho lưu trữ container.
Bây giờ hãy nói rằng bạn muốn triển khai điều này trên GKE K8 của Google. Để triển khai tính khả dụng duy trì, mỗi phiên bản ASIP (bản sao) được triển khai trên các nút (VM) khác nhau trong đó mỗi VM có địa chỉ IP bên trong đám mây riêng. Mỗi triển khai ASIP được định cấu hình trong tệp "triển khai.yaml" thông minh trong đó bạn chỉ định khai báo, trong số những điều khác, số lượng bản sao của các ASIP K8 đã cho sẽ triển khai.
Bước tiếp theo là đưa API ra thế giới ouside và các yêu cầu kênh cho một trong các phiên bản ASIP được triển khai. Vì chúng tôi có nhiều bản sao của cùng một ASIP chạy trên các nút khác nhau, chúng tôi cần một cái gì đó sẽ phân phối yêu cầu giữa các bản sao đó. Để giải quyết vấn đề này, chúng tôi có thể tạo và áp dụng tệp "service.yaml" sẽ định cấu hình dịch vụ K8s (KServ) sẽ được hiển thị bên ngoài và có thể truy cập thông qua địa chỉ IP. KServ này sẽ chịu trách nhiệm phân phối yêu cầu của API trong số các ASIP được cấu hình của nó. Lưu ý rằng một KServ sẽ được tự động cấu hình lại bởi chủ nhân K8 khi nút của ASIP bị lỗi và được khởi động lại. Địa chỉ IP nội bộ không bao giờ được sử dụng lại trong trường hợp đó và KServ phải được thông báo về vị trí triển khai của ASIP mới.
Nhưng chúng tôi có các gói dịch vụ Api khác sẽ được hiển thị trên cùng một tên miền. Việc quay một KServ mới sẽ tạo ra một địa chỉ IP bên ngoài mới và chúng tôi sẽ không thể hiển thị nó trên cùng một tên miền. Chà, đây là lúc Ingress đến.
Nhập vào giữa Internet và tất cả các dịch vụ mà chúng tôi tiếp xúc với thế giới bên ngoài. Ingress có khả năng cung cấp cân bằng tải, chấm dứt SSL và lưu trữ ảo dựa trên tên. Khả năng thứ hai có thể định tuyến một yêu cầu đến đúng dịch vụ bằng cách phân tích URL của nó. Tất nhiên, Ingress phải được cấu hình và áp dụng với một tệp ... "ingress.yaml" sẽ chỉ định các bản ghi lại và các tuyến cần thiết để gửi yêu cầu đến đúng KServ.
Internet -> Nhập -> Dịch vụ K8s -> Bản sao
Vì vậy, với cấu hình, dịch vụ KSIP và ASIP phù hợp, chúng tôi có thể hiển thị một cách an toàn nhiều API bằng cùng một tên miền.
Có 4 cách để cho phép các nhóm trong cụm của bạn nhận được lưu lượng truy cập bên ngoài:
1.) Pod sử dụng HostNetworking: true và (Cho phép 1 nhóm trên mỗi nút nghe trực tiếp các cổng trên nút máy chủ. Đôi khi, Minikube, kim loại trần và rasberry pi tuyến này có thể cho phép nút máy chủ nghe trên cổng 80/443 cho phép không sử dụng cấu hình cân bằng tải hoặc cấu hình cân bằng tải đám mây nâng cao, nó cũng bỏ qua Dịch vụ Kubernetes có thể hữu ích để tránh SNAT / đạt được hiệu quả tương tự của bên ngoàiPPPicy: trong đó không được hỗ trợ như trên AWS.)
2.) Dịch vụ NodePort
3.) Dịch vụ LoadBalancer (được xây dựng trên Dịch vụ NodePort)
4.) Bộ điều khiển xâm nhập + Đối tượng xâm nhập (Xây dựng trên
các đối tượng trên)
Hãy nói rằng bạn có 10 trang web được lưu trữ trong cụm của bạn và bạn muốn hiển thị tất cả chúng cho lưu lượng truy cập bên ngoài.
* Nếu bạn sử dụng Dịch vụ LoadBalancer loại, bạn sẽ sinh ra 10 bộ cân bằng tải HA Cloud (mỗi chi phí tiền)
* Nếu bạn sử dụng loại Bộ điều khiển Ingress, bạn sẽ sinh ra 1 Bộ cân bằng tải HA Cloud (tiết kiệm tiền) và nó sẽ trỏ đến Ingress Bộ điều khiển chạy trong cụm của bạn.
Bộ điều khiển Ingress là:
Bộ điều khiển L7 LB / Ingress bên trong cụm Lưu lượng cân bằng / lưu lượng truy cập proxy ngược vào Dịch vụ IP của cụm trong cụm của bạn, nó cũng có thể chấm dứt HTTPS nếu bạn có chứng chỉ Kubernetes Secret của loại TLS và đối tượng Ingress tham chiếu đến nó.)
Ingress: Đối tượng Ingress + Bộ điều khiển Ingress
Đối tượng xâm nhập:
Giống như Đối tượng dịch vụ, ngoại trừ nó không tự làm bất cứ điều gì. Đối tượng Ingress chỉ mô tả một cách để định tuyến lưu lượng Lớp 7 vào cụm của bạn, bằng cách chỉ định những thứ như đường dẫn yêu cầu, miền yêu cầu và dịch vụ kubernetes đích, trong khi đối tượng dịch vụ thực sự tạo ra các dịch vụ
Bộ điều khiển Ingress:
Một dịch vụ:
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
Ví dụ: Bộ điều khiển Ingress Nginx, có thể sử dụng một dịch vụ để nghe trên cổng 80 và 443 và sau đó đọc Đối tượng Ingress mới và phân tích chúng vào các phần máy chủ mới {} mà nó tự động đặt vào đó là nginx.conf
LoadBalancer: Nhà cung cấp cân bằng tải bên ngoài + Loại dịch vụ
Nhà cung cấp cân bằng tải bên ngoài:
Các nhà cung cấp cân bằng tải bên ngoài thường được cấu hình trong các đám mây như AWS và GKE và cung cấp một cách để gán IP bên ngoài thông qua việc tạo các bộ cân bằng tải bên ngoài. Chức năng này có thể được sử dụng bằng cách chỉ định một dịch vụ dưới dạng "LoadBalancer".
Loại dịch vụ:
Khi loại dịch vụ được đặt thành LoadBalancer, Kubernetes cố gắng tạo và sau đó lập trình một bộ cân bằng tải bên ngoài với các mục cho các nhóm Kubernetes, từ đó gán cho chúng các IP bên ngoài.
Bộ điều khiển dịch vụ Kubernetes tự động hóa việc tạo bộ cân bằng tải bên ngoài, kiểm tra sức khỏe (nếu cần), quy tắc tường lửa (nếu cần) và truy xuất IP bên ngoài của LoadBalancer mới được tạo hoặc được cấu hình được cung cấp bởi nhà cung cấp đám mây và đưa nó vào đối tượng phục vụ.
Các mối quan hệ:
Dịch vụ điều khiển Ingress thường được cung cấp dưới dạng LoadBalancer, do đó các yêu cầu http và https có thể được ủy quyền / định tuyến đến các dịch vụ nội bộ cụ thể thông qua một ip bên ngoài.
Tuy nhiên, LoadBalancer không thực sự cần thiết cho việc này. Vì, thông qua việc sử dụng hostNetwork hoặc hostPort, về mặt kỹ thuật, bạn có thể liên kết một cổng trên máy chủ với một dịch vụ (cho phép bạn truy cập nó thông qua ip: port bên ngoài của máy chủ). Mặc dù chính thức nhưng điều này không được khuyến khích vì nó sử dụng hết các cổng trên nút thực tế.
Người giới thiệu:
https://kubernetes.io/docs/con accept / configuration / view / # service
https://kubernetes.io/docs/t Nhiệm/access-application-cluster/create-external-load-balancer/
https://kubernetes.io/docs/con accept / service-network / forum /
Nói một cách đơn giản, bộ cân bằng tải phân phối các yêu cầu giữa nhiều dịch vụ phụ trợ (cùng loại) trong khi xâm nhập giống như một cổng API (proxy ngược) định tuyến yêu cầu đến một dịch vụ phụ trợ cụ thể dựa trên URL.