Container Networking: เครือข่ายสำหรับ Docker และ Kubernetes ในองค์กร

Container Networking: เครือข่ายสำหรับ Docker และ Kubernetes ในองค์กร

เมื่อองค์กรเริ่มใช้ Docker และ Kubernetes ในการ deploy application สิ่งที่ซับซ้อนที่สุดไม่ใช่การสร้าง container แต่เป็นการจัดการ networking ให้ container หลายร้อยหลายพัน instance สามารถสื่อสารกันได้อย่างถูกต้อง ปลอดภัย และมีประสิทธิภาพ Container Networking เป็นหัวข้อที่ Network Engineer และ DevOps ทุกคนต้องเข้าใจ เพราะมันเป็นรากฐานของ microservices architecture ยุคใหม่

จากรายงานของ CNCF (Cloud Native Computing Foundation) ปี 2025 พบว่า 96% ขององค์กรใช้หรือกำลังประเมิน Kubernetes และ networking เป็นปัญหาอันดับ 2 ที่พบบ่อยที่สุด (รองจาก security) การเข้าใจ container networking จึงเป็นทักษะที่จำเป็นอย่างยิ่ง

บทความนี้จะอธิบาย Container Networking ตั้งแต่พื้นฐานของ Docker networking, Kubernetes networking model, CNI plugins ยอดนิยม ไปจนถึง Service Mesh และ best practices สำหรับองค์กรที่กำลัง adopt container technology

พื้นฐาน Docker Networking

ก่อนจะเข้าใจ Kubernetes networking ต้องเข้าใจ Docker networking ก่อน เพราะ Kubernetes ทำงานอยู่บน container runtime (มักเป็น containerd ที่พัฒนาจาก Docker) หลักการ networking พื้นฐานจึงคล้ายกัน

Docker Network Drivers

Docker มี network driver หลักๆ 5 แบบ bridge เป็น default driver สร้าง virtual bridge (docker0) บน host container ที่ใช้ bridge เดียวกันสามารถคุยกันได้ผ่าน IP แต่จากภายนอกต้อง port mapping host ใช้ network stack ของ host โดยตรง ไม่มี isolation แต่ performance ดีที่สุด overlay สร้าง network ข้าม host หลายเครื่อง ใช้ VXLAN encapsulation จำเป็นสำหรับ Docker Swarm และ multi-host setups macvlan ให้ container มี MAC address เป็นของตัวเอง ปรากฏบน physical network เหมือนเครื่องจริง none ไม่มี networking เลย ใช้สำหรับ container ที่ไม่ต้องการ network access

Container-to-Container Communication

เมื่อ container หลายตัวต้องคุยกัน (เช่น web app กับ database) Docker ให้ใช้ user-defined bridge network แทน default bridge เพราะมี built-in DNS resolution สามารถเรียกชื่อ container แทน IP ได้ เช่น container ชื่อ “web” สามารถเชื่อมต่อ database ด้วย hostname “db” ได้เลย ไม่ต้องรู้ IP ทำให้ configuration ง่ายและไม่ต้อง hardcode IP ที่อาจเปลี่ยนทุกครั้งที่ container restart

Kubernetes Networking Model

Kubernetes มี networking model ที่แตกต่างจาก Docker อย่างมาก Kubernetes กำหนดกฎ 3 ข้อที่ CNI plugin ทุกตัวต้องทำตาม

The Kubernetes Networking Rules

กฎข้อแรก ทุก Pod สามารถสื่อสารกับทุก Pod อื่นได้โดยไม่ต้อง NAT ไม่ว่า Pod จะอยู่บน Node เดียวกันหรือต่าง Node ก็ตาม กฎข้อสอง ทุก Node สามารถสื่อสารกับทุก Pod ได้โดยไม่ต้อง NAT กฎข้อสาม IP ที่ Pod เห็นตัวเองเป็น IP เดียวกับที่ Pod อื่นเห็น ไม่มี hidden NAT กฎเหล่านี้ทำให้ Kubernetes networking model เรียบง่ายจากมุมมองของ application เพราะทุก Pod มี routable IP เป็นของตัวเอง

Services: การ expose application

Kubernetes Service เป็น abstraction layer ที่ให้ stable IP address และ DNS name สำหรับกลุ่มของ Pods ที่ทำงานเหมือนกัน มี 4 ประเภท ClusterIP expose ภายใน cluster เท่านั้น ใช้สำหรับ internal communication NodePort expose บน port ของทุก Node เข้าถึงได้จากภายนอก cluster LoadBalancer สร้าง cloud load balancer ภายนอก ใช้กับ cloud provider ExternalName map service ไปยัง DNS name ภายนอก ใช้สำหรับเชื่อมต่อ external services

Ingress: HTTP/HTTPS Routing

Ingress เป็น resource ที่จัดการ external HTTP/HTTPS access เข้าสู่ services ภายใน cluster ทำหน้าที่เหมือน reverse proxy ที่ route traffic ตาม hostname หรือ URL path ไปยัง service ที่ถูกต้อง ตัวอย่างเช่น api.example.com ไปที่ api service และ web.example.com ไปที่ frontend service Ingress Controller ที่นิยมใช้ เช่น NGINX Ingress, Traefik, HAProxy Ingress หรือ Istio Gateway

ตารางเปรียบเทียบ CNI Plugins ยอดนิยม

CNI Plugins: เลือกตัวไหนดี

CNI (Container Network Interface) เป็นมาตรฐานที่กำหนดว่า plugin จะจัดการ networking ให้ Pod ในแต่ละ Kubernetes อย่างไร การเลือก CNI plugin ที่เหมาะสมเป็นการตัดสินใจที่สำคัญมาก เพราะเปลี่ยนทีหลังยาก

Calico: ตัวเลือกยอดนิยมอันดับ 1

Calico เป็น CNI plugin ที่ได้รับความนิยมมากที่สุด ใช้ BGP routing แทน overlay ทำให้ performance สูงกว่า VXLAN-based solutions อย่างเห็นได้ชัด Network Policy ของ Calico ทรงพลังมาก รองรับทั้ง Kubernetes NetworkPolicy มาตรฐาน และ Calico-specific policies ที่ละเอียดกว่า เช่น กำหนด policy ตาม namespace, label, port, protocol หรือแม้แต่ CIDR range ได้ เหมาะสำหรับ production cluster ที่ต้องการ performance และ security

Cilium: eBPF-powered Networking

Cilium ใช้ eBPF (extended Berkeley Packet Filter) ซึ่งเป็นเทคโนโลยีใน Linux kernel ทำให้ networking operations ทำงานใน kernel space โดยตรง ไม่ต้องผ่าน iptables ผลลัพธ์คือ performance ที่ดีเยี่ยมและ observability ที่ลึกมาก Cilium สามารถ enforce policy ได้ถึง L7 (application layer) เช่น อนุญาตเฉพาะ HTTP GET ไปยัง /api/v1 เท่านั้น นอกจากนี้ Hubble (observability platform ของ Cilium) ให้ visibility เข้าถึง service communication ทั้งหมดโดยไม่ต้อง instrument code

Service Mesh: Networking สำหรับ Microservices

เมื่อ microservices มีจำนวนมากขึ้น การจัดการ communication ระหว่าง services กลายเป็นเรื่องซับซ้อน Service Mesh เข้ามาแก้ปัญหานี้

Service Mesh คืออะไร

Service Mesh เป็น infrastructure layer ที่จัดการ service-to-service communication โดยใส่ sidecar proxy (มักเป็น Envoy) ข้างทุก Pod proxy เหล่านี้จัดการ traffic routing, load balancing, mTLS encryption, retry, timeout, circuit breaking ให้โดยอัตโนมัติ application code ไม่ต้องรู้เรื่อง networking เลย แค่เรียก service ตามชื่อ mesh จัดการที่เหลือให้หมด

Istio vs Linkerd

Istio เป็น service mesh ที่ feature ครบที่สุด แต่ซับซ้อนที่สุดเช่นกัน มี traffic management ที่ยืดหยุ่นมาก เช่น canary deployment, A/B testing, fault injection security ด้วย mTLS อัตโนมัติ observability ผ่าน Kiali dashboard ข้อเสียคือ resource consumption สูง และ learning curve สูง Linkerd เป็นทางเลือกที่เบากว่ามาก ใช้ Rust-based proxy แทน Envoy กิน resource น้อยกว่า Istio หลายเท่า ติดตั้งและจัดการง่ายกว่า แต่ features อาจไม่ครบเท่า Istio

Network Policy: กำหนดกฎการสื่อสารระหว่าง Pods

Network Policy เป็น Kubernetes resource ที่กำหนดว่า Pod ไหนสามารถคุยกับ Pod ไหนได้ เหมือน firewall rules สำหรับ Pods

ทำไมต้องมี Network Policy

โดย default Kubernetes อนุญาตให้ทุก Pod คุยกับทุก Pod ได้หมด ซึ่งเป็น security risk มหาศาล ถ้า attacker compromise Pod ตัวหนึ่งได้ ก็สามารถ access ทุก service ใน cluster ได้ Network Policy ช่วยจำกัดการสื่อสารตามหลัก least privilege เช่น frontend Pod สามารถคุยกับ backend Pod เท่านั้น ห้ามคุยกับ database โดยตรง ลด blast radius เมื่อเกิด incident

การเขียน Network Policy

Network Policy ใช้ label selector ในการระบุ Pod ที่ policy จะบังคับใช้ และกำหนด ingress/egress rules ว่า traffic จากไหนถึงไหนได้บ้าง สิ่งสำคัญคือ ต้องมี CNI plugin ที่รองรับ Network Policy (Flannel ไม่รองรับ ต้องใช้ Calico หรือ Cilium) เริ่มจาก default deny policy ที่ block ทุกอย่างก่อน แล้วค่อยเปิด allow ทีละ rule เป็นวิธีที่ปลอดภัยที่สุด

Best Practices สำหรับ Container Networking ในองค์กร

การจัดการ Container Networking ในองค์กรต้องคิดเรื่อง scalability, security และ operability ไปพร้อมกัน

IP Address Planning

Kubernetes cluster ต้องการ IP range สำหรับ Pod network (Pod CIDR) และ Service network (Service CIDR) วางแผน IP space ให้ดี อย่าให้ overlap กับ corporate network ที่มีอยู่ ตัวอย่างเช่น ใช้ 10.244.0.0/16 สำหรับ Pods (65,534 IPs) และ 10.96.0.0/12 สำหรับ Services ถ้ามีหลาย clusters ต้องใช้ IP range ที่ไม่ overlap กันเพื่อให้ cross-cluster communication ทำได้

Observability และ Troubleshooting

Container networking มีหลาย layer ที่อาจเกิดปัญหา ตั้งแต่ CNI, iptables/eBPF rules, DNS resolution, Service routing ถึง Ingress ต้องมีเครื่องมือ monitoring ที่ดี ใช้ Hubble (สำหรับ Cilium) หรือ Calico Network Insights สำหรับ network flow visibility deploy Prometheus + Grafana สำหรับ metrics ใช้ kubectl debug และ ephemeral containers สำหรับ troubleshooting ภายใน Pod

ทิ้งท้าย: Container Networking เป็นทักษะที่ขาดไม่ได้

Container Networking เป็นหัวข้อที่ซับซ้อนแต่จำเป็นอย่างยิ่งสำหรับองค์กรที่ใช้ Docker และ Kubernetes การเข้าใจ networking model ของ Kubernetes การเลือก CNI plugin ที่เหมาะสม และการกำหนด Network Policy ที่ดี จะช่วยให้ application ทำงานได้อย่างเสถียร ปลอดภัย และ scale ได้

เริ่มจากการเรียนรู้ Docker networking พื้นฐาน แล้วค่อยขยับไปสู่ Kubernetes ทดลองใน lab environment ก่อน ใช้ kind หรือ minikube สำหรับการทดสอบ เมื่อพร้อมแล้วค่อย deploy production cluster ด้วย CNI plugin ที่เหมาะกับ use case ขององค์กร

อ่านเพิ่มเติมเกี่ยวกับ Server Clustering และ Zero Trust Network ที่ siamlancard.com หรือติดตามเนื้อหา IT จาก icafeforex.com และ siam2r.com