VPN theo Pod trong Kubernetes so với cổng ra: ai sở hữu đường hầm?

Bạn triển khai một Pod tên vpn-gateway, trỏ một máy khách thử nghiệm vào địa chỉ của nó và thấy các gói tin biến mất. Không có gì sai trong manifest và kubelet không có gì để phàn nàn. Lý do là cấu trúc chứ không phải cấu hình: Kubernetes cấp cho mỗi Pod không gian tên mạng riêng, nên một cái tên, một nhãn hay một không gian tên API dùng chung không thay đổi gì về nơi các gói tin đi. Vì vậy quyết định lưu lượng VPN rời cụm bằng cách nào bắt đầu bằng câu hỏi về quyền sở hữu, không phải về ảnh container.

Hai cơ chế bao phủ phần lớn triển khai thực tế, và chúng không thể thay thế cho nhau. Một cái đặt đường hầm vào không gian tên mạng của chính khối công việc. Cái kia yêu cầu CNI dẫn lưu lượng được chọn qua một nút cổng được chỉ định. Chúng thất bại theo cách khác nhau, mở rộng theo cách khác nhau và chịu trách nhiệm trước các nhóm khác nhau, đó là lý do câu hỏi về container thường sinh ra tranh luận không bao giờ kết thúc.

Ranh giới của Pod là không gian tên, không phải máy chủ nhảy

Không gian tên mạng của Linux sở hữu các giao diện, địa chỉ, tuyến và quy tắc tường lửa của nó, và mỗi Pod nhận một cái. Các container bên trong Pod đó tham gia vào nó, và đó chính là lý do một container phụ có thể viết lại các tuyến mà ứng dụng sau đó đi theo. Một Pod lân cận có ngăn xếp trông giống hệt nhưng hoàn toàn tách biệt. Không có bảng chung nào để Pod cổng kế thừa, và không có việc chuyển lưu lượng ngầm từ không gian tên này sang không gian tên khác.

Đó cũng là lý do mô hình Pod cổng chỉ hoạt động khi có thứ gì đó ở thượng nguồn thực sự gửi gói tin đến nó: một Service, một tuyến tĩnh trên nút hoặc chính sách dẫn hướng trong CNI. Chỉ một địa chỉ thì không thu hút gì cả.

Đường hầm theo Pod mua được gì, và giá bao nhiêu

Đường hầm chạy trong không gian tên của khối công việc trao cho khối công việc đó danh tính máy khách riêng, thứ mà nhiều dịch vụ truy cập từ xa yêu cầu trước khi cấp quyền hoặc tính toán một phiên. Bán kính ảnh hưởng cũng ở lại cục bộ: một đường hầm hỏng hạ gục một Deployment thay vì con đường chung mà mọi thứ dùng. Cách nó chạy phụ thuộc vào triển khai, và đây là chỗ người ta đoán sai.

Một thiết lập chỉ cần trạng thái nhân có thể kết thúc trong container init và thoát ra. Một daemon không gian người dùng phải sống suốt vòng đời của Pod cần dạng container init có thể khởi động lại được giới thiệu như sidecar gốc trong Kubernetes 1.29, và sự khác biệt đó đến từ cách triển khai đường hầm chứ không phải từ sở thích. Chi phí của mô hình này là trùng lặp: mỗi bản sao xác thực, nhận địa chỉ đường hầm riêng và chiếm một chỗ phiên từ xa, nên một sự kiện tự động mở rộng trở thành sự kiện dung lượng ở phía bên kia liên kết. Sao chép một thông tin đăng nhập vào mọi bản sao không loại bỏ chi phí đó, nó loại bỏ dấu vết kiểm toán. Các quyền hạn cũng đáng được xem xét như vậy, vì một đường hầm muốn NET_ADMIN trong không gian tên của chính nó không có lý do gì để kế thừa quyền hạn trên toàn bộ máy chủ từ một ví dụ có privileged: true.

Khi CNI sở hữu lối ra

Nếu CNI hỗ trợ, một cổng ra chọn lưu lượng theo khối công việc và dải đích, rồi gửi nó qua các nút được chọn dưới một địa chỉ nguồn có thể dự đoán. Phiên bản của Cilium là tài liệu tham chiếu phổ biến, và tài liệu của nó nói rõ rằng tính năng này cần cấu hình Cilium cụ thể cùng các nút cổng được cung cấp giao diện và địa chỉ đúng. Nó cũng ghi nhận một khoảng thời gian đầu sau khi Pod được tạo khi việc dẫn hướng chưa được áp dụng, và đó là đầu vào thiết kế chứ không phải chú thích.

Đọc độ trễ đó so với lời hứa của chính bạn. Nếu quy tắc là không lưu lượng nào được rời đi bằng con đường khác, một Pod mới truyền trong khoảng trống đó đã phá vỡ nó rồi, nên chuỗi khởi động cần câu trả lời riêng: giữ ứng dụng lại cho đến khi chính sách được áp dụng, hoặc chấp nhận khoảng cửa sổ và ghi lại nó.

Giữ tuyên bố hẹp lại. Một cổng ra chọn và dịch một đường đi. Nó không kết thúc VPN, và nó không biến cụm thành máy khách của mạng từ xa của bạn mà không có kết nối được hỗ trợ phía sau.

Việc dịch địa chỉ âm thầm thay đổi những gì phía xa nhìn thấy

Khi cổng viết lại nguồn, địa chỉ theo từng Pod biến mất, nên danh sách cho phép dựa trên danh tính trở thành danh sách dựa trên một địa chỉ chia sẻ. Đó là trao đổi chứ không phải khiếm khuyết: ít quy tắc phải bảo trì hơn, quy kết thô hơn khi có thứ gì đó hành xử tệ.

Xác thực ở tầng ứng dụng và ghi nhật ký yêu cầu phải mang những gì mạng không còn báo cáo. Hãy coi dung lượng và việc thay thế cổng là hạ tầng dùng chung, vì khởi động lại một nút giờ làm gián đoạn mọi khối công việc phía sau nó, và hãy kiểm tra đường về sớm: đầu xa phải biết cách đến địa chỉ đã dịch, thường là qua một tuyến hoặc NAT mà một con người, không phải manifest, phải sở hữu. Việc quy hoạch địa chỉ cũng thuộc về đây, vì các dải cụm và từ xa chồng lấn phá vỡ cả hai mô hình và việc áp dụng IPv6 không bào chữa cho một kế hoạch xung đột.

Quyết định theo quyền sở hữu, rồi kiểm tra thất bại bạn đã hứa

Chọn đường hầm theo Pod khi dịch vụ từ xa xác thực từng khối công việc riêng lẻ, khi chỉ vài Deployment cần liên kết, và khi một thất bại nên ở lại cục bộ. Chọn cổng khi một nhóm mạng đã sở hữu đường đi, khi nhiều khối công việc chia sẻ một đích, và khi một địa chỉ nguồn ổn định chính là toàn bộ mục đích của bài tập.

Dù chọn cách nào, hãy kiểm chứng thuộc tính bạn đã bán chứ không phải trạng thái ổn định. Tạo một Pod, để nó truyền ngay và quan sát những giây đầu nếu lời hứa là không có gì thoát khỏi đường hầm. Mở rộng lên năm bản sao và đếm số phiên mà đầu xa báo cáo nếu lời hứa là danh tính theo từng khối công việc. Hai kiểm tra đó phơi bày giới hạn của cơ chế nhanh hơn nhiều so với việc xem lại manifest, và chúng cho bạn biết nhóm nào sở hữu sự cố tiếp theo.