Pod IP, ClusterIP hay bộ cân bằng tải nội bộ cho người dùng VPN

Với VPC CNI, một Pod có thể mang địa chỉ từ VPC, và người dùng VPN có tuyến đường đúng có thể truy cập trực tiếp. Điều đó khiến truy cập trực tiếp vào Pod có vẻ là lựa chọn đơn giản nhất, và đúng là như vậy, cho đến khi Pod bị thay thế. Địa chỉ mà người dùng ghi nhớ nên thuộc về ứng dụng, không phải một bản sao. Việc so sánh ba lối vào rốt cuộc nằm ở chỗ đối tượng nào sở hữu địa chỉ và điều gì phải tiếp tục hoạt động khi khối lượng công việc di chuyển.

Trước hết hãy chọn theo vòng đời, sau đó theo điều mà mạng phải làm để lối vào có thể truy cập được.

Ba lối vào, ba vòng đời

Pod IP thuộc về một Pod: nó được cấp cùng với Pod và giải phóng khi Pod kết thúc. ClusterIP thuộc về một Service và là địa chỉ ảo, chỉ có ý nghĩa ở nơi tồn tại định tuyến dịch vụ của cụm. Bộ cân bằng tải nội bộ thuộc về một tài nguyên đám mây mà bộ điều khiển của cụm lập trình với các backend. Những mô hình sở hữu này dự báo lỗi mà bạn sẽ gặp: một địa chỉ cũ, một tên không thể tiếp cận, hoặc một tập backend đã lỗi thời.

Hãy viết so sánh trước khi chọn. Khi chủ sở hữu và lỗi đã được gọi tên, lựa chọn thường tự diễn ra.

Truy cập trực tiếp vào Pod: hữu ích, tạm thời

Truy cập trực tiếp thực sự hữu ích cho một kiểm tra có kiểm soát: một quản trị viên, một phiên ngắn, một cổng cụ thể. Nhưng đó là một hợp đồng tồi cho người dùng, vì địa chỉ là chi tiết triển khai thay đổi ở mỗi lần phát hành. Và ghi một địa chỉ như vậy vào wiki chính là cách một dịch vụ đang chạy biến thành tin đồn.

Nó cũng mời gọi những quy tắc rộng. Quyền cho một quản trị viên tiếp cận một Pod không phải là quyền cho mọi địa chỉ trong mạng con của nút, và thường thì cái thứ hai mới là thứ được viết ra.

ClusterIP: giới hạn trong cụm theo thiết kế

ClusterIP hoạt động vì mặt phẳng dữ liệu của cụm lập trình định tuyến cho nó bên trong cụm. Từ một máy tính xách tay trên VPN, địa chỉ không có ý nghĩa gì trừ khi có thứ gì đó cố ý phơi bày nó. Một tên kết thúc bằng svc.cluster.local thuộc về DNS của cụm, nên sao chép nó sang một máy khách có trình phân giải khác sẽ tạo ra một tên không tồn tại thay vì lỗi định tuyến.

ClusterIP vẫn là lối vào đúng cho những người gọi bên trong cụm, bao gồm các khối lượng công việc khác. Nó chỉ đơn giản không phải là cơ chế công bố cho người dùng ngoài miền định tuyến của cụm.

Bộ cân bằng tải nội bộ: con đường được công bố

Một bộ cân bằng tải nội bộ cho bạn một địa chỉ riêng ổn định và một tên mà vùng của bạn có thể trỏ tới, trong khi bộ điều khiển giữ cho tập backend luôn cập nhật, như hướng dẫn cân bằng tải của EKS mô tả. Đây là lối vào tồn tại qua một lần thay thế Pod thông thường mà không ai phải sửa tài liệu. Nó tốn một tài nguyên đám mây, một cấu hình bộ điều khiển và một tuyến từ VPN, và đó chính là những phần mà người ta đánh giá thấp.

Hãy dùng mô hình bộ điều khiển mà cụm thực sự chạy. Các chú thích viết cho một tích hợp không áp dụng cho tích hợp khác.

Địa chỉ nguồn là ai

Các nhóm bảo mật nhìn thấy nguồn đến ranh giới của chúng, và đó có thể là máy khách đã kết nối hoặc một địa chỉ được dịch tùy thuộc vào đường VPN và cân bằng tải. Trên các nút dựa trên EC2, các Pod VPC CNI thông thường mặc định thừa hưởng các nhóm ENI của nút, trong khi các cấu hình được hỗ trợ có thể gắn các nhóm dành riêng cho Pod. Hãy viết quy tắc cho con đường đã được tài liệu hóa, không phải cho một địa chỉ máy tính xách tay phỏng đoán.

Hãy giữ trình lắng nghe và xác thực riêng của ứng dụng như những kiểm soát riêng biệt. Một quy tắc mạng cho phép luồng không phải là quyết định ủy quyền và không nên được coi như vậy.

Cần giao gì cho người dùng

Hãy trao cho người dùng một tên dịch vụ, không phải địa chỉ. Công bố tên trong vùng riêng, trỏ nó tới lối vào nội bộ, rồi kiểm thử bằng cách thay thế một Pod backend trong khi máy khách giữ nguyên tên đó mở. Bài tập đó kiểm tra đúng thuộc tính quan trọng: tiếp cận cùng một ứng dụng sau một lần triển khai thường lệ.

Hãy giữ truy cập trực tiếp vào Pod như một ngoại lệ vận hành được tài liệu hóa với phạm vi riêng, cách xa hướng dẫn dành cho người dùng.