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 แค่ไหน

Under the Cloud – EC2

วันก่อนน้องในทีมถามว่า AWS EC2 เป็น VM หรือเปล่า?

คำตอบคือ ใช่ และไม่ใช่

ก็เลยคิดว่าควรจะเขียนบล็อคเล่าสักหน่อยว่าเท่าที่เรารู้ ข้างใต้ Cloud นั้นคืออะไร?

EC2

AWS สมัยแรกๆ ระบบ hypervisor (ที่ใช้ควบคุม VM) ค่อนข้างโจ่งแจ้ง นั่นคือเค้าใช้ Xen ซึ่งเครื่อง type โบราณต่างๆ จะมีให้เลือก virtualization mode ได้สองแบบ คือ

  • PV (Paravirtualization) ซึ่งจะมี overhead น้อยกว่า VM ปกติ แต่ข้อจำกัดคือจะต้องใช้ kernel image พิเศษที่ออกแบบมาสำหรับ Xen โดยเฉพาะ
  • HVM ซึ่งจะจำลอง Hardware ขึ้นมาทั้งหมด ทำให้สามารถรัน OS อะไรก็ได้โดยไม่ต้องดัดแปลง

ต่อมาด้วยความก้าวหน้าของเทคโนโลยี AWS ก็เริ่มแนะนำให้ใช้ HVM มากขึ้น เนื่องจากว่าสะดวกในการใช้งานมากกว่า และ EC2 เองก็เริ่มใช้ hardware มากขึ้น เช่น การ์ด network และ GPU ซึ่งเครื่อง HVM เท่านั้นที่สามารถใช้งาน hardware เหล่านี้ได้โดยตรง (passthrough)

EC2, 2013

ในปี 2013 AWS เปิดตัวเครื่อง C3 ซึ่งมาพร้อมกับระบบ Enhanced Networking ซึ่งเบื้องหลังคือ AWS ซื้อการ์ดเร่งความเร็ว network มาเพิ่ม ซึ่งการ์ดตัวนี้จะเสียบเข้ากับ network card ของจริงอีกทีหนึ่ง แล้ว VM ลูกค้าจะสามารถคุยกับการ์ด network ที่แยกเป็นหลายๆ ใบในระดับ hardware ได้โดยตรงโดยไม่ต้องผ่าน hypervisor ทำให้ประสิทธิภาพสูงเท่ากับ hardware จริง

C3 Enhanced Networking

หลังจาก C3 ออกมาแล้ว AWS ก็เริ่มเปลี่ยนชิ้นถัดไป นั่นคือ EBS หรือระบบ network storage ซึ่งในเครื่อง C4 ก็ได้ใช้ Hardware จากบริษัท Annapurna Labs มาทำให้เครื่องมองเห็น network storage เป็น NVMe (ที่เรานิยมใช้ใน SSD)

แต่ในขณะนั้น NVMe ยังค่อนข้างใหม่ AWS จึงไม่ได้ทำให้เครื่องมองเห็น NVMe โดยตรงแต่ hypervisor จะครอบ NVMe แล้วแปลงเป็น PV แบบเดิมให้อยู่

เนื่องจาก IO ทุกอย่างกลายเป็น hardware หมดแล้ว ทำให้เครื่องไม่ต้องเสีย CPU ไปเพื่อ virtualize IO อีก เครื่อง C4 จึงเปิด EBS Optimized ให้เป็นค่าเริ่มต้น และยังทำให้สามารถขาย CPU core ที่เหลือให้ลูกค้าได้อีกด้วย

C4 – EBS Optimized by Default

หลังจาก C4 แล้ว AWS ก็ออกเครื่อง X1 ที่ใส่ RAM ได้สูงสุด 12TB และ 128 CPU core ซึ่งนอกจากขนาดที่ใหญ่มากแล้ว เครื่อง X1 ยังเป็นรุ่นแรกที่เปลี่ยน driver network จาก Intel 82599 Virtual Function เป็น Elastic Network Adapter (ENA)

ด้านหลังของ ENA นั้นจะเปลี่ยนวิธี virtualize network ไป จากเดิมที่จะมีการ์ด network จริงอันหนึ่งแล้วใช้อีกการ์ดหนึ่งเพื่อแยกเป็นหลายๆ ใบ แต่ใน ENA นั้นจะใช้การ์ด network ที่สามารถ virtualize การ์ดได้เลย

การ์ดใบนี้สร้างโดย Annapurna เช่นกัน แต่ต่างจากเดิมคือ Annapurna กลายเป็นบริษัทในเครือ Amazon ไปแล้ว

X1 – Elastic Network Adapter

เครื่องบน Amazon บางประเภทจะมี storage ภายในเครื่อง (Instance storage) ซึ่งในช่วงเวลานี้ NVMe SSD ก็เป็นที่นิยมแล้ว AWS ก็ได้ออกเครื่อง i3 ที่เชื่อม SSD ทั้งลูกกับเครื่องเรา โดยใช้ hardware เข้ามา encrypt และ monitor การใช้งานอีกที

ก้าวใหญ่มากๆ ของ AWS อยู่ในปี 2017 ที่ออกเครื่อง C5 ขึ้นมา ซึ่ง AWS บอกว่า หลังจากทุกอย่างกลายเป็น hardware หมดแล้ว เค้าจึงเอาระบบ monitoring และ management ต่างๆ ออกไปเป็น hardware ทั้งหมด และตั้งชื่อ hardware ทุกตัวที่เค้าสร้างขึ้นมาในเครื่อง C5 ว่า Nitro

นั่นแปลว่าถ้าเราซื้อเครื่อง c5.18xlarge เราจะได้ทุก CPU Core ของ server ด้านล่างไว้ใช้คนเดียว แต่ก็ยังรันอยู่บน KVM เพื่อ emulate บาง CPU instruction อยู่

C5 – Nitro

อ่านถึงตรงนี้ทุกคนคงจะถามว่าแล้วจะเหลือ Hypervisor ไปทำไม?

ในเวลาเดียวกับที่เปิดตัวเครื่อง C5 AWS ก็เลยเปิดตัวเครื่อง i3.metal มาพร้อมกันด้วย โดยเพิ่มชิพ Nitro Security เข้ามาเพื่อป้องกันการเข้าถึง hardware ด้านล่างบางอย่าง

i3.metal – Bare metal hardware

ดังนั้นผมถึงบอกน้องเค้าว่า EC2 เป็นทั้ง VM และไม่ใช่ VM เพราะถ้าซื้อ C5 ก็ยังเป็น VM บางๆ อยู่ แต่ถ้าซื้อ i3.metal แล้วจะได้ทั้งเครื่องไปใช้คนเดียวเลย

ถึงตรงนี้ก็อยากแนะนำ Talk นี้ที่ผมไปขโมยสไลด์เค้ามาให้ดู ก็ไปฟังเค้าเล่ารายละเอียดกันได้ครับ สนุกมาก

หรือถ้าอยากฟัง Boot process ของเครื่อง i3 ว่าไม่มี VM เลยแล้วจะเปิดเครื่องผ่าน API ได้ยังไง ไปฟัง talk นี้ได้ครับ


ตอนหน้าว่าจะมาเขียนถึง Google Cloud บ้างว่าบริษัทที่ทำมือถือกล้องเดียวแล้วใช้ software ทำในสิ่งที่มือถือเจ้าอื่นต้องใช้ 2 กล้องทำเค้าทำ Cloud ยังไง?