หากคุณทำงานในโลกของการพัฒนาซอฟต์แวร์ คุณคงเคยได้ยินเกี่ยวกับ Kubernetes แต่มันคืออะไรกันแน่ และทำไมจึงกลายเป็นมาตรฐานโดยพฤตินัยสำหรับการจัดการแอปพลิเคชันที่ทำงานบนคอนเทนเนอร์? คู่มือนี้จะพาคุณจากพื้นฐานไปสู่แนวคิดหลัก พร้อมตัวอย่างเชิงปฏิบัติและแผนภาพเพื่อช่วยให้คุณเข้าใจ

ก่อน Kubernetes: ประวัติศาสตร์เล็กน้อย

เพื่อเข้าใจว่าทำไม Kubernetes จึงเป็นนวัตกรรม มาย้อนกลับไปดูกัน

1. การ Deploy แบบดั้งเดิม: เดิมทีแอปพลิเคชันทำงานบนเซิร์ฟเวอร์จริง วิธีนี้มีราคาแพง ยากต่อการขยาย และเกิดปัญหาการแย่งทรัพยากร
2. การ Deploy แบบ Virtualized: จากนั้น Virtual Machines (VMs) ก็มาถึง VMs ช่วยให้สามารถรันแอปพลิเคชันหลายตัวแยกจากกันบนฮาร์ดแวร์เดียวกัน ปรับปรุงการใช้ทรัพยากรและความปลอดภัย อย่างไรก็ตาม แต่ละ VM รันระบบปฏิบัติการทั้งระบบ ซึ่งใช้ทรัพยากรมาก
3. การ Deploy แบบ Containerized: คอนเทนเนอร์ (เช่น Docker) คือวิวัฒนาการถัดไป พวกมันใช้ระบบปฏิบัติการของโฮสต์ร่วมกันแต่รันกระบวนการแยก มีน้ำหนักเบา เริ่มต้นเร็ว และพกพาได้

คอนเทนเนอร์แก้ปัญหาความสามารถในการพกพาแต่สร้างปัญหาอื่น: จะจัดการคอนเทนเนอร์หลายร้อย (หรือหลายพัน) ตัวในสภาพแวดล้อมการผลิตได้อย่างไร? จะมั่นใจได้อย่างไรว่าพวกมันทำงานอยู่เสมอ สื่อสารกันได้ และปรับขนาดตามโหลด?

นี่คือจุดที่ Kubernetes เข้ามา

Kubernetes คืออะไร?

Kubernetes (มักย่อเป็น K8s) เป็นแพลตฟอร์มโอเพนซอร์สสำหรับการจัดการคอนเทนเนอร์ พูดง่ายๆ คือมันทำให้การ deploy การปรับขนาด และการจัดการแอปพลิเคชันบนคอนเทนเนอร์เป็นไปโดยอัตโนมัติ สร้างโดย Google และปัจจุบันดูแลโดย Cloud Native Computing Foundation (CNCF) Kubernetes กลายเป็นเครื่องมือหลักสำหรับทุกคนที่ทำงานกับ microservices ในขนาดใหญ่

สถาปัตยกรรมของ Kubernetes Cluster

สภาพแวดล้อม Kubernetes เรียกว่า cluster Cluster ประกอบด้วยชุดของเครื่อง เรียกว่า nodes ซึ่งรันแอปพลิเคชันของเรา สถาปัตยกรรมแบ่งออกเป็นสองส่วนหลัก: Control Plane และ Worker Nodes

Control Plane

Control Plane คือ "สมอง" ของ cluster มันทำการตัดสินใจระดับสากล (เช่น การจัดตาราง) และตรวจจับและตอบสนองต่อเหตุการณ์ใน cluster ส่วนประกอบหลักคือ:

• API Server (kube-apiserver): เป็นประตูสู่ cluster มันเปิดเผย Kubernetes API ซึ่งใช้โดยผู้ใช้ (ผ่าน kubectl) ส่วนประกอบของ cluster และเครื่องมือภายนอกในการสื่อสาร
• etcd: ฐานข้อมูล key-value ที่สอดคล้องและมีความพร้อมใช้งานสูง เก็บข้อมูลทั้งหมดของ cluster แสดงสถานะที่ต้องการและปัจจุบันของระบบ
• Scheduler (kube-scheduler): กำหนด Pods ที่สร้างใหม่ให้กับ Worker Node ที่มีอยู่ โดยพิจารณาจากความต้องการทรัพยากร นโยบาย และข้อจำกัดอื่นๆ
• Controller Manager (kube-controller-manager): รัน controllers ซึ่งเป็นลูปควบคุมที่เฝ้าดูสถานะของ cluster และทำงานเพื่อนำไปสู่สถานะที่ต้องการ ตัวอย่างเช่น Node Controller จัดการ nodes ในขณะที่ Replication Controller รับรองว่าจำนวน Pods ที่ถูกต้องกำลังทำงาน

Worker Node

Worker Nodes คือเครื่อง (จริงหรือเสมือน) ที่แอปพลิเคชันทำงานจริง แต่ละ node ถูกจัดการโดย Control Plane และประกอบด้วยส่วนประกอบต่อไปนี้:

• Kubelet: เอเจนต์ที่ทำงานบนแต่ละ node รับรองว่าคอนเทนเนอร์ที่อธิบายใน Pods กำลังทำงานและมีสุขภาพดี
• Kube-proxy: พร็อกซีเครือข่ายที่จัดการกฎเครือข่ายบน nodes ช่วยให้การสื่อสารเครือข่ายไปยัง Pods จากเซสชันเครือข่ายภายในหรือภายนอก cluster
• Container Runtime: ซอฟต์แวร์ที่รับผิดชอบการรันคอนเทนเนอร์ Docker เป็นที่รู้จักมากที่สุด แต่ Kubernetes ยังรองรับ runtime อื่นๆ เช่น containerd และ CRI-O

Object พื้นฐานของ Kubernetes

ใน Kubernetes ทุกอย่างแสดงด้วย objects Objects เหล่านี้คือ "บันทึกเจตนา": เมื่อคุณสร้าง object Kubernetes จะทำงานอย่างต่อเนื่องเพื่อให้แน่ใจว่ามันมีอยู่และตรงกับสถานะที่ต้องการ

นี่คือสิ่งที่สำคัญที่สุด:

Pod

Pod คือหน่วยการทำงานเล็กที่สุดใน Kubernetes มันแสดงถึงคอนเทนเนอร์หนึ่งตัวหรือมากกว่าที่ทำงานร่วมกันบน node เดียวกัน แชร์ทรัพยากรเช่น เครือข่ายและพื้นที่จัดเก็บ

โดยทั่วไปคุณรันคอนเทนเนอร์เพียงตัวเดียวต่อ Pod แต่ในสถานการณ์ขั้นสูง (เช่น "sidecar containers" สำหรับ logging หรือ monitoring) คุณอาจมีมากกว่านั้น

คุณแทบจะไม่เคยสร้าง Pods โดยตรง คุณใช้ abstraction ระดับสูงกว่าเช่น Deployments

Deployment

Deployment คือ object ที่คุณจะใช้บ่อยที่สุด มันอธิบายสถานะที่ต้องการสำหรับกลุ่มของ Pods ที่เหมือนกัน Deployment controller รับผิดชอบ:

• สร้างและจัดการ ReplicaSet (object อีกตัวที่รับรองว่าจำนวนสำเนาเฉพาะของ Pod จะทำงานอยู่เสมอ)
• ปรับขนาด จำนวน Pods ขึ้นหรือลง
• จัดการ อัปเดต แอปพลิเคชันในลักษณะที่ควบคุมได้ (เช่น Rolling Update) โดยไม่มีเวลาหยุดทำงาน

ตัวอย่างไฟล์ YAML สำหรับ Deployment ที่รัน 3 สำเนาของ NGINX server:

# nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Service

Pods ใน Kubernetes เป็นชั่วคราว: สามารถสร้างและทำลายได้ตลอดเวลา แต่ละ Pod มี IP address ของตัวเอง แต่ IP นี้ไม่เสถียร แล้วเราจะ expose แอปพลิเคชันอย่างน่าเชื่อถือได้อย่างไร?

ด้วย Service Service คือ abstraction ที่กำหนดชุดตรรกะของ Pods และนโยบายในการเข้าถึง มันให้ จุดเข้าถึงที่เสถียร (IP address เสมือนและชื่อ DNS) สำหรับกลุ่ม Pods

Service ใช้ selector ที่ใช้ labels เพื่อค้นหา Pods ที่ควรส่งต่อทราฟฟิก

วิธีสร้าง Service สำหรับ NGINX Deployment ของเรา:

# nginx-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP # Default - exposes the service only within the cluster

มี Service หลายประเภท:

• ClusterIP: Expose service บน IP ภายใน cluster (ค่าเริ่มต้น)
• NodePort: Expose service บน port คงที่บนแต่ละ Worker Node
• LoadBalancer: สร้าง load balancer ภายนอกใน cloud provider (เช่น AWS, GCP) และกำหนด IP สาธารณะให้ service

Ingress

Service แบบ LoadBalancer ดีมาก แต่การสร้างหนึ่งตัวสำหรับแต่ละ service อาจมีราคาแพง เพื่อ expose หลาย service HTTP/HTTPS สู่โลกภายนอก คุณใช้ Ingress

Ingress ทำหน้าที่เป็น "เราเตอร์อัจฉริยะ" สำหรับทราฟฟิกภายนอก ช่วยให้คุณกำหนดกฎเส้นทางตาม host (เช่น api.mysite.com) หรือ path (เช่น mysite.com/api)

ตัวอย่าง Ingress:

# example-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: mysite.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080
      - path: /ui
        pathType: Prefix
        backend:
          service:
            name: ui-service
            port:
              number: 3000

Object ที่เป็นประโยชน์อื่นๆ

• Namespace: ช่วยให้สร้าง "cluster เสมือน" ภายใน cluster จริง มีประโยชน์สำหรับการแยกสภาพแวดล้อม (เช่น development, staging, production) หรือทีม
• ConfigMap และ Secret: สำหรับจัดการข้อมูลการกำหนดค่าและความลับ (เช่น รหัสผ่านหรือ API key) แยกจาก container image
• StatefulSet: คล้ายกับ Deployment แต่เฉพาะสำหรับแอปพลิเคชันที่มีสถานะ (เช่น ฐานข้อมูล) ที่ต้องการ network identity ที่เสถียรและ persistent storage
• PersistentVolume (PV) และ PersistentVolumeClaim (PVC): สำหรับจัดการ persistent storage ใน cluster

บทสรุป

Kubernetes เป็นเครื่องมือที่ทรงพลังอย่างเหลือเชื่อ แต่เส้นโค้งการเรียนรู้อาจสูงชัน คู่มือนี้เพียงแตะผิวเผิน แต่หวังว่าจะให้ความเข้าใจที่มั่นคงเกี่ยวกับแนวคิดพื้นฐาน

ทำอะไรต่อ?

• ทดลองในเครื่อง: ติดตั้ง Minikube หรือ Kind เพื่อสร้าง Kubernetes cluster บนคอมพิวเตอร์ของคุณ
• ใช้ kubectl: ทำความคุ้นเคยกับคำสั่ง kubectl เครื่องมือหลักของคุณสำหรับการโต้ตอบกับ cluster ลองสร้าง NGINX Deployment และ Service จากบทความนี้
• สำรวจบทช่วยสอนอย่างเป็นทางการ: เอกสาร Kubernetes เป็นแหล่งข้อมูลที่ยอดเยี่ยมเต็มไปด้วยตัวอย่าง

การจัดการคอนเทนเนอร์เป็นทักษะพื้นฐานในโลก cloud-native และการเชี่ยวชาญ Kubernetes จะเปิดโลกแห่งความเป็นไปได้ สนุกกับมัน!