บทนำ: ทำไม IT Ops ต้องเรียนรู้ Kubernetes ในปี 2026
ในปี 2026 Kubernetes (K8s) ไม่ใช่เครื่องมือสำหรับ Developer เพียงอย่างเดียวอีกต่อไป องค์กรจำนวนมากกำลังนำ Kubernetes มาใช้เป็น Infrastructure Platform หลัก ทำให้ Sysadmin, Network Engineer, Storage Admin และ Security Engineer ต้องเข้าใจ Kubernetes อย่างหลีกเลี่ยงไม่ได้ หากคุณเป็น IT Operations ที่ยังไม่เคยสัมผัส Kubernetes บทความนี้จะช่วยให้คุณเข้าใจ K8s จากมุมมองของ Infrastructure ไม่ใช่จากมุมมองของ Developer
จากรายงานของ CNCF (Cloud Native Computing Foundation) ในปี 2025 พบว่ากว่า 96% ขององค์กรที่ตอบแบบสอบถามมีการใช้งานหรือกำลังประเมิน Kubernetes ซึ่งหมายความว่าทีม IT Ops แทบทุกแห่งจะต้องรับผิดชอบ Kubernetes Cluster ไม่ว่าจะเป็น On-premises หรือ Cloud สิ่งที่เปลี่ยนไปคือ IT Ops ไม่ได้แค่ดูแล Server แบบเดิมอีกต่อไป แต่ต้องดูแล Kubernetes Platform ที่รัน Workload ของทั้งองค์กร
บทความนี้จะครอบคลุมทุกด้านของ Kubernetes ที่ IT Ops ต้องรู้ ตั้งแต่ Architecture, Networking, Storage, Security, Monitoring, Backup, Disaster Recovery จนถึง Certification Path อย่าง CKA (Certified Kubernetes Administrator) เพื่อให้คุณพร้อมรับมือกับ Kubernetes ในสภาพแวดล้อมจริง
Kubernetes คืออะไร มองจากมุม IT Ops
นิยามของ Kubernetes สำหรับ Sysadmin
Kubernetes เป็น Container Orchestration Platform ที่ทำหน้าที่จัดการ Container จำนวนมากให้ทำงานร่วมกันอย่างมีประสิทธิภาพ สำหรับ IT Ops ให้คิดว่า Kubernetes เป็นเหมือน Operating System สำหรับ Datacenter ที่ทำหน้าที่จัดสรร Resources (CPU, Memory, Storage, Network) ให้กับ Application ต่างๆ โดยอัตโนมัติ
ถ้าเปรียบเทียบกับสิ่งที่ IT Ops คุ้นเคย Kubernetes ทำหน้าที่คล้ายกับ VMware vSphere แต่แทนที่จะจัดการ Virtual Machine จะจัดการ Container แทน และมีความสามารถในการ Self-healing, Auto-scaling, Rolling Update ที่ VMware ต้องใช้เครื่องมือเพิ่มเติม
สิ่งที่ IT Ops ต้องเข้าใจคือ Kubernetes ไม่ได้มาแทนที่ Infrastructure เดิมทั้งหมด แต่เป็น Layer เพิ่มเติมที่อยู่บน Infrastructure ที่มีอยู่ ไม่ว่าจะเป็น Physical Server, VMware, Cloud VM หรือแม้แต่ Bare Metal Server Kubernetes สามารถทำงานได้บนทุก Platform
Container vs VM ความแตกต่างที่ IT Ops ต้องเข้าใจ
Virtual Machine (VM) ที่ IT Ops คุ้นเคยนั้นมี Guest OS เต็มรูปแบบ ใช้ Resources มากกว่า แต่มี Isolation ที่แข็งแกร่ง ส่วน Container แชร์ Kernel กับ Host OS ทำให้เบาและเร็วกว่า แต่ Isolation น้อยกว่า VM
ในทางปฏิบัติ หลายองค์กรใช้ทั้ง VM และ Container ร่วมกัน โดยรัน Kubernetes บน VM อีกทีหนึ่ง เพื่อได้ประโยชน์ทั้ง Isolation ของ VM และความเบาของ Container นี่คือสิ่งที่ IT Ops ต้องเข้าใจ มันไม่ใช่เรื่องของการเลือกอย่างใดอย่างหนึ่ง แต่เป็นการใช้งานร่วมกันอย่างเหมาะสม
Kubernetes Architecture สำหรับ Sysadmin
Control Plane Components
Control Plane เป็นสมองของ Kubernetes Cluster ทำหน้าที่ตัดสินใจและจัดการ Cluster ทั้งหมด IT Ops ต้องเข้าใจ Component แต่ละตัวเพื่อ Troubleshoot ได้อย่างถูกต้อง
kube-apiserver: เป็น Front-end ของ Control Plane ทุก Request ไม่ว่าจะมาจาก kubectl, Dashboard หรือ Component อื่นๆ ต้องผ่าน API Server ทั้งหมด API Server ทำหน้าที่ Authentication, Authorization และ Admission Control ก่อนที่จะ Process Request ใดๆ สำหรับ IT Ops API Server เทียบได้กับ Management Interface ของอุปกรณ์ Network หรือ vCenter Server ของ VMware
etcd: เป็น Distributed Key-Value Store ที่เก็บ State ทั้งหมดของ Cluster ทุก Configuration, Secret, Deployment State ถูกเก็บใน etcd IT Ops ต้องให้ความสำคัญกับ etcd เป็นพิเศษ เพราะถ้า etcd เสียหายหรือข้อมูลสูญหาย Cluster ทั้งหมดจะไม่สามารถทำงานได้ การ Backup etcd เป็นงานสำคัญที่สุดอย่างหนึ่งของ IT Ops ที่ดูแล Kubernetes
kube-scheduler: ทำหน้าที่ตัดสินใจว่า Pod ใหม่จะถูกวางบน Worker Node ไหน โดยพิจารณาจาก Resource Request, Node Affinity, Taints/Tolerations, Pod Topology Spread และ Constraints อื่นๆ เทียบได้กับ DRS (Distributed Resource Scheduler) ใน VMware ที่ตัดสินใจว่า VM จะรันบน ESXi Host ไหน
kube-controller-manager: รัน Controller หลายตัวที่คอย Watch State ของ Cluster และทำให้ Current State ตรงกับ Desired State เช่น Replication Controller ดูแลจำนวน Pod ให้ตรงกับที่กำหนด, Node Controller ดูแล Node ที่ไม่ตอบสนอง, Endpoint Controller จัดการ Endpoint ของ Service
cloud-controller-manager: ถ้ารัน Kubernetes บน Cloud Provider (AWS, Azure, GCP) Component นี้จะเชื่อมต่อกับ Cloud API เพื่อจัดการ Load Balancer, Storage Volume, Node Instance โดยอัตโนมัติ ถ้ารัน On-premises จะไม่มี Component นี้
Worker Node Components
Worker Node คือเครื่องที่รัน Application จริง เปรียบได้กับ ESXi Host ใน VMware ที่รัน VM IT Ops ต้องเข้าใจ Component บน Worker Node เพื่อ Troubleshoot ปัญหาที่เกิดขึ้นกับ Application
kubelet: เป็น Agent ที่รันบนทุก Worker Node ทำหน้าที่รับคำสั่งจาก API Server และจัดการ Container บน Node นั้น kubelet ตรวจสอบว่า Container ที่ต้องรันอยู่นั้นมีสถานะ Healthy หรือไม่ ถ้าไม่ก็จะ Restart ให้ IT Ops ต้อง Monitor kubelet เป็นพิเศษ เพราะถ้า kubelet หยุดทำงาน Node นั้นจะถูก Mark เป็น NotReady
kube-proxy: จัดการ Network Rules บน Node เพื่อให้ Service Networking ทำงานได้ kube-proxy สร้าง iptables Rules หรือ IPVS Rules เพื่อ Forward Traffic ไปยัง Pod ที่ถูกต้อง สำหรับ Network Engineer kube-proxy เป็นจุดที่ต้องเข้าใจเพื่อ Debug Network Issues
Container Runtime: เป็น Software ที่รัน Container จริง ปัจจุบัน containerd เป็น Container Runtime ที่ใช้กันมากที่สุด (Docker ถูกยกเลิกตั้งแต่ Kubernetes 1.24) IT Ops ที่คุ้นเคยกับ Docker ต้องเรียนรู้ containerd และ crictl แทน docker command
etcd Backup และ Restore สำหรับ IT Ops
etcd เป็น Component ที่สำคัญที่สุดในการ Backup เพราะเก็บ State ทั้งหมดของ Cluster การ Backup etcd ทำได้ด้วย etcdctl snapshot save command โดย IT Ops ควร Schedule Backup อย่างน้อยทุก 1 ชั่วโมงและเก็บ Backup ไว้ที่ Remote Storage ที่แยกจาก Cluster
การ Restore etcd ต้องทำอย่างระมัดระวัง เพราะจะ Overwrite State ทั้งหมดของ Cluster ขั้นตอนคือหยุด kube-apiserver ก่อน แล้วใช้ etcdctl snapshot restore เพื่อสร้าง Data Directory ใหม่ จากนั้น Update etcd Configuration ให้ชี้ไปที่ Data Directory ใหม่ แล้วเริ่ม etcd และ kube-apiserver ใหม่
Bare-Metal Kubernetes vs Cloud-Managed (EKS/AKS/GKE)
Bare-Metal Kubernetes (Self-Managed)
Bare-Metal Kubernetes หมายถึงการติดตั้งและจัดการ Kubernetes Cluster ด้วยตัวเองบน Physical Server หรือ VM ที่องค์กรดูแลเอง เครื่องมือที่นิยมใช้ติดตั้ง ได้แก่ kubeadm (Official Tool), Kubespray (Ansible-based), RKE2 (Rancher), k3s (Lightweight) และ Talos Linux (Immutable OS สำหรับ K8s)
ข้อดีของ Bare-Metal คือควบคุมได้ทั้งหมด ตั้งแต่ Hardware, OS, Network, Storage ไม่มีค่าใช้จ่ายรายเดือนสำหรับ Control Plane (Cloud Provider คิดค่า Control Plane) เหมาะกับ Workload ที่ต้องการ Performance สูงเช่น GPU Workload, Database และ Compliance ที่ต้องการ Data Sovereignty
ข้อเสียคือ IT Ops ต้องรับผิดชอบทุกอย่าง ตั้งแต่ Installation, Upgrade, Patching, HA ของ Control Plane, Certificate Management, etcd Backup ซึ่งต้องใช้ทักษะและเวลามาก
Cloud-Managed Kubernetes
Amazon EKS (Elastic Kubernetes Service): AWS จัดการ Control Plane ให้ IT Ops ดูแลแค่ Worker Node (หรือใช้ Fargate ให้ AWS ดูแลให้ทั้งหมด) EKS รองรับ Integration กับ AWS Service ต่างๆ เช่น ALB (Application Load Balancer), EBS (Elastic Block Store), EFS (Elastic File System), IAM, CloudWatch ได้อย่างดี ค่าใช้จ่าย Control Plane อยู่ที่ประมาณ 0.10 USD ต่อชั่วโมง
Azure AKS (Azure Kubernetes Service): Microsoft จัดการ Control Plane ให้ฟรี (ไม่คิดค่า Control Plane) IT Ops จ่ายเฉพาะ Worker Node เท่านั้น AKS รองรับ Integration กับ Azure AD, Azure Monitor, Azure Disk, Azure Files ได้ดี เหมาะกับองค์กรที่ใช้ Microsoft Ecosystem
Google GKE (Google Kubernetes Engine): Google เป็นผู้สร้าง Kubernetes จึงมี GKE ที่ Advanced ที่สุด GKE Autopilot Mode ให้ Google จัดการทุกอย่างรวมถึง Worker Node โดย IT Ops แค่ Deploy Application GKE มี Feature เช่น Binary Authorization, Workload Identity, GKE Sandbox ที่ไม่มีใน Provider อื่น
การเลือกระหว่าง Self-Managed vs Cloud-Managed
สำหรับ IT Ops การตัดสินใจเลือกขึ้นอยู่กับหลายปัจจัย ถ้าองค์กรมี Datacenter เอง มีทีม IT ที่แข็งแกร่ง ต้องการ Full Control และ Data Sovereignty ควรเลือก Bare-Metal แต่ถ้าองค์กรต้องการ Time to Market เร็ว ไม่อยากดูแล Infrastructure มาก มี Budget สำหรับ Cloud ควรเลือก Cloud-Managed
หลายองค์กรใช้ Hybrid Approach โดยมี On-premises Cluster สำหรับ Sensitive Workload และ Cloud Cluster สำหรับ Public-facing Workload โดยใช้เครื่องมือเช่น Rancher, Red Hat OpenShift หรือ VMware Tanzu ในการจัดการ Multi-Cluster
Kubernetes Networking สำหรับ Network Engineer
Pod Networking Model
Kubernetes กำหนดว่าทุก Pod ต้องมี IP Address ของตัวเอง และ Pod ทุกตัวต้องสื่อสารกันได้โดยตรงโดยไม่ต้อง NAT นี่คือ Flat Network Model ที่แตกต่างจาก Docker Networking แบบเดิมที่ใช้ NAT
สำหรับ Network Engineer การที่ทุก Pod มี IP Address ของตัวเองหมายความว่าจะมี IP Address จำนวนมากใน Cluster เช่น Cluster ที่มี 100 Node อาจมี Pod หลายพันตัว แต่ละตัวมี IP ของตัวเอง ดังนั้นต้องวางแผน IP Address Space ให้ดี
CNI (Container Network Interface)
CNI เป็น Plugin ที่ Kubernetes ใช้จัดการ Network ของ Pod มี CNI หลายตัวให้เลือก แต่ละตัวมีข้อดีข้อเสียต่างกัน
Calico: เป็น CNI ที่ได้รับความนิยมมากที่สุด ใช้ BGP (Border Gateway Protocol) ในการ Route Traffic ระหว่าง Node ทำให้ Network Engineer ที่คุ้นเคยกับ BGP สามารถเข้าใจได้ง่าย Calico รองรับ Network Policy ที่ครบถ้วน มี eBPF Dataplane ที่ Performance ดีมาก และรองรับ WireGuard Encryption สำหรับ Traffic ระหว่าง Node
Cilium: เป็น CNI ที่ใช้ eBPF (extended Berkeley Packet Filter) เป็นหลัก ทำให้ Performance สูงมากและสามารถ Observe Network Traffic ได้อย่างละเอียดด้วย Hubble Cilium รองรับ L7 Network Policy ที่สามารถ Filter Traffic ตาม HTTP Method หรือ URL Path ได้ เหมาะกับองค์กรที่ต้องการ Network Visibility และ Security ขั้นสูง
Flannel: เป็น CNI ที่เรียบง่ายที่สุด ใช้ VXLAN Overlay Network เหมาะกับ Cluster ขนาดเล็กหรือ Lab ที่ไม่ต้องการ Feature ซับซ้อน Flannel ไม่รองรับ Network Policy จึงต้องใช้ร่วมกับ Calico ถ้าต้องการ Network Policy
Multus: ไม่ใช่ CNI โดยตรง แต่เป็น Meta CNI Plugin ที่อนุญาตให้ Pod มีหลาย Network Interface เหมาะกับ Workload ที่ต้องการ Management Network และ Data Network แยกกัน เช่น Telecom Workload (5G Core), NFV
Kubernetes Services
Service เป็น Abstraction ที่อยู่หน้า Group ของ Pod ทำหน้าที่ Load Balancing และ Service Discovery สำหรับ Network Engineer Service เทียบได้กับ Virtual IP (VIP) ที่อยู่หน้า Server Pool
ClusterIP: เป็น Service Type เริ่มต้น สร้าง Virtual IP ที่เข้าถึงได้เฉพาะภายใน Cluster เหมาะกับ Internal Service ที่ไม่ต้องเข้าถึงจากภายนอก
NodePort: เปิด Port บนทุก Node (30000-32767) เพื่อให้เข้าถึง Service จากภายนอก Cluster ได้ เทียบได้กับ Port Forwarding บน Firewall แต่ไม่เหมาะกับ Production เพราะ Port Range จำกัดและต้องรู้ IP ของ Node
LoadBalancer: สร้าง External Load Balancer (ถ้ารันบน Cloud) เพื่อกระจาย Traffic ไปยัง Pod สำหรับ Bare-Metal ต้องใช้ MetalLB หรือ kube-vip เพื่อจำลอง Load Balancer Service
ExternalName: สร้าง CNAME Record ที่ชี้ไปยัง External Service ใช้สำหรับ Integrate กับ Service ภายนอก Cluster เช่น Database ที่อยู่นอก Kubernetes
Ingress และ Ingress Controller
Ingress เป็น API Object ที่กำหนด HTTP/HTTPS Routing Rules ตาม Hostname หรือ Path เพื่อ Route Traffic ไปยัง Service ที่เหมาะสม เทียบได้กับ Reverse Proxy หรือ L7 Load Balancer
Ingress Controller คือ Software ที่ Implement Ingress Rules จริงๆ มีหลายตัวให้เลือก เช่น NGINX Ingress Controller (นิยมที่สุด), HAProxy Ingress, Traefik, Istio Gateway, Contour และ Kong Network Engineer ที่คุ้นเคยกับ F5 BIG-IP หรือ HAProxy จะเข้าใจ Concept ของ Ingress Controller ได้ง่าย
ตัวอย่าง Ingress Rule สามารถกำหนดได้ว่า Traffic ที่มาที่ app.example.com/api ให้ส่งไปที่ api-service และ Traffic ที่มาที่ app.example.com/web ให้ส่งไปที่ web-service พร้อม TLS Termination ที่ Ingress Controller
MetalLB สำหรับ Bare-Metal Load Balancing
เมื่อรัน Kubernetes บน Bare-Metal จะไม่มี Cloud Load Balancer MetalLB เป็น Solution ที่ได้รับความนิยมที่สุด ทำงานได้ 2 Mode คือ Layer 2 Mode ที่ใช้ ARP/NDP ในการ Announce IP Address (เหมาะกับ Cluster ขนาดเล็ก) และ BGP Mode ที่ Peer กับ Router เพื่อ Advertise IP Address (เหมาะกับ Production)
สำหรับ Network Engineer BGP Mode ของ MetalLB น่าสนใจมาก เพราะ MetalLB จะ Peer กับ Top-of-Rack Switch/Router แล้ว Advertise Service IP ผ่าน BGP ทำให้ Traffic ถูก Route มายัง Node ที่มี Pod อยู่โดยตรง ซึ่งเป็น Pattern ที่คุ้นเคยในการทำ Anycast
Kubernetes Storage สำหรับ Storage Admin
Persistent Volume (PV) และ Persistent Volume Claim (PVC)
ใน Kubernetes Container เป็น Ephemeral หมายความว่าข้อมูลจะหายไปเมื่อ Container ถูก Restart หรือ Reschedule สำหรับ Application ที่ต้องเก็บข้อมูลถาวร (Database, File Storage) ต้องใช้ Persistent Volume
Persistent Volume (PV) คือ Storage Resource ที่ Admin สร้างไว้ล่วงหน้า เทียบได้กับ LUN บน SAN หรือ NFS Share ที่ Storage Admin สร้างไว้ PV กำหนด Capacity, Access Mode (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) และ Storage Backend
Persistent Volume Claim (PVC) คือ Request จาก User/Developer ที่ต้องการ Storage เทียบได้กับใบขอใช้ Storage ที่ User ส่งมาให้ Storage Admin PVC กำหนดขนาด, Access Mode และ StorageClass ที่ต้องการ Kubernetes จะจับคู่ PVC กับ PV ที่เหมาะสมอัตโนมัติ
StorageClass และ Dynamic Provisioning
StorageClass ทำให้ IT Ops ไม่ต้องสร้าง PV ล่วงหน้า แต่ Kubernetes จะสร้าง PV อัตโนมัติเมื่อมี PVC Request เข้ามา เทียบได้กับ Storage Pool ที่กำหนด Tier ไว้ เช่น fast (SSD), standard (HDD), archival (Object Storage)
ตัวอย่างเช่น IT Ops สร้าง StorageClass ชื่อ fast-ssd ที่ใช้ NVMe SSD เมื่อ Developer สร้าง PVC ที่ระบุ StorageClass เป็น fast-ssd Kubernetes จะเรียก CSI Driver เพื่อสร้าง Volume บน NVMe SSD โดยอัตโนมัติ IT Ops ไม่ต้องทำอะไรเพิ่มเติม
CSI (Container Storage Interface)
CSI เป็น Standard Interface ที่ Storage Vendor ใช้ Integrate กับ Kubernetes CSI Driver ที่ได้รับความนิยม ได้แก่
Longhorn: เป็น Distributed Block Storage ที่ออกแบบสำหรับ Kubernetes โดยเฉพาะ พัฒนาโดย Rancher (SUSE) เหมาะกับ Bare-Metal Cluster ที่ต้องการ Replicated Storage โดยไม่ต้องมี External Storage Array
Rook-Ceph: เป็น Operator ที่รัน Ceph Storage Cluster บน Kubernetes เหมาะกับองค์กรที่ต้องการ Enterprise-grade Storage ที่รองรับ Block, File และ Object Storage บน Kubernetes
OpenEBS: รองรับหลาย Storage Engine เช่น Mayastor (NVMe-oF based) ที่มี Performance สูงมาก เหมาะกับ Workload ที่ต้องการ Low Latency
NFS CSI Driver: ใช้ NFS Server ที่มีอยู่เดิมเป็น Backend สำหรับ Kubernetes Storage เหมาะกับองค์กรที่มี NFS Infrastructure อยู่แล้วและต้องการเริ่มใช้ Kubernetes Storage อย่างง่าย
Cloud CSI Drivers: AWS EBS CSI, Azure Disk CSI, GCE PD CSI ใช้ Cloud Storage เป็น Backend ทำงานร่วมกับ Cloud-Managed Kubernetes ได้อย่างดี
Snapshot และ Clone
Kubernetes รองรับ Volume Snapshot ผ่าน CSI ทำให้ IT Ops สามารถสร้าง Snapshot ของ PV ได้เหมือนกับ Snapshot บน SAN หรือ VMware Volume Snapshot สามารถใช้สำหรับ Backup, สร้าง Clone สำหรับ Testing หรือ Disaster Recovery
Kubernetes Security สำหรับ Security Team
RBAC (Role-Based Access Control)
RBAC เป็นกลไกหลักในการควบคุม Access ใน Kubernetes IT Ops ต้องออกแบบ RBAC ให้เหมาะสมกับโครงสร้างองค์กร
Role และ ClusterRole: Role กำหนดสิทธิ์ภายใน Namespace เดียว ส่วน ClusterRole กำหนดสิทธิ์ทั้ง Cluster ตัวอย่างเช่น สร้าง Role ที่อนุญาตให้ Developer ดู Pod, Log, Exec เข้า Pod ได้ แต่ไม่สามารถลบ Namespace หรือแก้ไข Network Policy ได้
RoleBinding และ ClusterRoleBinding: ใช้ผูก Role/ClusterRole กับ User, Group หรือ ServiceAccount ตัวอย่างเช่น ผูก developer-role กับ Group developers ใน LDAP/AD ทำให้ Developer ทุกคนในกลุ่มได้รับสิทธิ์ตาม Role ที่กำหนด
Best Practice สำหรับ RBAC คือใช้หลัก Least Privilege ให้สิทธิ์น้อยที่สุดที่จำเป็น ใช้ Namespace เพื่อแยก Environment (dev, staging, prod) ใช้ Group-based Binding แทน User-based เพื่อง่ายต่อการจัดการ และ Audit RBAC Permissions เป็นประจำด้วยเครื่องมือเช่น rbac-lookup หรือ kubectl auth can-i
Pod Security Admission (PSA)
Pod Security Admission (PSA) มาแทนที่ Pod Security Policy (PSP) ที่ถูก Deprecated ตั้งแต่ Kubernetes 1.25 PSA กำหนด 3 ระดับ Security ให้เลือก
Privileged: ไม่มี Restriction ใดๆ Pod สามารถทำอะไรก็ได้ ใช้สำหรับ System Component เช่น CNI, CSI, Monitoring Agent ที่ต้องการ Privileged Access
Baseline: ป้องกัน Known Privilege Escalation ห้ามใช้ hostNetwork, hostPID, hostIPC, Privileged Container เหมาะกับ Workload ทั่วไปที่ไม่ต้องการ Special Privileges
Restricted: เข้มงวดที่สุด บังคับให้รันเป็น non-root, ห้ามเพิ่ม Capability, บังคับ readOnlyRootFilesystem เหมาะกับ Workload ที่ต้องการ Security สูงสุด
IT Ops ควรกำหนด PSA Level เป็น Baseline สำหรับ Namespace ทั่วไป และ Restricted สำหรับ Namespace ที่มี Sensitive Workload
Network Policy
Network Policy เป็น Firewall ของ Kubernetes ที่ควบคุม Traffic ระหว่าง Pod Network Engineer จะคุ้นเคยกับ Concept นี้เพราะคล้ายกับ Firewall Rules
โดย Default Kubernetes อนุญาตให้ Pod ทุกตัวสื่อสารกันได้ทั้งหมด ซึ่งไม่ปลอดภัย IT Ops ควรสร้าง Default Deny Policy ก่อน แล้วค่อยเปิด Allow Policy เฉพาะ Traffic ที่จำเป็น เช่น อนุญาตให้ Frontend Pod สื่อสารกับ Backend Pod ได้เฉพาะ Port 8080 และ Backend Pod สื่อสารกับ Database Pod ได้เฉพาะ Port 5432
สิ่งสำคัญคือ Network Policy ต้องมี CNI ที่รองรับ เช่น Calico, Cilium, Weave Net ถ้าใช้ Flannel อย่างเดียวจะไม่สามารถ Enforce Network Policy ได้
Secrets Management
Kubernetes Secret เป็น Object ที่ใช้เก็บข้อมูลที่ Sensitive เช่น Password, API Key, Certificate แต่โดย Default Secret ถูกเก็บเป็น Base64 Encoded ใน etcd ซึ่งไม่ได้ Encrypt จริง
IT Ops ควรเปิดใช้ Encryption at Rest สำหรับ etcd เพื่อ Encrypt Secret ที่เก็บอยู่ และพิจารณาใช้ External Secret Management เช่น HashiCorp Vault, AWS Secrets Manager, Azure Key Vault ร่วมกับ External Secrets Operator เพื่อ Sync Secret จาก External Source เข้ามาใน Kubernetes
Image Security
IT Ops ควรกำหนด Policy ว่า Container Image ที่ใช้ใน Cluster ต้องมาจาก Trusted Registry เท่านั้น ใช้ Image Scanning Tool เช่น Trivy, Grype เพื่อ Scan Vulnerability ก่อน Deploy และพิจารณาใช้ Image Signing ด้วย Cosign/Sigstore เพื่อยืนยันว่า Image ไม่ถูก Tamper
Monitoring Kubernetes Infrastructure
Prometheus และ Grafana
Prometheus เป็น Monitoring System มาตรฐานสำหรับ Kubernetes ทำหน้าที่เก็บ Metrics จาก Kubernetes Component ทุกตัว (API Server, kubelet, kube-proxy, etcd) รวมถึง Application Metrics
สำหรับ IT Ops ที่คุ้นเคยกับ SNMP Monitoring จะพบว่า Prometheus ใช้ Pull Model คล้ายกับ SNMP Polling โดย Prometheus จะ Scrape Metrics จาก Endpoint ที่กำหนดเป็นระยะ การติดตั้ง Prometheus บน Kubernetes ทำได้ง่ายที่สุดด้วย kube-prometheus-stack Helm Chart ที่รวม Prometheus, Grafana, Alertmanager และ Default Dashboard ไว้พร้อมใช้งาน
Metrics ที่ IT Ops ต้อง Monitor ได้แก่ Node CPU/Memory/Disk Usage, Pod CPU/Memory Request vs Usage, etcd Latency และ Leader Election, API Server Request Latency และ Error Rate, kubelet Pod Start Latency, Persistent Volume Usage และ IOPS, Network Traffic ระหว่าง Pod/Node
Resource Quotas และ Limit Ranges
Resource Quota กำหนดจำนวน Resource สูงสุดที่แต่ละ Namespace สามารถใช้ได้ เช่น จำกัด Namespace dev ให้ใช้ CPU ไม่เกิน 10 Core, Memory ไม่เกิน 32 GB, PVC ไม่เกิน 100 GB ป้องกันไม่ให้ทีมใดทีมหนึ่งใช้ Resource จนหมด
Limit Range กำหนด Default Resource Request/Limit สำหรับ Pod ใน Namespace ถ้า Developer ไม่กำหนด Resource Request/Limit Kubernetes จะใช้ค่าจาก Limit Range IT Ops ควรกำหนดทั้ง Resource Quota และ Limit Range สำหรับทุก Namespace
Logging Stack
Kubernetes ไม่ได้มี Built-in Log Aggregation IT Ops ต้องติดตั้ง Logging Stack เอง Solution ที่นิยม ได้แก่ EFK Stack (Elasticsearch, Fluentd/Fluent Bit, Kibana), Loki Stack (Grafana Loki, Promtail, Grafana) ซึ่งเบากว่า EFK มาก และ OpenTelemetry Collector ที่สามารถส่ง Log ไปยัง Backend ใดก็ได้
สำหรับ IT Ops ที่คุ้นเคยกับ Syslog/SIEM จะพบว่า Logging ใน Kubernetes ซับซ้อนกว่าเพราะ Pod เกิดและตายตลอดเวลา Log ต้องถูก Collect ก่อนที่ Pod จะถูกลบ และต้อง Correlate Log จากหลาย Pod หลาย Node เข้าด้วยกัน
Backup Kubernetes ด้วย Velero
ทำไมต้อง Backup Kubernetes
Kubernetes Cluster มีทั้ง Configuration (Deployment, Service, ConfigMap, Secret) และ Data (Persistent Volume) IT Ops ต้อง Backup ทั้งสองส่วน การ Backup แค่ etcd อย่างเดียวไม่เพียงพอ เพราะ etcd เก็บเฉพาะ Kubernetes Object ไม่ได้เก็บข้อมูลใน Persistent Volume
Velero คืออะไร
Velero (เดิมชื่อ Heptio Ark) เป็น Tool มาตรฐานสำหรับ Backup และ Restore Kubernetes Cluster Velero สามารถ Backup Kubernetes Resource (YAML) และ Persistent Volume Data ไปยัง Object Storage เช่น S3, Azure Blob, GCS หรือ MinIO
สำหรับ IT Ops Velero เทียบได้กับ Veeam สำหรับ VMware แต่สำหรับ Kubernetes Feature หลักของ Velero ได้แก่ Scheduled Backup (เช่น Backup ทุกวัน), Selective Backup ตาม Namespace หรือ Label, Volume Snapshot ผ่าน CSI, Cross-Cluster Restore สำหรับ Migration หรือ DR และ Backup Hooks ที่รัน Command ก่อน/หลัง Backup เช่น Freeze Database
การวางแผน Backup Strategy
IT Ops ควรกำหนด Backup Strategy ที่ครอบคลุม ทำ etcd Snapshot ทุก 1 ชั่วโมง เก็บไว้ 7 วัน ทำ Velero Backup ทุกวัน เก็บไว้ 30 วัน ทำ Velero Backup รายสัปดาห์ เก็บไว้ 90 วัน ทดสอบ Restore ทุกเดือนเพื่อให้มั่นใจว่า Backup ใช้งานได้จริง เก็บ Backup ไว้ที่ Remote Location ที่แยกจาก Cluster
Disaster Recovery สำหรับ Kubernetes
DR Strategy
IT Ops ต้องวางแผน DR สำหรับ Kubernetes เหมือนกับระบบอื่น โดยพิจารณา RPO (Recovery Point Objective) คือยอมรับข้อมูลที่จะสูญหายได้มากแค่ไหน และ RTO (Recovery Time Objective) คือต้อง Recover ได้เร็วแค่ไหน
Active-Passive DR: มี Primary Cluster ที่ใช้งานจริง และ DR Cluster ที่อยู่ใน Standby ใช้ Velero Backup จาก Primary Restore ไปยัง DR Cluster เมื่อเกิดเหตุ RTO ประมาณ 1-4 ชั่วโมงขึ้นอยู่กับขนาด Cluster
Active-Active DR: มี 2 Cluster ที่ทำงานพร้อมกัน ใช้ Global Load Balancer (DNS-based หรือ Anycast) เพื่อกระจาย Traffic ไปยังทั้ง 2 Cluster ถ้า Cluster ใดล่ม Traffic จะถูก Route ไปอีก Cluster อัตโนมัติ RTO ใกล้ 0 แต่ซับซ้อนในการ Setup โดยเฉพาะ Data Synchronization
GitOps-based DR: ใช้ GitOps Tool เช่น ArgoCD หรือ Flux เก็บ Configuration ทั้งหมดใน Git Repository เมื่อต้อง Rebuild Cluster แค่ชี้ ArgoCD ไปที่ Git Repository ก็จะ Deploy ทุกอย่างกลับมาอัตโนมัติ เหลือแค่ Restore Data จาก Velero Backup
Certificate Management ใน Kubernetes
Internal Certificates
Kubernetes ใช้ TLS Certificate จำนวนมากสำหรับการสื่อสารระหว่าง Component ทั้ง API Server Certificate, kubelet Certificate, etcd Peer Certificate และอื่นๆ Certificate เหล่านี้มี Expiration Date ที่ IT Ops ต้อง Monitor
ถ้าใช้ kubeadm Certificate จะ Expire ใน 1 ปี IT Ops ต้อง Renew ก่อนหมดอายุด้วย kubeadm certs renew command ถ้าปล่อยให้ Certificate Expire API Server จะหยุดทำงานและ Cluster จะ Down
cert-manager
cert-manager เป็น Kubernetes Operator ที่จัดการ TLS Certificate อัตโนมัติ รองรับ Let’s Encrypt, HashiCorp Vault, Venafi และ Self-signed CA IT Ops ใช้ cert-manager เพื่อ Automate Certificate สำหรับ Ingress (HTTPS), Service Mesh (mTLS) และ Internal Service
cert-manager จะ Request, Renew Certificate โดยอัตโนมัติ IT Ops แค่กำหนด Issuer (CA) และ Certificate Object ที่ต้องการ cert-manager จะจัดการให้ทั้งหมด ไม่ต้องกังวลเรื่อง Certificate Expiration อีกต่อไป
Troubleshooting Kubernetes จากมุม IT Ops
Node Issues
เมื่อ Node มีสถานะ NotReady IT Ops ต้องตรวจสอบ kubelet Status ด้วย systemctl status kubelet ตรวจสอบ kubelet Log ด้วย journalctl -u kubelet ตรวจสอบ Disk Space (kubelet จะ Evict Pod ถ้า Disk เต็ม) ตรวจสอบ Memory (OOM Killer อาจ Kill kubelet) และตรวจสอบ Container Runtime ว่ายัง Running อยู่หรือไม่
Pod Issues
Pod Pending: ตรวจสอบด้วย kubectl describe pod จะเห็นเหตุผลว่าทำไม Pod ไม่ถูก Schedule สาเหตุที่พบบ่อยคือ Insufficient CPU/Memory (ต้องเพิ่ม Node หรือลด Resource Request), No Matching Node (Taints/Tolerations ไม่ตรง), PVC Pending (Storage ไม่พร้อม)
Pod CrashLoopBackOff: Container Start แล้ว Crash ซ้ำๆ ตรวจสอบ Container Log ด้วย kubectl logs พร้อม –previous flag เพื่อดู Log ของ Container ที่ Crash ไปแล้ว สาเหตุอาจเป็น Configuration ผิด, Dependency ไม่พร้อม, Memory Limit น้อยเกินไป
Pod ImagePullBackOff: ไม่สามารถ Pull Container Image ได้ ตรวจสอบ Image Name ถูกต้องหรือไม่ Registry เข้าถึงได้หรือไม่ Image Pull Secret ถูกต้องหรือไม่
Network Issues
ปัญหา Network ใน Kubernetes อาจซับซ้อน IT Ops ใช้เครื่องมือต่างๆ ในการ Debug เช่น kubectl exec เข้าไปใน Pod แล้วใช้ curl/ping/nslookup ทดสอบ, ตรวจสอบ kube-proxy ว่า iptables/IPVS Rules ถูกต้อง, ตรวจสอบ CNI Plugin ว่ายัง Running อยู่, ตรวจสอบ CoreDNS ว่า DNS Resolution ทำงานปกติ
Useful kubectl Commands สำหรับ IT Ops
kubectl get nodes -o wide ดูสถานะ Node ทั้งหมด, kubectl top nodes ดู Resource Usage ของ Node, kubectl top pods ดู Resource Usage ของ Pod, kubectl describe node [name] ดูรายละเอียด Node รวมถึง Conditions และ Events, kubectl get events –sort-by=lastTimestamp ดู Event ล่าสุดของ Cluster, kubectl get pods –all-namespaces ดู Pod ทุก Namespace, kubectl logs [pod] –previous ดู Log ของ Container ก่อนหน้า, kubectl auth can-i [verb] [resource] ตรวจสอบสิทธิ์ RBAC
Kubernetes vs VMs: ไม่ใช่การแทนที่ แต่เป็นการเสริม
Workload ที่เหมาะกับ Kubernetes
Stateless Web Application ที่ต้อง Scale ขึ้นลงบ่อย Microservices Architecture ที่มี Service จำนวนมาก CI/CD Pipeline ที่ต้อง Spin Up Environment ชั่วคราว Batch Processing และ Job Scheduling API Gateway และ Backend Services
Workload ที่ยังเหมาะกับ VM
Legacy Application ที่ไม่ได้ออกแบบสำหรับ Container, Database ขนาดใหญ่ (Oracle, SQL Server) ที่ต้องการ Dedicated Resource, Application ที่ต้องการ GUI (Desktop Application), Application ที่ต้องการ Specific OS หรือ Kernel Version, Workload ที่ต้องการ Strong Isolation (Multi-tenant Security)
Hybrid Approach
องค์กรส่วนใหญ่จะใช้ทั้ง VM และ Kubernetes ร่วมกัน โดย Kubernetes Cluster เองก็มักจะรันบน VM (บน VMware vSphere หรือ Cloud Instance) IT Ops ต้องจัดการทั้ง VM Layer และ Kubernetes Layer พร้อมกัน
เครื่องมือเช่น KubeVirt อนุญาตให้รัน VM บน Kubernetes Cluster ทำให้ IT Ops สามารถจัดการทั้ง Container และ VM จาก Platform เดียวกัน ซึ่งเป็น Trend ที่เริ่มได้รับความนิยมมากขึ้น
Migration Considerations: ย้ายจาก Traditional Infrastructure สู่ Kubernetes
Assessment Phase
ก่อน Migrate IT Ops ต้อง Assess Workload ที่จะย้ายมา Kubernetes โดยพิจารณาว่า Application สามารถ Containerize ได้หรือไม่ มี State ที่ต้อง Persist หรือไม่ มี Dependency กับ Component อื่นอย่างไร Network Requirement เป็นอย่างไร Compliance Requirement มีอะไรบ้าง
Migration Strategy
Strangler Fig Pattern: ค่อยๆ ย้าย Service ทีละตัวจาก VM มาที่ Kubernetes โดยใช้ Load Balancer หรือ API Gateway เป็นตัว Route Traffic ระหว่าง Legacy (VM) และ New (K8s) ลดความเสี่ยงในการ Migrate ทั้งหมดครั้งเดียว
Lift and Shift: Containerize Application ที่มีอยู่โดยไม่เปลี่ยน Architecture เป็นวิธีที่เร็วที่สุดแต่อาจไม่ได้ประโยชน์จาก Kubernetes เต็มที่
Refactor: ปรับ Architecture ของ Application ให้เป็น Cloud Native ก่อนย้ายมา Kubernetes ใช้เวลามากที่สุดแต่ได้ประโยชน์มากที่สุด
Day 2 Operations
หลังจาก Deploy Kubernetes แล้ว IT Ops มี Day 2 Operations ที่ต้องทำอย่างต่อเนื่อง ได้แก่ Kubernetes Version Upgrade (ทุก 4 เดือนจะมี Minor Version ใหม่), Node OS Patching, Certificate Renewal, etcd Backup Verification, Security Audit, Capacity Planning, Performance Tuning และ Documentation Update
CKA Certification สำหรับ IT Ops
CKA (Certified Kubernetes Administrator) คืออะไร
CKA เป็น Certification จาก CNCF (Cloud Native Computing Foundation) ที่ยืนยันความสามารถในการ Administer Kubernetes Cluster เป็น Certification ที่เหมาะกับ IT Ops มากที่สุดเพราะเน้นด้าน Administration ไม่ใช่ Development
CKA เป็นแบบ Performance-based Exam ต้องแก้ปัญหาจริงบน Kubernetes Cluster ภายในเวลา 2 ชั่วโมง ครอบคลุมหัวข้อ Cluster Architecture (25%), Workloads (15%), Services and Networking (20%), Storage (10%), Troubleshooting (30%)
CKA เตรียมตัวอย่างไร
IT Ops ที่ต้องการสอบ CKA ควรเริ่มจากการตั้ง Lab ด้วย kubeadm บน VM หรือใช้ Kind/Minikube สำหรับ Practice ศึกษา Kubernetes Documentation อย่างละเอียด (Documentation สามารถเปิดดูระหว่างสอบได้) ฝึกใช้ kubectl อย่างชำนาญ รวมถึง Imperative Commands ที่ช่วยประหยัดเวลาในการสอบ
หัวข้อที่ IT Ops จะถนัดอยู่แล้วคือ Networking, Storage, Troubleshooting ส่วนหัวข้อที่อาจต้องศึกษาเพิ่มคือ Workload Management (Deployment, StatefulSet, DaemonSet) และ Kubernetes API Object
Certification อื่นที่เกี่ยวข้อง
นอกจาก CKA ยังมี CKS (Certified Kubernetes Security Specialist) สำหรับ Security Team, CKAD (Certified Kubernetes Application Developer) สำหรับ Developer และ KCNA (Kubernetes and Cloud Native Associate) สำหรับผู้เริ่มต้น IT Ops ที่ต้องการเพิ่ม Value ให้ตัวเองควรสอบ CKA ก่อน แล้วตามด้วย CKS
เครื่องมือ Kubernetes ที่ IT Ops ต้องรู้จัก
Cluster Management Tools
Helm: Package Manager สำหรับ Kubernetes เทียบได้กับ apt/yum สำหรับ Linux ใช้ติดตั้ง Application บน Kubernetes ด้วย Helm Chart ที่กำหนด Configuration ไว้ล่วงหน้า IT Ops ใช้ Helm ติดตั้ง Monitoring Stack, Ingress Controller, cert-manager และ Tool อื่นๆ
k9s: Terminal-based Dashboard สำหรับ Kubernetes ช่วยให้ IT Ops สามารถ Navigate และ Manage Cluster ได้สะดวกผ่าน Terminal Interface โดยไม่ต้องพิมพ์ kubectl Command ยาวๆ
Lens: Desktop Application สำหรับจัดการ Kubernetes Cluster มี GUI ที่ใช้งานง่าย แสดง Real-time Status ของ Cluster รวมถึง Resource Usage, Events, Logs
Rancher: Multi-Cluster Management Platform ช่วย IT Ops จัดการหลาย Kubernetes Cluster จาก Dashboard เดียว รองรับทั้ง On-premises และ Cloud Cluster
GitOps Tools
ArgoCD: GitOps Continuous Delivery Tool ที่ Watch Git Repository และ Sync Configuration ไปยัง Kubernetes Cluster อัตโนมัติ IT Ops ใช้ ArgoCD เพื่อจัดการ Infrastructure as Code สำหรับ Kubernetes
Flux: อีกหนึ่ง GitOps Tool จาก Weaveworks ที่ทำงานคล้าย ArgoCD แต่มี Architecture ที่แตกต่าง Flux เป็น Set ของ Controller ที่ทำงานภายใน Cluster ส่วน ArgoCD มี Centralized Server
Policy Tools
OPA/Gatekeeper: Open Policy Agent สำหรับ Kubernetes ใช้กำหนด Policy เช่น ห้าม Deploy Container ที่รันเป็น Root, บังคับให้มี Resource Limit, บังคับให้ใช้ Image จาก Approved Registry เท่านั้น
Kyverno: Policy Engine ที่ออกแบบเฉพาะสำหรับ Kubernetes ใช้ YAML-based Policy ที่เขียนง่ายกว่า OPA ที่ใช้ Rego Language เหมาะกับ IT Ops ที่ไม่อยากเรียนภาษา Policy ใหม่
สรุป: Kubernetes สำหรับ IT Ops ในปี 2026
Kubernetes ไม่ใช่เรื่องของ Developer อีกต่อไป IT Ops ทุกสาย ไม่ว่าจะเป็น Sysadmin, Network Engineer, Storage Admin หรือ Security Engineer ล้วนต้องเข้าใจ Kubernetes ในมุมมองของตัวเอง
สิ่งสำคัญที่ IT Ops ต้องจำคือ Kubernetes ไม่ได้มาแทนที่ Infrastructure เดิม แต่เป็น Layer เพิ่มเติมที่ต้องจัดการ ทักษะ IT Ops แบบเดิม (Networking, Storage, Security, Monitoring, Backup, DR) ยังคงสำคัญและจำเป็น แต่ต้องนำมาประยุกต์ใช้ใน Context ของ Kubernetes
เริ่มต้นจากการตั้ง Lab สัก 3 Node Cluster ด้วย kubeadm ฝึก Deploy Application, ตั้ง Monitoring, ทำ Backup/Restore, Troubleshoot ปัญหา เมื่อพร้อมก็สอบ CKA เพื่อยืนยันทักษะ Kubernetes จะเป็นทักษะที่คุ้มค่าที่สุดสำหรับ IT Ops ในปี 2026 และอนาคต
