สวัสดีฮับ!
ครั้งหนึ่งเราเป็นคนแรกที่แนะนำหัวข้อนี้สู่ตลาดรัสเซีย และดำเนินการต่อ เพื่อการพัฒนา โดยเฉพาะเราพบหัวข้อปฏิสัมพันธ์ระหว่างคาฟคากับ . สังเกตได้ (และค่อนข้างระมัดระวัง) หัวข้อนี้เผยแพร่ในบล็อก Confluent เมื่อเดือนตุลาคมปีที่แล้ว ภายใต้การประพันธ์ของ Gwen Shapira วันนี้เราอยากจะดึงความสนใจของคุณไปยังบทความล่าสุดจากเดือนเมษายนโดย Johann Gyger ผู้ซึ่งแม้จะไม่มีเครื่องหมายคำถามในชื่อเรื่อง แต่ก็ตรวจสอบหัวข้อในลักษณะที่มีสาระสำคัญมากขึ้นพร้อมกับข้อความพร้อมลิงก์ที่น่าสนใจ โปรดยกโทษให้เราในการแปล "chaos Monkey" ฟรีหากคุณทำได้!
การแนะนำ
Kubernetes ได้รับการออกแบบมาเพื่อจัดการปริมาณงานที่ไม่เก็บสถานะ โดยปกติแล้ว ปริมาณงานดังกล่าวจะแสดงในรูปแบบของสถาปัตยกรรมไมโครเซอร์วิส ซึ่งมีน้ำหนักเบา ปรับขนาดได้ดีในแนวนอน เป็นไปตามหลักการของแอปพลิเคชัน 12 ปัจจัย และสามารถทำงานร่วมกับเซอร์กิตเบรกเกอร์และ Chaos Monkey ได้
ในทางกลับกัน Kafka ทำหน้าที่เป็นฐานข้อมูลแบบกระจายเป็นหลัก ดังนั้นเมื่อทำงานคุณต้องจัดการกับสถานะและมันหนักกว่าไมโครเซอร์วิสมาก Kubernetes รองรับการโหลด stateful แต่ดังที่ Kelsey Hightower ชี้ให้เห็นในทวีตสองรายการ พวกเขาควรได้รับการจัดการด้วยความระมัดระวัง:
บางคนรู้สึกว่าหากคุณรวม Kubernetes เข้าสู่เวิร์กโหลดแบบมีสถานะ Kubernetes ก็จะกลายเป็นฐานข้อมูลที่มีการจัดการเต็มรูปแบบซึ่งแข่งขันกับ RDS นี่เป็นสิ่งที่ผิด บางที หากคุณทำงานหนักเพียงพอ เพิ่มส่วนประกอบเพิ่มเติม และดึงดูดทีมวิศวกร SRE คุณจะสามารถสร้าง RDS บน Kubernetes ได้
ฉันแนะนำให้ทุกคนใช้ความระมัดระวังอย่างยิ่งเสมอเมื่อใช้งานปริมาณงานแบบมีสถานะบน Kubernetes คนส่วนใหญ่ที่ถามว่า “ฉันสามารถเรียกใช้ปริมาณงานแบบมีสถานะบน Kubernetes ได้หรือไม่” ยังไม่มีประสบการณ์กับ Kubernetes เพียงพอ และบ่อยครั้งกับภาระงานที่พวกเขาถามถึง
คุณควรรัน Kafka บน Kubernetes หรือไม่? คำถามโต้แย้ง: Kafka จะทำงานได้ดีขึ้นหากไม่มี Kubernetes หรือไม่ นั่นเป็นเหตุผลที่ฉันต้องการเน้นในบทความนี้ว่า Kafka และ Kubernetes ส่งเสริมซึ่งกันและกันอย่างไร และข้อผิดพลาดที่อาจเกิดขึ้นจากการรวมเข้าด้วยกัน
เวลาที่เสร็จสิ้น
เรามาพูดถึงสิ่งพื้นฐานกันดีกว่า - สภาพแวดล้อมรันไทม์นั่นเอง
กระบวนการ
โบรกเกอร์ Kafka เป็นมิตรกับ CPU TLS อาจแนะนำค่าใช้จ่ายบางส่วน อย่างไรก็ตาม ไคลเอนต์ Kafka อาจใช้ CPU เข้มข้นมากขึ้นหากใช้การเข้ารหัส แต่สิ่งนี้จะไม่ส่งผลกระทบต่อโบรกเกอร์
หน่วยความจำ
นายหน้าคาฟคากินหน่วยความจำ โดยทั่วไปขนาดฮีป JVM จะจำกัดอยู่ที่ 4-5 GB แต่คุณจะต้องมีหน่วยความจำระบบจำนวนมากด้วยเนื่องจาก Kafka ใช้แคชของเพจอย่างมาก ใน Kubernetes ให้ตั้งค่าทรัพยากรคอนเทนเนอร์และขีดจำกัดคำขอตามลำดับ
ที่เก็บข้อมูล
การจัดเก็บข้อมูลในคอนเทนเนอร์เป็นแบบชั่วคราว - ข้อมูลจะสูญหายเมื่อรีสตาร์ท สำหรับข้อมูล Kafka คุณสามารถใช้วอลุ่มได้ emptyDirและผลลัพธ์จะคล้ายกัน: ข้อมูลนายหน้าของคุณจะหายไปหลังจากเสร็จสิ้น ข้อความของคุณยังคงสามารถจัดเก็บไว้ในโบรกเกอร์อื่นเป็นแบบจำลองได้ ดังนั้น หลังจากการรีสตาร์ท นายหน้าล้มเหลวจะต้องจำลองข้อมูลทั้งหมดก่อน และกระบวนการนี้อาจใช้เวลานาน
นี่คือเหตุผลที่คุณควรใช้การจัดเก็บข้อมูลระยะยาว ปล่อยให้เป็นที่เก็บข้อมูลระยะยาวที่ไม่ใช่ในเครื่องด้วยระบบไฟล์ XFS หรืออย่างแม่นยำยิ่งขึ้นคือ ext4 อย่าใช้ NFS ฉันเตือนคุณแล้ว. NFS เวอร์ชัน v3 หรือ v4 จะไม่ทำงาน กล่าวโดยสรุป นายหน้า Kafka จะขัดข้องหากไม่สามารถลบไดเร็กทอรีข้อมูลได้เนื่องจากปัญหา "การเปลี่ยนชื่อโง่" ใน NFS ถ้าฉันยังไม่มั่นใจคุณให้ระวังให้มาก . ที่เก็บข้อมูลควรไม่ใช่ในพื้นที่เพื่อให้ Kubernetes สามารถเลือกโหนดใหม่ได้อย่างยืดหยุ่นมากขึ้นหลังจากการรีสตาร์ทหรือการย้ายตำแหน่ง
เครือข่าย
เช่นเดียวกับระบบแบบกระจายส่วนใหญ่ ประสิทธิภาพของ Kafka ขึ้นอยู่กับการรักษาเวลาแฝงของเครือข่ายให้น้อยที่สุดและแบนด์วิธสูงสุด อย่าพยายามโฮสต์โบรกเกอร์ทั้งหมดบนโหนดเดียวกัน เนื่องจากจะทำให้ความพร้อมใช้งานลดลง หากโหนด Kubernetes ล้มเหลว คลัสเตอร์ Kafka ทั้งหมดจะล้มเหลว นอกจากนี้ อย่ากระจายคลัสเตอร์ Kafka ไปทั่วศูนย์ข้อมูลทั้งหมด เช่นเดียวกับคลัสเตอร์ Kubernetes การประนีประนอมที่ดีในกรณีนี้คือการเลือกโซนความพร้อมใช้งานที่แตกต่างกัน
องค์ประกอบ
แถลงการณ์ปกติ
เว็บไซต์ Kubernetes มี เกี่ยวกับวิธีกำหนดค่า ZooKeeper โดยใช้รายการ เนื่องจาก ZooKeeper เป็นส่วนหนึ่งของ Kafka จึงเป็นสถานที่ที่ดีในการเริ่มทำความคุ้นเคยกับแนวคิด Kubernetes ที่นำมาใช้ที่นี่ เมื่อคุณเข้าใจสิ่งนี้แล้ว คุณสามารถใช้แนวคิดเดียวกันกับคลัสเตอร์ Kafka ได้
- ใต้: พ็อดเป็นหน่วยที่ปรับใช้ได้เล็กที่สุดใน Kubernetes พ็อดประกอบด้วยภาระงานของคุณ และพ็อดเองก็สอดคล้องกับกระบวนการในคลัสเตอร์ของคุณ พ็อดประกอบด้วยคอนเทนเนอร์หนึ่งรายการขึ้นไป เซิร์ฟเวอร์ ZooKeeper แต่ละตัวใน Ensemble และแต่ละโบรกเกอร์ในคลัสเตอร์ Kafka จะทำงานบนพ็อดที่แยกจากกัน
- ชุดเก็บสถานะ: StatefulSet เป็นออบเจ็กต์ Kubernetes ที่จัดการปริมาณงานแบบมีสถานะหลายรายการ และปริมาณงานดังกล่าวจำเป็นต้องมีการประสานงาน StatefulSets ให้การรับประกันเกี่ยวกับการเรียงลำดับพ็อดและความเป็นเอกลักษณ์
- บริการหัวขาด: บริการช่วยให้คุณแยกพ็อดออกจากไคลเอ็นต์โดยใช้ชื่อแบบลอจิคัล Kubernetes ในกรณีนี้มีหน้าที่รับผิดชอบในการจัดสรรภาระงาน อย่างไรก็ตาม เมื่อใช้งานปริมาณงานแบบมีสถานะ เช่น ZooKeeper และ Kafka ลูกค้าจำเป็นต้องสื่อสารกับอินสแตนซ์เฉพาะ นี่คือจุดที่บริการ headless มีประโยชน์: ในกรณีนี้ ไคลเอนต์จะยังคงมีชื่อตรรกะ แต่คุณไม่จำเป็นต้องติดต่อกับพ็อดโดยตรง
- ปริมาณการจัดเก็บข้อมูลระยะยาว: จำเป็นต้องใช้วอลุ่มเหล่านี้เพื่อกำหนดค่าพื้นที่เก็บข้อมูลถาวรแบบบล็อกที่ไม่ใช่ในเครื่องที่กล่าวถึงข้างต้น
На มีชุดรายการที่ครอบคลุมเพื่อช่วยคุณเริ่มต้นใช้งาน Kafka บน Kubernetes
แผนภูมิหางเสือ
Helm เป็นตัวจัดการแพ็คเกจสำหรับ Kubernetes ที่สามารถเปรียบเทียบกับตัวจัดการแพ็คเกจ OS เช่น yum, apt, Homebrew หรือ Chocolatey ทำให้ง่ายต่อการติดตั้งแพ็คเกจซอฟต์แวร์ที่กำหนดไว้ล่วงหน้าที่อธิบายไว้ในแผนภูมิ Helm แผนภูมิ Helm ที่ได้รับการคัดเลือกมาอย่างดีทำให้การกำหนดค่าพารามิเตอร์ทั้งหมดเพื่อใช้ Kafka บน Kubernetes เป็นเรื่องง่าย มีไดอะแกรม Kafka หลายอัน: มีไดอะแกรมอย่างเป็นทางการอยู่ , มีอันหนึ่งจาก อีกหนึ่ง - จาก .
ผู้ประกอบการ
เนื่องจาก Helm มีข้อบกพร่อง เครื่องมืออีกอย่างหนึ่งจึงได้รับความนิยมอย่างมาก นั่นก็คือ ตัวดำเนินการ Kubernetes ผู้ดำเนินการไม่เพียงแต่จัดแพคเกจซอฟต์แวร์สำหรับ Kubernetes เท่านั้น แต่ยังช่วยให้คุณสามารถปรับใช้ซอฟต์แวร์ดังกล่าวและจัดการได้อีกด้วย
ในรายการ มีการกล่าวถึงโอเปอเรเตอร์สองตัวสำหรับ Kafka หนึ่งในนั้น - . Strimzi ช่วยให้คลัสเตอร์ Kafka ของคุณพร้อมใช้งานภายในไม่กี่นาทีเป็นเรื่องง่าย แทบไม่จำเป็นต้องมีการกำหนดค่า นอกจากนี้ ตัวดำเนินการเองก็มีคุณสมบัติที่ดีบางอย่าง เช่น การเข้ารหัส TLS แบบจุดต่อจุดภายในคลัสเตอร์ คอนฟลูเอนท์ก็จัดให้ .
การปฏิบัติ
การทดสอบประสิทธิภาพโดยการเปรียบเทียบอินสแตนซ์ Kafka ของคุณเป็นสิ่งสำคัญ การทดสอบดังกล่าวจะช่วยคุณค้นหาปัญหาคอขวดที่อาจเกิดขึ้นได้ก่อนที่ปัญหาจะเกิดขึ้น โชคดีที่ Kafka มีเครื่องมือทดสอบประสิทธิภาพอยู่ XNUMX เครื่องมือ: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. ใช้งานพวกมันอย่างแข็งขัน สำหรับการอ้างอิง คุณสามารถดูผลลัพธ์ที่อธิบายไว้ใน เจเครปส์หรือเน้นไปที่ Amazon MSK โดย Stéphane Maarek
การดำเนินงาน
การตรวจสอบ
ความโปร่งใสในระบบเป็นสิ่งสำคัญมาก - ไม่เช่นนั้นคุณจะไม่เข้าใจว่าเกิดอะไรขึ้น ปัจจุบันมีชุดเครื่องมือที่แข็งแกร่งที่ให้การตรวจสอบตามหน่วยเมตริกในรูปแบบคลาวด์เนทิฟ เครื่องมือยอดนิยมสองชนิดสำหรับจุดประสงค์นี้คือ Prometheus และ Grafana Prometheus สามารถรวบรวมตัววัดจากกระบวนการ Java ทั้งหมด (Kafka, Zookeeper, Kafka Connect) โดยใช้ JMX Exporter ด้วยวิธีที่ง่ายที่สุด หากคุณเพิ่มตัววัด cAdvisor คุณจะเข้าใจวิธีใช้ทรัพยากรใน Kubernetes ได้ชัดเจนยิ่งขึ้น
Strimzi มีตัวอย่างแดชบอร์ด Grafana สำหรับ Kafka ที่สะดวกมาก โดยจะแสดงภาพตัวชี้วัดหลัก เช่น เกี่ยวกับภาคที่มีการจำลองน้อยเกินไปหรือส่วนที่ออฟไลน์ ทุกอย่างชัดเจนมากที่นั่น ตัวชี้วัดเหล่านี้ได้รับการเสริมด้วยข้อมูลการใช้ทรัพยากรและประสิทธิภาพ รวมถึงตัวบ่งชี้ความเสถียร ดังนั้นคุณจะได้รับการตรวจสอบคลัสเตอร์ Kafka ขั้นพื้นฐานโดยไม่มีค่าใช้จ่าย!
ที่มา:
เป็นการดีที่จะเสริมทั้งหมดนี้ด้วยการตรวจสอบลูกค้า (ตัวชี้วัดของผู้บริโภคและผู้ผลิต) รวมถึงการตรวจสอบเวลาแฝง (สำหรับสิ่งนี้มี ) และการตรวจสอบตั้งแต่ต้นทางถึงปลายทาง - สำหรับการใช้งานนี้ .
การบันทึก
การบันทึกเป็นงานที่สำคัญอีกงานหนึ่ง ตรวจสอบให้แน่ใจว่าคอนเทนเนอร์ทั้งหมดในการติดตั้ง Kafka ของคุณได้รับการบันทึกไว้ stdout и stderrและตรวจสอบให้แน่ใจว่าคลัสเตอร์ Kubernetes ของคุณรวมบันทึกทั้งหมดไว้ในโครงสร้างพื้นฐานการบันทึกส่วนกลาง เช่น .
การทดสอบสมรรถนะ
Kubernetes ใช้การตรวจสอบความสดและความพร้อมเพื่อตรวจสอบว่าพ็อดของคุณทำงานตามปกติหรือไม่ หากการตรวจสอบความสดล้มเหลว Kubernetes จะหยุดคอนเทนเนอร์นั้นแล้วรีสตาร์ทโดยอัตโนมัติหากตั้งค่านโยบายการรีสตาร์ทไว้ตามนั้น หากการตรวจสอบความพร้อมล้มเหลว Kubernetes จะแยกพ็อดออกจากคำขอการบริการ ดังนั้น ในกรณีเช่นนี้ ไม่จำเป็นต้องใช้การแทรกแซงด้วยตนเองอีกต่อไป ซึ่งเป็นข้อดีอย่างมาก
กำลังเปิดตัวการอัปเดต
StatefulSets รองรับการอัปเดตอัตโนมัติ: หากคุณเลือกกลยุทธ์ RollingUpdate แต่ละอันภายใต้ Kafka จะได้รับการอัปเดตตามลำดับ ด้วยวิธีนี้ เวลาหยุดทำงานจะลดลงเหลือศูนย์
มาตราส่วน
การขยายคลัสเตอร์ Kafka ไม่ใช่เรื่องง่าย อย่างไรก็ตาม Kubernetes ทำให้การปรับขนาดพ็อดเป็นจำนวนเรพลิกาจำนวนหนึ่งเป็นเรื่องง่ายมาก ซึ่งหมายความว่าคุณสามารถกำหนดโบรกเกอร์ Kafka ได้มากเท่าที่คุณต้องการ สิ่งที่ยากที่สุดในกรณีนี้คือการกำหนดเซ็กเตอร์ใหม่หลังจากขยายขนาดหรือก่อนที่จะลดขนาดลง Kubernetes จะช่วยคุณในงานนี้อีกครั้ง
การบริหาร
งานที่เกี่ยวข้องกับการดูแลคลัสเตอร์ Kafka ของคุณ เช่น การสร้างหัวข้อและการกำหนดเซกเตอร์ใหม่ สามารถทำได้โดยใช้เชลล์สคริปต์ที่มีอยู่โดยการเปิดอินเทอร์เฟซบรรทัดคำสั่งในพ็อดของคุณ อย่างไรก็ตามวิธีนี้ไม่ได้สวยงามมากนัก Strimzi รองรับการจัดการหัวข้อโดยใช้โอเปอเรเตอร์อื่น มีห้องพักบางส่วนสำหรับการปรับปรุงที่นี่
สำรองและเรียกคืน
ขณะนี้ความพร้อมใช้งานของ Kafka จะขึ้นอยู่กับความพร้อมใช้งานของ Kubernetes ด้วย หากคลัสเตอร์ Kubernetes ของคุณล้มเหลว ในกรณีที่เลวร้ายที่สุด คลัสเตอร์ Kafka ของคุณก็จะล้มเหลวเช่นกัน ตามกฎของเมอร์ฟี่ สิ่งนี้จะเกิดขึ้นแน่นอน และคุณจะสูญเสียข้อมูล เพื่อลดความเสี่ยงประเภทนี้ ควรมีแนวคิดการสำรองข้อมูลที่ดี คุณสามารถใช้ MirrorMaker ได้ อีกทางเลือกหนึ่งคือใช้ S3 สำหรับสิ่งนี้ตามที่อธิบายไว้ในนี้ จากซาลันโด.
ข้อสรุป
เมื่อทำงานกับคลัสเตอร์ Kafka ขนาดเล็กถึงขนาดกลาง การใช้ Kubernetes คุ้มค่าอย่างแน่นอน เนื่องจากให้ความยืดหยุ่นเพิ่มเติมและทำให้ประสบการณ์ของผู้ปฏิบัติงานง่ายขึ้น หากคุณมีข้อกำหนดด้านเวลาแฝงและ/หรือปริมาณการประมวลผลที่ไม่สามารถทำงานได้อย่างมีนัยสำคัญ การพิจารณาตัวเลือกการปรับใช้อื่นๆ อาจเป็นการดีกว่า
ที่มา: will.com