1~
2หากคุณทำงานในโลกของการพัฒนาซอฟต์แวร์ คุณคงเคยได้ยินเกี่ยวกับ Kubernetes แต่มันคืออะไรกันแน่ และทำไมจึงกลายเป็นมาตรฐานโดยพฤตินัยสำหรับการจัดการแอปพลิเคชันที่ทำงานบนคอนเทนเนอร์? คู่มือนี้จะพาคุณจากพื้นฐานไปสู่แนวคิดหลัก พร้อมตัวอย่างเชิงปฏิบัติและแผนภาพเพื่อช่วยให้คุณเข้าใจ
3~
4## ก่อน Kubernetes: ประวัติศาสตร์เล็กน้อย
5~
6เพื่อเข้าใจว่าทำไม Kubernetes จึงเป็นนวัตกรรม มาย้อนกลับไปดูกัน
7~
81.  **การ Deploy แบบดั้งเดิม**: เดิมทีแอปพลิเคชันทำงานบนเซิร์ฟเวอร์จริง วิธีนี้มีราคาแพง ยากต่อการขยาย และเกิดปัญหาการแย่งทรัพยากร
92.  **การ Deploy แบบ Virtualized**: จากนั้น Virtual Machines (VMs) ก็มาถึง VMs ช่วยให้สามารถรันแอปพลิเคชันหลายตัวแยกจากกันบนฮาร์ดแวร์เดียวกัน ปรับปรุงการใช้ทรัพยากรและความปลอดภัย อย่างไรก็ตาม แต่ละ VM รันระบบปฏิบัติการทั้งระบบ ซึ่งใช้ทรัพยากรมาก
103.  **การ Deploy แบบ Containerized**: คอนเทนเนอร์ (เช่น Docker) คือวิวัฒนาการถัดไป พวกมันใช้ระบบปฏิบัติการของโฮสต์ร่วมกันแต่รันกระบวนการแยก มีน้ำหนักเบา เริ่มต้นเร็ว และพกพาได้
11~
12คอนเทนเนอร์แก้ปัญหาความสามารถในการพกพาแต่สร้างปัญหาอื่น: จะจัดการคอนเทนเนอร์หลายร้อย (หรือหลายพัน) ตัวในสภาพแวดล้อมการผลิตได้อย่างไร? จะมั่นใจได้อย่างไรว่าพวกมันทำงานอยู่เสมอ สื่อสารกันได้ และปรับขนาดตามโหลด?
13~
14นี่คือจุดที่ **Kubernetes** เข้ามา
15~
16## Kubernetes คืออะไร?
17~
18Kubernetes (มักย่อเป็น **K8s**) เป็นแพลตฟอร์มโอเพนซอร์สสำหรับการจัดการคอนเทนเนอร์ พูดง่ายๆ คือมันทำให้การ deploy การปรับขนาด และการจัดการแอปพลิเคชันบนคอนเทนเนอร์เป็นไปโดยอัตโนมัติ สร้างโดย Google และปัจจุบันดูแลโดย Cloud Native Computing Foundation (CNCF) Kubernetes กลายเป็นเครื่องมือหลักสำหรับทุกคนที่ทำงานกับ microservices ในขนาดใหญ่
19~
20## สถาปัตยกรรมของ Kubernetes Cluster
21~
22สภาพแวดล้อม Kubernetes เรียกว่า **cluster** Cluster ประกอบด้วยชุดของเครื่อง เรียกว่า **nodes** ซึ่งรันแอปพลิเคชันของเรา สถาปัตยกรรมแบ่งออกเป็นสองส่วนหลัก: Control Plane และ Worker Nodes
23~
24```mermaid
25graph TD
26    subgraph "Control Plane (Master)"
27        A["API Server"]
28        B["etcd"]
29        C["Scheduler"]
30        D["Controller Manager"]
31    end
32~
33    subgraph "Worker Node 1"
34        E["Kubelet"] --- F["Container Runtime"]
35        G["Kube-proxy"]
36        F --- H["Pod"]
37        F --- I["Pod"]
38    end
39~
40    subgraph "Worker Node 2"
41        J["Kubelet"] --- K["Container Runtime"]
42        L["Kube-proxy"]
43        K --- M["Pod"]
44    end
45~
46    A -- "Communicates with" --> E
47    A -- "Communicates with" --> J
48    User -- "kubectl" --> A
49    C -- "Assigns Pods to Nodes" --> E
50    D -- "Maintains state" --> A
51    A -- "Saves/Reads state" --> B
52```
53~
54### Control Plane
55~
56Control Plane คือ "สมอง" ของ cluster มันทำการตัดสินใจระดับสากล (เช่น การจัดตาราง) และตรวจจับและตอบสนองต่อเหตุการณ์ใน cluster ส่วนประกอบหลักคือ:
57~
58-   **API Server (`kube-apiserver`)**: เป็นประตูสู่ cluster มันเปิดเผย Kubernetes API ซึ่งใช้โดยผู้ใช้ (ผ่าน `kubectl`) ส่วนประกอบของ cluster และเครื่องมือภายนอกในการสื่อสาร
59-   **etcd**: ฐานข้อมูล key-value ที่สอดคล้องและมีความพร้อมใช้งานสูง เก็บข้อมูลทั้งหมดของ cluster แสดงสถานะที่ต้องการและปัจจุบันของระบบ
60-   **Scheduler (`kube-scheduler`)**: กำหนด Pods ที่สร้างใหม่ให้กับ Worker Node ที่มีอยู่ โดยพิจารณาจากความต้องการทรัพยากร นโยบาย และข้อจำกัดอื่นๆ
61-   **Controller Manager (`kube-controller-manager`)**: รัน controllers ซึ่งเป็นลูปควบคุมที่เฝ้าดูสถานะของ cluster และทำงานเพื่อนำไปสู่สถานะที่ต้องการ ตัวอย่างเช่น `Node Controller` จัดการ nodes ในขณะที่ `Replication Controller` รับรองว่าจำนวน Pods ที่ถูกต้องกำลังทำงาน
62~
63### Worker Node
64~
65Worker Nodes คือเครื่อง (จริงหรือเสมือน) ที่แอปพลิเคชันทำงานจริง แต่ละ node ถูกจัดการโดย Control Plane และประกอบด้วยส่วนประกอบต่อไปนี้:
66~
67-   **Kubelet**: เอเจนต์ที่ทำงานบนแต่ละ node รับรองว่าคอนเทนเนอร์ที่อธิบายใน Pods กำลังทำงานและมีสุขภาพดี
68-   **Kube-proxy**: พร็อกซีเครือข่ายที่จัดการกฎเครือข่ายบน nodes ช่วยให้การสื่อสารเครือข่ายไปยัง Pods จากเซสชันเครือข่ายภายในหรือภายนอก cluster
69-   **Container Runtime**: ซอฟต์แวร์ที่รับผิดชอบการรันคอนเทนเนอร์ Docker เป็นที่รู้จักมากที่สุด แต่ Kubernetes ยังรองรับ runtime อื่นๆ เช่น `containerd` และ `CRI-O`
70~
71## Object พื้นฐานของ Kubernetes
72~
73ใน Kubernetes ทุกอย่างแสดงด้วย **objects** Objects เหล่านี้คือ "บันทึกเจตนา": เมื่อคุณสร้าง object Kubernetes จะทำงานอย่างต่อเนื่องเพื่อให้แน่ใจว่ามันมีอยู่และตรงกับสถานะที่ต้องการ
74~
75นี่คือสิ่งที่สำคัญที่สุด:
76~
77### Pod
78~
79**Pod** คือหน่วยการทำงานเล็กที่สุดใน Kubernetes มันแสดงถึงคอนเทนเนอร์หนึ่งตัวหรือมากกว่าที่ทำงานร่วมกันบน node เดียวกัน แชร์ทรัพยากรเช่น เครือข่ายและพื้นที่จัดเก็บ
80~
81โดยทั่วไปคุณรันคอนเทนเนอร์เพียงตัวเดียวต่อ Pod แต่ในสถานการณ์ขั้นสูง (เช่น "sidecar containers" สำหรับ logging หรือ monitoring) คุณอาจมีมากกว่านั้น
82~
83คุณแทบจะไม่เคยสร้าง Pods โดยตรง คุณใช้ abstraction ระดับสูงกว่าเช่น Deployments
84~
85### Deployment
86~
87**Deployment** คือ object ที่คุณจะใช้บ่อยที่สุด มันอธิบายสถานะที่ต้องการสำหรับกลุ่มของ Pods ที่เหมือนกัน Deployment controller รับผิดชอบ:
88~
89-   สร้างและจัดการ **ReplicaSet** (object อีกตัวที่รับรองว่าจำนวนสำเนาเฉพาะของ Pod จะทำงานอยู่เสมอ)
90-   **ปรับขนาด** จำนวน Pods ขึ้นหรือลง
91-   จัดการ **อัปเดต** แอปพลิเคชันในลักษณะที่ควบคุมได้ (เช่น *Rolling Update*) โดยไม่มีเวลาหยุดทำงาน
92~
93ตัวอย่างไฟล์ YAML สำหรับ Deployment ที่รัน 3 สำเนาของ NGINX server:
94~
95```yaml
96# nginx-deployment.yaml
97apiVersion: apps/v1
98kind: Deployment
99metadata:
100  name: nginx-deployment
101spec:
102  replicas: 3
103  selector:
104    matchLabels:
105      app: nginx
106  template:
107    metadata:
108      labels:
109        app: nginx
110    spec:
111      containers:
112      - name: nginx
113        image: nginx:1.14.2
114        ports:
115        - containerPort: 80
116```
117~
118### Service
119~
120Pods ใน Kubernetes เป็นชั่วคราว: สามารถสร้างและทำลายได้ตลอดเวลา แต่ละ Pod มี IP address ของตัวเอง แต่ IP นี้ไม่เสถียร แล้วเราจะ expose แอปพลิเคชันอย่างน่าเชื่อถือได้อย่างไร?
121~
122ด้วย **Service** Service คือ abstraction ที่กำหนดชุดตรรกะของ Pods และนโยบายในการเข้าถึง มันให้ **จุดเข้าถึงที่เสถียร** (IP address เสมือนและชื่อ DNS) สำหรับกลุ่ม Pods
123~
124```mermaid
125graph TD
126    subgraph "Service (nginx-service)"
127        A["ClusterIP: 10.96.0.10"]
128    end
129~
130    subgraph "Pods"
131        B("Pod 1 - IP: 192.168.1.2")
132        C("Pod 2 - IP: 192.168.1.3")
133        D("Pod 3 - IP: 192.168.1.4")
134    end
135~
136    A -- "Selector: app=nginx" --> B
137    A -- "Selector: app=nginx" --> C
138    A -- "Selector: app=nginx" --> D
139~
140    Client -- "Request to nginx-service" --> A
141```
142~
143Service ใช้ `selector` ที่ใช้ `labels` เพื่อค้นหา Pods ที่ควรส่งต่อทราฟฟิก
144~
145วิธีสร้าง Service สำหรับ NGINX Deployment ของเรา:
146~
147```yaml
148# nginx-service.yaml
149apiVersion: v1
150kind: Service
151metadata:
152  name: nginx-service
153spec:
154  selector:
155    app: nginx
156  ports:
157    - protocol: TCP
158      port: 80
159      targetPort: 80
160  type: ClusterIP # Default - exposes the service only within the cluster
161```
162~
163มี Service หลายประเภท:
164- `ClusterIP`: Expose service บน IP ภายใน cluster (ค่าเริ่มต้น)
165- `NodePort`: Expose service บน port คงที่บนแต่ละ Worker Node
166- `LoadBalancer`: สร้าง load balancer ภายนอกใน cloud provider (เช่น AWS, GCP) และกำหนด IP สาธารณะให้ service
167~
168### Ingress
169~
170Service แบบ `LoadBalancer` ดีมาก แต่การสร้างหนึ่งตัวสำหรับแต่ละ service อาจมีราคาแพง เพื่อ expose หลาย service HTTP/HTTPS สู่โลกภายนอก คุณใช้ **Ingress**
171~
172Ingress ทำหน้าที่เป็น "เราเตอร์อัจฉริยะ" สำหรับทราฟฟิกภายนอก ช่วยให้คุณกำหนดกฎเส้นทางตาม host (เช่น `api.mysite.com`) หรือ path (เช่น `mysite.com/api`)
173~
174```mermaid
175graph LR
176    User -- "mysite.com/api" --> Ingress
177    User -- "mysite.com/ui" --> Ingress
178~
179    subgraph "Cluster"
180        Ingress -- "/api" --> ServiceA("api-service")
181        Ingress -- "/ui" --> ServiceB("ui-service")
182~
183        ServiceA --> PodA1("API Pod 1")
184        ServiceA --> PodA2("API Pod 2")
185~
186        ServiceB --> PodB1("UI Pod 1")
187        ServiceB --> PodB2("UI Pod 2")
188    end
189```
190~
191ตัวอย่าง Ingress:
192```yaml
193# example-ingress.yaml
194apiVersion: networking.k8s.io/v1
195kind: Ingress
196metadata:
197  name: example-ingress
198spec:
199  rules:
200  - host: mysite.com
201    http:
202      paths:
203      - path: /api
204        pathType: Prefix
205        backend:
206          service:
207            name: api-service
208            port:
209              number: 8080
210      - path: /ui
211        pathType: Prefix
212        backend:
213          service:
214            name: ui-service
215            port:
216              number: 3000
217```
218~
219### Object ที่เป็นประโยชน์อื่นๆ
220~
221-   **Namespace**: ช่วยให้สร้าง "cluster เสมือน" ภายใน cluster จริง มีประโยชน์สำหรับการแยกสภาพแวดล้อม (เช่น `development`, `staging`, `production`) หรือทีม
222-   **ConfigMap และ Secret**: สำหรับจัดการข้อมูลการกำหนดค่าและความลับ (เช่น รหัสผ่านหรือ API key) แยกจาก container image
223-   **StatefulSet**: คล้ายกับ Deployment แต่เฉพาะสำหรับแอปพลิเคชันที่มีสถานะ (เช่น ฐานข้อมูล) ที่ต้องการ network identity ที่เสถียรและ persistent storage
224-   **PersistentVolume (PV) และ PersistentVolumeClaim (PVC)**: สำหรับจัดการ persistent storage ใน cluster
225~
226## บทสรุป
227~
228Kubernetes เป็นเครื่องมือที่ทรงพลังอย่างเหลือเชื่อ แต่เส้นโค้งการเรียนรู้อาจสูงชัน คู่มือนี้เพียงแตะผิวเผิน แต่หวังว่าจะให้ความเข้าใจที่มั่นคงเกี่ยวกับแนวคิดพื้นฐาน
229~
230**ทำอะไรต่อ?**
231- **ทดลองในเครื่อง**: ติดตั้ง [Minikube](https://minikube.sigs.k8s.io/docs/start/) หรือ [Kind](https://kind.sigs.k8s.io/docs/user/quick-start/) เพื่อสร้าง Kubernetes cluster บนคอมพิวเตอร์ของคุณ
232- **ใช้ `kubectl`**: ทำความคุ้นเคยกับคำสั่ง `kubectl` เครื่องมือหลักของคุณสำหรับการโต้ตอบกับ cluster ลองสร้าง NGINX Deployment และ Service จากบทความนี้
233- **สำรวจบทช่วยสอนอย่างเป็นทางการ**: [เอกสาร Kubernetes](https://kubernetes.io/docs/tutorials/) เป็นแหล่งข้อมูลที่ยอดเยี่ยมเต็มไปด้วยตัวอย่าง
234~
235การจัดการคอนเทนเนอร์เป็นทักษะพื้นฐานในโลก cloud-native และการเชี่ยวชาญ Kubernetes จะเปิดโลกแห่งความเป็นไปได้ สนุกกับมัน!
236~