CNI là gì?

CNI (Container Network Interface) là một dự án của Cloud Native Computing Foundation (CNCF) bao gồm specification và libraries để cấu hình network interfaces trong Linux containers. CNI chỉ tập trung vào hai việc:

• Kết nối network cho container khi được tạo
• Dọn dẹp network khi container bị xóa

CNI không quản lý DNS, service discovery, hay load balancing - đó là việc của các thành phần khác trong Kubernetes.

Kubernetes Network Model

Kubernetes đặt ra các yêu cầu cơ bản cho networking:

1. Mỗi Pod có một IP duy nhất trong toàn cluster
2. Pod trên mọi node có thể giao tiếp với nhau KHÔNG cần NAT
3. Agents trên node (kubelet, system daemons) có thể giao tiếp với tất cả Pod trên node đó

Nghe đơn giản, nhưng triển khai thực tế rất khác nhau tùy cloud provider. Hãy xem GKE và AWS EKS giải quyết bài toán này như thế nào.

GKE: Routes-Based vs VPC-Native

Google Kubernetes Engine cung cấp hai chế độ networking:

Routes-Based Mode

Đặc điểm:

• Mỗi node nhận một dải /24 riêng (~254 Pod IPs per node)
• Pod IPs không được đăng ký trong VPC - chúng chỉ tồn tại ở mức node
• GKE tự động tạo routes giữa các node dựa trên Pod CIDR
• Traffic cross-node đi qua node IP rồi được forward đến Pod

Networking bên trong node: Pods có network namespace riêng biệt. Node kết nối với Pod qua veth pair, tất cả veth interfaces kết nối vào bridge cbr0 (Layer 2).

VPC-Native Mode (Khuyến nghị)

VPC-Native sử dụng Alias IP Ranges - một network interface có thể có nhiều IP ranges. Ưu điểm so với Routes-Based:

VPC-Native mode không có nhược điểm so với Routes-Based. Google khuyến nghị luôn sử dụng VPC-Native.

AWS EKS: VPC CNI

AWS EKS sử dụng Amazon VPC CNI - cách tiếp cận hoàn toàn khác: mỗi Pod nhận một IP thực từ VPC subnet.

Kiến trúc

Hai thành phần chính

1. CNI Binary - chạy trên root filesystem của node:

• Được kubelet gọi khi Pod được tạo/xóa
• Cấu hình network cho Pod (veth pair, route, ARP)
• Sử dụng kỹ thuật /32 IP + link-local gateway 169.254.1.1

2. ipamd (IP Address Management Daemon) - chạy liên tục trên mỗi node:

• Quản lý các ENI (Elastic Network Interface) trên node
• Duy trì warm pool các IP address sẵn sàng gán cho Pod
• Tự động request thêm ENI/IP khi pool cạn

Pod networking bên trong node

Pod Network Namespace:
+--------------------------------------+
|  eth0: 172.31.23.163/32              |
|                                      |
|  Route table:                        |
|  default via 169.254.1.1 dev eth0    |
|  169.254.1.1 dev eth0 scope link     |
|                                      |
|  ARP:                                |
|  169.254.1.1 -> MAC(veth_host_side)  |
+--------------------------------------+

Nhận ra pattern này chưa? Đây chính xác là kỹ thuật Secondary IP với Link-Local Gateway mà chúng ta đã thực hành trong bài Container Networking from Scratch!

Giới hạn

Số Pod trên mỗi node bị giới hạn bởi instance type:

Max Pods = (Số ENI tối đa) x (Số IP mỗi ENI - 1)

Ví dụ t3.medium:
  3 ENIs x (6 IPs - 1) = 15 Pods

Ví dụ m5.xlarge:
  4 ENIs x (15 IPs - 1) = 56 Pods

Security Groups cho Pods

GKE: Firewall Rules

GKE sử dụng VPC Firewall Rules với các thành phần:

Với VPC-Native mode, firewall rules có thể target specific pod IP ranges thay vì toàn bộ node - giúp security granular hơn nhiều.

AWS EKS: Security Groups for Pods

AWS cho phép gán security group riêng cho từng Pod (không chỉ cho node). Cơ chế này sử dụng trunk ENI:

Kích hoạt bằng cách set ENABLE_POD_ENI=true trên VPC CNI, sau đó tạo SecurityGroupPolicy CRD:

apiVersion: vpcresources.k8s.aws/v1beta1
kind: SecurityGroupPolicy
metadata:
  name: my-security-group-policy
  namespace: my-namespace
spec:
  podSelector:
    matchLabels:
      role: my-role
  securityGroups:
    groupIds:
      - sg-0123456789abcdef0

Mỗi Pod với label matching sẽ nhận ENI riêng với security group chỉ định, thay vì dùng chung ENI với node.

So sánh các CNI phổ biến

CNI Performance Benchmarking

Khi chọn CNI, performance là yếu tố quan trọng. Methodology benchmark bao gồm:

1. Preparation - Setup nodes, Kubernetes, CNI
2. Idle Performance - CPU/memory overhead sau khi cài CNI
3. Pod-to-Pod TCP Bandwidth - Single stream và multiple streams (8 threads)
4. Pod-to-Pod UDP Bandwidth - Single stream và multiple streams
5. Pod-to-Service TCP/UDP Bandwidth - Qua kube-proxy (iptables vs IPVS)

Các cấu hình thường được so sánh:

• Calico + kube-proxy + iptables: Setup phổ biến nhất
• Calico + kube-proxy + IPVS: Tốt hơn khi có nhiều Services
• Cilium + eBPF: Thay thế hoàn toàn kube-proxy, performance cao nhất

Tham khảo chi tiết: Benchmark Kubernetes Network Plugins over 40Gbit/s (2024)

Tổng kết

Tiếp theo

• Container Networking from Scratch - Tự tay xây dựng networking từ veth pair đến CNI plugin
• AWS VPC CNI Deep Dive - ENIs, trunk networking, và policy routing trên AWS

Tài nguyên tham khảo

• Kubernetes Networking Model
• CNI Specification
• GKE VPC-Native Clusters
• AWS VPC CNI Plugin
• Cilium Documentation
• Benchmark: Kubernetes Network Plugins over 40Gbit/s