คู่มือปฏิบัติการ วันที่ 3 | การจัดการ Namespaces และการแยกขอบเขตทรัพยากร (Resource Scoping)

คู่มือปฏิบัติการ • 20–30 นาทีต่อวัน

ยินดีต้อนรับสู่ วันที่ 3: การจัดการ Namespaces และการแยกขอบเขตทรัพยากร (Resource Scoping)!

สำหรับวันนี้ เราจะมาเรียนรู้วิธีการจัดกลุ่มและแบ่งแยกขอบเขตทรัพยากรใน Kubernetes ด้วย Namespaces รวมถึงการใช้ตัวกรองขอบเขตทรัพยากรบน Headlamp UI เพื่อจัดการคลัสเตอร์หลายทีมได้อย่างเป็นระเบียบ

5-10m

ช่วงที่ 1: สรุปแนวคิดสถาปัตยกรรม

เข้าใจบทบาทของ Logical Partitioning และการทำงานของแถบ Namespace Scoping บนหน้าจอ Headlamp

15-20m

ช่วงที่ 2: การลงมือปฏิบัติจริง (5 ขั้นตอน)

สร้าง Namespace แยกทีม ปรับใช้แอปชื่อเดียวกันแต่คนละเนมสเปซ สลับ Filter บน UI และเทียบผลลัพธ์กับ CLI

สรุปแนวคิดและสถาปัตยกรรม (5–10 นาที)

Namespaces: Logical Partitioning

Namespaces เป็นการแบ่งคลัสเตอร์ออกเป็นสัดส่วนทางตรรกะ เพื่อแยกสภาพแวดล้อมออกจากกัน เช่น dev-team, staging-team หรือ production ทำให้เราสามารถตั้งชื่อ Workload ซ้ำกันได้ (เช่น app-v1) โดยไม่เกิดการชนกัน

• ป้องกันความสับสนระหว่างโปรเจกต์ และเตรียมพร้อมสำหรับควบคุมสิทธิ์ RBAC

Namespace Scoping บน Headlamp UI

Headlamp มีแถบ Namespace Selector อยู่บริเวณแถบด้านบนของหน้าจอ ช่วยให้เรากรองดูเฉพาะทรัพยากรในเนมสเปซที่ต้องการทำงานด้วย หรือเลือกดูภาพรวมทั้งหมดผ่านมุมมอง All Namespaces ได้ในคลิกเดียวโดยไม่ต้องพิมพ์คำสั่งยาวๆ

• กรองข้อมูล Deployments, Pods, ConfigMaps และ Services ได้พร้อมกันทั้งหน้าต่าง

ขั้นตอนลงมือปฏิบัติจริง (15–20 นาที)

ติ๊กถูกเมื่อทำแต่ละขั้นตอนเสร็จ

ขั้นตอนที่ 1: สร้าง Namespaces สำหรับแยกทีม Step 1 of 5

เปิด Terminal แล้วสร้าง Namespace ใหม่ 2 ตัวเพื่อจำลองการแยกทีมพัฒนาและทดสอบระบบ:

Terminal Bash • สร้าง Namespaces

kubectl create namespace dev-team
kubectl create namespace staging-team

✓ ผลลัพธ์ที่คาดหวัง: Terminal จะแสดงข้อความยืนยัน namespace/dev-team created และ namespace/staging-team created

ขั้นตอนที่ 2: ปรับใช้ Workloads เข้าไปในแต่ละ Namespace Step 2 of 5

สร้าง Deployment โดยตั้งชื่อแอปพลิเคชันเป็น app-v1 เหมือนกันทั้งคู่ แต่ส่งไปรันคนละ Namespace ด้วยพารามิเตอร์ -n:

Terminal Bash • Deployments with -n Flag

kubectl create deployment app-v1 --image=redis:alpine -n dev-team
kubectl create deployment app-v1 --image=memcached:alpine -n staging-team

สังเกตว่าเราสามารถตั้งชื่อ Deployment ชื่อ app-v1 ซ้ำกันได้โดยไม่ขัดแย้งกัน เพราะถูกกักเขตด้วย Namespace คนละตัว

ขั้นตอนที่ 3: สลับการกรอง Namespace ใน Headlamp UI Step 3 of 5

เปิดหน้าต่าง Headlamp ขึ้นมาเพื่อทดลองใช้แถบตัวกรองเนมสเปซแบบ Graphic:

เปิด Headlamp UI ขึ้นมา (ผ่าน http://localhost:8080 หรือเปิดแอป Headlamp Desktop)
สังเกตแถบ Namespace Selector (ดรอปดาวน์เลือกเนมสเปซ) ที่บริเวณแถบเมนูด้านบน
คลิกเปิดดรอปดาวน์แล้วเลือกเฉพาะ dev-team

เมื่อเลือกแล้ว ทรัพยากรทั้งหมดบนหน้าต่าง Headlamp จะถูก Scope เหลือเฉพาะสิ่งที่อยู่ในเนมสเปซ dev-team เท่านั้น

ขั้นตอนที่ 4: ตรวจสอบการแยกขอบเขตทรัพยากร Step 4 of 5

สำรวจดูว่าตัวกรองของ Headlamp คัดแยกเวิร์กโหลดออกจากกันอย่างถูกต้องหรือไม่:

ไปที่เมนูด้านซ้าย เลือก Workloads > Deployments หรือ Pods
ตรวจสอบว่าในรายการแสดงเฉพาะเวิร์กโหลดของ Redis (dev-team) และ ไม่แสดง Memcached ของ staging-team
ลองคลิกดรอปดาวน์ด้านบนเพื่อสลับตัวกรองไปที่ staging-team
สังเกตว่าตารางจะรีเฟรชเปลี่ยนมาแสดงเฉพาะเวิร์กโหลดของ Memcached ทันที

✓ ข้อดี: ช่วยให้เวลาดูแลแอปพลิเคชัน ไม่ต้องกลัวว่าจะเผลอไปกดลบหรือแก้ไข Pod ของสภาพแวดล้อมอื่นโดยไม่ตั้งใจ

ขั้นตอนที่ 5: ตรวจสอบเปรียบเทียบกับ CLI Step 5 of 5

สลับตัวกรองใน Headlamp ไปที่ All Namespaces แล้วเปรียบเทียบกับคำสั่งรันดู Pods ทั้งหมดใน Cluster ผ่าน Terminal:

Terminal Bash • All Namespaces (-A)

kubectl get pods -A

• จุดสังเกต:

คุณจะเห็นรายชื่อ Pods จากทุก Namespace ในคลัสเตอร์พร้อมๆ กัน รวมถึง kube-system, headlamp, dev-team, และ staging-team ซึ่งสอดคล้องกับมุมมองแบบ All Namespaces ในหน้าต่าง Headlamp พอดี

ภารกิจสำหรับวันที่ 3 (Day 3 Mission)

ลองสร้าง Namespaces และทดสอบสลับตัวกรองบน Headlamp UI ดูนะครับ หากเรียบร้อยแล้วแจ้งได้เลยครับว่าระบบแยกแอปพลิเคชันทั้งสองทีมถูกต้องหรือไม่ เพื่อไปต่อใน วันที่ 4: การจัดการ Manifests แบบ Declarative YAML และการใช้ Headlamp Inline Editor!

ขั้นตอนถัดไป: เตรียมพบกับการเขียนและแก้ไขไฟล์ YAML สดๆ ผ่านตัวแก้ไขโค้ดบน Headlamp ใน วันที่ 4