# Config Network Managed Kubernetes Khi khởi tạo một **Managed Kubernetes Cluster**, phần cấu hình mạng (**Config Network**) đóng vai trò quan trọng trong việc xác định cách thức giao tiếp giữa các thành phần trong cluster. Dưới đây là các thành phần chính và vai trò của chúng: **I. Network Type** ------------------- ### **1\. Network Type** * **Network Type** là thành phần quyết định cách thức cấu hình và quản lý mạng nội bộ trong Kubernetes. * Nó xác định cách các thành phần của Kubernetes (Pods, Services, Nodes) giao tiếp với nhau, cách định tuyến lưu lượng, và cách các chính sách mạng được áp dụng. * Lựa chọn đúng Network Type là yếu tố quan trọng để đảm bảo hiệu suất, bảo mật, và tính linh hoạt của hệ thống. ### 2\. Các loại Network Type #### **a. Cilium** * Cilium là một giải pháp điều phối mạng hiện đại dựa trên **eBPF (Extended Berkeley Packet Filter)**. eBPF là một công nghệ trong Linux Kernel cho phép thực thi mã trong kernel một cách an toàn và hiệu quả. * **Tính năng nổi bật**: * **Bảo mật mạng:** Sử dụng L3/L4/L7 Ppolicy, bảo mật dựa trên danh tính (identity). * **Quan sát mạng:** Hubble cho phép giám sát luồng dữ liệu và phát hiện bất thường. * **Hiệu suất cao:** Xử lý gói tin bằng eBPF, giảm độ trễ và tăng throughput. * **Cân bằng tải:** Cân bằng trực tiếp trong kernel, không cần proxy. * **Hỗ trợ đa môi trường:** Tích hợp Kubernetes, multi-cluster, cloud và bare-metal. * **Mở rộng dễ dàng:** Hỗ trợ chương trình eBPF tùy chỉnh và tích hợp service mesh (Istio, Envoy). #### **b. Calico** * Calico là một giải pháp điều phối mạng phổ biến, hỗ trợ cả Overlay Network và Routing trực tiếp (Native Routing). Tích hợp mạnh mẽ với Kubernetes để cung cấp tính năng bảo mật và quản lý mạng. * **Tính năng nổi bật**: * **Bảo mật mạng:** Áp dụng Network Policy L3/L4, hỗ trợ Zero Trust Security. * **Quan sát và giám sát:** Theo dõi luồng dữ liệu, phát hiện và khắc phục sự cố mạng. * **Hiệu suất cao:** Xử lý gói tin trực tiếp trong kernel, giảm overhead và tăng tốc độ mạng. * **Hỗ trợ nhiều môi trường:** Chạy trên Kubernetes, OpenShift, bare-metal và cloud. * **Cân bằng tải và NAT:** Tích hợp BGP, IP-in-IP và VXLAN để tối ưu lưu lượng mạng. * **Khả năng mở rộng:** Hỗ trợ multi-cluster, kết nối mạng quy mô lớn và tích hợp với service mesh. ### **3\. Lựa chọn Network Type phù hợp** **Khi nào chọn Cilium?** * Đòi hỏi hiệu năng cao cho các cluster lớn. * Yêu cầu các tính năng Network Policies nâng cao. * Sử dụng eBPF để tối ưu mạng và giám sát chi tiết. **Khi nào chọn Calico?** * Cần hỗ trợ tốt cho Network Policies nhưng không sử dụng eBPF. * Cluster cần hiệu năng cao và bảo mật tốt với Native Routing. **II. Subnet** -------------- ### **1\. Khái niệm** * **Subnet** (mạng con) là một phân đoạn của dải địa chỉ IP trong **Virtual Private Cloud (VPC)** được sử dụng để cung cấp địa chỉ IP cho các tài nguyên trong Kubernetes Cluster, bao gồm các Node. * Đảm bảo các Node trong cluster Kubernetes có thể giao tiếp với nhau qua mạng nội bộ. * Phân vùng địa chỉ mạng để tối ưu hóa việc quản lý mạng trong VPC. ### **2\. Lưu ý khi cấu hình** * **Dải địa chỉ IP** của Subnet phải đủ rộng để chứa toàn bộ Node's CIDR trong cluster. * Subnet nên được thiết kế sao cho không xung đột với các mạng khác trong hệ thống VPC hoặc mạng on-premise (nếu có). * Các Subnet cần tương thích với các vùng (availability zones) mà cluster được triển khai. **III. Node's CIDR** -------------- ### **1\. Tổng quan** * **Node's CIDR** là dải địa chỉ IP được chỉ định cho các Node trong cluster Kubernetes. Mỗi Node trong cluster sẽ được gán một địa chỉ IP từ Node's CIDR. * Đảm bảo mỗi Node có một địa chỉ IP duy nhất để chỉ định cho các pod chạy trên node đó. Điều này giúp tránh xung đột địa chỉ IP giữa các node. Dải địa chỉ này được quản lý bởi Kubernetes hoặc nhà cung cấp dịch vụ cloud (nếu là managed Kubernetes). ### **2\. Lưu ý khi cấu hình** * **Kích thước CIDR của Node**: Kích thước của Node's CIDR phải đủ lớn để đáp ứng số lượng Node tối đa dự kiến trong cluster. Ví dụ: Nếu có 256 Node, Node's CIDR có thể là `/24` (256 địa chỉ IP). * **Không trùng lặp với Subnet hoặc Pod's CIDR**: Địa chỉ Node's CIDR phải nằm trong Subnet nhưng không được trùng lặp với các Pod's CIDR trong cùng một cluster. * **Liên kết Subnet**: Mỗi Node trong cluster phải thuộc về một Subnet cụ thể. Điều này được xác định khi khởi tạo cluster. **IV. Service's CIDR** -------------- ### **1\. Service's CIDR là gì?** * **Service's CIDR** là dải địa chỉ IP được Kubernetes sử dụng để cấp phát địa chỉ IP cho các **Service** trong cluster. * Các Service này cung cấp cách giao tiếp giữa các Pods, giữa Pods và các ứng dụng bên ngoài cluster, hoặc giữa các thành phần trong cluster với nhau. ### **2\. Vai trò của Service's CIDR** * **Service IP**: Mỗi Service trong Kubernetes sẽ được cấp một địa chỉ IP từ Service's CIDR, giúp nó hoạt động như một địa chỉ tĩnh cho các Pods. * **Cluster IP**: Địa chỉ IP của **ClusterIP Service** thuộc Service's CIDR và được sử dụng để giao tiếp nội bộ trong cluster. * Không gian địa chỉ này phải được tách biệt với các CIDR của Subnet, Node, và Pod để tránh xung đột. **V. Pod's CIDR** -------------- ### **1\. Tổng quan** * **Pod's CIDR** là dải địa chỉ IP được sử dụng để cấp phát địa chỉ cho các Pods trong Kubernetes.  * Đảm bảo rằng mỗi dịch vụ có một địa chỉ IP duy nhất trong phạm vi này để có thể truy cập được từ bất kỳ đâu trong cụm. Địa chỉ IP này là tĩnh và không thay đổi, giúp dễ dàng quản lý và định tuyến lưu lượng đến các dịch vụ. * Pod's CIDR được chia nhỏ từ Node's CIDR, nghĩa là mỗi Node sẽ cấp phát một phần địa chỉ IP cho các Pods chạy trên Node đó. ### **2\. Lưu ý khi cấu hình** * **Phân bổ từ Node's CIDR**: Mỗi Node sẽ được gán một dải địa chỉ con từ Pod's CIDR để cấp phát cho các Pods trên Node. Ví dụ: Nếu Pod's CIDR là `/20`, thì mỗi Node có thể được cấp phát một phần nhỏ hơn, như `/24`. * **Kích thước CIDR**: Pod's CIDR cần đủ lớn để đáp ứng tổng số lượng Pods tối đa dự kiến trong cluster, nên Pod's CIDR phải được tính toán dựa trên giới hạn này. * **Không xung đột với Node's CIDR hoặc Service's CIDR**: Địa chỉ IP của Pods phải không trùng với Node hoặc Service để tránh xung đột. **VI. Tương quan giữa Subnet, Node's CIDR,** **Service's CIDR** **và Pod's CIDR** -------------- ### **1. Cách thức phân bổ**: **Subnet:** * Là phạm vi địa chỉ IP tổng thể được chia nhỏ cho các node và dịch vụ. * Subnet có thể bao gồm địa chỉ của **Node’s CIDR, Pod’s CIDR và Service’s CIDR**. * Ví dụ: `10.0.0.0/16` có thể là subnet của toàn bộ cluster. **Node's CIDR:** * Mỗi node trong cluster sẽ được gán một phạm vi CIDR riêng để gán IP cho các pod trên node đó. * Ví dụ: Một node có thể nhận CIDR `10.0.1.0/24` từ subnet `10.0.0.0/16`. * Mỗi node có thể chạy nhiều pod, và pod sẽ nhận IP từ CIDR này. **Pod's CIDR:** * Phạm vi địa chỉ IP dành cho các pod chạy trên một node. * Mỗi node có một **Pod CIDR** riêng biệt (một phần của Node's CIDR). * Ví dụ: Node có CIDR `10.0.1.0/24` có thể gán IP `10.0.1.1`, `10.0.1.2` cho các pod. **Service’s CIDR:** * CIDR dành riêng cho các dịch vụ Kubernetes (Service). * Các IP trong phạm vi này không trực tiếp gán cho pod hay node mà là địa chỉ ảo, giúp load balancing và điều hướng traffic tới pod. * Ví dụ: `10.96.0.0/12` là dải IP cho Service. * * * ### **2\. Tương quan và Cách hoạt động:** * **Subnet** là phạm vi tổng, từ đó phân chia thành các **Node’s CIDR**. * Mỗi node có một **Pod’s CIDR**, pod trong node sẽ nhận IP từ CIDR này. * **Service’s CIDR** là dải IP riêng, tách biệt và hoạt động ở tầng ảo để load balance giữa các pod. * **Khi pod giao tiếp với service**, traffic được chuyển đến pod thông qua địa chỉ service (proxy qua kube-proxy hoặc Cilium/Calico). **Ví dụ cụ thể:** * Subnet tổng: `10.0.0.0/16` * Node's CIDR: `10.0.1.0/24` (Pod trên Node sẽ có IP như `10.0.1.5`) * Service's CIDR: `10.96.0.0/12` (Service IP có thể là `10.96.1.10`) **Các phạm vi CIDR này đảm bảo rằng:** * Pod không bị trùng IP với service hoặc node khác. * Dịch vụ có thể giao tiếp với pod qua proxy (kube-proxy). * Mở rộng quy mô bằng cách thêm node mà không cần thay đổi cấu trúc mạng.