DevOps

Kubernetes Operator Pattern Guide

📅 2026-02-09 | โดย อ.บอม กิตติทัศน์ เจริญพนาสิทธิ์ — SiamCafe.net Since 1997

Kubernetes Operator Pattern Guide คืออะไร / ทำไมถึงสำคัญ

น้องๆ หลายคนอาจจะเคยได้ยินคำว่า Kubernetes Operator กันมาบ้างแล้ว แต่ยังไม่ค่อย get ว่ามันคืออะไรกันแน่ เอาแบบบ้านๆ เลยนะ Operator มันก็เหมือน "พี่เลี้ยง" ของ Application ที่รันอยู่บน Kubernetes นั่นแหละ

สมัยผมทำร้านเน็ต SiamCafe เนี่ย เราต้องคอยดูแล Server เองทุกอย่าง ตั้งแต่ลง OS, ติดตั้งโปรแกรม, มอนิเตอร์สถานะ จนถึงแก้ปัญหาต่างๆ จุกจิก แต่ Kubernetes Operator มันช่วยให้เรา "Automate" งานพวกนี้ได้เยอะมาก ทำให้เราไม่ต้องมานั่งเฝ้า Server ตลอด 24 ชั่วโมง

ทำไมมันถึงสำคัญ? เพราะมันช่วยลดภาระงานของ DevOps Engineer อย่างเราๆ ไปได้เยอะ ทำให้เรามีเวลาไปโฟกัสกับงานที่สำคัญกว่า เช่น การพัฒนา Feature ใหม่ๆ หรือปรับปรุง Performance ของ Application แทน

พื้นฐานที่ต้องรู้

ก่อนจะไปลงลึกเรื่อง Operator เรามาปูพื้นฐานกันก่อนนิดนึงนะ จะได้ไม่งง

Kubernetes Custom Resources (CRDs)

CRD คือ extension ของ Kubernetes API ที่ช่วยให้เรา define object type ใหม่ๆ ได้เอง สมมติว่าเราอยากจะสร้าง Custom Resource ชื่อว่า "MyApp" เราก็สามารถทำได้โดยการ define CRD ขึ้นมา

เคยไหมสมัยก่อนที่เราต้อง config ไฟล์นู่นนี่นั่นเต็มไปหมด พอมี CRD ทุกอย่างมัน centralized และจัดการง่ายขึ้นเยอะเลย

Kubernetes Controllers

Controller คือ loop ที่คอยมอนิเตอร์สถานะของ Kubernetes Resources ต่างๆ (รวมถึง CRD ที่เราสร้างขึ้นมาด้วย) และพยายามทำให้สถานะปัจจุบันเป็นไปตามที่เราต้องการ (Desired State)

คิดง่ายๆ Controller มันเหมือน "โรบอท" ที่คอยเช็คว่าทุกอย่างเป็นไปตามที่เราสั่งหรือไม่ ถ้าไม่เป็นไปตามนั้น มันก็จะพยายามแก้ไขให้ถูกต้อง

Reconciliation Loop

Reconciliation Loop คือหัวใจสำคัญของ Controller มันคือ loop ที่ Controller ใช้ในการเปรียบเทียบสถานะปัจจุบันกับสถานะที่ต้องการ และทำการเปลี่ยนแปลงเพื่อให้ทั้งสองสถานะตรงกัน

Reconciliation Loop มันเหมือน "แผนที่" ที่บอก Controller ว่าต้องทำอะไรบ้างเพื่อให้ทุกอย่างเป็นไปตามเป้าหมาย

วิธีใช้งาน / เริ่มต้นยังไง

มาถึงส่วนที่หลายคนรอคอย คือวิธีใช้งาน Operator จริงๆ แล้วมันไม่ได้ยากอย่างที่คิดนะ

มี Framework หลายตัวที่ช่วยให้เราสร้าง Operator ได้ง่ายขึ้น เช่น Operator SDK, Kubebuilder, และ Metacontroller แต่ในบทความนี้เราจะเน้นไปที่ Operator SDK เพราะมันค่อนข้าง popular และใช้งานง่าย

ขั้นตอนปฏิบัติจริง

สร้าง Project ด้วย Operator SDK

ขั้นแรก เราต้องติดตั้ง Operator SDK ก่อน จากนั้นเราก็สามารถสร้าง Project ใหม่ได้ด้วย command นี้

operator-sdk new my-app-operator --repo github.com/my-org/my-app-operator

คำสั่งนี้จะสร้าง directory ชื่อ `my-app-operator` ที่มีโครงสร้าง Project ที่จำเป็นสำหรับการสร้าง Operator

Define Custom Resource Definition (CRD)

หลังจากสร้าง Project แล้ว เราต้อง define CRD ที่เราต้องการจะใช้ ตัวอย่างเช่น ถ้าเราต้องการสร้าง CRD สำหรับ "MyApp" เราก็ต้องสร้างไฟล์ YAML ที่ define schema ของ MyApp

สมัยก่อน config อะไรทีต้องแก้ไฟล์นู่นนี่เยอะแยะไปหมด พอมาใช้ CRD ชีวิตง่ายขึ้นเยอะ

Implement Controller Logic

ขั้นตอนสุดท้าย คือการ implement logic ของ Controller ที่จะคอยมอนิเตอร์และจัดการ MyApp Resources เราต้องเขียน code ที่จะ handle event ต่างๆ เช่น การสร้าง, อัพเดท, และลบ MyApp Resources

ส่วนนี้แหละที่ต้องใช้ความรู้ programming นิดหน่อย แต่ Operator SDK ก็มี Tool ที่ช่วย generate code skeleton ให้เราได้เยอะมาก

// Example code snippet (Go)
func (r *MyAppReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
	// Fetch the MyApp instance
	var myApp v1alpha1.MyApp
	if err := r.Get(ctx, req.NamespacedName, &myApp); err != nil {
		if errors.IsNotFound(err) {
			// Object not found, cleanup logic
			return ctrl.Result{}, nil
		}
		// Error reading the object - requeue the request.
		return ctrl.Result{}, err
	}

	// Implement your reconciliation logic here
	// ...

	return ctrl.Result{}, nil
}

เปรียบเทียบกับทางเลือกอื่น

Operator ไม่ใช่ Solution เดียวในการจัดการ Application บน Kubernetes ยังมีทางเลือกอื่นๆ อีก เช่น Helm Charts, Deployment Configs, และ StatefulSets แต่ละทางเลือกก็มีข้อดีข้อเสียแตกต่างกันไป

Helm Charts เหมาะสำหรับ deploy Application ที่ค่อนข้าง static และไม่ต้องการการจัดการที่ซับซ้อน ส่วน Deployment Configs และ StatefulSets เหมาะสำหรับจัดการ Application ที่ต้องการ Scaling และ High Availability แต่ Operator เหมาะสำหรับ Application ที่ต้องการการจัดการที่ Custom และ Dynamic

ลองดูตารางเปรียบเทียบด้านล่างนี้ จะเห็นภาพชัดเจนขึ้น

Feature	Helm Charts	Deployment Configs/StatefulSets	Kubernetes Operators
Complexity	Low	Medium	High
Automation	Limited	Basic	Advanced
Customization	Limited	Medium	High
Use Cases	Simple Deployments	General Purpose Applications	Complex, Statefull Applications

สรุปคือ เลือกใช้เครื่องมือให้เหมาะสมกับงาน ถ้างานง่ายๆ ก็ใช้ Helm Charts ก็พอ แต่ถ้างานซับซ้อน ต้องการ Automation สูงๆ ก็ต้อง Operator นี่แหละ SiamCafe Blog มีบทความเกี่ยวกับ Helm ด้วยนะ ลองไปอ่านดูได้

หวังว่าบทความนี้จะช่วยให้น้องๆ เข้าใจ Kubernetes Operator มากขึ้นนะ ถ้ามีคำถามอะไรเพิ่มเติม ถามมาได้เลย ยินดีตอบเสมอ SiamCafe Blog ยังมีบทความดีๆ อีกเยอะ อย่าลืมแวะไปอ่านกันนะ

Best Practices / เคล็ดลับจากประสบการณ์

Operator Pattern เนี่ย มันเหมือนเราสร้างโปรแกรมเมอร์ AI ส่วนตัว ที่คอยดูแลแอปพลิเคชันของเราบน Kubernetes แบบอัตโนมัติ แต่จะให้มันฉลาดจริง ทำงานได้ดีจริง มันก็มีเคล็ดลับอยู่ครับ สมัยผมทำร้านเน็ตฯ ก็ต้องมีคู่มือดูแลร้านให้ลูกน้องทำตาม ไม่งั้นเจ๊ง! อันนี้ก็เหมือนกัน

Operator ที่ดี ต้องเข้าใจแอปพลิเคชันของเราอย่างลึกซึ้ง ไม่ใช่แค่ restart pod ได้นะ ต้องรู้ว่า config file อยู่ตรงไหน ต้อง back up database ยังไง ต้อง scale ยังไงให้ถูกต้องตามสถานการณ์

3-4 เทคนิคที่ใช้ได้จริง

1. Reconcile Loop ต้อง Idempotent

อันนี้สำคัญมาก! Reconcile loop คือหัวใจของ Operator มันคือ loop ที่คอยเช็คสถานะของแอปฯ เรา แล้วปรับให้เป็นไปตามที่เราต้องการ แต่ถ้ามันไม่ idempotent (ทำซ้ำได้โดยไม่เกิดผลข้างเคียง) ล่ะก็หายนะ! สมมติมันสร้าง database user ซ้ำไปเรื่อยๆ เพราะ error ตอนแรก user ก็เต็ม database สิครับ

# ตัวอย่าง (pseudo-code)
def reconcile(resource):
  # เช็คว่า user มีอยู่แล้วยัง
  if not user_exists(resource.spec.username):
    create_user(resource.spec.username, resource.spec.password)
    # สำคัญ: อย่าลืม set status ว่าสร้าง user แล้ว
    resource.status.user_created = True
  else:
    # user มีแล้วก็ไม่ต้องทำอะไร
    pass

เห็นมั้ยครับว่าเราต้องเช็คก่อนเสมอว่า user มีอยู่แล้วหรือยัง ถ้ามีแล้วก็ไม่ต้องทำอะไรเลย

2. ใช้ Status Field ให้เป็นประโยชน์

Status field ใน Custom Resource เนี่ยแหละ คือที่เก็บข้อมูลสำคัญเกี่ยวกับสถานะของแอปฯ เรา Operator ต้องเขียน status กลับไปเสมอว่าทำอะไรสำเร็จไปแล้วบ้าง ทำอะไรยังไม่สำเร็จ มี error อะไรเกิดขึ้นบ้าง

สมัยผมทำร้านเน็ตฯ เวลาเด็กในร้านทำอะไรพลาด ผมจะให้เขียนรายงานส่งมาเสมอ จะได้รู้ว่าเกิดอะไรขึ้น แล้วเราจะได้แก้ไขได้ถูกจุด Status field ก็เหมือนรายงานนี่แหละ

3. อย่ากลัวที่จะ Break Down ปัญหา

แอปพลิเคชันมันซับซ้อน Operator ก็ซับซ้อนตามไปด้วย อย่าพยายามเขียน Operator ตัวเดียวที่ทำทุกอย่าง ให้แบ่งปัญหาออกเป็นส่วนๆ แล้วสร้าง controller หลายๆ ตัวที่ทำงานร่วมกันจะดีกว่า

เหมือนร้านเน็ตฯ เราก็ต้องมีคนดูแลเครื่อง, คนดูแลลูกค้า, คนดูแลระบบไฟ แต่ละคนก็มีหน้าที่ของตัวเอง

4. Test, Test, Test!

Operator มันคือ code ดังนั้นก็ต้อง test เหมือน code ทั่วไป เขียน unit test, integration test, end-to-end test ให้ครอบคลุมทุกกรณี Test ให้แน่ใจว่า Operator ของเราทำงานได้ถูกต้อง แม้ในสถานการณ์ที่เลวร้ายที่สุด

iCafeForex

FAQ คำถามที่พบบ่อย

Operator มันยากไปไหม? มีวิธีเริ่มง่ายๆ ไหม?

ยากจริงครับ! ยอมรับเลย แต่ก็มีเครื่องมือช่วยเยอะ อย่าง Operator SDK หรือ Kubebuilder ลองเริ่มจาก tutorial ง่ายๆ ก่อน แล้วค่อยๆ ศึกษาไปเรื่อยๆ ครับ

Operator จำเป็นสำหรับทุกแอปพลิเคชันเลยหรือเปล่า?

ไม่จำเป็นครับ ถ้าแอปฯ ของคุณมันง่ายๆ จัดการด้วย Helm chart ก็พอแล้ว Operator เหมาะกับแอปฯ ที่ซับซ้อน ต้องการการจัดการที่ละเอียดมากๆ เท่านั้น

แล้วถ้า Operator พังล่ะ?

นั่นคือเหตุผลที่เราต้อง monitor Operator อย่างใกล้ชิด! ใช้ Prometheus + Grafana มอนิเตอร์ metrics ของ Operator ถ้า Operator เริ่มมีปัญหา ก็ต้องรีบแก้ทันที

Operator มันแพงไหม?

ถ้าคิดแค่ค่า resource ที่ Operator ใช้ มันก็ไม่ได้แพงอะไร แต่ถ้าคิดถึงเวลาและความรู้ที่เราต้องลงทุนไป มันก็อาจจะแพงอยู่เหมือนกัน ต้องชั่งน้ำหนักดูว่าคุ้มค่าหรือเปล่า

สรุป

Operator Pattern เป็นเครื่องมือที่ทรงพลัง แต่ก็ต้องใช้ด้วยความระมัดระวัง ศึกษาให้เข้าใจก่อนลงมือทำจริง แล้วคุณจะพบว่ามันช่วยลดภาระงานของ DevOps ไปได้เยอะมาก SiamCafe Blog สมัยผมทำร้านเน็ตฯ ผมอยากมีเครื่องมือแบบนี้จัง จะได้ไม่ต้องเหนื่อยเฝ้าร้านทั้งวันทั้งคืน!