บันทึก. แปล: Dailymotion เป็นหนึ่งในบริการโฮสต์วิดีโอที่ใหญ่ที่สุดในโลก และเป็นผู้ใช้ Kubernetes ที่มีชื่อเสียง ในเนื้อหานี้ สถาปนิกระบบ David Donchez แบ่งปันผลลัพธ์ของการสร้างแพลตฟอร์มการผลิตของบริษัทโดยใช้ K8 ซึ่งเริ่มต้นด้วยการติดตั้งระบบคลาวด์ใน GKE และสิ้นสุดเป็นโซลูชันแบบไฮบริด ซึ่งช่วยให้มีเวลาตอบสนองดีขึ้นและประหยัดต้นทุนโครงสร้างพื้นฐาน
การตัดสินใจสร้าง Core API ใหม่ เมื่อสามปีที่แล้ว เราต้องการพัฒนาวิธีที่มีประสิทธิภาพมากขึ้นในการโฮสต์แอปพลิเคชันและทำให้ง่ายขึ้น . เพื่อจุดประสงค์นี้ เราจึงตัดสินใจใช้แพลตฟอร์มการจัดการคอนเทนเนอร์และเลือก Kubernetes โดยธรรมชาติ
เหตุใดจึงคุ้มค่าที่จะสร้างแพลตฟอร์มของคุณเองโดยใช้ Kubernetes
API ระดับการผลิตในเวลาไม่นานโดยใช้ Google Cloud
ฤดูร้อนปี 2016
เมื่อสามปีที่แล้ว ทันทีหลังจากที่ Dailymotion ถูกซื้อโดย ทีมวิศวกรของเรามุ่งเน้นไปที่เป้าหมายระดับโลกเดียว: เพื่อสร้างผลิตภัณฑ์ Dailymotion ใหม่ทั้งหมด
จากการวิเคราะห์คอนเทนเนอร์ โซลูชันการจัดการ และประสบการณ์ที่ผ่านมา เราเชื่อว่า Kubernetes คือตัวเลือกที่เหมาะสม นักพัฒนาบางรายมีความเข้าใจแนวคิดพื้นฐานอยู่แล้วและรู้วิธีใช้งาน ซึ่งเป็นข้อได้เปรียบอย่างมากสำหรับการเปลี่ยนแปลงโครงสร้างพื้นฐาน
จากมุมมองของโครงสร้างพื้นฐาน ระบบที่มีประสิทธิภาพและยืดหยุ่นเป็นสิ่งจำเป็นในการโฮสต์แอปพลิเคชันบนคลาวด์ประเภทใหม่ๆ เราเลือกที่จะอยู่ในระบบคลาวด์ตั้งแต่เริ่มต้นการเดินทาง เพื่อที่เราจะสร้างแพลตฟอร์มภายในองค์กรที่แข็งแกร่งที่สุดเท่าที่จะเป็นไปได้ด้วยความอุ่นใจ เราตัดสินใจปรับใช้แอปพลิเคชันของเราโดยใช้ Google Kubernetes Engine แม้ว่าเราจะรู้ว่าไม่ช้าก็เร็วเราจะย้ายไปที่ศูนย์ข้อมูลของเราเองและใช้กลยุทธ์แบบไฮบริด
ทำไมคุณถึงเลือก GKE
เราเลือกตัวเลือกนี้ด้วยเหตุผลทางเทคนิคเป็นหลัก นอกจากนี้ จำเป็นต้องจัดหาโครงสร้างพื้นฐานที่ตรงกับความต้องการทางธุรกิจของบริษัทอย่างรวดเร็ว เรามีข้อกำหนดบางประการสำหรับการโฮสต์แอปพลิเคชัน เช่น การกระจายทางภูมิศาสตร์ ความสามารถในการปรับขนาด และความทนทานต่อข้อผิดพลาด
คลัสเตอร์ GKE ใน Dailymotion
เนื่องจาก Dailymotion เป็นแพลตฟอร์มวิดีโอที่มีให้บริการทั่วโลก เราจึงต้องการปรับปรุงคุณภาพของบริการโดยการลดเวลารอคอย (แฝง). ก่อนหน้านี้ มีเฉพาะในปารีสเท่านั้นซึ่งยังไม่ค่อยเหมาะสมนัก ฉันต้องการที่จะโฮสต์แอปพลิเคชันได้ไม่เพียงแต่ในยุโรป แต่ยังรวมถึงในเอเชียและสหรัฐอเมริกาด้วย
ความอ่อนไหวต่อเวลาแฝงนี้หมายความว่าจะต้องทำงานจริงจังกับสถาปัตยกรรมเครือข่ายของแพลตฟอร์ม แม้ว่าบริการคลาวด์ส่วนใหญ่จะบังคับให้คุณสร้างเครือข่ายของคุณเองในแต่ละภูมิภาค จากนั้นเชื่อมต่อผ่าน VPN หรือบริการที่มีการจัดการบางประเภท แต่ Google Cloud อนุญาตให้คุณสร้างเครือข่ายเดียวที่สามารถกำหนดเส้นทางได้อย่างสมบูรณ์ครอบคลุมภูมิภาคของ Google ทั้งหมด นี่เป็นข้อดีอย่างมากในแง่ของการทำงานและประสิทธิภาพของระบบ
นอกจากนี้ บริการเครือข่ายและโหลดบาลานเซอร์จาก Google Cloud ยังทำงานได้ดีอีกด้วย พวกเขาเพียงแค่อนุญาตให้คุณใช้ที่อยู่ IP สาธารณะโดยพลการจากแต่ละภูมิภาค และโปรโตคอล BGP ที่ยอดเยี่ยมจะดูแลส่วนที่เหลือ (เช่น การเปลี่ยนเส้นทางผู้ใช้ไปยังคลัสเตอร์ที่ใกล้ที่สุด) แน่นอนว่าในกรณีที่เกิดเหตุขัดข้อง การจราจรจะไปยังภูมิภาคอื่นโดยอัตโนมัติโดยไม่มีการแทรกแซงจากมนุษย์
การตรวจสอบ Google Load Balancing
แพลตฟอร์มของเรายังใช้งาน GPU อย่างหนักอีกด้วย Google Cloud ช่วยให้คุณใช้งานได้อย่างมีประสิทธิภาพโดยตรงในคลัสเตอร์ Kubernetes
ในขณะนั้น ทีมงานโครงสร้างพื้นฐานมุ่งเน้นไปที่สแตกแบบเดิมที่ใช้งานบนเซิร์ฟเวอร์จริงเป็นหลัก นั่นเป็นสาเหตุที่การใช้บริการที่มีการจัดการ (รวมถึงต้นแบบ Kubernetes) ตรงตามข้อกำหนดของเรา และช่วยให้เราฝึกอบรมทีมให้ทำงานกับคลัสเตอร์ในพื้นที่ได้
ด้วยเหตุนี้ เราจึงสามารถเริ่มรับปริมาณการใช้งานจริงบนโครงสร้างพื้นฐานของ Google Cloud ได้เพียง 6 เดือนหลังจากเริ่มทำงาน
Однако несмотря на ряд преимуществ, работа с облачным провайдером сопряжена с определенными затратами, которые могут увеличиваться в зависимости от нагрузки. Вот почему мы внимательно анализировали каждый используемый управляемый сервис, рассчитывая в будущем реализовать их у себя on-premises. На самом деле внедрение локальных кластеров началось в конце 2016 года и тогда же была инициирована гибридная стратегия.
เปิดตัวแพลตฟอร์มการจัดการคอนเทนเนอร์ในท้องถิ่น Dailymotion
ฤดูใบไม้ร่วง 2016
ในสภาวะที่สแต็กทั้งหมดพร้อมสำหรับการผลิตและทำงานกับ API ถึงเวลาที่จะต้องมุ่งความสนใจไปที่กลุ่มภูมิภาค
ในเวลานั้น ผู้ใช้รับชมวิดีโอมากกว่า 3 พันล้านรายการทุกเดือน แน่นอนว่าเรามีเครือข่ายการจัดส่งเนื้อหาที่กว้างขวางมานานหลายปี เราต้องการใช้ประโยชน์จากสถานการณ์นี้และปรับใช้คลัสเตอร์ Kubernetes ในศูนย์ข้อมูลที่มีอยู่
โครงสร้างพื้นฐานของ Dailymotion ประกอบด้วยเซิร์ฟเวอร์มากกว่า 2,5 พันเครื่องในศูนย์ข้อมูล XNUMX แห่ง ทั้งหมดได้รับการกำหนดค่าโดยใช้ Saltstack เราเริ่มเตรียมสูตรที่จำเป็นทั้งหมดสำหรับการสร้างโหนดหลักและโหนดผู้ปฏิบัติงาน รวมถึงคลัสเตอร์ ฯลฯ
ส่วนเครือข่าย
เครือข่ายของเราถูกกำหนดเส้นทางอย่างสมบูรณ์ แต่ละเซิร์ฟเวอร์โฆษณา IP ของตนบนเครือข่ายโดยใช้ Exabgp เราเปรียบเทียบปลั๊กอินเครือข่ายหลายตัว และปลั๊กอินเดียวที่ตอบสนองความต้องการทั้งหมด (เนื่องจากใช้วิธี L3) คือ . มันเข้ากันได้อย่างลงตัวกับโมเดลโครงสร้างพื้นฐานเครือข่ายที่มีอยู่
เนื่องจากเราต้องการใช้องค์ประกอบโครงสร้างพื้นฐานที่มีอยู่ทั้งหมด สิ่งแรกที่เราต้องทำคือค้นหายูทิลิตี้เครือข่ายที่เราสร้างขึ้นเอง (ใช้กับเซิร์ฟเวอร์ทั้งหมด): ใช้เพื่อโฆษณาช่วงที่อยู่ IP บนเครือข่ายด้วยโหนด Kubernetes เราอนุญาตให้ Calico กำหนดที่อยู่ IP ให้กับพ็อดได้ แต่ไม่ได้ทำเช่นนั้นและยังคงไม่ได้ใช้สำหรับเซสชัน BGP บนอุปกรณ์เครือข่าย ในความเป็นจริง Exabgp จัดการการกำหนดเส้นทางซึ่งโฆษณาเครือข่ายย่อยที่ Calico ใช้ สิ่งนี้ทำให้เราสามารถเข้าถึงพ็อดใดก็ได้จากเครือข่ายภายใน (และโดยเฉพาะจากโหลดบาลานเซอร์)
เราจัดการการรับส่งข้อมูลขาเข้าอย่างไร
หากต้องการเปลี่ยนเส้นทางคำขอขาเข้าไปยังบริการที่ต้องการ จึงตัดสินใจใช้ Ingress Controller เนื่องจากการผสานรวมกับทรัพยากรทางเข้าของ Kubernetes
เมื่อสามปีที่แล้ว nginx-ingress-controller เป็นตัวควบคุมที่เป็นผู้ใหญ่ที่สุด Nginx มีมาเป็นเวลานานและมีชื่อเสียงในด้านความเสถียรและประสิทธิภาพ
ในระบบของเรา เราตัดสินใจวางคอนโทรลเลอร์บนเบลดเซิร์ฟเวอร์ขนาด 10 กิกะบิตโดยเฉพาะ ตัวควบคุมแต่ละตัวเชื่อมต่อกับจุดสิ้นสุด kube-apiserver ของคลัสเตอร์ที่เกี่ยวข้อง เซิร์ฟเวอร์เหล่านี้ยังใช้ Exabgp เพื่อโฆษณาที่อยู่ IP สาธารณะหรือส่วนตัว โทโพโลยีเครือข่ายของเราช่วยให้เราสามารถใช้ BGP จากตัวควบคุมเหล่านี้เพื่อกำหนดเส้นทางการรับส่งข้อมูลทั้งหมดไปยังพ็อดโดยตรงโดยไม่ต้องใช้บริการเช่น NodePort วิธีการนี้ช่วยหลีกเลี่ยงการรับส่งข้อมูลในแนวนอนระหว่างโหนดและปรับปรุงประสิทธิภาพ
ความเคลื่อนไหวการรับส่งข้อมูลจากอินเทอร์เน็ตไปยังพ็อด
ตอนนี้เราเข้าใจแพลตฟอร์มไฮบริดของเราแล้ว เราก็สามารถเจาะลึกเข้าไปในกระบวนการย้ายการรับส่งข้อมูลได้
การย้ายการรับส่งข้อมูลจาก Google Cloud ไปยังโครงสร้างพื้นฐาน Dailymotion
ฤดูใบไม้ร่วง 2018
หลังจากสร้าง ทดสอบ และปรับแต่งมาเกือบสองปี ในที่สุดเราก็มีสแต็ก Kubernetes เต็มรูปแบบที่พร้อมจะยอมรับการรับส่งข้อมูลบางส่วน
กลยุทธ์การกำหนดเส้นทางปัจจุบันค่อนข้างเรียบง่าย แต่เพียงพอที่จะตอบสนองความต้องการ นอกเหนือจาก IP สาธารณะ (บน Google Cloud และ Dailymotion) แล้ว AWS Route 53 ยังใช้เพื่อกำหนดนโยบายและเปลี่ยนเส้นทางผู้ใช้ไปยังคลัสเตอร์ที่เราเลือก
ตัวอย่างนโยบายการกำหนดเส้นทางโดยใช้ Route 53
Google Cloud ช่วยให้ทำได้ง่ายเนื่องจากเราแชร์ IP เดียวในทุกคลัสเตอร์ และเปลี่ยนเส้นทางผู้ใช้ไปยังคลัสเตอร์ GKE ที่ใกล้ที่สุด สำหรับคลัสเตอร์ของเรา เทคโนโลยีจะแตกต่าง เนื่องจาก IP ของพวกเขาแตกต่างกัน
ในระหว่างการย้ายข้อมูล เราต้องการเปลี่ยนเส้นทางคำขอระดับภูมิภาคไปยังคลัสเตอร์ที่เหมาะสม และประเมินประโยชน์ของแนวทางนี้
เนื่องจากคลัสเตอร์ GKE ของเราได้รับการกำหนดค่าให้ปรับขนาดอัตโนมัติโดยใช้เมตริกที่กำหนดเอง จึงปรับขนาดขึ้น/ลงตามการรับส่งข้อมูลขาเข้า
ในโหมดปกติ การรับส่งข้อมูลระดับภูมิภาคทั้งหมดจะถูกส่งไปยังคลัสเตอร์ท้องถิ่น และ GKE จะทำหน้าที่เป็นตัวสำรองในกรณีที่เกิดปัญหา (การตรวจสุขภาพจะดำเนินการโดยเส้นทาง 53)
...
ในอนาคต เราต้องการกำหนดนโยบายการกำหนดเส้นทางอัตโนมัติเต็มรูปแบบเพื่อให้บรรลุกลยุทธ์ไฮบริดแบบอัตโนมัติที่ปรับปรุงการเข้าถึงสำหรับผู้ใช้อย่างต่อเนื่อง ในด้านบวก ต้นทุนคลาวด์ลดลงอย่างมาก และเวลาตอบสนองของ API ก็ลดลงด้วยซ้ำ เราเชื่อถือแพลตฟอร์มคลาวด์ที่เกิดขึ้นและพร้อมที่จะเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังแพลตฟอร์มดังกล่าวมากขึ้นหากจำเป็น
ปล.จากผู้แปล
คุณอาจสนใจโพสต์ Dailymotion อื่นเกี่ยวกับ Kubernetes มีไว้เพื่อการปรับใช้แอปพลิเคชันด้วย Helm บนคลัสเตอร์ Kubernetes จำนวนมากและ ประมาณหนึ่งเดือนที่ผ่านมา.
อ่านเพิ่มเติมในบล็อกของเรา:
- «'
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «'
ที่มา: will.com