Container Networking: Docker และ Kubernetes Network สำหรับ DevOps
Container Networking เป็นหัวใจสำคัญของ containerized applications ที่ DevOps ต้องเข้าใจ เมื่อ applications ถูก deploy เป็น containers (Docker) หรือ orchestrated ด้วย Kubernetes networking จะซับซ้อนกว่า traditional VM networking มาก เพราะ containers มีจำนวนมาก (หลายร้อย-หลายพัน) สร้างและทำลายตลอดเวลา IP address เปลี่ยนแปลงบ่อย
บทความนี้จะอธิบาย Docker networking ตั้งแต่พื้นฐาน (bridge, host, overlay) และ Kubernetes networking (Pod networking, Services, Ingress, CNI plugins) เพื่อให้ network engineers และ DevOps เข้าใจและทำงานร่วมกันได้
Docker Networking
Network Drivers
| Driver | ลักษณะ | เหมาะกับ |
|---|---|---|
| bridge | Default, isolated network บน host เดียว | Containers บน host เดียวที่ต้องคุยกัน |
| host | Container ใช้ network ของ host โดยตรง | Performance สูงสุด ไม่ต้องการ isolation |
| overlay | Network ข้าม hosts (multi-host) | Docker Swarm, containers บนหลาย hosts |
| macvlan | Container ได้ MAC address และ IP บน physical network | Legacy apps ที่ต้องการเหมือนอยู่บน LAN |
| none | ไม่มี networking | Containers ที่ไม่ต้องการ network |
Bridge Network (Default)
Bridge network สร้าง virtual bridge (docker0) บน host containers ที่อยู่บน bridge เดียวกันคุยกันได้ผ่าน bridge containers เข้าถึง internet ผ่าน NAT (iptables MASQUERADE) เปิด port ให้ภายนอกเข้าถึงด้วย -p flag (port mapping) เช่น -p 8080:80 map host port 8080 ไป container port 80
User-Defined Bridge
สร้าง custom bridge network ด้วย docker network create ดีกว่า default bridge เพราะ containers คุยกันด้วย container name ได้ (DNS resolution) มี isolation ดีกว่า (containers ต่าง network คุยกันไม่ได้) สามารถกำหนด subnet, gateway ได้เอง
Kubernetes Networking
Networking Model
Kubernetes มี 4 networking requirements ที่ CNI plugin ต้อง implement: Pod-to-Pod: ทุก Pod คุยกันได้โดยไม่ต้อง NAT (flat network) Pod-to-Service: Pods เข้าถึง Services ผ่าน ClusterIP Container-to-Container: Containers ใน Pod เดียวกันคุยผ่าน localhost External-to-Service: Traffic จากภายนอกเข้า cluster ผ่าน NodePort, LoadBalancer หรือ Ingress
Pod Networking
แต่ละ Pod ได้รับ IP address ของตัวเอง (ไม่ซ้ำกันใน cluster) Containers ใน Pod เดียวกัน share network namespace (คุยผ่าน localhost) Pods บน Node เดียวกันคุยผ่าน virtual bridge (cbr0) Pods บนต่าง Node คุยผ่าน overlay network หรือ routing ขึ้นอยู่กับ CNI plugin
Kubernetes Services
| Service Type | ลักษณะ | เหมาะกับ |
|---|---|---|
| ClusterIP | Internal IP ภายใน cluster เท่านั้น | Internal services (DB, cache, API internal) |
| NodePort | เปิด port บนทุก Node (30000-32767) | Development, testing |
| LoadBalancer | สร้าง external load balancer (cloud) | Production services บน cloud (AWS ELB, GCP LB) |
| ExternalName | DNS CNAME ไปยัง external service | Integrate กับ services นอก cluster |
Ingress
Ingress เป็น L7 load balancer สำหรับ HTTP/HTTPS traffic route traffic ตาม hostname หรือ URL path ไปยัง Services ที่ต่างกัน SSL/TLS termination ที่ Ingress ตัวอย่าง: api.example.com → API Service, app.example.com → Frontend Service Ingress Controllers ยอดนิยม: Nginx Ingress, Traefik, HAProxy, Istio Gateway
CNI Plugins เปรียบเทียบ
| CNI Plugin | Networking | Network Policy | จุดเด่น |
|---|---|---|---|
| Calico | BGP routing / VXLAN overlay | ใช่ (ดีมาก) | Performance ดี security ดี นิยมที่สุด |
| Flannel | VXLAN overlay | ไม่ (ต้องใช้ Calico เสริม) | ง่ายที่สุด เหมาะกับเริ่มต้น |
| Cilium | eBPF-based | ใช่ (L3-L7) | Performance สูงสุด observability ดี |
| Weave Net | VXLAN overlay + encryption | ใช่ | Encrypted overlay ง่าย |
| AWS VPC CNI | VPC native (ENI) | ใช่ (Security Groups) | AWS native performance ดี |
Network Policies
Micro-segmentation สำหรับ Kubernetes
Network Policy คือ firewall rules สำหรับ Pods กำหนดว่า Pod ไหนคุยกับ Pod ไหนได้ ตาม labels, namespaces, IP blocks default: ทุก Pod คุยกันได้ (ไม่ปลอดภัย) ใช้ Network Policy จำกัดให้เฉพาะ traffic ที่จำเป็น เช่น: frontend Pods คุยกับ backend Pods ได้เท่านั้น backend Pods คุยกับ database Pods ได้เท่านั้น database Pods ไม่รับ traffic จาก frontend โดยตรง
Service Mesh
Istio / Linkerd
Service Mesh เป็น infrastructure layer สำหรับ service-to-service communication ให้ mTLS (mutual TLS) encryption ระหว่าง services อัตโนมัติ traffic management (canary deployments, circuit breakers, retries) observability (distributed tracing, metrics, logging) Istio เป็น service mesh ที่นิยมที่สุด Linkerd เป็นทางเลือกที่เบากว่า
Docker vs Kubernetes Networking
| คุณสมบัติ | Docker (standalone) | Kubernetes |
|---|---|---|
| IP Assignment | Per container | Per Pod |
| Service Discovery | Docker DNS (container name) | CoreDNS (service name.namespace) |
| Load Balancing | Docker Swarm / manual | kube-proxy (iptables/IPVS) |
| External Access | Port mapping (-p) | NodePort / LoadBalancer / Ingress |
| Network Policy | ไม่มี built-in | NetworkPolicy resource + CNI |
| Multi-host | overlay (Swarm) | CNI plugins (Calico, Flannel, Cilium) |
ทิ้งท้าย: Container Networking ต้องเข้าใจ
Container Networking เป็นทักษะที่ DevOps และ Network Engineers ต้องมี เริ่มจาก Docker bridge networking แล้วขยายไป Kubernetes Pod networking, Services, Ingress เลือก CNI plugin ที่เหมาะสม (Calico สำหรับ general use, Cilium สำหรับ performance) ใช้ Network Policies สำหรับ security
อ่านเพิ่มเติมเกี่ยวกับ Network Virtualization และ Cloud Networking ที่ siamlancard.com หรือจาก icafeforex.com และ siam2r.com
