Một sidecar VPN cần quy tắc khởi động và quy tắc thất bại

Một pod khởi động container đường hầm trước ứng dụng và các yêu cầu đầu tiên thành công, và đây chính là trường hợp che giấu vấn đề. Thứ tự sửa một cuộc đua và không nói gì về lưu lượng mà ứng dụng bắt đầu bốn giờ sau đó, sau khi đường hầm đã hỏng. Đó là hai quyết định riêng biệt. Thường chỉ một trong hai được thiết kế.

Thứ tự chỉ chặn yêu cầu đầu tiên

Kubernetes hỗ trợ vòng đời sidecar được xây dựng từ các container init có thể khởi động lại. Trong mô hình đó, một probe khởi động có thể giữ bước khởi tạo tiếp theo cho đến khi đường hầm báo sẵn sàng. Đó là một cải tiến thực sự, và đáng dùng có chủ đích thay vì thêm sleep vào script điểm vào. Cổng chỉ tốt bằng điều kiện mà nó kiểm tra.

Ngoài mô hình đó, ngữ nghĩa thứ tự thuộc về runtime hoặc hệ thống phụ thuộc mà bạn đang dùng, và chúng không nhất thiết phải khớp nhau. Một bản triển khai sao chép từ nền tảng khác có thể trông như đang chờ đường hầm vì ứng dụng tình cờ khởi động chậm. Đó không phải cùng một bảo đảm, và nó hỏng dưới tải.

Nói rõ cổng quan sát điều gì: có một tiến trình, có một giao diện, một handshake đã hoàn tất. Mỗi điều đó là một khẳng định yếu hơn «đường dữ liệu tới các đích mà pod này cần đang hoạt động».

Thi hành đường dữ liệu thay vì giả định nó

Probe là một lần kiểm tra tại một thời điểm và tường lửa là thuộc tính đúng giữa các thời điểm. Nếu yêu cầu là lưu lượng ứng dụng không bao giờ ra ngoài đường hầm, nó phải được diễn đạt trong không gian tên mạng dùng chung như một quy tắc chấp nhận-hoặc-bỏ. Thứ tự khởi động container không thể mang yêu cầu đó. Chỉ một quy tắc mới có thể.

Các container trong một pod chia sẻ không gian tên đó, nên điểm thi hành là chính không gian tên. Dù bạn viết gì, nó phải để kết nối bên ngoài của chính đường hầm khả dụng, vì chặn nó để bảo vệ ứng dụng sẽ cắt đường mà ứng dụng cần.

Quyết định chính sách thất bại một cách rõ ràng: lưu lượng ứng dụng có nên dừng hoàn toàn khi đường hầm không khỏe mạnh, hay tiếp tục và được đánh dấu là không được bảo vệ? Cả hai đều có lý, và không cái nào là thứ bạn có được bằng cách khởi động container theo một thứ tự nhất định.

Kiểm tra lưu lượng bạn không nhắc tới

Thực hiện một yêu cầu mới trong lúc đường hầm hỏng có kiểm soát và xem nó có ra ngoài không. Sau đó lặp lại kiểm tra cho các đường mà bài kiểm tra địa chỉ ra không bao giờ chạm tới: phân giải DNS trong cụm, các đích IPv6, và các dịch vụ đạt tới qua địa chỉ nội bộ cụm thay vì internet công cộng. Đó là những đường tiếp tục hoạt động âm thầm sau khi đường hầm chết.

Một trang địa chỉ ra chứng minh rằng một yêu cầu đã đi tới nơi bạn mong đợi tại thời điểm đó. Nó không thể kiểm kê các đường khác, và khoảng cách giữa điều bạn đã kiểm tra và điều pod có thể chạm tới là nơi những thất bại thú vị sinh sống.

Lặp lại kiểm tra sau khi khởi động lại sidecar chứ không chỉ sau một lần khởi động sạch. Một container đường hầm được khởi động lại có thể để không gian tên với các tuyến và chính sách ở trạng thái trung gian.

Viết bản ghi triển khai

Ba sự thật thuộc về ghi chú triển khai: bài kiểm tra sẵn sàng và điều nó quan sát, hành động phục hồi khi bài kiểm tra đó thất bại, và quy tắc thi hành chi phối lưu lượng ra. Tài liệu về container sidecar bao quát cơ chế vòng đời và để quyết định chính sách đó cho bạn. Sự phân chia đó là đúng, và đó cũng là lý do chính sách thường thiếu.

Một lần kiểm tra sức khỏe bị nhầm với sự bảo vệ là loại chỉ báo xanh đắt nhất, vì nó khiến người ta ngừng đặt câu hỏi. Gọi tên chính xác nó trong tài liệu tốn một câu và ngăn điều đó.

Cuối cùng, hãy kiểm tra đường phục hồi một lần khi ứng dụng đang chạy. Một thiết kế đòi phải tạo lại pod để khôi phục lưu lượng ra là một quyết định, và nó nên là quyết định bạn đã đưa ra, không phải điều bạn phát hiện ra.