Mở đầu: Câu chuyện về 2 cái Server, Port UDP và K3s

Khởi nguồn của một cụm Cluster bất đắc dĩ #

Mọi chuyện bắt đầu từ một sự cố có phần hơi… dở khóc dở cười.

Tôi có một dự án web cần deploy gấp. Thay vì lên mạng thuê VPS như bình thường, tôi nhắn tin cho một người anh trong ngành để hỏi xem có server nào đang trống không thì nhượng lại. Rất nhiệt tình, anh ấy quăng ngay cho tôi thông tin một con server để vào việc.

Nhưng đời không như mơ. Trong quá trình setup hạ tầng, tôi phát hiện ra con server này đang bị nhà mạng chặn hẳn inbound/outgoing kết nối UDP. Khổ nỗi, kiến trúc dự án của tôi lại bắt buộc phải sử dụng giao thức này. Với những ai làm hệ thống nhiều sẽ hiểu, UDP thường bị ISP mặc định khóa chặt để phòng chống rủi ro DDoS. Không thể tự can thiệp từ phía hệ điều hành, anh bạn tôi đành phải tạo một ticket gửi thẳng cho bộ phận kỹ thuật của nhà cung cấp để yêu cầu mở port và đành ngồi chờ họ xử lý.

Đứng trước áp lực thời gian của dự án không thể chờ đợi thêm, tôi tặc lưỡi tự bỏ tiền túi ra mua luôn một con server mới tinh ở bên khác để chạy cho kịp tiến độ.

Sáng hôm sau, bộ phận kỹ thuật báo đã xử lý xong ticket. Tuy nhiên, họ chỉ có thể mở UDP cho dải IP trong nước, còn hướng bắn ra quốc tế vẫn bị chặn hoàn toàn. Nhưng điều khiến tôi tá hỏa hơn cả là lúc này tôi mới nhận ra một sự thật: Hóa ra cái con server bị lỗi port tối qua không phải là server cũ anh ấy có sẵn, mà là một con server mới tinh anh ấy vừa âm thầm bỏ tiền túi ra mua thêm để cho tôi thuê. Sự thật là anh ấy hoàn toàn không tính thêm bất kỳ chi phí nào và chỉ đơn thuần muốn giúp đỡ tôi cho kịp tiến độ dự án.

Sự nhiệt tình của người anh em cộng với cái “xui” dính policy mạng lúc đập hộp đã tạo ra một tình huống trớ trêu. Tất nhiên, tôi không thể từ chối tấm lòng đó, đành nhận luôn.

Và thế là, từ một kẻ đang vã mồ hôi tìm chỗ chứa một cái web app, tôi đột nhiên nắm trong tay 2 con server.

Với một người làm kỹ thuật, việc để một server gánh còng lưng chạy code và một server cấu hình khủng “nằm chơi” là một sự lãng phí tài nguyên không thể chấp nhận được. Trong đầu tôi lập tức nảy ra một kế hoạch: “Tại sao không nối hai cái máy này lại thành một cụm cluster, để chúng cùng gánh tải, chia sẻ tài nguyên và dự phòng cho nhau?”

Đó chính là khởi nguồn của chuỗi series này. Tôi tìm đến Kubernetes – tiêu chuẩn vàng của hệ thống phân tán. Nhưng ngay ngày đầu tiên triển khai, nó đã vả cho tôi một gáo nước lạnh vì quá nặng nề! Để chạy tầng control plane của hệ thống này, nó ngốn gần hết RAM và CPU của máy chủ, chẳng còn lại bao nhiêu không gian thực sự cho ứng dụng.

Giải pháp xuất hiện mang tên K3s – một phiên bản Kubernetes đã được vắt kiệt mỡ thừa, loại bỏ hàng triệu dòng code không cần thiết nhưng vẫn giữ nguyên vẹn sức mạnh cốt lõi của một hệ điều hành phân tán.

Đây là hành trình tôi bước từ thế giới của Docker sang thế giới của Kubernetes.

[!NOTE]

Dành cho những anh em tò mò về kiến trúc thực tế tôi đã dựng để giải quyết bài toán mạng oái oăm trên:

• Vì port UDP bị chặn hướng đi quốc tế và ngay cả khi mở port outgoing thì lưu lượng cũng chỉ đi được trong nội địa. Điều này khiến kết nối VPN nội bộ rớt thảm hại và buộc hệ thống phải fallback về TCP. Do đó, tôi đã quyết định dùng Tailscale làm hạ tầng mạng lõi.
• Để vượt rào và giảm độ trễ, tôi tự host luôn một DERP Server tĩnh ngay trên cụm K3s.
• Sau khi mọi thứ đã thông suốt, tôi nối thẳng PC cá nhân ở nhà vào cluster này để gánh các tác vụ AI. Việc xài tạm GPU ở nhà giúp tôi tiết kiệm một khoản lớn chi phí đi thuê ngoài.

Đúng vậy, một cụm Hybrid Cloud kết hợp giữa VPS trên mây và phần cứng tại gia. Đây cũng là lần đầu tiên tôi thực sự bắt tay vào “nhào nặn” Kubernetes cho một dự án cá nhân. Do đó, chuỗi bài viết này không chỉ là nhật ký kiến trúc, mà còn là một bộ tài liệu hướng dẫn thực chiến K3s từ con số 0 dành cho những ai vô tình cố ý có 2 cái server.