ในช่วงหลายปีที่ผ่านมา ผู้ใช้ Pinterest 300 ล้านคนได้สร้างพินมากกว่า 200 พันล้านพินบนบอร์ดมากกว่า 4 พันล้านบอร์ด เพื่อรองรับกลุ่มผู้ใช้และฐานเนื้อหาที่กว้างขวาง พอร์ทัลได้พัฒนาบริการหลายพันรายการ ตั้งแต่ไมโครเซอร์วิสที่สามารถจัดการได้ด้วย CPU เพียงไม่กี่ตัว ไปจนถึงเสาหินขนาดยักษ์ที่ทำงานบนกลุ่มเครื่องเสมือนทั้งหมด และแล้วช่วงเวลานั้นก็มาถึงเมื่อบริษัทจ้องมองไปที่ k8s เหตุใด “คิวบ์” จึงดูดีบน Pinterest คุณจะได้เรียนรู้เกี่ยวกับสิ่งนี้จากการแปลบทความล่าสุดของเราจาก .
ผู้ใช้หลายร้อยล้านคนและพินนับแสนล้าน เพื่อให้บริการแก่ผู้ใช้จำนวนมากและฐานเนื้อหาที่กว้างขวาง เราได้พัฒนาบริการหลายพันรายการ ตั้งแต่ไมโครเซอร์วิสที่สามารถจัดการได้ด้วย CPU เพียงไม่กี่ตัว ไปจนถึงเสาหินขนาดยักษ์ที่ทำงานบนฟลีตของเครื่องเสมือนทั้งหมด นอกจากนี้ เรายังมีเฟรมเวิร์กที่หลากหลายที่อาจต้องใช้การเข้าถึง CPU, หน่วยความจำ หรือ I/O
ในการรักษาสวนสัตว์แห่งเครื่องมือนี้ไว้ ทีมพัฒนาเผชิญกับความท้าทายหลายประการ:
- ไม่มีวิธีที่เหมือนกันสำหรับวิศวกรในการจัดการสภาพแวดล้อมการผลิต บริการไร้สัญชาติ บริการ stateful และโครงการที่อยู่ระหว่างการพัฒนาอยู่บนพื้นฐานของกลุ่มเทคโนโลยีที่แตกต่างกันโดยสิ้นเชิง สิ่งนี้นำไปสู่การสร้างหลักสูตรการฝึกอบรมทั้งหมดสำหรับวิศวกร และยังทำให้การทำงานของทีมโครงสร้างพื้นฐานของเรามีความซับซ้อนอย่างมากอีกด้วย
- นักพัฒนาที่มีเครื่องเสมือนเป็นของตัวเองสร้างภาระมหาศาลให้กับผู้ดูแลระบบภายใน ด้วยเหตุนี้ การดำเนินการง่ายๆ เช่น การอัปเดต OS หรือ AMI จึงใช้เวลาหลายสัปดาห์หรือหลายเดือน สิ่งนี้นำไปสู่ภาระงานที่เพิ่มขึ้นในสถานการณ์ที่ดูเหมือนทุกวัน
- ความยากลำบากในการสร้างเครื่องมือการจัดการโครงสร้างพื้นฐานระดับโลกนอกเหนือจากโซลูชันที่มีอยู่ สถานการณ์มีความซับซ้อนมากขึ้นเนื่องจากการค้นหาเจ้าของเครื่องเสมือนไม่ใช่เรื่องง่าย นั่นคือเราไม่ทราบว่าความสามารถนี้สามารถดึงออกมาอย่างปลอดภัยเพื่อดำเนินการในส่วนอื่น ๆ ของโครงสร้างพื้นฐานของเราได้หรือไม่
ระบบการจัดการคอนเทนเนอร์เป็นวิธีหนึ่งในการรวมการจัดการปริมาณงานเข้าด้วยกัน พวกเขาเปิดประตูเพื่อเพิ่มความเร็วในการพัฒนาและทำให้การจัดการโครงสร้างพื้นฐานง่ายขึ้น เนื่องจากทรัพยากรทั้งหมดที่เกี่ยวข้องกับโครงการได้รับการจัดการโดยระบบรวมศูนย์ระบบเดียว
รูปที่ 1: ลำดับความสำคัญของโครงสร้างพื้นฐาน (ความน่าเชื่อถือ ประสิทธิภาพการทำงานของนักพัฒนา และประสิทธิภาพ)
ทีมแพลตฟอร์มการจัดการระบบคลาวด์ที่ Pinterest ค้นพบ K8 ในปี 2017 ภายในครึ่งแรกของปี 2017 เราได้บันทึกความสามารถด้านการผลิตส่วนใหญ่ของเราแล้ว รวมถึง API และเว็บเซิร์ฟเวอร์ทั้งหมดของเรา หลังจากนั้น เราได้ดำเนินการประเมินระบบต่างๆ อย่างละเอียดเพื่อประสานโซลูชันคอนเทนเนอร์ การสร้างคลัสเตอร์ และการทำงานร่วมกับโซลูชันเหล่านั้น ในช่วงปลายปี 2017 เราตัดสินใจใช้ Kubernetes มันค่อนข้างยืดหยุ่นและได้รับการสนับสนุนอย่างกว้างขวางในชุมชนนักพัฒนา
จนถึงปัจจุบัน เราได้สร้างเครื่องมือการบูตคลัสเตอร์ของเราเองโดยใช้ Kops และย้ายส่วนประกอบโครงสร้างพื้นฐานที่มีอยู่ เช่น เครือข่าย ความปลอดภัย ตัวชี้วัด การบันทึก การจัดการข้อมูลประจำตัว และการรับส่งข้อมูลไปยัง Kubernetes นอกจากนี้เรายังใช้ระบบการสร้างแบบจำลองภาระงานสำหรับทรัพยากรของเรา ซึ่งความซับซ้อนนี้ถูกซ่อนไม่ให้นักพัฒนาเห็น ตอนนี้เรามุ่งเน้นไปที่การรับรองเสถียรภาพของคลัสเตอร์ การปรับขนาดและการเชื่อมต่อลูกค้าใหม่
Kubernetes: วิถีแห่ง Pinterest
การเริ่มต้นใช้งาน Kubernetes ในระดับ Pinterest ในฐานะแพลตฟอร์มที่วิศวกรของเราชื่นชอบมาพร้อมกับความท้าทายมากมาย
ในฐานะบริษัทขนาดใหญ่ เราได้ลงทุนจำนวนมากในเครื่องมือโครงสร้างพื้นฐาน ตัวอย่างได้แก่ เครื่องมือรักษาความปลอดภัยที่จัดการการประมวลผลใบรับรองและการแจกจ่ายคีย์ ส่วนประกอบควบคุมการรับส่งข้อมูล ระบบค้นหาบริการ ส่วนประกอบการมองเห็น และส่วนประกอบการจัดส่งบันทึกและตัวชี้วัด ทั้งหมดนี้ถูกรวบรวมด้วยเหตุผล: เราผ่านเส้นทางปกติของการลองผิดลองถูก ดังนั้นเราจึงต้องการรวมอุปกรณ์ทั้งหมดนี้เข้ากับโครงสร้างพื้นฐานใหม่บน Kubernetes แทนที่จะสร้างวงล้อเก่าขึ้นมาใหม่บนแพลตฟอร์มใหม่ แนวทางนี้ทำให้การย้ายข้อมูลโดยรวมง่ายขึ้น เนื่องจากมีการสนับสนุนแอปพลิเคชันทั้งหมดอยู่แล้ว และไม่จำเป็นต้องสร้างใหม่ตั้งแต่ต้น
ในทางกลับกัน โมเดลการคาดการณ์โหลดใน Kubernetes เอง (เช่น การใช้งาน งาน และชุด Daemon) นั้นไม่เพียงพอสำหรับโปรเจ็กต์ของเรา ปัญหาด้านการใช้งานเหล่านี้เป็นอุปสรรคสำคัญในการเปลี่ยนไปใช้ Kubernetes ตัวอย่างเช่น เราได้ยินมาว่านักพัฒนาบริการบ่นว่าการตั้งค่าการเข้าสู่ระบบหายไปหรือไม่ถูกต้อง นอกจากนี้เรายังพบการใช้เอ็นจิ้นเทมเพลตที่ไม่ถูกต้อง เมื่อมีการสร้างสำเนาหลายร้อยชุดด้วยคุณสมบัติและงานเดียวกัน ซึ่งส่งผลให้เกิดปัญหาการแก้ไขจุดบกพร่องฝันร้าย
นอกจากนี้ยังเป็นเรื่องยากมากที่จะรักษาเวอร์ชันต่างๆ ไว้ในคลัสเตอร์เดียวกัน ลองจินตนาการถึงความซับซ้อนของการสนับสนุนลูกค้า หากคุณต้องการทำงานพร้อมกันในสภาพแวดล้อมรันไทม์เดียวกันหลายเวอร์ชัน พร้อมปัญหา ข้อบกพร่อง และการอัปเดตทั้งหมด
คุณสมบัติผู้ใช้และตัวควบคุมของ Pinterest
เพื่อให้วิศวกรของเราใช้งาน Kubernetes ได้ง่ายขึ้น และเพื่อลดความซับซ้อนและเพิ่มความเร็วให้กับโครงสร้างพื้นฐาน เราได้พัฒนาคำจำกัดความทรัพยากรที่กำหนดเอง (CRD) ของเราเอง
CRD มีฟังก์ชันการทำงานดังต่อไปนี้:
- การรวมทรัพยากร Kubernetes ดั้งเดิมที่แตกต่างกันเพื่อให้ทำงานเป็นภาระงานเดียว ตัวอย่างเช่น ทรัพยากร PinterestService ประกอบด้วยการปรับใช้งาน บริการเข้าสู่ระบบ และแผนผังการกำหนดค่า ช่วยให้นักพัฒนาไม่ต้องกังวลกับการตั้งค่า DNS
- ใช้การสนับสนุนแอปพลิเคชันที่จำเป็น ผู้ใช้จำเป็นต้องมุ่งเน้นเฉพาะข้อมูลจำเพาะของคอนเทนเนอร์ตามตรรกะทางธุรกิจของตน ในขณะที่ตัวควบคุม CRD ใช้งานคอนเทนเนอร์ init ที่จำเป็นทั้งหมด ตัวแปรสภาพแวดล้อม และข้อกำหนดเฉพาะของพ็อด สิ่งนี้มอบความสะดวกสบายในระดับที่แตกต่างกันโดยพื้นฐานสำหรับนักพัฒนา
- ตัวควบคุม CRD ยังจัดการวงจรชีวิตของทรัพยากรดั้งเดิมและปรับปรุงความพร้อมในการดีบัก ซึ่งรวมถึงการกระทบยอดข้อกำหนดที่ต้องการและตามความเป็นจริง การอัปเดตสถานะ CRD และการรักษาบันทึกเหตุการณ์ และอื่นๆ หากไม่มี CRD นักพัฒนาจะถูกบังคับให้จัดการทรัพยากรหลายรายการ ซึ่งจะยิ่งเพิ่มโอกาสที่จะเกิดข้อผิดพลาดเท่านั้น
นี่คือตัวอย่างของ PinterestService และทรัพยากรภายในที่จัดการโดยผู้ควบคุมของเรา:
ดังที่คุณเห็นข้างต้น เพื่อรองรับคอนเทนเนอร์แบบกำหนดเอง เราจำเป็นต้องผสานรวมคอนเทนเนอร์เริ่มต้นและส่วนเสริมต่างๆ เพื่อมอบความปลอดภัย การมองเห็น และการรับส่งข้อมูลเครือข่าย นอกจากนี้ เรายังสร้างเทมเพลตแผนที่การกำหนดค่าและใช้การสนับสนุนเทมเพลต PVC สำหรับงานแบบแบตช์ รวมถึงการติดตามตัวแปรสภาพแวดล้อมหลายตัวเพื่อติดตามข้อมูลประจำตัว การใช้ทรัพยากร และการรวบรวมขยะ
เป็นเรื่องยากที่จะจินตนาการว่านักพัฒนาต้องการเขียนไฟล์การกำหนดค่าเหล่านี้ด้วยมือโดยไม่รองรับ CRD ไม่ต้องพูดถึงการบำรุงรักษาและดีบักการกำหนดค่าเพิ่มเติม
เวิร์กโฟลว์การปรับใช้แอปพลิเคชัน
รูปภาพด้านบนแสดงวิธีปรับใช้ทรัพยากรที่กำหนดเองของ Pinterest กับคลัสเตอร์ Kubernetes:
- นักพัฒนาโต้ตอบกับคลัสเตอร์ Kubernetes ของเราผ่าน CLI และอินเทอร์เฟซผู้ใช้
- เครื่องมือ CLI/UI จะดึงไฟล์ YAML การกำหนดค่าเวิร์กโฟลว์และคุณสมบัติบิลด์อื่นๆ (ID เวอร์ชันเดียวกัน) จาก Artifactory จากนั้นส่งไปที่บริการส่งงาน ขั้นตอนนี้ช่วยให้แน่ใจว่าเฉพาะเวอร์ชันที่ใช้งานจริงเท่านั้นที่จะถูกส่งไปยังคลัสเตอร์
- JSS เป็นเกตเวย์สำหรับแพลตฟอร์มต่างๆ รวมถึง Kubernetes ที่นี่ผู้ใช้ได้รับการรับรองความถูกต้อง มีการออกโควต้า และการกำหนดค่า CRD ของเราได้รับการตรวจสอบบางส่วน
- หลังจากตรวจสอบ CRD บนฝั่ง JSS แล้ว ข้อมูลจะถูกส่งไปยัง API แพลตฟอร์ม k8s
- ตัวควบคุม CRD ของเราจะตรวจสอบเหตุการณ์ในทรัพยากรผู้ใช้ทั้งหมด โดยจะแปลง CR เป็นทรัพยากร k8 ดั้งเดิม เพิ่มโมดูลที่จำเป็น ตั้งค่าตัวแปรสภาพแวดล้อมที่เหมาะสม และดำเนินการสนับสนุนอื่นๆ เพื่อให้แน่ใจว่าแอปพลิเคชันผู้ใช้ในคอนเทนเนอร์ได้รับการสนับสนุนโครงสร้างพื้นฐานที่เพียงพอ
- จากนั้นตัวควบคุม CRD จะส่งข้อมูลที่ได้รับไปยัง Kubernetes API เพื่อให้ผู้กำหนดตารางเวลาสามารถประมวลผลและนำไปใช้จริงได้
หมายเหตุ: ขั้นตอนการทำงานก่อนเผยแพร่ของการปรับใช้นี้สร้างขึ้นสำหรับผู้ใช้รายแรกของแพลตฟอร์ม k8s ใหม่ ขณะนี้เรากำลังอยู่ในกระบวนการปรับปรุงกระบวนการนี้เพื่อบูรณาการกับ CI/CD ใหม่ของเราโดยสมบูรณ์ ซึ่งหมายความว่าเราไม่สามารถบอกคุณทุกอย่างที่เกี่ยวข้องกับ Kubernetes ได้ เราตั้งตารอที่จะแบ่งปันประสบการณ์และความก้าวหน้าของทีมงานในทิศทางนี้ในบล็อกโพสต์ถัดไปของเรา “การสร้างแพลตฟอร์ม CI/CD สำหรับ Pinterest”
ประเภทของทรัพยากรพิเศษ
ตามความต้องการเฉพาะของ Pinterest เราได้พัฒนา CRD ต่อไปนี้เพื่อให้เหมาะกับขั้นตอนการทำงานที่แตกต่างกัน:
- PinterestService เป็นบริการไร้สัญชาติที่ทำงานมาเป็นเวลานาน ระบบหลักของเราหลายระบบอิงตามชุดบริการดังกล่าว
- PinterestJobSet สร้างแบบจำลองงานแบทช์แบบเต็มรอบ สถานการณ์ทั่วไปบน Pinterest ก็คืองานหลายงานใช้งานคอนเทนเนอร์เดียวกันพร้อมกัน โดยไม่คำนึงถึงกระบวนการอื่นที่คล้ายคลึงกัน
- PinterestCronJob ใช้กันอย่างแพร่หลายร่วมกับการโหลดเป็นระยะๆ นี่คือ wrapper สำหรับงาน cron แบบเนทีฟที่มีกลไกสนับสนุนของ Pinterest ที่รับผิดชอบด้านความปลอดภัย การรับส่งข้อมูล บันทึก และตัวชี้วัด
- PinterestDaemon มีโครงสร้างพื้นฐาน Daemons ครอบครัวนี้เติบโตอย่างต่อเนื่องเมื่อเราเพิ่มการสนับสนุนให้กับคลัสเตอร์ของเรา
- PinterestTrainingJob ขยายไปสู่กระบวนการ Tensorflow และ Pytorch โดยให้การสนับสนุนรันไทม์ในระดับเดียวกับ CRD อื่นๆ ทั้งหมด เนื่องจาก Pinterest ใช้ Tensorflow และระบบการเรียนรู้ของเครื่องอื่นๆ อย่างจริงจัง เราจึงมีเหตุผลที่จะสร้าง CRD ที่แยกจากกัน
เรายังดำเนินการเกี่ยวกับ PinterestStatefulSet ซึ่งจะถูกนำไปปรับใช้กับคลังข้อมูลและระบบเก็บสถานะอื่นๆ เร็วๆ นี้
การสนับสนุนรันไทม์
เมื่อพ็อดแอปพลิเคชันทำงานบน Kubernetes พ็อดจะได้รับใบรับรองเพื่อระบุตัวเองโดยอัตโนมัติ ใบรับรองนี้ใช้เพื่อเข้าถึงที่เก็บข้อมูลลับหรือสื่อสารกับบริการอื่นผ่าน mTLS ในขณะเดียวกัน Container Init Configurator และ Daemon จะดาวน์โหลดการขึ้นต่อกันที่จำเป็นทั้งหมดก่อนเรียกใช้แอปพลิเคชันที่มีคอนเทนเนอร์ เมื่อทุกอย่างพร้อม รถเทียมข้างรถจักรยานยนต์และ Daemon จะลงทะเบียนที่อยู่ IP ของโมดูลกับ Zookeeper ของเรา เพื่อให้ลูกค้าสามารถค้นพบได้ ทั้งหมดนี้จะใช้ได้ผลเนื่องจากมีการกำหนดค่าโมดูลเครือข่ายก่อนเปิดตัวแอปพลิเคชัน
ข้างต้นเป็นตัวอย่างทั่วไปของการสนับสนุนรันไทม์สำหรับปริมาณงาน ปริมาณงานประเภทอื่นๆ อาจต้องการการสนับสนุนที่แตกต่างกันเล็กน้อย แต่ทั้งหมดมาในรูปแบบของ Sidecar ระดับพ็อด ระดับโหนด หรือ Daemon ระดับเครื่องเสมือน เรารับรองว่าทั้งหมดนี้ถูกปรับใช้ภายในโครงสร้างพื้นฐานการจัดการและมีความสอดคล้องกันในแอปพลิเคชันต่างๆ ซึ่งท้ายที่สุดจะช่วยลดภาระในแง่ของงานด้านเทคนิคและการสนับสนุนลูกค้าได้อย่างมาก
การทดสอบและประกันคุณภาพ
เราสร้างไปป์ไลน์การทดสอบแบบ end-to-end บนโครงสร้างพื้นฐานการทดสอบ Kubernetes ที่มีอยู่ การทดสอบเหล่านี้ใช้กับคลัสเตอร์ทั้งหมดของเรา ไปป์ไลน์ของเราได้ผ่านการแก้ไขหลายครั้งก่อนที่จะกลายเป็นส่วนหนึ่งของกลุ่มผลิตภัณฑ์
นอกเหนือจากระบบการทดสอบแล้ว เรายังมีระบบติดตามและแจ้งเตือนที่ติดตามสถานะของส่วนประกอบของระบบ การใช้ทรัพยากร และตัวบ่งชี้สำคัญอื่นๆ อย่างต่อเนื่อง โดยแจ้งให้เราทราบเฉพาะเมื่อจำเป็นต้องมีการแทรกแซงจากมนุษย์เท่านั้น
ทางเลือก
เราพิจารณาทางเลือกอื่นนอกเหนือจากทรัพยากรแบบกำหนดเอง เช่น ตัวควบคุมการเข้าถึงการเปลี่ยนแปลงและระบบเทมเพลต อย่างไรก็ตาม ทั้งหมดนี้มาพร้อมกับความท้าทายในการปฏิบัติงานที่สำคัญ ดังนั้นเราจึงเลือกเส้นทาง CRD
ตัวควบคุมการรับเข้าแบบกลายพันธุ์ถูกนำมาใช้เพื่อแนะนำรถเทียมข้างรถจักรยานยนต์ ตัวแปรสภาพแวดล้อม และการสนับสนุนรันไทม์อื่นๆ อย่างไรก็ตาม ประสบปัญหาต่างๆ เช่น การเชื่อมโยงทรัพยากรและการจัดการวงจรชีวิต ซึ่งปัญหาดังกล่าวไม่เกิดขึ้นใน CRD
หมายเหตุ: ระบบเทมเพลต เช่น แผนภูมิ Helm ยังใช้กันอย่างแพร่หลายในการรันแอปพลิเคชันที่มีการกำหนดค่าคล้ายกัน อย่างไรก็ตาม แอปพลิเคชันงานของเรามีความหลากหลายเกินกว่าจะจัดการโดยใช้เทมเพลตได้ นอกจากนี้ในระหว่างการปรับใช้อย่างต่อเนื่อง จะมีข้อผิดพลาดมากเกินไปเมื่อใช้เทมเพลต
งานที่จะเกิดขึ้น
ขณะนี้เรากำลังเผชิญกับภาระงานที่หลากหลายทั่วทั้งคลัสเตอร์ของเรา เพื่อรองรับกระบวนการประเภทและขนาดต่างๆ เราทำงานในด้านต่อไปนี้:
- กลุ่มคลัสเตอร์จะกระจายแอปพลิเคชันขนาดใหญ่ไปยังคลัสเตอร์ต่างๆ เพื่อความสามารถในการขยายขนาดและความเสถียร
- รับประกันความเสถียรของคลัสเตอร์ ความสามารถในการปรับขนาด และการมองเห็นเพื่อสร้างการเชื่อมต่อแอปพลิเคชันและ SLA
- การจัดการทรัพยากรและโควต้าเพื่อให้แอปพลิเคชันไม่ขัดแย้งกัน และขนาดของคลัสเตอร์จะถูกควบคุมในส่วนของเรา
- แพลตฟอร์ม CI/CD ใหม่สำหรับการสนับสนุนและปรับใช้แอปพลิเคชันบน Kubernetes
ที่มา: will.com