Skip to main content

9.2. Networking - CNI, Service Networking and Network Policies

Mục lục​

1. Khám phá Cluster Networking​

1.1 Bắt đầu từ vấn đề thực tế​

Sáng nay, dev team deploy một ứng dụng mới lên cluster. Pod chạy OK nhưng không kết nối được đến database. Kiểm tra thì thấy:

  • Pod có IP 10.244.1.5.
  • Database service có IP 10.96.0.10.
  • Ping 10.96.0.10 không được.

Câu hỏi: Làm sao Pod giao tiếp với nhau, với Services, và làm sao DNS resolution hoạt động trong cluster?

1.2 Xem Nodes trong Cluster​

Bắt đầu bằng việc xem các node và IP của chúng:

kubectl get nodes -o wide

# Output (minh họa):
# NAME       STATUS   ROLES           AGE   VERSION   INTERNAL-IP    EXTERNAL-IP
# master     Ready    control-plane   6d    v1.28     192.168.1.10   <none>
# worker-1   Ready    <none>           5d    v1.28     192.168.1.11   <none>
# worker-2   Ready    <none>           5d    v1.28     192.168.1.11   <none>

Cột INTERNAL-IP là địa chỉ IP thật của node trên mạng vật lý.

1.3 Xem Interfaces và MAC Addresses​

Xem tất cả interfaces trên node:

ip address
# hoặc viết tắt
ip addr

# Output (minh họa):
# 1: lo: <LOOPBACK,UP> ...
# 2: eth0: <BROADCAST,MULTICAST,UP> inet 192.168.1.11/24
# 3: cni0: <BROADCAST,MULTICAST,UP> inet 10.244.1.1/24

Tìm interface có IP cụ thể:

ip addr show eth0

# Output (minh họa):
# 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state UP
#     link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
#     inet 192.168.1.11/24 brd 192.168.1.255 scope global eth0

MAC address (link/ether) là địa chỉ vật lý duy nhất của card mạng.

1.4 Tìm Bridge Interface​

Container runtime (containerd) sử dụng bridge interface để kết nối containers. Tìm nó:

ip addr show type bridge

# Output (minh họa):
# 3: cni0: <BROADCAST,MULTICAST,UP> mtu 1450
#     inet 10.244.1.1/24

Bridge interface cni0 là bridge được CNI plugin (thường là bridge plugin hoặc host-local) tạo ra. Mỗi node có bridge riêng với dải IP riêng.

1.5 Xem Routing Table​

ip route

# Output (minh họa):
# default via 192.168.1.1 dev eth0
# 10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1
# 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.11

Kiểm tra default gateway:

ip route | grep default

# Output (minh họa):
# default via 192.168.1.1 dev eth0

1.6 Kiểm tra Ports của Control Plane​

Xem các ports đang lắng nghe trên control plane:

netstat -npl

# Output (minh họa - một phần):
# Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
# tcp        0      0 0.0.0.0:6443            0.0.0.0:*               LISTEN      1234/kube-apiserver
# tcp        0      0 127.0.0.1:2379          0.0.0.0:*               LISTEN      2345/etcd
# tcp        0      0 0.0.0.0:10250           0.0.0.0:*               LISTEN      3456/kubelet

Flags hữu ích:

  • -n: Không resolve tên (hiển thị IP/port thay vì hostname).
  • -l: Chỉ hiển thị listening sockets.
  • -p: Hiển thị tên chương trình.

2. Pod Networking trong Kubernetes​

2.1 Các yêu cầu về Pod Networking​

Kubernetes định nghĩa rõ ràng bốn yêu cầu bắt buộc cho Pod networking:

  1. Mỗi Pod có IP duy nhất — không trùng lặp trong cluster.
  2. Pod cùng node giao tiếp qua IP — không cần NAT.
  3. Pod khác node giao tiếp qua IP — không cần NAT.
  4. Không cần NAT — Pod thấy IP thật của đối phương.

💡 Hình dung: IP của Pod giống địa chỉ nhà riêng — không đổi, ai muốn đến đều đến thẳng được. Không có "điểm trung chuyển" thay đổi địa chỉ nguồn/đích.

2.2 Triển khai Pod Networking: Bước 1-4​

Cách CNI plugin thực hiện networking cho Pod:

Bước 1: Tạo Bridge Network trên mỗi Node​

# Tạo bridge network
ip link add name mybridge type bridge
ip link set mybridge up

# Output: (không có output = thành công)

Bước 2: Gán IP cho Bridge​

Mỗi node có bridge với dải IP riêng:

# Trên node 1
ip addr add 10.244.1.1/24 dev mybridge

# Trên node 2
ip addr add 10.244.2.1/24 dev mybridge

# Trên node 3
ip addr add 10.244.3.1/24 dev mybridge

Bước 3: Gắn Container vào Network​

Mỗi khi container mới được tạo, CNI plugin thực hiện:

# Tạo veth pair (virtual cable)
ip link add veth-abc type veth peer name veth-xyz

# Gắn một đầu vào container namespace
ip link set veth-abc netns container-namespace

# Gắn đầu kia vào bridge
ip link set veth-xyz master mybridge
ip link set veth-xyz up

# Gán IP cho container
ip addr add 10.244.1.2/24 dev veth-abc

# Bật interface
ip link set veth-abc up

Bước 4: Thêm Routes để kết nối inter-node​

Pod trên node 1 muốn reach Pod trên node 2:

# Trên node 1, thêm route đến mạng của node 2
ip route add 10.244.2.0/24 via 192.168.1.12

# Trên node 1, thêm route đến mạng của node 3
ip route add 10.244.3.0/24 via 192.168.1.13

2.3 CNI tự động hóa toàn bộ quy trình​

Khi container được tạo, container runtime gọi CNI plugin theo flow:

  1. Container runtime nhận container ID và namespace.
  2. Tìm script/plugin trong CNI bin directory (/opt/cni/bin).
  3. Thực thi plugin với command ADD.
  4. Plugin thực hiện các bước networking (bridge, veth, IP, routes).
  5. Plugin trả về kết quả (IP đã gán, routes đã tạo).
Pod Networking: Mỗi Pod có IP riêng, giao tiếp không cần NATNode 1 (192.168.1.10)Bridge: cni010.244.1.1/24Pod A10.244.1.5Node 2 (192.168.1.11)Bridge: cni010.244.2.1/24Pod B10.244.2.10Route: 10.244.2.0/24 via 192.168.1.11CNI Plugin Flow1. kubelet gọi CNI plugin2. Plugin tạo veth pair3. Gắn vào bridge, gán IP4. Trả về IP đã gánPod A (10.244.1.5) ping Pod B (10.244.2.10) — không cần NAT

3. CNI trong Kubernetes​

3.1 CNI Plugins Directory​

Tất cả CNI plugins được cài đặt tại /opt/cni/bin:

ls /opt/cni/bin

# Output (minh họa):
# bandwidth  bridge  dhcp  flannel  host-local  ipvlan
# loopback   macvlan  portmap  ptp  sample  tuning
# vlan       vrf     windows...

Mỗi file là một executable — plugin thực sự.

3.2 CNI Configuration Directory​

Cấu hình plugin được lưu tại /etc/cni/net.d:

ls /etc/cni/net.d

# Output (minh họa):
# 10-flannel.conflist
# 99-loopback.conf

Runtime sẽ đọc file trong thư mục này để biết plugin nào được sử dụng.

3.3 CNI Configuration File​

File cấu hình CNI có format JSON. Ví dụ 10-mynet.conf:

{
  "cniVersion": "0.2.0",
  "name": "mynet",
  "type": "bridge",
  "bridge": "cni0",
  "isGateway": true,
  "ipMasq": true,
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/16"
  }
}

Giải thích các tham số:​

Tham sốMô tả
typeTên của CNI plugin (bridge, flannel, calico...)
bridgeTên bridge interface được tạo/sử dụng
isGatewayBridge nhận IP để hoạt động như gateway
ipMasqThêm NAT rule cho IP masquerading (ra internet)
ipam.typePlugin quản lý IP address (host-local, dhcp)
subnetDải IP subnet được gán cho pods

3.4 Quy trình khi Pod được tạo​

  1. Kubelet nhận yêu cầu tạo Pod.
  2. Container runtime (containerd) tạo container và network namespace.
  3. Kubelet đọc CNI configuration từ /etc/cni/net.d.
  4. Gọi plugin với command ADD và container ID, namespace.
  5. Plugin thực hiện:
    • Tạo veth pair.
    • Gắn một đầu vào bridge.
    • Gán IP từ dải subnet.
    • Tạo routes cần thiết.
  6. Plugin trả về kết quả (IP đã gán, gateway, DNS...).

3.5 Lab: Kiểm tra CNI Configuration​

Kiểm tra container runtime endpoint:

ps aux | grep -i kubelet | grep -v grep

# Output (minh họa):
# /usr/bin/kubelet --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock ...

Xem plugins có sẵn:

ls /opt/cni/bin

# Output:
# bandwidth  bridge  dhcp  flannel  host-local ...

Kiểm tra plugin cụ thể:

ls /opt/cni/bin | grep -E "bridge|dhcp|vlan|cisco"

# Output:
# bridge
# dhcp

Xem CNI configuration:

cat /etc/cni/net.d/10-flannel.conflist

# Output (minh họa):
# {
#   "name": "cni0",
#   "cniVersion": "0.3.1",
#   "plugins": [
#     {
#       "type": "flannel",
#       "delegate": {
#         "type": "bridge",
#         "bridge": "cni0"
#       }
#     }
#   ]
# }

4. IP Address Management (IPAM)​

4.1 Trách nhiệm của IPAM​

IPAM (IP Address Management) trong Kubernetes quan tâm đến:

  • Dải subnet được gán cho virtual bridge networks trên các nodes.
  • Cách pods được gán IP từ dải đó.
  • Lưu trữ thông tin IP ở đâu (tránh trùng lặp).
  • Đảm bảo không có IP trùng lặp trong cluster.

4.2 CNI và IPAM​

CNI chịu trách nhiệm gán IP cho containers. Có thể:

  • Tự quản lý bằng cách lưu danh sách IP vào file.
  • Sử dụng IPAM plugin có sẵn.

4.3 Host-local Plugin​

Plugin host-local quản lý IP addresses cục bộ trên mỗi host — mỗi node tự quản lý dải IP của nó.

Cấu hình trong CNI config:

{
  "cniVersion": "0.2.0",
  "name": "mynet",
  "type": "bridge",
  "bridge": "cni0",
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/16",
    "routes": [
      {
        "dst": "0.0.0.0/0"
      }
    ]
  }
}

Host-local lưu trữ IP đã sử dụng trong file local — không cần centralized database.

💡 Hình dung: host-local giống "sổ phòng trọ" của từng chủ nhà trọ — mỗi chủ tự ghi ai đang ở phòng nào, không cần hỏi ai.

5. Service Networking​

5.1 Recap: Service là gì?​

Service cung cấp một IP ổn định (ClusterIP) để access Pods, dù Pod IPs thay đổi khi restart.

ClusterIP Service​

  • Được gán một địa chỉ IP ảo từ dải service-cluster-ip-range.
  • Pods khác trong cluster truy cập Service qua IP hoặc tên.
  • Không thể truy cập từ bên ngoài cluster.

NodePort Service​

  • Expose application trên port cố định (30000-32767) trên tất cả nodes.
  • Users truy cập qua: http://<node-ip>:<port>.

LoadBalancer Service​

  • Tích hợp với cloud provider's load balancer.
  • Cung cấp external IP để truy cập từ internet.

5.2 Service IP Address​

IP Range cho Services​

Dải IP cho Services được chỉ định bởi kube-apiserver:

# Kiểm tra trong manifest của kube-apiserver
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep service-cluster-ip-range

# Output:
# --service-cluster-ip-range=10.96.0.0/12

Mặc định: 10.96.0.0/12 — cung cấp khoảng 1 triệu IP cho Services.

Cách Service nhận IP​

Khi Service được tạo:

  1. Kubernetes gán IP từ dải service-cluster-ip-range.
  2. IP này là virtual — không có interface thật nào mang IP này.
  3. kube-proxy tạo rules để forward traffic đến backend Pods.

5.3 Kube-proxy​

Kube-proxy chạy trên mỗi node (DaemonSet) và theo dõi changes qua kube-apiserver. Khi Service được tạo, kube-proxy tạo forwarding rules.

Các Proxy Modes​

ModeMô tảƯu điểmNhược điểm
userspacekube-proxy lắng nghe port, tự proxy traffic đến pods ở user spaceTương thích caoRất chậm, gần như không còn ai dùng
iptables (mặc định)Tạo iptables rules cho forwardingNhanh, stableKhó debug, rules phình to khi cluster có nhiều Service
ipvs (deprecated)Dùng IPVS — IP Virtual Server, module cân bằng tải chạy ở tầng kernel Linux (cùng công nghệ đứng sau LVS) — để forward trafficRất nhanh, hỗ trợ nhiều thuật toán load balancingCần kernel module riêng; đã bị đánh dấu deprecated, khuyến nghị chuyển sang nftables
nftablesTạo nftables rules cho forwarding — framework kế thừa iptables trong kernel Linux, cú pháp gọn và hiệu năng tốt hơnNhanh hơn iptables đáng kể ở cluster lớn, đã GA (ổn định)Chưa phải default, phải khai báo --proxy-mode=nftables thủ công

Từ Kubernetes 1.35, chế độ ipvs chính thức bị đánh dấu deprecated — nftables được chọn làm hướng thay thế lâu dài vì vừa giải quyết vấn đề hiệu năng của iptables (rules dạng linked-list, chậm dần khi số Service tăng), vừa tránh được các bug tồn đọng của ipvs. nftables đã GA từ Kubernetes 1.33, nhưng vì lý do tương thích ngược, iptables vẫn giữ vai trò default — cluster phải khai báo tường minh để chuyển sang nftables.

5.4 Xem Service Rules trong iptables​

# Xem tất cả NAT rules liên quan đến Service
iptables -t nat -L -n | grep KUBE-SERVICES

# Output (minh họa):
# KUBE-SERVICES  tcp  --  0.0.0.0/0  10.96.0.10  tcp dpt:80

Xem chi tiết rule cho một Service cụ thể:

iptables -t nat -L -n | grep <service-name>

# Output (minh họa):
# K8S-SVC-ABCD1234  tcp  --  anywhere  10.103.132.104  tcp dpt:3306
#   DNAT  tcp  --  anywhere  anywhere  to:10.244.1.2:3306

Traffic đến Service IP 10.103.132.104:3306 sẽ được DNAT (Destination NAT) đến Pod IP 10.244.1.2:3306.

5.5 NodePort Service Rules​

Khi tạo NodePort Service, kube-proxy tạo rules để forward traffic từ port trên node đến backend Pods:

iptables -t nat -L -n | grep NODEPORT

# Output (minh họa):
# KUBE-NODEPORT-ABCD  tcp  --  0.0.0.0/0  0.0.0.0:30080  tcp dpt:30080
#   DNAT  tcp  --  192.168.1.0/24  anywhere  tcp dpt:30080 to:10.244.1.2:80

5.6 Lab: Kiểm tra Service Networking​

Xem IP Range của Pods:

# Kiểm tra logs của network addon (ví dụ: Weave Net)
kubectl logs <weave-pod-name> -n kube-system | grep IPALLOC

# Output (minh họa):
# INFO [weave] IPALLOC_RANGE=10.244.0.0/16

Xem IP Range của Services:

cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep service-cluster-ip-range

# Output:
# --service-cluster-ip-range=10.96.0.0/12

Kiểm tra Kube-proxy Pods:

kubectl get pods -n kube-system | grep kube-proxy

# Output (minh họa):
# kube-proxy-abcde   1/1     Running   0   5d
# kube-proxy-fghij   1/1     Running   0   5d

Xem proxy mode:

kubectl logs <kube-proxy-pod-name> -n kube-system | grep -i "using"

# Output (minh họa):
# I0910 08:00:00  kube-proxy.go:123 using iptables proxy

Kube-proxy được triển khai như DaemonSet để đảm bảo nó chạy trên mọi nodes trong cluster.

Service Networking: kube-proxy tạo iptables rulesService (ClusterIP)10.96.0.10:80(virtual IP - không có interface)Pod A10.244.1.2:80Pod B10.244.1.5:80kube-proxy iptables rules:# iptables -t nat -L -n | grep my-svcK8S-SVC-XXX tcp -- 0.0.0.0/0 10.96.0.10 tcp dpt:80 DNAT tcp -- anywhere anywhere to:10.244.1.2:80 DNAT tcp -- anywhere anywhere to:10.244.1.5:80

6. DNS trong Kubernetes Cluster​

6.1 DNS Records cho Services​

Khi Service được tạo, Kubernetes DNS service tạo record ánh xạ service name đến IP.

Cấu trúc DNS Name đầy đủ​

<service-name>.<namespace>.svc.cluster.local

Ví dụ: Service web-service trong namespace default:

web-service.default.svc.cluster.local

Địa chỉ trong cùng Namespace​

Pods trong cùng namespace có thể truy cập service chỉ bằng tên:

kubectl exec -it <pod-name> -- curl http://web-service

# Output (minh họa):
# <!DOCTYPE html>
# <html>...

Địa chỉ từ Namespace khác​

kubectl exec -it <pod-name> -- curl http://web-service.apps

# Hoặc đầy đủ:
kubectl exec -it <pod-name> -- curl http://web-service.apps.svc.cluster.local

6.2 DNS Records cho Pods​

Tạo Records cho Pods​

Theo mặc định, records cho pods không được tạo. Có thể enable tính năng này trong CoreDNS configuration.

Format Pod DNS Name​

Khi enabled, Kubernetes tạo hostname từ IP:

  • Thay dots bằng dashes.
  • Thêm namespace và type.

Ví dụ: Pod IP 10.244.1.5 trở thành:

# DNS name của Pod
10-244-1-5.default.pod.cluster.local

6.3 Search Entries trong /etc/resolv.conf​

File /etc/resolv.conf trên pods có các search entries:

kubectl exec -it <pod-name> -- cat /etc/resolv.conf

# Output (minh họa):
# nameserver 10.96.0.10
# search default.svc.cluster.local svc.cluster.local cluster.local
# options ndots:5

Điều này cho phép tìm service bằng nhiều cách:

  • web-service.
  • web-service.default.
  • web-service.default.svc.
  • web-service.default.svc.cluster.local.

💡 Hình dung: DNS search path giống "danh sách hậu tố tự động" — khi bạn nói "web-service", máy tự thử thêm ".default.svc.cluster.local" nếu không tìm thấy đâu.

7. Network Policies trong Kubernetes​

7.1 Vấn đề: mặc định mọi Pod đều thấy nhau​

Quay lại tình huống mở đầu tài liệu này: Pod của dev team không kết nối được đến database. Giả sử lần này ngược lại — Pod kết nối được đến database, nhưng lại kết nối được đến cả những Service không liên quan gì đến nó, ví dụ một Pod frontend tình cờ query thẳng được vào database của team khác trong cùng cluster. Đó không phải bug, mà là hành vi mặc định của Kubernetes: mọi Pod có thể giao tiếp với mọi Pod khác trong cluster, không cần khai báo gì thêm — network flat, không có tường ngăn nào giữa các namespace hay các nhóm Pod.

Trong môi trường nhiều team chia sẻ chung một cluster, đây là rủi ro bảo mật thực sự: một Pod bị compromise có thể quét (scan) toàn bộ mạng nội bộ cluster mà không gặp cản trở nào. NetworkPolicy là cơ chế Kubernetes dùng để giải quyết đúng vấn đề này — kiểm soát Pod nào được phép giao tiếp với Pod nào.

7.2 NetworkPolicy là gì?​

NetworkPolicy là một Kubernetes object, hoạt động giống một tập firewall rule gắn theo label thay vì gắn theo địa chỉ IP. Thay vì nói "chặn traffic từ IP X", NetworkPolicy nói "chỉ cho phép traffic từ Pod có label role: frontend" — vì IP của Pod luôn đổi mỗi khi Pod bị tạo lại, còn label thì ổn định theo vai trò.

Một NetworkPolicy gồm ba phần chính:

  • podSelector: chọn nhóm Pod mà policy này áp dụng lên (Pod "mục tiêu" cần được bảo vệ).
  • policyTypes: policy này kiểm soát chiều Ingress (traffic đi vào Pod mục tiêu), Egress (traffic đi ra từ Pod mục tiêu), hay cả hai.
  • ingress/egress rules: danh sách traffic được phép — theo Pod (podSelector), theo namespace (namespaceSelector), hoặc theo dải IP (ipBlock).

💡 Hình dung: NetworkPolicy giống danh sách khách mời gắn ở cổng một khu chung cư riêng — bảo vệ không kiểm tra CMND hay biển số xe (địa chỉ IP, vì nó đổi liên tục), mà kiểm tra thẻ nhân viên (label) của người đến. Chỉ ai có đúng loại thẻ được ghi trong danh sách mới qua được cổng, còn lại đứng ngoài — bất kể họ đi xe gì hay từ đâu tới.

Một điểm quan trọng dễ hiểu nhầm: nếu một Pod không được podSelector của bất kỳ NetworkPolicy nào chọn trúng, Pod đó vẫn giữ hành vi mặc định — cho phép tất cả. NetworkPolicy chỉ bắt đầu giới hạn traffic kể từ khi có ít nhất một policy chọn trúng Pod đó.

7.3 Viết NetworkPolicy: mẫu default-deny​

Cách tiếp cận an toàn nhất — và cũng là điểm khởi đầu khuyến nghị cho mọi namespace nhạy cảm — là default-deny: chặn hết mọi traffic trước, rồi mới mở từng luồng cần thiết. Một podSelector: {} rỗng nghĩa là "áp dụng cho tất cả Pod trong namespace này":

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Policy này không có bất kỳ rule ingress/egress nào bên trong — nghĩa là với mọi Pod trong namespace default, không traffic nào (cả chiều vào lẫn chiều ra) được phép, trừ khi có policy khác mở thêm.

7.4 Cho phép traffic có chọn lọc​

Ví dụ thực tế hơn: một database Pod (label role: db) chỉ nên nhận traffic từ đúng API Pod (label role: api), qua đúng port 3306:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-allow-api
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api
    ports:
    - protocol: TCP
      port: 3306

podSelector ở cấp spec (mục tiêu cần bảo vệ) chọn Pod có role: db. from.podSelector bên trong rule ingress (nguồn được phép) chọn Pod có role: api. Hai podSelector này độc lập nhau — dễ đọc nhầm là cùng một selector nếu đọc lướt.

Muốn cho phép traffic từ một namespace khác thay vì từ Pod cụ thể, dùng namespaceSelector (namespace đích phải có label tương ứng, ví dụ kubectl label namespace prod team=backend):

  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          team: backend

Áp dụng policy rồi kiểm tra lại bằng kubectl describe:

kubectl apply -f db-allow-api.yaml
kubectl describe networkpolicy db-allow-api

# Output minh họa
Name:         db-allow-api
Namespace:    default
Spec:
  PodSelector:     role=db
  Allowing ingress traffic:
    To Port: 3306/TCP
    From:
      PodSelector: role=api
  Policy Types: Ingress

(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, số liệu cụ thể chỉ mang tính ví dụ.) Field PodSelector ở đầu output chính là Pod mục tiêu được bảo vệ; mục From bên dưới Allowing ingress traffic mới là nguồn được phép — đọc đúng thứ tự này giúp tránh nhầm lẫn hai selector nói ở trên.

7.5 Điều kiện để NetworkPolicy thực sự có hiệu lực: vai trò của CNI plugin​

Đây là điểm dễ gây bối rối nhất khi mới làm quen với NetworkPolicy: bản thân Kubernetes API không enforce NetworkPolicy — kube-apiserver chỉ lưu object đó lại, còn việc thực sự chặn/cho phép packet là trách nhiệm của CNI plugin đang chạy trên cluster. Nếu CNI plugin không hỗ trợ NetworkPolicy, object vẫn được tạo thành công, kubectl get networkpolicy vẫn hiển thị nó bình thường, nhưng traffic không hề bị chặn — một trạng thái im lặng, dễ gây ảo tưởng an toàn.

CNI đơn giản kiểu bridge/host-local hay Flannel thuần (loại đã dùng xuyên suốt các lab trong tài liệu này, xem §3) không enforce NetworkPolicy. Các CNI plugin hỗ trợ đầy đủ gồm Calico, Cilium, và Weave Net. Vì vậy, trước khi tin tưởng một NetworkPolicy đang thực sự bảo vệ cluster, luôn cần xác nhận CNI đang dùng có hỗ trợ tính năng này không:

kubectl get pods -n kube-system

# Output minh họa — cụm dùng Calico (có enforcement)
NAME                    READY   STATUS    RESTARTS   AGE
calico-node-4f8k2       1/1     Running   0          5d
calico-node-9j3lm       1/1     Running   0          5d
coredns-5d8c9b8b7f-abc  1/1     Running   0          5d

(Output minh họa — cấu trúc đúng theo lệnh thật, số liệu cụ thể chỉ mang tính ví dụ.) Thấy Pod calico-node/cilium/weave-net trong kube-system là tín hiệu CNI đang dùng có enforce NetworkPolicy; chỉ thấy kube-flannel mà không có gì khác thì NetworkPolicy vừa tạo sẽ không có tác dụng thực tế.

NetworkPolicy db-allow-api: chỉ Pod role=api mới vào được DBPod api-1role: apiPod frontend-1role: frontendPod ngoài team khácrole: (không khớp)Pod db-1role: db — target podSelectorport 3306Được phép (podSelector khớp)Bị chặn (label/namespace khác)Enforcement do CNI plugin đảm nhiệm (Calico/Cilium/Weave)Flannel/bridge thuần: policy được tạo nhưng không có tác dụng

Nguồn tham khảo​

Nguồn gốc: Khóa "Certified Kubernetes Administrator (CKA)" — phần "Networking" (Pod Networking, CNI trong Kubernetes, IP Address Management, Service Networking, DNS trong Cluster, Network Policies), nền tảng KodeKloud. Giảng viên: Mumshad Mannambeth.

Repo ghi chú, link tài liệu, và đáp án các practice question của toàn bộ khóa học: kodekloudhub/certified-kubernetes-administrator-course.

Fact-check:

  • kube-proxy có thêm mode nftables, đã GA (ổn định) từ Kubernetes v1.33 nhưng chưa phải default — iptables vẫn là default mode ở v1.37 — 2026-09-23, NFTables mode for kube-proxy.
  • Mode ipvs của kube-proxy chính thức deprecated từ Kubernetes v1.35 theo KEP-5495 (feature gate dự kiến Default: false ở v1.40, khoá hẳn ở v1.43), nftables là hướng thay thế được khuyến nghị — 2026-09-23, KEP-5495: Deprecate ipvs mode in kube-proxy.
  • Dải Service ClusterIP mặc định của kubeadm là 10.96.0.0/12, cấu hình qua flag --service-cluster-ip-range của kube-apiserver — 2026-09-23, Kubernetes Service concept.
  • NetworkPolicy chỉ có hiệu lực nếu CNI plugin hỗ trợ enforce (Calico, Cilium, Weave Net); CNI dạng bridge/host-local hoặc Flannel thuần không enforce — object vẫn tạo được nhưng không chặn traffic — 2026-09-23, Kubernetes: Network Policies.
  • Mặc định, Pod không bị bất kỳ NetworkPolicy nào chọn trúng (podSelector) vẫn cho phép tất cả traffic (allow-all); cách an toàn để siết chặt namespace là tạo policy podSelector: {} không kèm rule (default-deny) — 2026-09-23, Kubernetes: Network Policies — Default policies.