Kubernetes: เพิ่มความเร็วบริการของคุณโดยลบขีดจำกัดของ CPU

ย้อนกลับไปในปี 2016 พวกเราอยู่ที่ Buffer เปลี่ยนไปใช้ Kubernetesและตอนนี้มีโหนดประมาณ 60 โหนด (บน AWS) และคอนเทนเนอร์ 1500 คอนเทนเนอร์ที่ทำงานบนคลัสเตอร์ k8s ของเราที่จัดการโดย คอปส์. อย่างไรก็ตาม เราเปลี่ยนไปใช้ไมโครเซอร์วิสผ่านการลองผิดลองถูก และแม้หลังจากทำงานกับ k8 มาหลายปี เราก็ยังต้องเผชิญกับปัญหาใหม่ ในโพสต์นี้เราจะพูดถึง ข้อจำกัดของโปรเซสเซอร์: ทำไมเราถึงคิดว่ามันเป็นแนวปฏิบัติที่ดีและทำไมพวกเขาถึงไม่ดีนัก

ข้อจำกัดของโปรเซสเซอร์และการควบคุมปริมาณ

เช่นเดียวกับผู้ใช้ Kubernetes คนอื่นๆ Google ขอแนะนำอย่างยิ่งให้ตั้งค่าขีดจำกัดของ CPU. หากไม่มีการตั้งค่าดังกล่าว คอนเทนเนอร์ในโหนดจะใช้พลังงานตัวประมวลผลทั้งหมดได้ ซึ่งจะทำให้เกิดกระบวนการ Kubernetes ที่สำคัญ (เช่น kubelet) จะหยุดตอบสนองต่อคำขอ ดังนั้น การตั้งค่าขีดจำกัดของ CPU จึงเป็นวิธีที่ดีในการปกป้องโหนดของคุณ

ขีดจำกัดของตัวประมวลผลจะตั้งค่าคอนเทนเนอร์ให้เป็นเวลา CPU สูงสุดที่สามารถใช้ได้ในช่วงเวลาที่กำหนด (ค่าเริ่มต้นคือ 100 มิลลิวินาที) และคอนเทนเนอร์จะไม่เกินขีดจำกัดนี้ ใน Kubernetes สำหรับ การควบคุมปริมาณ และป้องกันไม่ให้เกินขีดจำกัดจึงใช้เครื่องมือพิเศษ โควต้า CFSแต่ขีดจำกัด CPU ปลอมเหล่านี้กลับส่งผลเสียต่อประสิทธิภาพและเพิ่มเวลาตอบสนองของคอนเทนเนอร์ของคุณ

จะเกิดอะไรขึ้นหากเราไม่กำหนดขีดจำกัดของโปรเซสเซอร์

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

การแสดงปัญหาการควบคุมปริมาณและการตอบสนอง

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

ดังที่คุณเห็นด้านล่าง เราได้กำหนดขีดจำกัดไว้ที่ 800m (แกนหลัก 0.8 หรือ 80%) และค่าสูงสุดที่เข้าถึงได้ดีที่สุด 200m (แกน 20%) ดูเหมือนว่าก่อนที่จะควบคุมปริมาณบริการ เรายังมีพลังประมวลผลเหลือเฟือ อย่างไรก็ตาม...

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

เมื่อเผชิญกับสิ่งนี้ ในไม่ช้า เราก็ค้นพบแหล่งข้อมูลหลายประการ (ปัญหาบน GitHub, การนำเสนอเกี่ยวกับซาดาโน, โพสต์บน omio) เกี่ยวกับประสิทธิภาพและเวลาตอบสนองที่ลดลงของบริการเนื่องจากการควบคุมปริมาณ

เหตุใดเราจึงเห็นการควบคุมปริมาณเมื่อโหลด CPU ต่ำ เวอร์ชันย่อคือ: “มีข้อบกพร่องในเคอร์เนล Linux ที่ทำให้คอนเทนเนอร์ควบคุมปริมาณโดยไม่จำเป็นตามขีดจำกัดโปรเซสเซอร์ที่ระบุ” หากคุณสนใจลักษณะของปัญหาสามารถอ่านการนำเสนอได้ (วีดีโอ и ข้อความ ตัวเลือก) โดย Dave Chiluk

การลบข้อ จำกัด ของ CPU (ด้วยความระมัดระวังอย่างยิ่ง)

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

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

การติดต่อทางธุรกิจในประเด็นเร่งด่วน

จะปกป้องโหนดของคุณเมื่อข้อจำกัดถูกยกเลิกได้อย่างไร

การแยกบริการ “ไม่จำกัด”:

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

เราตัดสินใจวางบริการดังกล่าวไว้ในโหนดแยกต่างหาก ("ติดป้ายกำกับ") เพื่อไม่ให้รบกวนบริการ "ที่เกี่ยวข้อง" ด้วยเหตุนี้ ด้วยการทำเครื่องหมายบางโหนดและเพิ่มพารามิเตอร์ความอดทนให้กับบริการที่ "ไม่เกี่ยวข้อง" เราจึงสามารถควบคุมคลัสเตอร์ได้มากขึ้น และการระบุปัญหาเกี่ยวกับโหนดก็ง่ายขึ้นสำหรับเรา หากต้องการดำเนินการตามกระบวนการที่คล้ายกันด้วยตนเอง คุณสามารถทำความคุ้นเคยได้ เอกสาร.

การกำหนดคำขอโปรเซสเซอร์และหน่วยความจำที่ถูกต้อง:

ความกลัวที่ใหญ่ที่สุดของเราคือกระบวนการจะใช้ทรัพยากรมากเกินไป และโหนดจะหยุดตอบสนองต่อคำขอ ตั้งแต่ตอนนี้ (ต้องขอบคุณ Datadog) เราสามารถตรวจสอบบริการทั้งหมดบนคลัสเตอร์ของเราได้อย่างชัดเจน ฉันจึงวิเคราะห์การดำเนินงานหลายเดือนของบริการที่เราวางแผนจะกำหนดให้เป็น “ไม่เกี่ยวข้อง” ฉันเพียงตั้งค่าการใช้งาน CPU สูงสุดด้วยระยะขอบ 20% และจัดสรรพื้นที่ในโหนดในกรณีที่ k8s พยายามกำหนดบริการอื่น ๆ ให้กับโหนด

ดังที่คุณเห็นในกราฟ ถึงภาระสูงสุดของโปรเซสเซอร์แล้ว 242m แกน CPU (แกนประมวลผล 0.242) สำหรับคำขอตัวประมวลผล ก็เพียงพอที่จะใช้ตัวเลขที่มากกว่าค่านี้เล็กน้อย โปรดทราบว่าเนื่องจากบริการมีผู้ใช้เป็นศูนย์กลาง ค่าโหลดสูงสุดจึงตรงกับการรับส่งข้อมูล

ทำเช่นเดียวกันกับการใช้หน่วยความจำและการสืบค้น และ voila - คุณพร้อมแล้ว! เพื่อความปลอดภัยที่มากขึ้น คุณสามารถเพิ่มการปรับขนาดพ็อดแนวนอนอัตโนมัติได้ ดังนั้น ทุกครั้งที่โหลดทรัพยากรสูง การปรับขนาดอัตโนมัติจะสร้างพ็อดใหม่และ kubernetes จะกระจายพ็อดเหล่านั้นไปยังโหนดที่มีพื้นที่ว่าง ในกรณีที่ไม่มีพื้นที่เหลือในคลัสเตอร์ คุณสามารถตั้งค่าการแจ้งเตือนให้ตัวเองหรือกำหนดค่าการเพิ่มโหนดใหม่ผ่านการปรับขนาดอัตโนมัติได้

ข้อเสียเป็นที่น่าสังเกตว่าเราแพ้ใน”ความหนาแน่นของภาชนะ", เช่น. จำนวนคอนเทนเนอร์ที่ทำงานบนโหนดเดียว นอกจากนี้เรายังอาจมี "การผ่อนคลาย" มากมายที่ความหนาแน่นของการรับส่งข้อมูลต่ำ และยังมีโอกาสที่คุณจะเข้าถึงโหลดตัวประมวลผลสูง แต่โหนดปรับขนาดอัตโนมัติน่าจะช่วยได้

ผลการวิจัย

ฉันยินดีที่จะเผยแพร่ผลลัพธ์ที่ยอดเยี่ยมเหล่านี้จากการทดสอบในช่วงสองสามสัปดาห์ที่ผ่านมา เราได้เห็นการปรับปรุงที่สำคัญในการตอบสนองต่อบริการที่ปรับเปลี่ยนทั้งหมดแล้ว:

เราได้รับผลลัพธ์ที่ดีที่สุดในหน้าแรกของเรา (buffer.com) มีการเร่งให้บริการเข้ามา ยี่สิบสองครั้ง!

ข้อผิดพลาดเคอร์เนล Linux ได้รับการแก้ไขแล้วหรือไม่

ใช่ จุดบกพร่องได้รับการแก้ไขแล้วและเพิ่มการแก้ไขลงในเคอร์เนลแล้ว การแจกแจงเวอร์ชัน 4.19 และสูงกว่า

อย่างไรก็ตาม เมื่อได้อ่าน ปัญหา Kubernetes บน GitHub สำหรับวันที่ 2020 กันยายน XNUMX เรายังคงพบการกล่าวถึงโครงการ Linux บางโครงการที่มีข้อบกพร่องคล้ายกัน ฉันเชื่อว่าลีนุกซ์บางรุ่นยังคงมีข้อบกพร่องนี้ และกำลังดำเนินการแก้ไขอยู่

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

• Debian: แก้ไขรวมเข้ากับเวอร์ชันล่าสุดของการแจกจ่าย มือปราบและดูค่อนข้างสด (สิงหาคม 2020). เวอร์ชันก่อนหน้าบางเวอร์ชันอาจได้รับการแก้ไขด้วย
• Ubuntu: แก้ไขการรวมเข้ากับเวอร์ชันล่าสุด อูบุนตูโฟกัส Fossa 20.04
• EKS ได้รับการแก้ไขแล้ว ในเดือนธันวาคม 2019. หากเวอร์ชันของคุณต่ำกว่านี้ คุณควรอัปเดต AMI
• คอปส์: ตั้งแต่เดือนมิถุนายน 2020 у kops 1.18+ อิมเมจโฮสต์หลักจะเป็น Ubuntu 20.04 หาก kops เวอร์ชันของคุณเก่ากว่า คุณอาจต้องรอการแก้ไข พวกเราเองกำลังรออยู่ตอนนี้
• GKE (Google Cloud): แก้ไขแบบรวม ในเดือนมกราคม 2020แต่มีปัญหาเรื่องการควบคุมปริมาณ ยังคงเฝ้าสังเกตอยู่.

จะทำอย่างไรถ้าการแก้ไขแก้ไขปัญหาการควบคุมปริมาณได้

ฉันไม่แน่ใจว่าปัญหาได้รับการแก้ไขอย่างสมบูรณ์ เมื่อเราไปถึงเวอร์ชันเคอร์เนลพร้อมการแก้ไข ฉันจะทดสอบคลัสเตอร์และอัปเดตโพสต์ หากใครอัพเดตแล้ว ผมสนใจอ่านผลของคุณครับ

ข้อสรุป

• หากคุณทำงานกับคอนเทนเนอร์ Docker ภายใต้ Linux (ไม่ว่าจะเป็น Kubernetes, Mesos, Swarm หรืออื่นๆ) คอนเทนเนอร์ของคุณอาจสูญเสียประสิทธิภาพเนื่องจากการควบคุมปริมาณ
• ลองอัปเดตการแจกจ่ายของคุณเป็นเวอร์ชันล่าสุดโดยหวังว่าข้อผิดพลาดจะได้รับการแก้ไขแล้ว
• การลบขีดจำกัดของโปรเซสเซอร์จะช่วยแก้ปัญหาได้ แต่นี่เป็นเทคนิคอันตรายที่ควรใช้ด้วยความระมัดระวังอย่างยิ่ง (ควรอัปเดตเคอร์เนลก่อนและเปรียบเทียบผลลัพธ์จะดีกว่า)
• หากคุณลบขีดจำกัดของ CPU ออก ให้ตรวจสอบการใช้งาน CPU และหน่วยความจำของคุณอย่างระมัดระวัง และตรวจสอบให้แน่ใจว่าทรัพยากร CPU ของคุณเกินปริมาณการใช้งานของคุณ
• ตัวเลือกที่ปลอดภัยคือการปรับขนาดพ็อดอัตโนมัติเพื่อสร้างพ็อดใหม่ในกรณีที่มีการโหลดฮาร์ดแวร์สูง เพื่อให้ kubernetes กำหนดให้โหนดว่าง

ฉันหวังว่าโพสต์นี้จะช่วยคุณปรับปรุงประสิทธิภาพของระบบคอนเทนเนอร์ของคุณ

PS ที่นี่ ผู้เขียนสอดคล้องกับผู้อ่านและผู้วิจารณ์ (เป็นภาษาอังกฤษ)


ที่มา: will.com