คู่มือสำหรับคนที่ไม่ชอบ Kubernetes

 (paulbutler.org)
31 คะแนน โดย GN⁺ 2024-03-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

คู่มือเชิงวิพากษ์เกี่ยวกับ Kubernetes

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

เหตุผลที่ใช้ Kubernetes

  • Kubernetes เป็นทางเลือกที่ผ่านการใช้งานมาดีที่สุดเมื่อคุณต้องการทั้งสามอย่างต่อไปนี้พร้อมกัน:
    • ต้องการรันหลายโปรเซส/หลายเซิร์ฟเวอร์/งานตามเวลาที่กำหนด
    • ต้องการให้สิ่งเหล่านี้ทำงานแบบซ้ำซ้อนและกระจายโหลด
    • ต้องการกำหนดค่าของสิ่งเหล่านี้และความสัมพันธ์ระหว่างกันด้วยโค้ด
  • Kubernetes คือชั้น abstraction ที่ทำให้สามารถมองพูลของคอมพิวเตอร์เป็นเหมือนคอมพิวเตอร์ไร้หัวเครื่องเดียวได้
  • Jamsocket deploy วันละหลายครั้ง และหากมีปัญหาในผลิตภัณฑ์ก็จะกระทบต่อผลิตภัณฑ์ของลูกค้าด้วย จึงได้ความมั่นใจในการ deploy บ่อย ๆ ผ่าน rolling deployment

วิธีที่ใช้ Kubernetes

  • Jamsocket เป็นบริการที่สร้างโปรเซสแบบไดนามิกที่สื่อสารกับเว็บแอปได้ คล้ายกับ AWS Lambda แต่ช่วงอายุของโปรเซสไม่ได้ผูกกับคำขอ/คำตอบเพียงครั้งเดียว แต่ผูกกับการเชื่อมต่อ WebSocket
  • Kubernetes ถูกใช้เพื่อรันโปรเซสระยะยาว เช่น API server, container registry, controller, log collector, บริการ DNS บางส่วน และการเก็บ metrics
  • สิ่งที่ไม่ใช้ Kubernetes: โปรเซสชั่วคราว, เว็บไซต์แบบ static/marketing, สิ่งที่เก็บข้อมูลโดยตรง
  • ใช้ Google Kubernetes Engine เพื่อมอบหมายการดูแล Kubernetes ออกไปภายนอก และหากจำเป็นก็ย้ายไป Amazon EKS ได้ค่อนข้างง่าย

ทรัพยากร Kubernetes ที่ใช้งานอย่างจริงจัง

  • Deployments: Pod ส่วนใหญ่ถูกสร้างผ่าน deployment
  • Services: ใช้ ClusterIP สำหรับบริการภายใน และ LoadBalancer สำหรับบริการภายนอก
  • CronJobs: ใช้สำหรับสคริปต์ทำความสะอาด เป็นต้น
  • ConfigMaps และ Secrets: ใช้เพื่อส่งข้อมูลให้กับทรัพยากรด้านบน

สิ่งที่ใช้อย่างระมัดระวัง

  • ใช้ StatefulSet และ PersistentVolumeClaim อยู่ แต่ต้องการเก็บข้อมูลสำคัญไว้ในบริการแบบ managed ที่อยู่นอก Kubernetes มากกว่า
  • พยายามหลีกเลี่ยง RBAC ให้มากที่สุด เพราะมันเพิ่มความซับซ้อน

สิ่งที่หลีกเลี่ยงอย่างจริงจัง

  • การเขียน YAML ด้วยมือ: ใช้ TypeScript และ Pulumi ในการสร้าง definition ของทรัพยากร Kubernetes
  • ทรัพยากรที่ไม่เป็นมาตรฐานและ operator: แม้จะทำให้ซอฟต์แวร์จาก third-party ใช้โครงสร้างพื้นฐานของ Kubernetes ได้ แต่ในทางปฏิบัติใช้งานยาก
  • Helm: ไม่ใช้เพราะมี operator และกฎของ YAML
  • ทุกสิ่งที่มีคำว่า "mesh" อยู่ในชื่อ: มองว่าไม่จำเป็น
  • ทรัพยากร Ingress: หลีกเลี่ยงการเพิ่มชั้นอ้อมที่ไม่จำเป็น
  • การจำลองทั้งสแตกของ k8s ไว้บนเครื่อง local: ใช้ Docker Compose หรือสคริปต์ของตัวเองเพื่อสตาร์ตเฉพาะบางส่วนของระบบที่จำเป็น

มนุษย์ไม่ควรต้องรอ Pod

  • Kubernetes ถูกออกแบบมาโดยเน้นความทนทานและความเป็นโมดูลาร์มากกว่าเวลาเริ่มต้นของ container จึงไม่เหมาะกับกรณีที่มนุษย์ต้องรอให้ Pod เริ่มทำงาน
  • Jamsocket ใช้ Plane ซึ่งเป็น Rust orchestrator ภายใต้สัญญาอนุญาต MIT เพื่อจัดตารางและรันโปรเซสอย่างรวดเร็วสำหรับ interactive workload

abstraction ระดับสูงกว่า

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

ความเห็นของ GN⁺

  • แม้ Kubernetes จะเป็นเครื่องมือทรงพลังด้านการจัดการความซับซ้อนและระบบอัตโนมัติ โดยเฉพาะในระบบขนาดใหญ่ แต่ความซับซ้อนของมันก็อาจเป็นภาระสำหรับโปรเจกต์ขนาดเล็กหรือสตาร์ทอัป
  • บทความนี้เสนอวิธีหลีกเลี่ยงความซับซ้อนเกินจำเป็นที่อาจเกิดขึ้นเมื่อใช้ Kubernetes ช่วยให้ผู้เริ่มต้นหรือทีมเล็ก ๆ ใช้ประโยชน์จาก Kubernetes ได้
  • ก่อนใช้ Kubernetes ควรพิจารณาความสามารถที่จำเป็นจริง ๆ และศักยภาพทางเทคนิคของทีม เพื่อประเมินอย่างรอบคอบถึงความซับซ้อนในการดูแล ต้นทุน และประโยชน์ที่ได้รับ
  • บางครั้งการใช้บริการที่ง่ายกว่าและดูแลง่ายกว่าก็อาจดีกว่า Kubernetes เช่น Docker Swarm, Apache Mesos, Nomad เป็นต้น ซึ่งแต่ละตัวมีข้อดีข้อเสียต่างกัน
  • เมื่อนำ Kubernetes มาใช้ ควรคำนึงถึงการผสานรวมกับโครงสร้างพื้นฐานเดิม ความปลอดภัย ต้นทุนการดูแล และเส้นโค้งการเรียนรู้
  • ประโยชน์ที่ได้จากการเลือก Kubernetes คือความสามารถในการขยายระบบ ความพร้อมใช้งานสูง และประสบการณ์การ deploy ที่สม่ำเสมอในสภาพแวดล้อมคลาวด์ที่หลากหลาย อย่างไรก็ตาม ก็จำเป็นต้องมีความเข้าใจเรื่องการจัดการทรัพยากรและ orchestration ที่เกี่ยวข้องด้วย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-04
ความเห็นจาก Hacker News

  • สรุปความเห็นแรก:

    • เมื่อนำระบบที่ซับซ้อนอย่าง Kubernetes มาใช้ ความซับซ้อนนั้นมักขยายตัวต่อเนื่อง จนคอมโพเนนต์หลากหลายส่วนคอยเสริมกันและกันและถูกมองว่าเป็นสิ่งจำเป็น
    • ตอนที่คลาวด์เริ่มเกิดขึ้นใหม่ ๆ ผู้คนรู้สึกดึงดูดกับการลดความซับซ้อนของ load balancer และการดูแลฐานข้อมูล
    • app server แบบ stateless ไม่ได้เป็นปัญหาใหญ่ด้านการดูแลรักษาอยู่แล้ว แต่การเผยแพร่แนวคิด microservices กลับสร้างปัญหาที่เดิมไม่มีขึ้นมา
    • ตอนนี้วัฒนธรรมแบบนี้ได้ฝังรากแล้ว จึงยากที่จะพยักหน้าเห็นด้วยกับคำกล่าวที่ว่า microservices เป็นสิ่งจำเป็น

  • สรุปความเห็นที่สอง:

    • ในฐานะคนที่นำ Kubernetes ไปใช้ในบริษัทขนาดกลางและขนาดเล็ก แม้จะมีวิศวกรที่ไม่พอใจอยู่บ้าง แต่ส่วนใหญ่ตอบว่าพอใจ
    • Kubernetes มีความซับซ้อน แต่ก็เป็นเครื่องมือที่เหมาะกับปัญหาที่ซับซ้อน
    • การมีมาตรฐานย่อมดีกว่าความวุ่นวายแบบเรียบง่ายที่ไม่ได้มีการจัดทำเอกสารไว้ และ "kubectl explain X" ก็อ้างว่าดีกว่าเอกสารของ AWS มาก
    • แม้ Kubernetes จะซับซ้อน แต่ก็ทำงานเหมือนกับที่นักพัฒนาเคยใช้ในบริษัทก่อนหน้า และความเร็วเป็นสิ่งสำคัญ

  • สรุปความเห็นที่สาม:

    • แม้การวิจารณ์ Kubernetes จะกำลังเป็นกระแส แต่มันก็ยังเป็นโซลูชันที่ดีที่สุดอยู่ดี
    • สามารถกำหนดโครงสร้างพื้นฐานแบบ declarative ได้ และมี load balancing, auto-healing และ scaling ให้
    • ให้ observability ที่ยอดเยี่ยมครอบคลุมทั้งสแตก และยังใช้ซอฟต์แวร์ที่แพ็กเกจไว้ล่วงหน้าได้มากมาย
    • สามารถสร้างโครงสร้างพื้นฐานที่แทบเหมือนกันได้ทั้งบนคลาวด์ เซิร์ฟเวอร์ของตัวเอง และสภาพแวดล้อม local จึงไม่ผูกติดกับผู้ให้บริการคลาวด์รายใดรายหนึ่ง

  • สรุปความเห็นที่สี่:

    • ข้อดีสำคัญของ Kubernetes คือ Helm หรือ Operators
    • ถ้าต้องจ่ายต้นทุนของความซับซ้อน ก็ควรได้ประโยชน์จาก 'app store' ของคอมโพเนนต์โครงสร้างพื้นฐาน และการจัดการ operations แบบโปรแกรมได้
    • ตัวอย่างเช่น หากต้องตั้งค่าระบบที่ซับซ้อนอย่าง Ceph, Rook เป็นวิธีที่ดี
    • Helm หรือ Operators ไม่ได้ทำให้โครงสร้างพื้นฐานกลายเป็นอุปกรณ์ managed แบบ 'turnkey' แต่โดยทั่วไปแล้วอินเทอร์เฟซแบบ declarative จะจัดการได้ดีกว่า

  • สรุปความเห็นที่ห้า:

    • Kubernetes เป็นเทคโนโลยีที่ดี แต่ความซับซ้อนทำให้ผู้ดูแลรักษามักกลายเป็นฮีโร่ของบริษัท
    • การปรับแต่งและคันโยกจำนวนมากอาจทำให้หลุดโฟกัสจากเป้าหมายที่แท้จริงของโปรเจ็กต์ได้

  • สรุปความเห็นที่หก:

    • บริษัทปัจจุบันแบ่งออกเป็นระบบ deploy แบบคัสตอมที่ใช้ Kubernetes และ Ansible เป็นฐาน
    • วิธีแบบ Ansible ก็ทำงานได้ดี แต่การย้ายไป Kubernetes ช่วยลดเวลา deploy จากหลายชั่วโมงเหลือไม่กี่นาที และทำ auto-scaling ได้เร็วและมีประสิทธิภาพมากขึ้น
    • ความยากในการหาสาเหตุของการ deploy Helm ที่ล้มเหลว และความจำเป็นต้องเรียนรู้รูปแบบการปฏิบัติงานใหม่ เป็นเสียงสะท้อนที่ได้ยินอย่างสม่ำเสมอจากทีมที่ย้ายมาก่อนหน้า

  • สรุปความเห็นที่เจ็ด:

    • จากบทสนทนากับอดีตวิศวกร Site Reliability ของ Google มีการบอกว่าบริษัทที่ต้องใช้ Kubernetes จริง ๆ นั้นมีน้อยมาก
    • หลายคนมีแนวโน้มจะพัฒนาตามกระแส

  • สรุปความเห็นที่แปด:

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

  • สรุปความเห็นที่เก้า:

    • การเขียน YAML โดยตรงอาจเป็นปัญหาได้ จึงใช้ TypeScript และ Pulumi เพื่อสร้างนิยาม resource ของ Kubernetes แทน
    • แทนที่จะ lint YAML ก็กลับต้องนำ runtime ของภาษาโปรแกรมเต็มรูปแบบและไลบรารีจาก third party เข้ามา พร้อมรับความซับซ้อนเพิ่ม เช่น การดูแลเวอร์ชันและการคอมไพล์โปรเจ็กต์

  • สรุปความเห็นที่สิบ:

    • ในฐานะคนที่เคยหลงใหลใน Kubernetes ส่วนที่ดีของ Kubernetes คือองค์ประกอบพื้นฐานอย่าง deployments, services, configmaps และที่เหลือควรใช้เฉพาะในสถานการณ์พิเศษ
    • ทีมชอบเขียน YAML แบบดิบและใช้ kustomize เพื่อให้การตั้งค่าชัดเจนและตรงไปตรงมา