เพื่อนรัก นายได้สร้าง Kubernetes ขึ้นมาแล้ว

• จดหมายถึงเพื่อน

  • อธิบายว่าแม้จะพยายามหลีกเลี่ยง Kubernetes แต่สุดท้ายก็ลงเอยด้วยการสร้างระบบที่คล้ายกันขึ้นมา
  • เพื่อนเลือกใช้ "เทคโนโลยีที่น่าเบื่อ" และต้องการเพียงการรันคอนเทนเนอร์แบบง่าย ๆ แต่สุดท้ายกลับเกิดปัญหาจากสคริปต์และการตั้งค่าที่ซับซ้อน
  • แม้จะเปลี่ยนไปใช้ Docker Compose ก็ไม่สามารถแก้ทุกปัญหาได้ และตระหนักว่าจำเป็นต้องมีโซลูชันแยกต่างหากสำหรับการดีพลอย, rolling update, rollback และการสเกล

• การขยายเซิร์ฟเวอร์และความซับซ้อนของเครือข่าย

  • เริ่มรู้สึกถึงความจำเป็นที่จะต้องขยายไปยังเซิร์ฟเวอร์เครื่องที่สอง
  • พยายามใช้โอเวอร์เลย์เน็ตเวิร์กอย่าง Tailscale เพื่อทำ service discovery
  • แม้จะพยายามแก้ปัญหาความซับซ้อนของเครือข่าย แต่สุดท้ายก็ต้องเผชิญกับปัญหาเพิ่มขึ้นอีก

• การบำรุงรักษาและระบบอัตโนมัติ

  • เกิดคำถามขึ้นมาว่า หากคนที่เขียนสคริปต์ลาพักร้อนหรือออกจากบริษัท ใครจะเป็นผู้ดูแลการตั้งค่าที่ซับซ้อนและการเปลี่ยนแปลงคอนฟิกที่ไม่มีการบันทึกเอกสารไว้
  • เพื่อแก้ปัญหาการบำรุงรักษาของสคริปต์แบบคัสตอม จึงใช้ Ansible เพื่อทำให้ VM มีลักษณะ immutable และสามารถจัดการเวอร์ชันได้
  • คิดว่าการไม่ใช้ Kubernetes น่าจะทำให้ดูแลรักษาได้ง่ายกว่า

• การสร้างคอนเทนเนอร์และปัญหาด้านความปลอดภัย

  • มีความต้องการใหม่ที่ต้องสร้างคอนเทนเนอร์อื่นขึ้นมาแบบเป็นโปรแกรม
  • การเมานต์ Docker socket เข้ากับเว็บแอปมีความเสี่ยงด้านความปลอดภัย จึงเขียนบริการแยกต่างหากเพื่อแก้ปัญหานี้
    • แก้ปัญหาโดยเขียนบริการแยกต่างหากที่เปิดเผยเฉพาะส่วนที่ปลอดภัยของ Docker API

• บทสรุป

  • ท้ายที่สุดก็ตระหนักว่าตัวเองได้สร้างระบบที่คล้าย Kubernetes ขึ้นมาแล้ว
    • ได้ระบบที่ซับซ้อนครบชุดซึ่งรวมถึงฟอร์แมตคอนฟิกมาตรฐาน, วิธีดีพลอย, โอเวอร์เลย์เน็ตเวิร์ก, service discovery, immutable node และ API server

• PS

  • ไม่ได้ปฏิเสธความเป็นไปได้ว่าอาจมีโซลูชันที่ดีกว่าสำหรับแทน Kubernetes
  • เพียงแต่อยากแนะนำว่า ก่อนจะตัดสินว่า Kubernetes ซับซ้อนเกินไป ควรทำความเข้าใจปัญหาที่มันถูกสร้างมาเพื่อแก้ให้เพียงพอก่อน

[savvykang]

ผมไม่ค่อยเข้าใจเท่าไหร่ว่าทำไมถึงบอกว่านำ Kubernetes มาใช้เพื่อแก้ปัญหาการส่งมอบงานด้านการดีพลอย

[kandk]

การบำรุงรักษาและระบบอัตโนมัติทำได้ง่ายในระดับโค้ด
และยังทำ Infra as code ได้ด้วย

[savvykang]

ในสภาพแวดล้อมของบริการ k8s แบบ managed อย่าง EKS มีทั้ง load balancer และยังเชื่อมต่อกับ Route 53 ได้ แต่พอเป็น k8s ที่ self-host กลับไม่มีทั้ง implementation ของ load balancer และการเชื่อมต่อ DNS ก็มีข้อจำกัดครับ ในบริษัทที่มีทีมดูแล k8s แยกต่างหาก ข้อดีที่คุณพูดถึงอาจจะเป็นจริงก็ได้

ฟังเผินๆ เหมือนจะเป็นโซลูชันที่โอเค แต่พอใช้จริงแล้วไม่ได้ทำงานได้ในทุกสถานการณ์

[kandk]

ใช้งานได้ง่ายแม้ไม่มีทีมดูแล k8s ใช้ EKS ก็พอแล้ว

[savvykang]

มันก็ไม่ต่างจากการอ้างว่าแค่ให้ซอร์สโค้ดมาก็ถือว่าส่งต่องานเสร็จแล้วไม่ใช่หรือครับ? ผมว่ายังไงก็ยังจำเป็นต้องมีคู่มือการทำงานกับประวัติการดำเนินงานอยู่ดีนะครับ

[kbumsik]

Infra as Code เองก็มีไว้เพื่อให้จบได้แค่ส่งซอร์สโค้ดมาเท่านั้นอยู่แล้วนี่ครับ
อ้อ แน่นอนว่าไม่ว่าโค้ดไหน ๆ ก็ควรต้องมีการจัดทำเอกสารพื้นฐานไว้เหมือนกันครับ

[kandk]

ถ้าซอร์สโค้ดเขียนมาอย่างดีและเอกสารทำไว้ดี ก็เป็นไปได้ครับ
ถ้ามีคู่มือการทำงานกับประวัติการดำเนินงานแยกไว้ต่างหากก็คงช่วยได้ แต่ดูเหมือนว่านั่นจะเป็นอีกเรื่องหนึ่งจากบทความนี้นะครับ

[GN⁺]

ความคิดเห็นจาก Hacker News

• เคยมีประสบการณ์ทำดีพลอยให้สำเร็จด้วย shell script ในหลายบริษัท

  • มีบริการ PHP 2 ตัวที่รองรับคำขอมากกว่า 1 พันล้านครั้งต่อวัน และทำดีพลอยแบบไม่มีดาวน์ไทม์ด้วยการส่งไฟล์ขึ้นเซิร์ฟเวอร์และรัน migration
  • ในอุตสาหกรรมที่ไม่ต้องการ web scale เช่น บัญชีเกษียณอายุ มีการดีพลอยผ่าน Jenkins ด้วยคำสั่ง Docker
  • สามารถเตรียมสภาพแวดล้อมทดสอบให้พร้อมใช้งานตามต้องการได้ภายในไม่กี่นาที
  • บริษัทปัจจุบันกำลังพยายามนำ Kubernetes มาใช้ แต่ติดปัญหาเพราะความซับซ้อน

• Kubernetes ต้องมีคนเฉพาะทาง 2-3 คนคอยดูแลไฟล์ YAML

  • ถ้าเลือกผู้ให้บริการคลาวด์ก็ช่วยจัดการส่วนที่ซับซ้อนได้ แต่ต้องจ่ายเพิ่ม
  • ไฟล์ YAML เป็นไฟล์คอนฟิกที่ไม่ควรให้คนเขียนเอง แต่ควรให้เครื่องมือสร้างขึ้นมา
  • เว็บไซต์และบริการส่วนใหญ่ไม่ได้จำเป็นต้องใช้ Kubernetes

• แนวคิดที่ว่าสิ่งที่เรียบง่ายย่อมเปราะบางนั้นเป็นความเข้าใจที่ผิด

  • การทำความเข้าใจและดีบักความซับซ้อนของไฟล์ YAML และ Kubernetes นั้นยากกว่า
  • ทางเลือกแทน Kubernetes คือ shell script

• มีหลายกรณีที่ไม่จำเป็นต้องใช้ Kubernetes

  • ใช้ EC2 instance กับ shell script แบบง่าย ๆ ก็รองรับผู้ใช้พร้อมกันได้มากกว่า 100,000 คน
  • ถ้าไม่มีปัญหา ก็ไม่จำเป็นต้องเปลี่ยน

• shell script ช่วยจัดการกฎ iptables และการแก้ไข sysctl ได้ง่าย

  • สามารถ push งานผ่านคิวงานได้ แทนการสร้างคอนเทนเนอร์แบบ programmatic

• การวิจารณ์ Kubernetes ไม่ใช่เรื่องไม่มีความเป็นมืออาชีพ

  • ถ้าไม่ได้เป็นแอปพลิเคชันขนาดใหญ่ระดับ Google หรือ Netflix การเขียนสคริปต์ง่าย ๆ จะดีกว่า

• สมมติฐานที่ว่าข้อจำกัดของระบบที่ทำขึ้นใช้เองล้วนแปลเป็นต้นทุน และความยืดหยุ่นของโซลูชันแบบอเนกประสงค์ล้วนเป็นข้อดีนั้นไม่ถูกต้อง

  • คุณย่อมอยากให้โค้ดเบสใช้แพตเทิร์นที่คล้ายกัน และให้บริการต่าง ๆ ถูกดีพลอยด้วยวิธีเดียวกัน

• ปัญหาของ Kubernetes คือมีไลบรารีโอเพนซอร์สจำนวนมากจนทำให้ระบบเข้าใจได้ยากและก่อให้เกิดบั๊ก

• คนที่ผ่านช่วงการเรียนรู้ของ Kubernetes มาแล้วมักบอกว่าความซับซ้อนไม่ได้แย่อย่างที่คิด

  • การสอน Kubernetes ให้กับนักพัฒนาใช้เวลาประมาณ 30 นาที และทำให้พวกเขาเขียน Helm chart ได้