114

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 đế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?

|
126

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. Theo 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 nhóm trình đ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!

|
  • 1

    Tôi nhận được sự khác biệt giữa bộ điều khiển xâm nhập và bộ điều khiển xâm nhập và vai trò tương ứng của chúng. Trong thực tế, bộ cân bằng tải cũng chịu trách nhiệm hướng lưu lượng truy cập đến các nhóm kubernetes của tôi thông qua một bộ quy tắc được xác định. Bạn có thể vui lòng làm sáng tỏ hơn về cách điều khiển xâm nhập khác với cân bằng tải về khía cạnh đó? Có lẽ một ví dụ trong đó cả cân bằng tải và tải được sử dụng sẽ giúp ích.

    – Huỳnh Thạch Thảo 08:54:46 18/07/2017
  • 1

    Bộ điều khiển xâm nhập không phải là loại kubernetes chính thức, nó chỉ là một triển khai hình ảnh LB (nginx chỉ là một ví dụ) có thể diễn giải các quy tắc xâm nhập. Tôi tin rằng hầu hết mọi người đều cho rằng bộ điều khiển xâm nhập cũng là một LB bên trong sống bên trong cụm. Tôi thực sự đã không cố gắng tạo ra một bộ cân bằng tải bên ngoài để giải thích các quy tắc xâm nhập. Tôi tưởng tượng nó có thể, nhưng tôi có thể sai hoàn toàn :)

    – Lý Hoài Đoan 14:20:36 18/07/2017
  • 1

    Trong ứng dụng hiện tại của tôi, tôi đã triển khai triển khai nginx dưới dạng dịch vụ LoadBalancer trên GKE và thực hiện ủy quyền ngược từ nginx cho tất cả các dịch vụ khác đang chạy trong cụm. Tôi có nên sử dụng xâm nhập thay vì cách tiếp cận trên?

    – Biển Ngọc 21:08:07 10/08/2017
  • 1

    hi @rigal trong proxy nginx của bạn làm thế nào để các quy tắc proxy trông như thế nào? Họ có được giải quyết bằng kube-dns không?

    – Lý Anh Thư 08:09:49 23/11/2017
  • 1

    @arunkjn vâng. Các quy tắc trông như thế này: location / api / url / {proxy_pass tên dịch vụ: 80 / api / url ; }

    – Dương Diễm Kiều 09:07:10 24/11/2017
27

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, hoặc điểm truy cập 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.)

|
8

TL: DR

  1. Ingress nằm giữa mạng công cộng (Internet) và các dịch vụ Kubernetes công khai phơi bày việc triển khai Api của chúng tôi.
  2. 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.
  3. Khả năng xâm nhập cho phép hiển thị an toàn nhiều API hoặc Ứng dụng từ một tên miền.

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. Quay một KServ mới sẽ tạo 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.

|
1

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 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ế.

Tài liệu tham khảo:

https://kubernetes.io/docs/con accept / configuration / review / # service

https://kubernetes.io/docs/t Nhiệm/access-application-cluster/create-external-load-balancer/

https://kubernetes.io/docs/t Nhiệm/access-application-cluster/create-external-load-balancer/#external-load-balancer-providers

https://kubernetes.io/docs/con accept / service-networking / forum /

|

Câu trả lời của bạn (> 20 ký tự)

Bằng cách click "Đăng trả lời", bạn đồng ý với Điều khoản dịch vụ, Chính sách bảo mật and Chính sách cookie của chúng tôi.

Không tìm thấy câu trả lời bạn tìm kiếm? Duyệt qua các câu hỏi được gắn thẻ hoặc hỏi câu hỏi của bạn.