Flannel trong Kubernetes là gì? Hướng dẫn cách triển khai Flannel

Khi các Pod được phân bố trên nhiều node, Kubernetes cần một lớp mạng đủ ổn định để duy trì khả năng giao tiếp xuyên suốt cluster. Flannel trong Kubernetes giải quyết bài toán đó bằng cách cấp subnet cho từng node và thiết lập đường truyền giữa các workload. Cùng Viettel IDC tìm hiểu cụ thể hơn về Flannel và cách triển khai cụ thể trong Kubernetes.

Flannel trong Kubernetes là gì?

Flannel trong Kubernetes là một plugin mạng theo chuẩn CNI, có nhiệm vụ xây dựng lớp kết nối để các Pod trong cùng cluster có thể trao đổi dữ liệu với nhau. Thông qua mạng ảo được tạo trên hạ tầng sẵn có, Pod nằm trên nhiều node khác nhau vẫn có thể giao tiếp bằng địa chỉ IP riêng mà không cần cấu hình định tuyến thủ công cho từng máy chủ.

Mỗi node được cấp một subnet riêng để phân bổ địa chỉ IP cho các Pod đang hoạt động. Tiến trình flanneld quản lý các subnet, thiết lập đường truyền và chuyển tiếp lưu lượng giữa các node thông qua backend như VXLAN hoặc host-gw. Nhờ kiến trúc đơn giản, Flannel thường phù hợp với cluster cần triển khai nhanh, mô hình mạng gọn và chưa yêu cầu chính sách bảo mật mạng phức tạp.

Flannel hoạt động như thế nào?

Flannel tạo một mạng Layer 3 chung để các Pod trên nhiều node có thể liên lạc bằng địa chỉ IP nội bộ. Trên mỗi node, tiến trình flanneld kết nối với Kubernetes API để đọc cấu hình mạng, sau đó nhận một subnet từ dải Pod CIDR của toàn cluster và dành subnet đó cho các Pod chạy trên node tương ứng.

Khi một Pod gửi dữ liệu đến Pod nằm trên node khác, hệ thống xác định subnet đích rồi chuyển gói tin qua backend đã cấu hình. Với VXLAN, gói tin được đóng gói và truyền qua mạng vật lý trước khi được tháo gói tại node đích; còn host-gw bổ sung các tuyến trực tiếp vào bảng định tuyến của máy chủ nên không cần lớp đóng gói VXLAN.

flanneld đồng thời theo dõi thông tin subnet của những node khác và cập nhật tuyến truyền khi cluster có node mới hoặc cấu trúc mạng thay đổi. Sau khi nhận subnet và thiết lập backend, tiến trình ghi các thông số như địa chỉ subnet và MTU vào tệp /run/flannel/subnet.env để CNI plugin sử dụng khi tạo giao diện mạng cho Pod.

Các backend phổ biến của Flannel

Backend quy định cách lưu lượng được truyền giữa các node trong cluster. Trong Flannel Kubernetes, VXLAN và host-gw là hai lựa chọn phổ biến với cơ chế vận hành khác nhau.

VXLAN

VXLAN tạo một mạng overlay bằng cách đóng gói lưu lượng của Pod vào gói UDP trước khi truyền qua hạ tầng vật lý. Khi đến node đích, gói tin được tháo lớp đóng gói rồi chuyển tiếp đến Pod tương ứng.

Ưu điểm của VXLAN nằm ở khả năng hoạt động trên nhiều kiến trúc mạng, kể cả khi các node thuộc những subnet vật lý khác nhau. Tuy nhiên, quá trình đóng gói làm phát sinh thêm overhead và có thể khiến hiệu suất thấp hơn so với định tuyến trực tiếp.

Host-gw

Host-gw sử dụng bảng định tuyến của máy chủ để chuyển lưu lượng trực tiếp đến subnet Pod trên node đích. Do không cần đóng gói gói tin qua mạng overlay, backend này thường mang lại độ trễ thấp và hiệu suất truyền tải tốt hơn VXLAN.

Để hoạt động ổn định, các node phải kết nối trực tiếp ở Layer 2 và có thể sử dụng địa chỉ IP của nhau làm gateway. Vì thế, host-gw phù hợp với cluster on-premises hoặc trung tâm dữ liệu có hạ tầng mạng phẳng, đồng nhất và dễ kiểm soát.

Ưu và nhược điểm của Flannel trong Kubernetes

Flannel Kubernetes được đánh giá cao nhờ kiến trúc gọn nhẹ, dễ triển khai và phù hợp với nhiều cluster có nhu cầu kết nối mạng cơ bản. Tuy vậy, công cụ vẫn tồn tại một số giới hạn về bảo mật, khả năng kiểm soát lưu lượng và mức độ tối ưu cho hệ thống quy mô lớn.

Hướng dẫn cách cài đặt Flannel trên Kubernetes

Quy trình cài đặt Flannel trên Kubernetes gồm ba bước chính: cấu hình Pod CIDR, áp dụng manifest và kiểm tra trạng thái mạng. Hướng dẫn dưới đây áp dụng cho cluster được khởi tạo bằng kubeadm.

Bước 1: Chuẩn bị dải mạng dành cho Pod

Mỗi node cần một subnet riêng để cấp địa chỉ IP cho các Pod đang chạy. Với cluster mới, có thể chọn dải 10.244.0.0/16 ngay từ lúc khởi tạo control plane:

Dải Pod CIDR phải tách biệt với mạng máy chủ, VPN và các dải IP nội bộ khác. Chẳng hạn, khi các node sử dụng mạng 192.168.10.0/24, dải 10.244.0.0/16 có thể dành riêng cho workload để hạn chế xung đột định tuyến.

Sau khi control plane khởi tạo thành công, cấu hình quyền truy cập cluster cho tài khoản hiện tại:

Ở thời điểm chưa có plugin mạng, node thường hiển thị NotReady và CoreDNS có thể nằm ở trạng thái Pending. Các trạng thái trên cho thấy cluster đang chờ lớp kết nối dành cho Pod.

Bước 2: Đưa Flannel vào cluster

Để triển khai Flannel trong Kubernetes, áp dụng manifest từ trang phát hành chính thức:

Manifest tạo namespace kube-flannel, ConfigMap, ServiceAccount, quyền RBAC và DaemonSet. Sau đó, DaemonSet phân bổ một Pod kube-flannel lên từng node để thiết lập mạng cục bộ và duy trì đường truyền giữa các subnet.

Nếu cluster sử dụng Pod CIDR khác 10.244.0.0/16, nên tải manifest về máy trước khi áp dụng:

Mở file kube-flannel.yml, thay dải mạng mặc định bằng Pod CIDR đã chọn rồi triển khai:

Pod CIDR trong manifest phải khớp với cấu hình của cluster. Sai lệch giữa hai dải mạng có thể khiến Pod nhận địa chỉ IP nhưng không thể truyền dữ liệu sang node khác.

Bước 3: Kết nối các worker node

Trên từng worker node, chạy lệnh kubeadm join được trả về sau khi control plane khởi tạo:

Khi worker tham gia cluster, DaemonSet sẽ tự tạo Pod mạng trên node mới. Đội ngũ vận hành không cần cài từng thành phần thủ công trên từng máy.

Nếu không còn lệnh join ban đầu, có thể tạo lại trên control plane:

Bước 4: Kiểm tra trạng thái mạng

Trước tiên, xác nhận Pod mạng đã xuất hiện trên toàn bộ node:

Số Pod kube-flannel thường tương ứng với số node đủ điều kiện chạy DaemonSet. Mỗi Pod cần đạt trạng thái Running và cột READY hiển thị 1/1.

Tiếp tục kiểm tra node và CoreDNS:

Quá trình cài đặt đạt yêu cầu khi:

- Các node chuyển từ NotReady sang Ready.

- Pod kube-flannel chạy ổn định trên từng node.

- CoreDNS chuyển khỏi trạng thái Pending.

- Không xuất hiện lỗi cấp subnet hoặc chọn sai interface trong log.

Nếu số Pod mạng thấp hơn số node, cần kiểm tra taint, lỗi tải image, trạng thái node hoặc cấu hình card mạng.

Bước 5: Xác nhận kết nối giữa các Pod

Trạng thái Running mới phản ánh container đã khởi động, chưa đủ để khẳng định lưu lượng xuyên node hoạt động ổn định. Một bài kiểm tra đơn giản có thể dùng Nginx làm đích và BusyBox làm máy khách.

Tạo hai Pod thử nghiệm:

Kiểm tra địa chỉ IP và node đang chứa từng Pod:

Giả sử web-test nhận địa chỉ 10.244.1.5, gửi yêu cầu từ client-test:

Khi terminal trả về nội dung trang mặc định của Nginx, lưu lượng đã đến đúng Pod đích. Hai Pod nên nằm trên hai worker khác nhau để kết quả phản ánh chính xác khả năng kết nối xuyên node.

Bước 6: Khoanh vùng lỗi khi node chưa sẵn sàng

Nếu node vẫn hiển thị NotReady, hãy kiểm tra log và trạng thái DaemonSet trước:

Các nguyên nhân thường gặp gồm:

- Pod CIDR trong cluster không khớp với manifest.

- Dải IP dành cho Pod trùng với mạng host hoặc VPN.

- Firewall chặn lưu lượng giữa các node.

- Máy chủ có nhiều card mạng nhưng plugin chọn sai interface.

- MTU không phù hợp với hạ tầng có thêm lớp tunnel.

- Cluster đã cài một CNI khác từ trước.

Khi cần xem diễn biến gần nhất trong namespace, dùng lệnh:

Quá trình cài đặt hoàn tất khi Pod kube-flannel hoạt động trên toàn bộ node, cluster đạt trạng thái Ready và các workload trên nhiều worker có thể kết nối trực tiếp qua địa chỉ IP nội bộ.

Khi nào nên sử dụng Flannel trong Kubernetes?

Flannel phù hợp với các cluster ưu tiên khả năng triển khai nhanh, kiến trúc mạng gọn và yêu cầu vận hành không quá phức tạp. Giải pháp t phát huy hiệu quả khi mục tiêu chính là bảo đảm Pod trên nhiều node có thể giao tiếp ổn định mà chưa cần đến các tính năng bảo mật mạng chuyên sâu.

- Cluster nhỏ và vừa: Phù hợp với hệ thống có quy mô vừa phải, số lượng node chưa quá lớn và lưu lượng mạng không quá phức tạp.

- Môi trường phát triển hoặc kiểm thử: Cấu hình đơn giản giúp đội ngũ kỹ thuật nhanh chóng dựng cluster để thử nghiệm ứng dụng.

- Hạ tầng cần triển khai nhanh: Flannel CNI có thể đáp ứng tốt các hệ thống cần mạng Pod cơ bản mà không muốn đầu tư nhiều thời gian cho cấu hình nâng cao.

- Cluster chưa yêu cầu NetworkPolicy: Phù hợp khi các Pod được phép giao tiếp tương đối tự do và chưa cần kiểm soát truy cập chi tiết giữa từng namespace hoặc workload.

- Mạng on-premises hoặc cloud có cấu trúc rõ ràng: Có thể lựa chọn VXLAN cho hạ tầng linh hoạt hoặc host-gw khi các node cùng mạng Layer 2 và cần giảm overhead.

- Đội ngũ vận hành muốn giảm độ phức tạp: Kiến trúc gọn giúp quá trình quản lý, kiểm tra log và xử lý lỗi mạng dễ tiếp cận hơn.

Kết luận

Hiểu rõ Flannel trong Kubernetes giúp đội ngũ vận hành lựa chọn đúng mô hình mạng trước khi đưa cluster vào sử dụng. Với kiến trúc đơn giản, cách triển khai tương đối nhanh và khả năng kết nối Pod ổn định, Flannel phù hợp với những hệ thống chưa cần NetworkPolicy chuyên sâu hoặc bộ tính năng mạng quá phức tạp.

Đối với doanh nghiệp muốn rút ngắn thời gian xây dựng hạ tầng Kubernetes, Viettel Dedicated Kubernetes Service (vDKS) mang đến môi trường chuyên dụng được khởi tạo nhanh trên nền tảng Public Cloud của Viettel IDC. Dịch vụ hỗ trợ quản lý tập trung, mở rộng tài nguyên linh hoạt và giảm khối lượng công việc vận hành cho đội ngũ kỹ thuật.

Tham khảo chi tiết tại: https://viettelidc.com.vn/viettel-kubernetes-service