ตัวดำเนินการใน Kubernetes สำหรับจัดการคลัสเตอร์ฐานข้อมูล วลาดิสลาฟ คลิเมนโก้ (Altinity, 2019)

รายงานนี้เน้นไปที่ประเด็นในทางปฏิบัติในการพัฒนาผู้ปฏิบัติงานใน Kubernetes การออกแบบสถาปัตยกรรมและหลักการทำงานขั้นพื้นฐาน

ในส่วนแรกของรายงาน เราจะพิจารณา:

• โอเปอเรเตอร์ใน Kubernetes คืออะไร และเหตุใดจึงจำเป็น
• ผู้ปฏิบัติงานทำให้การจัดการระบบที่ซับซ้อนง่ายขึ้นได้อย่างไร
• สิ่งที่ผู้ดำเนินการทำได้และทำไม่ได้

ต่อไป เรามาพูดถึงโครงสร้างภายในของผู้ปฏิบัติงานกันดีกว่า มาดูสถาปัตยกรรมและการทำงานของผู้ปฏิบัติงานทีละขั้นตอนกัน มาดูรายละเอียดกัน:

• ปฏิสัมพันธ์ระหว่างโอเปอเรเตอร์กับ Kubernetes
• ฟังก์ชันใดที่โอเปอเรเตอร์ใช้ และฟังก์ชันใดที่โอเปอเรเตอร์มอบหมายให้กับ Kubernetes

มาดูการจัดการชาร์ดและแบบจำลองฐานข้อมูลใน Kubernetes กัน
ต่อไป เราจะหารือเกี่ยวกับปัญหาการจัดเก็บข้อมูล:

• วิธีทำงานกับ Persistent Storage จากมุมมองของผู้ปฏิบัติงาน
• ข้อผิดพลาดของการใช้ Local Storage

ในส่วนสุดท้ายของรายงาน เราจะพิจารณาตัวอย่างการใช้งานจริง คลิกเฮาส์โอเปอเรเตอร์ ด้วยบริการ Amazon หรือ Google Cloud รายงานนี้อิงตามตัวอย่างการพัฒนาและประสบการณ์การดำเนินงานของผู้ปฏิบัติงาน ClickHouse

วิดีโอ:

ฉันชื่อวลาดิสลาฟ คลิเมนโก วันนี้ผมอยากจะพูดถึงประสบการณ์ของเราในการพัฒนาและใช้งานโอเปอเรเตอร์ และนี่คือโอเปอเรเตอร์เฉพาะทางสำหรับการจัดการคลัสเตอร์ฐานข้อมูล ตัวอย่างเช่น คลิกHouse-operator เพื่อจัดการคลัสเตอร์ ClickHouse

ทำไมเราถึงมีโอกาสพูดคุยเกี่ยวกับโอเปอเรเตอร์และ ClickHouse?

• เราสนับสนุนและพัฒนา ClickHouse
• ในขณะนี้ เรากำลังพยายามที่จะสนับสนุนการพัฒนา ClickHouse อย่างช้าๆ และเราเป็นอันดับสองรองจากยานเดกซ์ในแง่ของปริมาณการเปลี่ยนแปลงที่ทำกับ ClickHouse
• เรากำลังพยายามทำโครงการเพิ่มเติมสำหรับระบบนิเวศ ClickHouse

ฉันอยากจะบอกคุณเกี่ยวกับหนึ่งในโครงการเหล่านี้ นี่เป็นเรื่องเกี่ยวกับ ClickHouse-operator สำหรับ Kubernetes

ในรายงานของฉัน ฉันอยากจะกล่าวถึงสองหัวข้อ:

• หัวข้อแรกคือวิธีการทำงานของผู้ดำเนินการจัดการฐานข้อมูล ClickHouse ใน Kubernetes
• หัวข้อที่สองคือวิธีการทำงานของโอเปอเรเตอร์ เช่น การโต้ตอบกับ Kubernetes

อย่างไรก็ตาม คำถามทั้งสองนี้จะขัดแย้งกันตลอดรายงานของฉัน

ใครจะสนใจฟังสิ่งที่ฉันพยายามจะเล่า?

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

เพื่อให้เข้าใจสิ่งที่เราจะพูดคุยกันในวันนี้ให้ดีที่สุด เป็นความคิดที่ดีที่จะทราบว่า Kubernetes ทำงานอย่างไรและมีการฝึกอบรมระบบคลาวด์ขั้นพื้นฐาน

ClickHouse คืออะไร? นี่คือฐานข้อมูลแบบเรียงเป็นแนวพร้อมคุณสมบัติเฉพาะสำหรับการประมวลผลแบบสอบถามเชิงวิเคราะห์แบบออนไลน์ และเป็นโอเพ่นซอร์สโดยสมบูรณ์

และเป็นสิ่งสำคัญสำหรับเราที่จะรู้เพียงสองสิ่งเท่านั้น คุณจำเป็นต้องรู้ว่านี่คือฐานข้อมูล ดังนั้นสิ่งที่ฉันจะบอกคุณจะสามารถใช้ได้กับฐานข้อมูลเกือบทุกประเภท และความจริงที่ว่า ClickHouse DBMS สามารถปรับขนาดได้ดีมาก ทำให้สามารถปรับขนาดได้เกือบเป็นเส้นตรง ดังนั้นสถานะคลัสเตอร์จึงเป็นสถานะปกติสำหรับ ClickHouse และเราสนใจที่จะพูดคุยถึงวิธีการให้บริการคลัสเตอร์ ClickHouse ใน Kubernetes มากที่สุด

ทำไมเขาถึงต้องการที่นั่น? ทำไมเราถึงดำเนินการเองต่อไปไม่ได้? และคำตอบบางส่วนเป็นด้านเทคนิคและบางส่วนเป็นเชิงองค์กร

• ในทางปฏิบัติ เรากำลังเผชิญกับสถานการณ์ที่องค์ประกอบเกือบทั้งหมดในบริษัทขนาดใหญ่มีอยู่แล้วใน Kubernetes มากขึ้นเรื่อยๆ ฐานข้อมูลยังคงอยู่ภายนอก
• และมีคำถามมากขึ้นเรื่อยๆ ว่า “สิ่งนี้สามารถวางไว้ข้างในได้หรือไม่” ดังนั้น บริษัทขนาดใหญ่จึงพยายามที่จะบรรลุการรวมการจัดการสูงสุดเพื่อให้สามารถจัดการคลังข้อมูลของตนได้อย่างรวดเร็ว
• และสิ่งนี้จะช่วยได้เป็นพิเศษหากคุณต้องการโอกาสสูงสุดในการทำซ้ำสิ่งเดียวกันในสถานที่ใหม่ นั่นคือ ความสามารถในการพกพาสูงสุด

มันง่ายหรือยากแค่ไหน? แน่นอนว่าสามารถทำได้ด้วยมือ แต่มันไม่ง่ายนัก เพราะเรามีความซับซ้อนเพิ่มขึ้นในการจัดการ Kubernetes แต่ในขณะเดียวกัน ข้อมูลเฉพาะของ ClickHouse ก็ถูกทับซ้อนกัน และผลการรวมกลุ่มดังกล่าว

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

ด้วยการกำหนดค่าแบบไดนามิก ClickHouse มีปัญหาจำนวนมากที่สร้างภาระอย่างต่อเนื่องบน DevOps:

• เมื่อเราต้องการเปลี่ยนแปลงบางอย่างใน ClickHouse เช่น เพิ่มแบบจำลองหรือชิ้นส่วน เราจำเป็นต้องจัดการการกำหนดค่า
• จากนั้นเปลี่ยนสคีมาข้อมูล เนื่องจาก ClickHouse มีวิธีการแบ่งส่วนเฉพาะ ที่นั่นคุณต้องจัดวางไดอะแกรมข้อมูลจัดวางการกำหนดค่า
• คุณต้องตั้งค่าการตรวจสอบ
• การรวบรวมบันทึกสำหรับชิ้นส่วนใหม่ สำหรับแบบจำลองใหม่
• ดูแลฟื้นฟู.
• และเริ่มต้นใหม่

งานเหล่านี้เป็นงานประจำที่ฉันอยากให้ใช้งานได้ง่ายขึ้นจริงๆ

Kubernetes เองก็ช่วยในการทำงานได้ดี แต่ในเรื่องพื้นฐานของระบบ

Kubernetes เก่งในการอำนวยความสะดวกและทำให้สิ่งต่างๆ เป็นแบบอัตโนมัติ เช่น:

• การกู้คืน.
• เริ่มต้นใหม่.
• การจัดการระบบจัดเก็บข้อมูล

ดี นั่นเป็นทิศทางที่ถูกต้อง แต่เขาไม่มีความรู้เลยเกี่ยวกับวิธีการใช้งานคลัสเตอร์ฐานข้อมูล

เราต้องการมากกว่านี้ เราต้องการให้ฐานข้อมูลทั้งหมดทำงานใน Kubernetes

ฉันต้องการได้บางอย่างเช่นปุ่มสีแดงวิเศษขนาดใหญ่ที่คุณกด และคลัสเตอร์ที่มีงานประจำวันที่ต้องแก้ไขจะถูกนำไปใช้และบำรุงรักษาตลอดวงจรชีวิตทั้งหมด คลัสเตอร์ ClickHouse ใน Kubernetes

และเราพยายามหาวิธีแก้ปัญหาที่จะช่วยให้งานง่ายขึ้น นี่คือตัวดำเนินการ ClickHouse สำหรับ Kubernetes จาก Altinity

โอเปอเรเตอร์คือโปรแกรมที่มีหน้าที่หลักในการจัดการโปรแกรมอื่นๆ เช่น เป็นผู้จัดการ

และมีรูปแบบพฤติกรรมด้วย คุณสามารถเรียกความรู้ที่ประมวลนี้เกี่ยวกับสาขาวิชาได้

และงานหลักของเขาคือการทำให้ชีวิตของ DevOps ง่ายขึ้น และลดการจัดการแบบจุลภาค เพื่อให้เขา (DevOps) คิดในระดับสูงอยู่แล้ว นั่นคือเพื่อที่เขา (DevOps) จะไม่มีส่วนร่วมในการจัดการแบบย่อย ดังนั้นเขาจึงไม่ได้กำหนดค่า รายละเอียดทั้งหมดด้วยตนเอง

และมีเพียงผู้ปฏิบัติงานเท่านั้นที่เป็นผู้ช่วยหุ่นยนต์ที่เกี่ยวข้องกับงานย่อยและช่วยเหลือ DevOps

ทำไมคุณต้องมีโอเปอเรเตอร์? เขาทำงานได้ดีเป็นพิเศษในสองด้าน:

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

สิ่งนี้จำเป็นมากที่สุดโดยผู้ที่เพิ่งเริ่มต้นการเดินทาง หรือโดยผู้ที่ต้องทำระบบอัตโนมัติจำนวนมาก

แนวทางแบบอิงผู้ปฏิบัติงานแตกต่างจากระบบอื่นอย่างไร นั่นก็คือเฮล์ม นอกจากนี้ยังช่วยในการติดตั้ง ClickHouse คุณสามารถวาดแผนภูมิหางเสือซึ่งจะติดตั้งคลัสเตอร์ ClickHouse ทั้งหมดด้วยซ้ำ แล้วอะไรคือความแตกต่างระหว่างตัวดำเนินการกับตัวเดียวกัน เช่น Helm?

ความแตกต่างพื้นฐานที่สำคัญคือ Helm คือการจัดการแพ็คเกจ และ Operator ก้าวไปอีกขั้น นี่คือการสนับสนุนตลอดวงจรชีวิต นี่ไม่ใช่แค่การติดตั้งเท่านั้น แต่ยังเป็นงานประจำวันซึ่งรวมถึงการปรับขนาด การแบ่งส่วน นั่นคือ ทุกสิ่งที่ต้องทำในระหว่างวงจรชีวิต (หากจำเป็น ให้ลบออกด้วย) - ทั้งหมดนี้เป็นผู้ดำเนินการเป็นผู้ตัดสินใจ พยายามทำให้เป็นอัตโนมัติและรักษาวงจรการใช้งานซอฟต์แวร์ทั้งหมด นี่คือความแตกต่างพื้นฐานจากโซลูชันอื่นที่นำเสนอ

นั่นคือส่วนเบื้องต้น มาดูกันดีกว่า

เราจะสร้างตัวดำเนินการของเราได้อย่างไร? เรากำลังพยายามแก้ไขปัญหาเพื่อจัดการคลัสเตอร์ ClickHouse เป็นทรัพยากรเดียว

ที่นี่เรามีข้อมูลที่ป้อนทางด้านซ้ายของภาพ นี่คือ YAML ที่มีข้อกำหนดเฉพาะของคลัสเตอร์ ซึ่งส่งต่อไปยัง Kubernetes ด้วยวิธีคลาสสิกผ่าน kubectl เจ้าหน้าที่ของเราหยิบมันขึ้นมาและทำเวทย์มนตร์ของเขาที่นั่น และที่ผลลัพธ์เราจะได้โครงร่างดังต่อไปนี้ นี่คือการใช้งาน ClickHouse ใน Kubernetes

จากนั้นเราจะค่อยๆ ดูว่าผู้ปฏิบัติงานทำงานอย่างไร และงานทั่วไปใดบ้างที่สามารถแก้ไขได้ เราจะพิจารณาเฉพาะงานทั่วไปเนื่องจากเรามีเวลาจำกัด และไม่ใช่ทุกสิ่งที่ผู้ปฏิบัติงานสามารถตัดสินใจได้จะถูกพูดคุยกัน

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

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

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

นี่เป็นแถลงการณ์ที่ซับซ้อนมาก สิ่งที่เราเน้นด้วยสีแดงคือสิ่งที่เราต้องให้ความสำคัญ เราขอให้ผู้ดำเนินการสร้างคลัสเตอร์ชื่อสาธิต

นี่เป็นตัวอย่างพื้นฐานสำหรับตอนนี้ พื้นที่เก็บข้อมูลยังไม่ได้อธิบาย แต่เราจะกลับไปที่พื้นที่เก็บข้อมูลในภายหลังเล็กน้อย สำหรับตอนนี้ เราจะสังเกตพลวัตของการพัฒนาคลัสเตอร์

เราได้สร้างแถลงการณ์นี้ขึ้นมา เราป้อนมันให้กับผู้ปฏิบัติงานของเรา เขาทำงาน เขาสร้างเวทมนตร์

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

เจ้าหน้าที่ปฏิบัติงานทำงานแล้ว และเราสามารถเห็นได้ว่าเขาสร้างอะไรกันแน่

เขาสร้างอะไรแบบนี้ เรามี StatefulSet, Pod, ConfigMap สำหรับแต่ละเรพลิกา, ConfigMap สำหรับทั้งคลัสเตอร์ จำเป็นต้องมีบริการเป็นจุดเริ่มต้นเข้าสู่คลัสเตอร์

บริการต่างๆ คือบริการ Load Balancer ส่วนกลาง และยังสามารถใช้กับแบบจำลองแต่ละรายการ สำหรับแต่ละส่วนย่อยได้อีกด้วย

คลัสเตอร์พื้นฐานของเรามีลักษณะเช่นนี้ มันมาจากโหนดเดียว

ไปต่อและทำให้สิ่งต่าง ๆ ซับซ้อนขึ้น เราจำเป็นต้องแบ่งคลัสเตอร์

งานของเรากำลังเติบโตขึ้น ไดนามิกกำลังเริ่มต้นขึ้น เราต้องการเพิ่มชิ้นส่วน เราติดตามการพัฒนา เรากำลังเปลี่ยนแปลงข้อกำหนดของเรา เราระบุว่าเราต้องการชิ้นส่วนสองชิ้น

นี่เป็นไฟล์เดียวกับที่พัฒนาแบบไดนามิกตามการเติบโตของระบบ ไม่มีที่เก็บข้อมูล พื้นที่เก็บข้อมูลจะมีการหารือเพิ่มเติม นี่เป็นหัวข้อแยกต่างหาก

เราป้อนตัวดำเนินการ YAML และดูว่าเกิดอะไรขึ้น

ผู้ดำเนินการคิดและสร้างเอนทิตีดังต่อไปนี้ เรามีพ็อดสองรายการ บริการสามรายการ และ StatefulSets 2 รายการในทันที ทำไมต้องมี 2 StatefulSets

ในแผนภาพมันเป็นเช่นนี้ - นี่คือสถานะเริ่มต้นของเราเมื่อเรามีหนึ่งพ็อด

มันกลายเป็นแบบนี้ จนถึงตอนนี้ทุกอย่างก็เรียบง่าย มันถูกทำซ้ำ

และเหตุใดจึงมี StatefulSets สองชุด? ที่นี่เราต้องพูดนอกเรื่องและหารือเกี่ยวกับคำถามว่าพ็อดได้รับการจัดการใน Kubernetes อย่างไร

มีออบเจ็กต์ชื่อ StatefulSet ที่ให้คุณสร้างชุด Pod จากเทมเพลตได้ ปัจจัยสำคัญที่นี่คือเทมเพลต และคุณสามารถเปิด Pod จำนวนมากได้โดยใช้เทมเพลตเดียวใน StatefulSet เดียว และวลีสำคัญที่นี่คือ “หลายพ็อดสำหรับเทมเพลตเดียว”

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

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

หลังจากคิดอยู่สักพักก็ตัดสินใจว่าเราจะทำแบบนี้ เรามีแต่ละแบบจำลองใน StatefulSet ของตัวเอง มีข้อเสียบางประการสำหรับโซลูชันนี้ แต่ในทางปฏิบัติแล้ว ผู้ปฏิบัติงานจะห่อหุ้มไว้ทั้งหมด และมีข้อดีมากมาย เราสามารถสร้างคลัสเตอร์ที่เราต้องการได้ เช่น คลัสเตอร์ที่ต่างกันโดยสิ้นเชิง ดังนั้น ในคลัสเตอร์ที่เรามีส่วนแบ่งข้อมูลสองส่วนพร้อมแบบจำลองเดียว เราจะมี 2 StatefulSets และ 2 Pod อย่างแน่นอน เนื่องจากเราเลือกแนวทางนี้ด้วยเหตุผลที่ระบุไว้ข้างต้นเพื่อให้สามารถสร้างคลัสเตอร์ที่ต่างกันได้

กลับไปสู่ปัญหาในทางปฏิบัติ ในคลัสเตอร์ของเรา เราจำเป็นต้องกำหนดค่าผู้ใช้ เช่น คุณต้องทำการกำหนดค่า ClickHouse ใน Kubernetes ผู้ดำเนินการให้ความเป็นไปได้ทั้งหมดสำหรับสิ่งนี้

เราสามารถเขียนสิ่งที่เราต้องการได้โดยตรงใน YAML ตัวเลือกการกำหนดค่าทั้งหมดจะถูกแมปโดยตรงจาก YAML นี้ไปยังการกำหนดค่า ClickHouse ซึ่งจะกระจายทั่วทั้งคลัสเตอร์

คุณสามารถเขียนมันแบบนี้ นี่เป็นตัวอย่าง รหัสผ่านสามารถเข้ารหัสได้ รองรับตัวเลือกการกำหนดค่า ClickHouse ทั้งหมดอย่างแน่นอน นี่เป็นเพียงตัวอย่าง

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

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

เราต้องการอะไรในการจำลองแบบ?

เราต้องการ ZooKeeper ใน ClickHouse การจำลองถูกสร้างขึ้นโดยใช้ ZooKeeper ZooKeeper เป็นสิ่งจำเป็นเพื่อให้แบบจำลอง ClickHouse ที่แตกต่างกันมีความเห็นพ้องต้องกันว่าบล็อกข้อมูลใดที่ ClickHouse ใด

ZooKeeper ทุกคนสามารถใช้ได้ หากองค์กรมี ZooKeeper ภายนอก ก็สามารถใช้งานได้ ถ้าไม่เช่นนั้น คุณสามารถติดตั้งได้จากพื้นที่เก็บข้อมูลของเรา มีตัวติดตั้งที่ทำให้ทุกอย่างง่ายขึ้น

และแผนภาพปฏิสัมพันธ์ของทั้งระบบจะเป็นเช่นนี้ เรามี Kubernetes เป็นแพลตฟอร์ม มันดำเนินการตัวดำเนินการ ClickHouse ฉันนึกภาพ ZooKeeper ที่นี่ และผู้ปฏิบัติงานโต้ตอบกับทั้ง ClickHouse และ ZooKeeper นั่นคือผลลัพธ์ของการโต้ตอบ

และทั้งหมดนี้จำเป็นสำหรับ ClickHouse ในการจำลองข้อมูลใน k8s ได้สำเร็จ

ตอนนี้เรามาดูตัวงานกันดีกว่า ว่ารายการสำหรับการจำลองจะมีลักษณะอย่างไร

เรากำลังเพิ่มสองส่วนในรายการของเรา อย่างแรกคือที่ที่จะรับ ZooKeeper ซึ่งอาจอยู่ใน Kubernetes หรือภายนอกก็ได้ นี่เป็นเพียงคำอธิบาย และเราสั่งแบบจำลอง เหล่านั้น. เราต้องการแบบจำลองสองอัน โดยรวมแล้วเราควรจะมี 4 พ็อดที่เอาต์พุต เราจำเรื่องการจัดเก็บได้มันจะกลับมาในภายหลังเล็กน้อย การจัดเก็บเป็นเรื่องแยกต่างหาก

มันเป็นเช่นนี้

มันจะกลายเป็นแบบนี้ มีการเพิ่มแบบจำลอง อันที่ 4 ไม่พอดี เราเชื่อว่าน่าจะมีหลายคนอยู่ตรงนั้น และ ZooKeeper ก็ถูกเพิ่มเข้ามาที่ด้านข้าง แผนการมีความซับซ้อนมากขึ้น

และก็ถึงเวลาเพิ่มงานต่อไป เราจะเพิ่มพื้นที่เก็บข้อมูลถาวร

สำหรับ Persistent Storage เรามีตัวเลือกต่างๆ มากมาย

หากเราทำงานในผู้ให้บริการระบบคลาวด์ เช่น ใช้ Amazon, Google ก็มีแนวโน้มที่ดีที่จะใช้พื้นที่เก็บข้อมูลบนคลาวด์ สะดวกมากมันดี

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

มาดูกันว่าเรามีอะไรบ้างเกี่ยวกับที่เก็บข้อมูลบนคลาวด์

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

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

และเพราะว่า ClickHouse มุ่งเน้นที่ประสิทธิภาพการทำงานโดยเฉพาะ บางคนถึงกับบอกว่ามันบีบทุกอย่างเท่าที่ทำได้ ซึ่งเป็นเหตุผลว่าทำไมลูกค้าหลายรายจึงพยายามบีบประสิทธิภาพการทำงานสูงสุดออกมา

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

Kubernetes มีนามธรรมสามประการสำหรับการใช้พื้นที่จัดเก็บในตัวเครื่องใน Kubernetes นี้:

• ว่างเปล่าDir
• โฮสต์พาธ
• ในประเทศ

มาดูกันว่ามันต่างกันอย่างไรและคล้ายกันอย่างไร

ประการแรก ในทั้งสามแนวทาง เรามีพื้นที่จัดเก็บข้อมูล ซึ่งเป็นดิสก์ภายในเครื่องที่อยู่บนโหนด k8s ทางกายภาพเดียวกัน แต่พวกเขามีความแตกต่างบางอย่าง

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

ในทางปฏิบัติ Docker จะสร้างโฟลเดอร์ชั่วคราวที่ไหนสักแห่งตามเส้นทางของตัวเองและเรียกมันว่าแฮชแบบยาว และมีอินเทอร์เฟซในการเข้าถึง

สิ่งนี้จะทำงานอย่างไรตามประสิทธิภาพ? สิ่งนี้จะทำงานที่ความเร็วของดิสก์ในเครื่องเช่น นี่คือการเข้าถึงสกรูของคุณอย่างเต็มที่

แต่กรณีนี้มีข้อเสียเปรียบ ความคงอยู่ค่อนข้างน่าสงสัยในเรื่องนี้ ครั้งแรกที่ Docker เคลื่อนย้ายพร้อมกับคอนเทนเนอร์ Persistent จะสูญหายไป หาก Kubernetes ต้องการย้ายพ็อดนี้ไปยังดิสก์อื่นด้วยเหตุผลบางประการ ข้อมูลจะสูญหาย

วิธีนี้เหมาะสำหรับการทดสอบเนื่องจากแสดงความเร็วปกติแล้ว แต่สำหรับสิ่งที่ร้ายแรง ตัวเลือกนี้ไม่เหมาะ

ดังนั้นจึงมีแนวทางที่สอง นี่คือโฮสต์พาธ หากคุณดูสไลด์ก่อนหน้าและสไลด์นี้ คุณจะเห็นความแตกต่างเพียงอย่างเดียว โฟลเดอร์ของเราย้ายจาก Docker ไปยังโหนด Kubernetes โดยตรง ที่นี่ง่ายกว่าเล็กน้อย เราระบุเส้นทางโดยตรงบนระบบไฟล์ในเครื่องที่เราต้องการจัดเก็บข้อมูลของเรา

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

นอกจากนี้ยังมีข้อเสีย นี่คือความซับซ้อนของการจัดการ Kubernetes ของเราอาจต้องการย้าย Pod ไปยังโหนดทางกายภาพอื่น และนี่คือจุดที่ DevOps เข้ามามีบทบาท เขาต้องอธิบายให้ทั้งระบบถูกต้องว่าพ็อดเหล่านี้สามารถย้ายไปยังโหนดที่คุณมีบางอย่างติดตั้งอยู่ตามเส้นทางเหล่านี้ได้เท่านั้น และได้ครั้งละไม่เกินหนึ่งโหนด มันค่อนข้างยาก

โดยเฉพาะอย่างยิ่งสำหรับวัตถุประสงค์เหล่านี้ เราได้สร้างเทมเพลตในตัวดำเนินการของเราเพื่อซ่อนความซับซ้อนทั้งหมดนี้ และคุณสามารถพูดได้ว่า: “ฉันต้องการมี ClickHouse หนึ่งอินสแตนซ์สำหรับแต่ละโหนดทางกายภาพและตามเส้นทางดังกล่าว”

แต่เราไม่ใช่คนเดียวที่ต้องการความต้องการนี้ ดังนั้นสุภาพบุรุษจาก Kubernetes เองก็เข้าใจดีว่าผู้คนต้องการเข้าถึงดิสก์จริง ดังนั้นพวกเขาจึงจัดเตรียมเลเยอร์ที่สาม

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

กลับมาที่ปัญหาเชิงปฏิบัติของเรากัน กลับไปที่เทมเพลต YAML กัน ที่นี่เรามีพื้นที่เก็บของจริง เรากลับมาแล้ว เราตั้งค่าเทมเพลต VolumeClaim แบบคลาสสิกเช่นเดียวกับใน k8s และเราอธิบายว่าเราต้องการพื้นที่เก็บข้อมูลประเภทใด

หลังจากนี้ k8s จะขอพื้นที่เก็บข้อมูล จะจัดสรรให้เราใน StatefulSet และในที่สุดมันก็จะเป็นของ ClickHouse

เรามีโครงการนี้ การจัดเก็บถาวรของเราเป็นสีแดง ซึ่งดูเหมือนจะบอกเป็นนัยว่าจำเป็นต้องทำให้เสร็จ

และกลายเป็นสีเขียว ขณะนี้ ClickHouse บนโครงร่างคลัสเตอร์ k8s เสร็จสมบูรณ์แล้ว เรามีชิ้นส่วน แบบจำลอง ZooKeeper เรามี Persistent จริง ซึ่งนำไปใช้ไม่ทางใดก็ทางหนึ่ง โครงการนี้เปิดดำเนินการเต็มรูปแบบแล้ว

เรามีชีวิตอยู่ต่อไป คลัสเตอร์ของเรากำลังพัฒนา และ Alexey พยายามและเผยแพร่ ClickHouse เวอร์ชันใหม่

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

เราจะพูดอะไรเกี่ยวกับเรื่องนี้ได้บ้าง?

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

เข้าไปลึกเข้าไปข้างในกันหน่อย ก่อนหน้านี้ เราได้พูดคุยเกี่ยวกับวิธีการทำงานของตัวดำเนินการ ClickHouse ที่เกี่ยวข้องกับข้อมูลเฉพาะของ ClickHouse

ตอนนี้ฉันอยากจะพูดสักสองสามคำเกี่ยวกับวิธีการทำงานของโอเปอเรเตอร์โดยทั่วไป รวมถึงวิธีโต้ตอบกับ K8

มาดูการโต้ตอบกับ K8 กันก่อน จะเกิดอะไรขึ้นเมื่อเราสมัคร kubectl? ออบเจ็กต์ของเราปรากฏใน etcd ผ่านทาง API

ตัวอย่างเช่น ออบเจ็กต์ Kubernetes พื้นฐาน: พ็อด, StatefulSet, บริการ และอื่นๆ ในรายการ

ในขณะเดียวกันก็ไม่มีอะไรเกิดขึ้นทางกายภาพเลย วัตถุเหล่านี้จะต้องเป็นรูปธรรมในคลัสเตอร์

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

และมันทำให้วัตถุของเราเป็นรูปธรรมใน K8

แต่เราต้องการดำเนินการไม่เพียงแต่กับพ็อดและ StatefulSets เท่านั้น เรายังต้องการสร้าง ClickHouseInstallation เช่น ออบเจ็กต์ประเภท ClickHouse เพื่อดำเนินการกับมันโดยรวม จนถึงขณะนี้ยังไม่มีความเป็นไปได้ดังกล่าว

แต่ K8s มีสิ่งดีๆ ดังต่อไปนี้ เราต้องการให้เรามีเอนทิตีที่ซับซ้อนเช่นนี้ ซึ่งคลัสเตอร์ของเราจะประกอบจากพ็อดและ StatefulSet

และต้องทำอะไรเพื่อสิ่งนี้? ขั้นแรก คำจำกัดความทรัพยากรที่กำหนดเองจะเข้ามาในรูปภาพ มันคืออะไร? นี่คือคำอธิบายสำหรับ K8 ว่าคุณจะมีประเภทข้อมูลอีกหนึ่งประเภทที่เราต้องการเพิ่มทรัพยากรที่กำหนดเองลงในพ็อด StatefulSet ซึ่งจะซับซ้อนภายใน นี่คือคำอธิบายของโครงสร้างข้อมูล

เรายังส่งไปที่นั่นผ่านทาง kubectl Apply Kubernetes รับมันอย่างมีความสุข

และตอนนี้ในที่เก็บข้อมูลของเรา ออบเจ็กต์ใน etcd มีโอกาสที่จะบันทึกทรัพยากรที่กำหนดเองที่เรียกว่า ClickHouseInstallation

แต่สำหรับตอนนี้จะไม่มีอะไรเกิดขึ้นอีกต่อไป นั่นคือหากตอนนี้เราสร้างไฟล์ YAML ที่เราดูเพื่ออธิบายส่วนย่อยและแบบจำลองแล้วพูดว่า "ใช้ kubectl" จากนั้น Kubernetes จะยอมรับมัน ใส่ไว้ใน etcd แล้วพูดว่า: "เยี่ยมมาก แต่ฉันไม่รู้ว่าต้องทำอย่างไร กับมัน ฉันไม่รู้วิธีรักษา ClickHouseInstallation ไว้”

ดังนั้นเราจึงต้องการใครสักคนเพื่อช่วย Kubernetes ให้บริการข้อมูลประเภทใหม่ ทางด้านซ้ายเรามีตัวควบคุม Kubernetes ดั้งเดิมที่ใช้งานได้กับประเภทข้อมูลดั้งเดิม และทางด้านขวาเราควรมีตัวควบคุมแบบกำหนดเองที่สามารถทำงานกับประเภทข้อมูลแบบกำหนดเองได้

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

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

ผู้ปฏิบัติงานทำงานอย่างไร? มาดูทางด้านขวาเพื่อดูว่าเขาทำกันอย่างไร มาดูกันว่าโอเปอเรเตอร์ทำให้ทั้งหมดนี้เป็นจริงได้อย่างไร และปฏิสัมพันธ์กับ K8 เกิดขึ้นได้อย่างไร

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

ผู้ปฏิบัติงานสมัครรับกิจกรรมและต้องแสดงปฏิกิริยาบางอย่าง หน้าที่ของตนคือการตอบสนองต่อเหตุการณ์ที่เกิดขึ้นใหม่

กิจกรรมถูกสร้างขึ้นโดยการอัพเดตบางอย่าง ไฟล์ YAML ของเราพร้อมคำอธิบาย ClickHouseInstallation มาถึงแล้ว เขาไป etcd ผ่าน kubectl Apply มีเหตุการณ์เกิดขึ้นที่นั่น และด้วยเหตุนี้เหตุการณ์นี้จึงมาถึงผู้ดำเนินการ ClickHouse ผู้ดำเนินการได้รับคำอธิบายนี้ และเขาจะต้องทำอะไรสักอย่าง หากมีการอัปเดตมาถึงสำหรับออบเจ็กต์ ClickHouseInstallation คุณจะต้องอัปเดตคลัสเตอร์ และหน้าที่ของผู้ปฏิบัติงานคือการอัพเดตคลัสเตอร์

เขากำลังทำอะไร? ก่อนอื่น เราต้องจัดทำแผนปฏิบัติการสำหรับสิ่งที่เราจะทำกับการอัปเดตนี้ การอัปเดตอาจมีขนาดเล็กมาก เช่น มีขนาดเล็กในการดำเนินการ YAML แต่สามารถนำมาซึ่งการเปลี่ยนแปลงขนาดใหญ่มากในคลัสเตอร์ ดังนั้นผู้ปฏิบัติงานจึงสร้างแผนขึ้นมา และจากนั้นเขาก็ยึดติดกับแผนนั้น

ตามแผนนี้ เขาเริ่มปรุงโครงสร้างนี้ภายในเพื่อทำให้ฝัก บริการต่างๆ เป็นจริง เช่น ทำสิ่งที่งานหลักของเขาคือ นี่คือวิธีสร้างคลัสเตอร์ ClickHouse ใน Kubernetes

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

Kubernetes รับผิดชอบสิ่งต่าง ๆ ของระบบ เช่น สำหรับชุดพื้นฐานของออบเจ็กต์ที่สามารถตีความได้ว่าเป็นขอบเขตระบบ Kubernetes รู้วิธีเปิดพ็อด วิธีรีสตาร์ทคอนเทนเนอร์ วิธีเมานต์วอลุ่ม วิธีทำงานกับ ConfigMap เช่น ทุกสิ่งที่สามารถเรียกได้ว่าเป็นระบบ

ตัวดำเนินการดำเนินการในโดเมน โอเปอเรเตอร์แต่ละรายถูกสร้างขึ้นมาสำหรับสาขาวิชาของตนเอง เราทำเพื่อ ClickHouse

และผู้ปฏิบัติงานโต้ตอบอย่างแม่นยำในแง่ของสาขาวิชา เช่น การเพิ่มแบบจำลอง การสร้างไดอะแกรม การตั้งค่าการตรวจสอบ ส่งผลให้เกิดความแตกแยก

ลองดูตัวอย่างในทางปฏิบัติว่าการแบ่งความรับผิดชอบนี้เกิดขึ้นได้อย่างไรเมื่อเราดำเนินการเพิ่มแบบจำลอง

ผู้ปฏิบัติงานได้รับงาน - เพื่อเพิ่มเรพลิกา ผู้ดำเนินการทำอะไร? ผู้ดำเนินการจะคำนวณว่าจำเป็นต้องสร้าง StatefulSet ใหม่ โดยจะต้องอธิบายเทมเพลต การอ้างสิทธิ์ปริมาณดังกล่าวและดังกล่าว

เขาเตรียมมันทั้งหมดแล้วส่งต่อให้กับ K8 เขาบอกว่าเขาต้องการ ConfigMap, StatefulSet, Volume Kubernetes กำลังทำงานอยู่ เขาสร้างหน่วยพื้นฐานที่เขาใช้งานให้เป็นรูปธรรม

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

และหลังจากนั้น ClickHouse เองก็เข้ามามีบทบาทเช่น อีกหนึ่งเอนทิตีระดับสูงกว่า นี่เป็นฐานข้อมูลอยู่แล้ว มีอินสแตนซ์ของตัวเอง ซึ่งเป็นอีกแบบจำลองที่กำหนดค่าไว้ซึ่งพร้อมที่จะเข้าร่วมคลัสเตอร์

ปรากฎว่าห่วงโซ่การดำเนินการและการแบ่งความรับผิดชอบเมื่อเพิ่มแบบจำลองนั้นค่อนข้างยาว

เราดำเนินงานภาคปฏิบัติของเราต่อไป หากคุณมีคลัสเตอร์อยู่แล้ว คุณสามารถย้ายการกำหนดค่าได้

เราสร้างมันขึ้นมาเพื่อให้คุณสามารถวางลงใน xml ที่มีอยู่ได้ ซึ่ง ClickHouse เข้าใจ

คุณสามารถปรับแต่ง ClickHouse ได้ การปรับใช้แบบแบ่งโซนเพียงอย่างเดียวคือสิ่งที่ฉันพูดถึงเมื่ออธิบาย hostPath ซึ่งเป็นที่จัดเก็บในตัวเครื่อง นี่คือวิธีการปรับใช้แบบแบ่งโซนอย่างถูกต้อง

ภารกิจภาคปฏิบัติต่อไปคือการเฝ้าติดตาม

หากคลัสเตอร์ของเราเปลี่ยนแปลง เราจำเป็นต้องกำหนดค่าการตรวจสอบเป็นระยะ

ลองดูที่แผนภาพ เราได้ดูลูกศรสีเขียวที่นี่แล้ว ทีนี้มาดูลูกศรสีแดงกัน นี่คือวิธีที่เราต้องการตรวจสอบคลัสเตอร์ของเรา วิธีที่หน่วยวัดจากคลัสเตอร์ ClickHouse เข้าสู่ Prometheus แล้วเข้าสู่ Grafana

ความยากลำบากในการติดตามคืออะไร? เหตุใดจึงนำเสนอสิ่งนี้ว่าเป็นความสำเร็จบางประเภท ความยากอยู่ที่ไดนามิก เมื่อเรามีคลัสเตอร์เดียวและเป็นแบบคงที่ เราก็สามารถตั้งค่าการตรวจสอบได้เพียงครั้งเดียวและไม่ต้องกังวลอีกต่อไป

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

คลัสเตอร์ของเราพัฒนาไปอย่างไร? ในตอนแรกเขาก็เป็นเช่นนั้น

แล้วเขาก็เป็นแบบนี้

สุดท้ายเขาก็กลายเป็นแบบนี้

และการตรวจสอบจะดำเนินการโดยอัตโนมัติโดยผู้ปฏิบัติงาน จุดเข้าเพียงจุดเดียว

และที่ทางออก เราจะดูแดชบอร์ด Grafana เพื่อดูว่าชีวิตภายในคลัสเตอร์ของเราเดือดพล่านแค่ไหน

อย่างไรก็ตาม แดชบอร์ด Grafana ยังแจกจ่ายให้กับผู้ให้บริการของเราโดยตรงในซอร์สโค้ด คุณสามารถเชื่อมต่อและใช้งานได้ DevOps ของเราให้ภาพหน้าจอนี้แก่ฉัน

เราอยากจะไปที่ไหนต่อไป? นี้:

• พัฒนาการทดสอบอัตโนมัติ ภารกิจหลักคือการทดสอบเวอร์ชันใหม่โดยอัตโนมัติ
• เรายังต้องการทำให้การผสานรวมกับ ZooKeeper เป็นแบบอัตโนมัติอีกด้วย และมีแผนที่จะบูรณาการกับผู้ให้บริการ ZooKeeper เหล่านั้น. มีการเขียนโอเปอเรเตอร์สำหรับ ZooKeeper และมีเหตุผลที่โอเปอเรเตอร์ทั้งสองเริ่มบูรณาการเพื่อสร้างโซลูชันที่สะดวกยิ่งขึ้น
• เราต้องการทำสัญญาณชีพที่ซับซ้อนกว่านี้
• ฉันเน้นด้วยสีเขียวว่าเรากำลังเข้าใกล้การสืบทอดเทมเพลต - เสร็จแล้วนั่นคือ ด้วยโอเปอเรเตอร์รุ่นถัดไปเราจะมีการสืบทอดเทมเพลตแล้ว นี่เป็นเครื่องมืออันทรงพลังที่ช่วยให้คุณสามารถสร้างการกำหนดค่าที่ซับซ้อนได้จากชิ้นส่วนต่างๆ
• และเราต้องการระบบอัตโนมัติสำหรับงานที่ซับซ้อน หลักๆ คือการ Re-sharding

ลองใช้ผลลัพธ์ระดับกลางบ้าง

เราได้อะไรตามมา? และคุ้มที่จะทำหรือไม่? จำเป็นหรือไม่ที่จะพยายามลากฐานข้อมูลไปยัง Kubernetes และใช้ตัวดำเนินการโดยทั่วไปและตัวดำเนินการ Alitnity โดยเฉพาะ

ที่ผลลัพธ์ที่เราได้รับ:

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

เหลือเพียงคำถามสุดท้ายเท่านั้น เรามีฐานข้อมูลใน Kubernetes, virtualization อยู่แล้ว แล้วประสิทธิภาพของโซลูชั่นดังกล่าวล่ะ โดยเฉพาะอย่างยิ่งเมื่อ ClickHouse ได้รับการปรับให้เหมาะกับประสิทธิภาพแล้ว?

คำตอบคือทุกอย่างเรียบร้อยดี! ฉันจะไม่ลงรายละเอียดนี่คือหัวข้อของรายงานแยกต่างหาก

แต่มีโครงการเช่น TSBS ภารกิจหลักคืออะไร? นี่คือการทดสอบประสิทธิภาพของฐานข้อมูล นี่คือความพยายามที่จะเปรียบเทียบความอบอุ่นกับความอบอุ่น นุ่มนวลกับความนุ่มนวล

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

รองรับฐานข้อมูลจำนวนมากอยู่แล้ว ฉันได้ระบุสามสิ่งหลักแล้ว นี้:

• มาตราส่วนเวลาDB.
• InfluxDB.
• คลิกเฮาส์

มีการเปรียบเทียบกับโซลูชันอื่นที่คล้ายกันด้วย เปรียบเทียบกับ RedShift มีการเปรียบเทียบใน Amazon ClickHouse ยังนำหน้าทุกคนในเรื่องนี้เป็นอย่างดี

สิ่งที่ฉันพูดได้ข้อสรุปอะไรบ้าง?

• DB ใน Kubernetes เป็นไปได้ อาจเป็นไปได้ แต่โดยรวมแล้วดูเหมือนว่าจะเป็นไปได้ ClickHouse ใน Kubernetes เป็นไปได้อย่างแน่นอนด้วยความช่วยเหลือจากโอเปอเรเตอร์ของเรา
• ผู้ปฏิบัติงานช่วยให้กระบวนการต่างๆ เป็นอัตโนมัติและทำให้ชีวิตง่ายขึ้นอย่างแท้จริง
• ประสิทธิภาพเป็นเรื่องปกติ
• และสำหรับเราดูเหมือนว่าสิ่งนี้สามารถและควรใช้ได้

โอเพ่นซอร์ส - เข้าร่วมกับเรา!

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

ขอบคุณทุกคน!

คำถาม

ขอบคุณสำหรับรายงาน! ฉันชื่อแอนตัน ฉันมาจาก SEMrush ฉันสงสัยว่าเกิดอะไรขึ้นกับการบันทึก เราได้ยินเกี่ยวกับการตรวจสอบ แต่ไม่มีอะไรเกี่ยวกับการบันทึก ถ้าเราพูดถึงคลัสเตอร์ทั้งหมด ตัวอย่างเช่น เราได้ยกคลัสเตอร์บนฮาร์ดแวร์ และเราใช้การบันทึกแบบรวมศูนย์ โดยรวบรวมไว้ในฮีปทั่วไปโดยใช้วิธีมาตรฐาน จากนั้นเราก็จะได้ข้อมูลที่เราสนใจ

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

สวัสดี! ขอบคุณสำหรับรายงาน! ฉันมีคำถามมาตรฐานที่เกี่ยวข้องกับวอลุ่มถาวร เมื่อเราสร้างการกำหนดค่าด้วยโอเปอเรเตอร์นี้ โอเปอเรเตอร์จะระบุได้อย่างไรว่าเรามีดิสก์หรือโฟลเดอร์ใดแนบอยู่ในโหนดใด ก่อนอื่นเราต้องอธิบายให้เขาฟังว่ากรุณาวาง ClickHouse ของเราบนโหนดเหล่านี้ที่มีดิสก์หรือไม่?

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

สั้นๆ หน้าตาเป็นแบบนี้ครับ โดยปกติแล้ว เราจำเป็นต้องจัดเตรียมวอลุ่มเหล่านี้ ในขณะนี้ ไม่มีข้อกำหนดแบบไดนามิกในที่จัดเก็บในตัวเครื่อง ดังนั้น DevOps จึงต้องตัดดิสก์เองซึ่งเป็นวอลุ่มเหล่านี้ และพวกเขาจะต้องอธิบายการจัดเตรียม Kubernetes ว่าคุณจะมีวอลุ่มถาวรของคลาสดังกล่าวและคลาสดังกล่าว ซึ่งอยู่บนโหนดดังกล่าวและโหนดดังกล่าว จากนั้น คุณจะต้องอธิบายให้ Kubernetes ฟังว่าพ็อดที่ต้องการคลาสพื้นที่จัดเก็บในตัวเครื่องนั้นจะต้องถูกส่งไปยังโหนดดังกล่าวและโหนดดังกล่าวโดยใช้ป้ายกำกับเท่านั้น เพื่อวัตถุประสงค์เหล่านี้ ผู้ปฏิบัติงานสามารถกำหนดป้ายกำกับบางประเภทและหนึ่งรายการต่ออินสแตนซ์โฮสต์ได้ และปรากฎว่า Kubernetes กำหนดเส้นทางพ็อดให้ทำงานบนโหนดที่ตรงตามข้อกำหนดและป้ายกำกับเท่านั้น ผู้ดูแลระบบจะกำหนดป้ายกำกับและจัดสรรดิสก์ด้วยตนเอง แล้วมันก็ขยายขนาด

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

ฉันมีคำถามที่สองเกี่ยวกับเรื่องนี้ Kubernetes ได้รับการออกแบบในลักษณะที่ไม่สำคัญสำหรับเราไม่ว่าเราจะสูญเสียโหนดหรือไม่ก็ตาม ในกรณีนี้เราควรทำอย่างไรหากเราสูญเสียโหนดที่ชาร์ดของเราค้าง?

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

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

นิสัยที่ตามมาคืออะไร? DevOps มีหน้าที่รับผิดชอบในการตรวจสอบให้แน่ใจว่าข้อมูลจะไม่สูญหาย เขาต้องตั้งค่าการจำลองอย่างถูกต้อง และต้องแน่ใจว่าการจำลองกำลังทำงานอยู่ แบบจำลองในระดับ ClickHouse ต้องมีข้อมูลที่ซ้ำกัน นี่ไม่ใช่ปัญหาที่ผู้ปฏิบัติงานแก้ไข และไม่ใช่ปัญหาที่ Kubernetes แก้ไขเอง นี่คือระดับ ClickHouse

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

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

จะเกิดอะไรขึ้นถ้าตัวดำเนินการขัดข้องและรีสตาร์ทใช่ไหม?

ใช่. และในขณะนั้นเหตุการณ์ก็มาถึง

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

สวัสดี! ขอบคุณสำหรับรายงาน! บริษัท มิทรี ซาเวียลอฟ สเมโดวา. มีแผนที่จะเพิ่มความสามารถในการกำหนดค่าด้วย haproxy ให้กับผู้ปฏิบัติงานหรือไม่? ฉันสนใจบาลานเซอร์ตัวอื่นนอกเหนือจากแบบมาตรฐาน เพื่อให้มันฉลาดและเข้าใจว่า ClickHouse อยู่ที่นั่นจริงๆ

คุณกำลังพูดถึงทางเข้า?

ใช่ แทนที่ Ingress ด้วย haproxy ใน haproxy คุณสามารถระบุโทโพโลยีของคลัสเตอร์ที่มีเรพลิกาได้

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

มีแล้ว.

ดี. เราเปิดรับข้อเสนอแนะใด ๆ และ haproxy จะถูกเพิ่มเข้าไปในรายการสิ่งที่ต้องทำ รายการสิ่งที่ต้องทำมีเพิ่มขึ้นแต่ยังไม่หดตัว แต่นี่เป็นสิ่งที่ดีก็หมายความว่าสินค้าเป็นที่ต้องการ

ที่มา: will.com