สิ่งที่การสัมภาษณ์งานสอนผมเกี่ยวกับ Kubernetes

 (notnotp.com)
9 คะแนน โดย GN⁺ 8 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Kubernetes กำลังถูกนำมาใช้แม้ในบริษัทขนาดเล็ก ไม่ใช่เพราะความสามารถในการขยายระบบทางเทคนิค แต่เป็นมาตรฐานสำหรับแก้ปัญหาเรื่อง การทำให้รูปแบบการ deploy เป็นแบบเดียวกัน และการดำเนินงานขององค์กร
  • จากการหางานล่าสุด บริษัทที่ได้พูดคุยด้วยต่างก็ใช้ Kubernetes ทั้งหมด ซึ่งต่างจากเมื่อ 5 ปีก่อนที่ยังมีทั้ง VM·serverless·K8s อยู่ร่วมกัน
  • เหตุผลหลักที่ CTO ยกขึ้นมาคือ สามารถ deploy ทุก service ด้วยวิธีเดียวกัน เก็บความรู้ด้านปฏิบัติการไว้ใน YAML และ Helm chart และติดตามประวัติการเปลี่ยนแปลงได้ด้วย GitOps
  • บริษัทขนาดเล็กกำลังยอมรับความซับซ้อนของ Kubernetes ไม่ใช่เพราะฟีเจอร์ขั้นสูงอย่าง HPA, Pod Disruption Budget หรือ node affinity แต่เพราะ ข้อได้เปรียบเชิงองค์กร
  • บริษัทระยะเริ่มต้นควรเริ่มโดยไม่มี Kubernetes เพื่อจะได้โฟกัสกับผลิตภัณฑ์ และความจำเป็นในการนำมาใช้จะเพิ่มขึ้นเมื่อ CTO ไม่ได้เป็นคนทำวิศวกรรมเพียงคนเดียวอีกต่อไป

การเปลี่ยนแปลงที่เห็นจากการหางานล่าสุด

  • ระหว่างการหางานล่าสุด หลังจากอ่านประกาศรับสมัคร สัมภาษณ์ และพูดคุยกับทีมวิศวกรรมราวสิบสองแห่ง ผลคือทุกบริษัทที่ได้คุยต่างก็ใช้ Kubernetes
  • ตอนหางานเมื่อ 5 ปีก่อน ยังมีทั้งกลุ่มที่ใช้ Kubernetes แบบพบไม่บ่อย กลุ่มที่ใช้ systemd บน VM/VPS/EC2 และกลุ่ม serverless อย่าง Lambda กับ Cloud Run อยู่พร้อมกัน
  • ที่ทำงานปัจจุบันมีปัญหาระดับ Big Tech จึงชัดเจนว่า Kubernetes เหมาะสม แต่ก็น่าแปลกใจที่แม้แต่สตาร์ตอัป 10 คนที่มีแค่สอง service ก็ยังใช้ Kubernetes
  • บริษัทที่ได้คุยด้วยไม่ได้รัน microservices หรืออยู่ในสภาพแวดล้อมที่ใกล้เคียงกับสเกลสูง และก็ไม่ได้สนใจด้านเทคนิคของ Kubernetes มากนัก

เหตุผลในการเลือกใช้ Kubernetes และเกณฑ์การตัดสินใจ

  • ทำไมถึงใช้ Kubernetes

    • เหตุผลแรกคือ uniformity และเมื่อทุก service ถูก deploy ด้วยวิธีเดียวกัน ก็จะไม่เกิดสถานการณ์ที่มีเฉพาะบาง service เท่านั้นที่ยังผูกติดอยู่กับ bash script บน bare VM รุ่นเก่าหรือ Docker Compose
    • เหตุผลที่สองคือ ความรู้ที่แชร์ต่อได้และใช้ในการจ้างงานได้ และเมื่อ Kubernetes ถูกใช้เสมือนเป็นภาษากลาง แค่ดู Helm chart และการตั้งค่า Kube ก็สามารถเข้าใจสถาปัตยกรรมได้อย่างรวดเร็ว
    • หากความรู้ไม่ได้อยู่ในหัวของคน แต่อยู่ใน YAML ก็จะลดกรณีที่คนมารับช่วงต่อหลังมีคนลาออกต้องใช้เวลาหลายสัปดาห์เพื่อทำความเข้าใจวิธีรันระบบ
    • SRE ที่เข้าเวร on-call ในบริษัทปัจจุบันสามารถดูแล service ที่ไม่เคยเห็นมาก่อนได้ เพราะรูปแบบ Kubernetes ของแต่ละทีมคล้ายกัน
    • ข้อดีนี้จะเกิดขึ้นได้ก็ต่อเมื่อการตั้งค่าไม่ได้พิเศษหรือแหวกแนวเกินไป
    • เหตุผลที่สามคือ ความสามารถในการติดตามย้อนหลัง โดยแทนที่จะรัน kubectl apply -f ใส่ cluster โดยตรง ก็อัปโหลด Helm chart ขึ้น git จากนั้นผ่านการอนุมัติ MR และ deploy ด้วย FluxCD หรือ ArgoCD ทำให้มีประวัติการเปลี่ยนแปลงเหลืออยู่
    • กระบวนการแบบนี้ช่วยเรื่อง compliance แทบไม่มีต้นทุนเพิ่ม เพราะ GitOps กับ Kubernetes เข้ากันได้อย่างเป็นธรรมชาติ
    • บริษัทปัจจุบันก็กำลังผ่านการรับรอง ISO ได้ดีด้วยวิธีนี้

  • ข้อสรุปที่ได้

    • การตัดสินใจของ CTO ไม่ใช่การเลือกที่โง่เขลา แต่เป็นวิธีแก้ปัญหาจริง
    • Kubernetes ดูเหมือนเป็นคำตอบทางเทคนิคสำหรับปัญหาทางเทคนิค แต่ CTO จำนวนมากสนใจ ข้อดีที่ไม่ใช่เชิงเทคนิค มากกว่าที่คาดไว้
    • ปัญหาทางเทคนิคของบริษัทขนาดเล็กไม่ได้ถึงขั้นต้องมี Kubernetes เสมอไป และมีความเป็นไปได้สูงว่าใน manifest ของพวกเขาจะไม่มี topologySpreadConstraints, HPA, Pod Disruption Budget หรือกฎ node affinity
    • พวกเขายังคงรักษาจำนวน node ไว้ใกล้เคียงกับตอนใช้ VM แต่ยอมรับต้นทุนในการดูแลซอฟต์แวร์ที่ซับซ้อนกว่าเพื่อแลกกับข้อดีเชิงองค์กร

  • ทำไมการเปลี่ยนผ่านถึงเกิดขึ้นในช่วงนี้

    • เมื่อ 5 ปีก่อน VM กับ systemd, serverless และ Kubernetes ยังเป็นตัวเลือกทั้งหมด แต่ตอนนี้ในประกาศรับสมัครงาน แทบไม่เห็นคู่ VM กับ systemd แล้ว ส่วน serverless ก็ยังอยู่ในตลาดเฉพาะทาง และ Kubernetes เป็นฝ่ายชนะ
    • เหตุผลของจังหวะการเปลี่ยนผ่านนี้ยังไม่แน่ชัดทั้งหมด
    • เหตุผลที่เป็นไปได้คือ managed Kubernetes อย่าง EKS, GKE และ AKS โตเต็มที่แล้ว และจำนวนคนที่เรียนรู้ Kubernetes ก็เพิ่มขึ้นมากจนการจ้างคนไปใช้แนวทางอื่นกลับยากกว่า
    • Helm ทำให้การใช้ chart ที่คนอื่นสร้างไว้ตรง ๆ กลายเป็นตัวเลือกที่ใช้งานได้จริง

  • เมื่อไรควรใช้ Kubernetes

    • เกณฑ์ส่วนตัวคือช่วงที่ CTO ไม่ได้เป็นวิศวกรเพียงคนเดียวอีกต่อไป
    • เมื่อวิศวกรคนที่สองเข้าร่วม จะมีคนที่ต้อง deploy โดยไม่ได้เป็นผู้ตั้งค่าเซิร์ฟเวอร์เอง และจำเป็นต้องมีการควบคุมสิทธิ์เข้าถึงที่เหมาะสม แทนการแจก SSH key ให้ทุกอย่าง
    • สุดท้ายแล้วใครบางคนก็ต้องออกจากบริษัท และความรู้ด้านปฏิบัติการที่อยู่กับคนนั้นก็อาจหายไปด้วย
    • ตั้งแต่จุดนี้เป็นต้นไป ความรู้ควรอยู่ใน ระบบ มากกว่าอยู่ในตัวบุคคล
    • แต่ก่อนจะถึงขั้นนั้น การ debug cluster นั้นยากจริง และอาจทำให้เอาพลังงานที่ควรใช้กับผลิตภัณฑ์ไปลงกับโครงสร้างพื้นฐานแทน
    • เมื่อเทียบกับการต้องใช้เวลาสองชั่วโมงหาสาเหตุของ pod ที่ติด CrashLoopBackOff ก่อนคุยกับลูกค้ารายใหญ่ การแก้ฉุกเฉินด้วย git pull บน VPS อาจเร็วกว่าและเข้าใจง่ายกว่า

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

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

 
GN⁺ 8 시간 전
ความคิดเห็นจาก Lobste.rs

  • ฝั่งยุโรปมีเหตุผลที่ชัดเจนอยู่ CTO เชื่อว่า ถ้ารันบน K8s ก็สามารถเปลี่ยนผู้ให้บริการ Managed K8s ได้ภายในไม่กี่สัปดาห์
    ไม่ได้แปลว่านั่นถูกต้อง แต่พวกเขาเชื่อกันแบบนั้นจริง ๆ และยังคิดว่าสภาพแวดล้อม PR จะง่ายขึ้นด้วย
    แต่ประเด็นหลักคือการย้ายผู้ให้บริการ ในอีกไม่กี่ปีข้างหน้าคาดว่าจะมีการ ห้ามใช้ผู้ให้บริการที่เชื่อมโยงกับสหรัฐฯ โดยเฉพาะในเรื่อง GDPR, ระบบการเงิน ฯลฯ เลยเตรียมรับความเสี่ยงนั้นไว้

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

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

  • เครื่องมือ deploy ที่ซับซ้อนมากพอ สุดท้ายก็มักจะมี Kubernetes เวอร์ชันครึ่ง ๆ กลาง ๆ ที่ทำขึ้นแบบชั่วคราว นิยามกันแบบไม่เป็นทางการ มีบั๊กเยอะ และช้า รวมอยู่ด้วย

    • คำว่า “ครึ่ง ๆ” ก็ถูกนะ เพียงแต่ครึ่งนั้นดันเป็น ครึ่งที่จำเป็น
      ผมเล่าได้ยาวเลยว่าในปี 2009 เขาจัดระบบบริษัท SaaS อีคอมเมิร์ซมูลค่าพันล้านดอลลาร์กันอย่างไร หรือแบ็กเอนด์ออนไลน์ของเกม AAA แบบมัลติเพลเยอร์ขนาดมหึมาทำงานกันอย่างไร ซึ่งสิ่งเหล่านั้นใกล้เคียงกับ Kubernetes มากกว่าการ deploy ลงเครื่องเดียวแน่นอน
      แต่มันเร็วกว่า และมีจุดยืนที่ชัดเจนในแบบที่องค์กรต้องการจริง ๆ ไม่ใช่ในแบบที่ไปขัดกับข้อกำหนดของผลิตภัณฑ์
      ความ “บั๊กเยอะ” ของ Kubernetes มักไม่ได้มาจากตัวระบบหลักเองเท่าไร แต่มาจาก ชั้นอินเทอร์เฟซ จำนวนมากที่เราวางทับลงไปเพื่อบังคับให้มันทำงานแบบที่เราต้องการ
    • นี่เป็นเรื่องของ Erlang ไม่ใช่ Kubernetes ใช้กับ Kubernetes แล้วไม่เข้าท่าเลย

  • ปัญหาคือองค์กรส่วนใหญ่เอา K8s มาใช้แบบครึ่ง ๆ กลาง ๆ มีทีม DevOps มาดูแล แต่สุดท้ายก็ยังโยนงานเขียนที่เกี่ยวกับ K8s, การ deploy, การ debug และการปฏิบัติการทั้งหมดให้วิศวกรซอฟต์แวร์อยู่ดี
    ถ้าเป็นทีม DevOps ที่ดี ก็ควรให้ประสบการณ์แบบ Heroku ภายในองค์กรได้ กำหนด resource ที่ต้องใช้แล้ว merge เข้า main จากนั้นก็ควร deploy ได้เลย ไม่ใช่ต้องไปงมหาว่าอะไรพังในแดชบอร์ด GitOps/DevOps ห่วย ๆ
    Heroku เคยเป็นจุดสูงสุดของประสบการณ์นักพัฒนา และหลังจากยุค K8s เราก็สูญเสียสิ่งนั้นไป

    • นอกจากการที่เราเห็น Pod รันอยู่บนโหนดแล้ว ผมไม่ค่อยเข้าใจว่าความต่างใหญ่ ๆ ของ ประสบการณ์ใช้งาน Heroku กับ Kubernetes คืออะไร
      แน่นอนว่า Heroku ให้ประสบการณ์ที่บูรณาการกว่าทั้งการเชื่อมฐานข้อมูลหรือการ deploy ด้วย git push แต่การทำเปลือกครอบแบบคัสตอมบน Kubernetes ก็ไม่ค่อยเวิร์ก สุดท้ายมันก็มักต้องปล่อยพารามิเตอร์ทั้งหมดทะลุผ่านอยู่ดี

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

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

  • ผมไม่ได้ทำ DevOps มากนัก ตอนนี้ระบบก็ทำงานได้ดีด้วยแค่ systemd กับคอนเทนเนอร์ podman ที่ใช้เป็นครั้งคราว ทำงานอยู่สาย IoT/AgTech
    บทความนี้มี “คำกล่าวอ้าง” แบบที่ได้ยินจากผู้บริหารที่ไม่ใช่สายเทคนิคบ่อย ๆ ประมาณว่า “ฝั่งนั้นก็ใช้ LoRa ใช่ไหม? งั้นก็โอเคสิ? พรุ่งนี้ออกได้เลยใช่ไหม?”
    มีความเชื่อว่า ความไม่เป็นเนื้อเดียวกันคืออุปสรรคเดียวของความสำเร็จ ถ้าสองระบบใช้ Fiber, Modbus หรือมี “API” ก็จะเอามาต่อกันได้ทันทีและสร้างประสบการณ์เจ๋ง ๆ แบบ “1 + 1 มากกว่าผลรวม” ได้
    แต่การที่ซอฟต์แวร์สองตัวตกลงใช้มาตรฐานการทำงานร่วมกันระดับต่ำเหมือนกัน ไม่ได้แปลว่างานจริงในการตัดสินใจว่าจะตีความข้อมูลที่ parse ได้ง่ายนั้นอย่างไรและจะใช้มันให้เกิดประโยชน์อย่างไรจะหายไป
    แค่คนสองคนพูดภาษาเดียวกันได้ ไม่ได้แปลว่าไม่มีอะไรต้องทำต่อ และการใช้ภาษาร่วมกันก็ไม่ได้ทำให้การตัดสินใจที่ทีมบางส่วนเคยทำไว้ภายใต้เงื่อนไขและเครื่องมือในตอนนั้นหายไปด้วย
    ในยุคแรก ๆ Fortran เคยเป็นภาษากลางในวงการวิทยาศาสตร์/วิศวกรรม แต่ก็ไม่ได้ทำให้คนไม่งงกับงานที่เพื่อนร่วมงานทำไว้หรือไม่ต้องเขียนใหม่
    ผมไม่ได้มีปัญหากับคุณค่าของ K8s หรือการที่มันกลายเป็น “มาตรฐาน” ในปัจจุบัน แค่ยากจะเห็นด้วยกับคำกล่าวอ้างว่ามันทำให้ปัญหาการเขียนโปรแกรมบางประเภทหายไป กฎการอนุรักษ์ความอัปลักษณ์ ยังอยู่เหมือนเดิม

  • Kubernetes เป็น แพลตฟอร์มสำหรับ deploy ที่ใช้ได้ทีเดียว

  • รูปแบบการ deploy ก็เป็นอีกเหตุผลหนึ่ง ผมทำงานกับ Canton node โดยซอฟต์แวร์ Canton ต้นน้ำและแอปที่เกี่ยวข้องถูกแจกมาเป็น Helm chart
    ไม่ว่าจริง ๆ แล้ว Kubernetes จะเหมาะกับงานของเราหรือไม่ ซึ่งผมมองว่าไม่ มันก็คือวิธีที่ซอฟต์แวร์นี้ถูก deploy และมีการซัพพอร์ต ถ้าออกนอกเส้นทางนั้น งานจะยิ่งมากกว่าการต้องรับมือกับ Kubernetes เอง

  • มีผมคนเดียวหรือเปล่าที่รู้สึกว่าบทความนี้เหมือน AI เขียนมากเกินไป
    ถึงอย่างนั้นผมก็เห็นด้วยกับเจตนาหลัก ตอนนี้กำลังย้ายชุดโฮมแล็บ/เซลฟ์โฮสต์ของตัวเองออกจากสภาพที่เป็น systemd config แบบคัสตอม คำสั่งเชลล์ที่จำไม่ได้ และ “ให้ตายสิ ผมเขียนขั้นตอนตั้งค่านั่นไว้ในไฟล์ Markdown ไหนนะ?” ซึ่งรู้สึกสดชื่นมาก
    ยังไม่ได้ใช้ระบบ continuous deployment จริงจังหรอก แต่แค่มีเชลล์สคริปต์ apply เล็ก ๆ กับชุดไฟล์ YAML ก็ให้ความรู้สึกดีว่าต่อให้เกิดภัยพิบัติก็น่าจะกู้กลับมาได้ 90%
    systemd นั้นเรียบง่ายในเชิงแนวคิด แต่ ความสามารถในการทำซ้ำได้ ซับซ้อน ส่วน Kubernetes กลับกัน คุณจ่ายต้นทุนเชิงแนวคิดมากกว่า แต่ได้ความสามารถในการทำซ้ำและความเข้าใจที่ตามมาซึ่งแข็งแรงกว่ามาก อย่างน้อยตอนนี้ผมมองแบบนั้น
    ผมยังอยู่ในช่วงกลาง ๆ ของการเรียนรู้ Kubernetes แต่ช่วงนี้ก็สนุกกับมันพอสมควร

    • ถ้าเป็นเมื่อ 10 ปีก่อนผมคงเห็นด้วย แต่ตอนนี้ systemd เองก็รู้สึกเหมือน “สัตว์ประหลาดอีกตัว” เพราะมี ตัวเลือก namespace หลากหลายและการผสานผู้ใช้แบบไดนามิก
      การบูรณาการแนวดิ่งที่มีนิยามแบบ first-class ลักษณะนี้ดูเหมือนจะเป็นทิศทางที่ผิด
    • จะเขียนโดย AI หรือไม่ไม่ค่อยสำคัญ สิ่งสำคัญคือเขียนออกมาดีหรือไม่