On Kubernetes Node Sizing

เหมือนเคยเขียนใน Facebook แต่ไม่แน่ใจ จริงๆ ก็อยากเขียนให้มัน scientific ดีๆ ลง blog บริษัท

คำถามที่ไม่มีใครตอบได้อันนึงของ Kubernetes คือ node ใช้ size อะไรดี โดยเฉพาะใน cloud ที่

  • m5.xlarge 4vCPU RAM 16GB ราคา $0.24/hr
  • m5.4xlarge 16vCPU RAM 64GB ราคา $0.96/hr

ซึ่งถ้าซื้อ m5.xlarge 4 เครื่องให้สเปคเท่ากัน มันก็ $0.96/hr อยู่ดี เลยไม่ต่างกันแล้วจะเลือกยังไง…

Fault isolation

ใน design cluster เดิมผมใช้ m5.xlarge รันอยู่

ข้อดีของวิธีนี้คือเครื่องจะเป็น single point of failure น้อย

ข้อเสียคือสมมุติว่าทุกเครื่องมันจะเหลือ CPU ประมาณ 200m เพราะมันไม่มี workload size ที่ลงได้ สมมุติว่าเรามี 10 เครื่องที่เหลือรวมกันก็ 2000m แล้ว ยังไ่มรวม memory

อีกปัญหาหนึ่งคือ workload ที่มัน burst เกิน cpu request ต่อเนื่องจะกลายเป็น noisy neighbour ให้กับ pod ข้างๆ ซึ่งแก้ไม่ได้เพราะบางทีมันก็ burst แป๊บเดียวจริงๆ เช่นตอน start อาจจะโหลดหนักมากแต่ตอนรันใช้ cpu แค่ 20m ถ้าเราใส่ cpu cap ให้มันเป็น 20m ทีนี้ start ทีนึงหลายนาที เผลอๆ connection timeout แล้ว start ไม่ติด (cloud ต่างๆ ใช้ burst model เป็นแบบเป็น credit ซึ่ง Kubernetes ไม่มี)

Bigger the better

ใน cluster ใหม่ ผมกับ director คิดกันว่าควรจะเลือกเครื่อง size ใหญ่ขึ้น

เหตุผลของผมคือเราใช้ AWS ENI ต่อเข้า pod แล้วพอเครื่องใหญ่ขึ้นจะได้ ENI มากขึ้น คิดว่าประมาณ m5.4xlarge กำลังเหมาะเพราะมันจะได้ 234 pod ซึ่งคิดว่า average case แล้วมันไม่น่า่จะอัดกันเครื่องเดียวได้ 234 pod แต่ก็มีบ้างถ้าเครื่องโดน assign แต่ workload เล็กๆ

เหตุผลของ Director ผมคือถ้าเราไปใช้ m5.8xlarge ขึ้นไป เราจะได้การันตี 10Gbps network (ต่ำกว่านี้เป็น up to) ซึ่งคิดว่ามันน่าจะช่วยให้ network เสถียรขึ้น แต่ก็คงใช้เฉพาะใน production เท่านั้น

ข้อเสียคือถ้าเครื่องมันดับ impact จะใหญ่ขึ้นมากๆ และเวลา scale up เครื่องมันจะเหลือ

จากที่ใช้งานมาจริง ก็พบว่า

  • Network มันน่าจะนิ่งและเร็วขึ้น เพราะเครื่องใหญ่แล้วโอกาสที่ workload จะรันอยู่บนเครื่องเดียวกันจะมากขึ้น
  • ส่วนมากคนจะเขียน resource request เป็น p80 ขึ้นไปแต่เวลาใช้งานจริงส่วนมากจะไม่ถึง และ workload บนเครื่องที่หลากหลายขึ้น คิดว่าน่าจะทำให้ในทางปฏิบัติทุก pod สามารถ burst ชน cpu limit ได้ตลอดเวลา เพราะไม่น่าจะมีโอกาสที่ทุก pod จะอยาก burst พร้อมกัน ซึ่งก็จะลดปัญหา noisy neighbor ไปได้
    • Google มี finding คล้ายๆ กันว่าถ้าเครื่องมันใหญ่กว่าขนาดของ workload มากๆ ทุกคนน่าจะสามารถ burst พร้อมกันได้ถ้ามันกระจายตัวดีพอ
  • rolling reboot เร็วขึ้น แต่ก่อน reboot ทั้ง cluster หลายชั่วโมง
  • resource request ส่วนที่เหลือทิ้งของเครื่องที่เต็มยังเท่าเดิมจริง แต่เครื่องมักจะไม่เต็มเพราะ Kubernetes จะเน้นกระจายมากกว่าพยายามอัดให้เต็มเป็นเครื่องๆ ไป ก็เลยเหลือทิ้งอยู่ดี

ไว้ prod เอาขึ้นแล้วน่าจะได้รู้ผลของทฤษฎีกันจริงๆ ว่าจะ work แค่ไหน