การปรับใช้ Kubernetes เทียบกับ StatefulSets


112

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

ใคร ๆ ก็แชร์ประสบการณ์ได้จะเจ๋ง !!

คำตอบ:


116

Deployments and ReplicationControllers มีไว้สำหรับการใช้งานแบบไม่ระบุสถานะและค่อนข้างเบา StatefulSetsถูกใช้เมื่อสถานะต้องคงอยู่ ดังนั้นการใช้volumeClaimTemplates/ การอ้างสิทธิ์ในไดรฟ์ข้อมูลต่อเนื่องเพื่อให้แน่ใจว่าสามารถรักษาสถานะในการรีสตาร์ทส่วนประกอบได้

ดังนั้นหากแอปพลิเคชันของคุณเป็นสถานะหรือหากคุณต้องการปรับใช้ที่เก็บข้อมูลแบบ stateful บน Kubernetes ให้ใช้ StatefulSet

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

รายละเอียดเพิ่มเติมเกี่ยวกับการเรียกใช้แอปพลิเคชัน stateful สามารถพบได้ในรายการบล็อกของ kubernetes ปี 2016 เกี่ยวกับแอปพลิเคชันที่มีสถานะ


16
ฉันยังสามารถเชื่อมต่อพ็อดของการปรับใช้กับการอ้างสิทธิ์ปริมาณอย่างต่อเนื่องและปลอดภัย
Torsten Bronger

9
@TorstenBronger ฉันเห็นด้วย - ณ จุดใดที่เรากลับไปที่คำถามเดิมว่าประเด็นของ StatefulSets คืออะไร?
HDave

6
@HDave ด้วยไดรฟ์ข้อมูลต่อเนื่องแบบไดนามิกและผู้ให้บริการจัดเก็บข้อมูลที่พัฒนาอย่างรวดเร็ว (เช่น Portworx, OpenEBS) ปัญหาการคงอยู่ของข้อมูลสามารถแก้ไขได้ แต่การตั้งชื่อและลำดับการเริ่มต้น / อัปเกรดยังคงแตกต่างกันกับ StatefulSets ทำให้แอปที่ต้องใช้ Master / Slave หรือการตั้งค่าอื่น ๆ สร้างคลัสเตอร์อย่างถูกต้อง แม้ว่าฉันจะยอมรับว่าบางทีทั้งหมดนี้สามารถพับลงในdeploymentconfig เดียวด้วยข้อมูลจำเพาะง่ายๆในการตั้งค่า 1-per-node (daemonset) การจำลองหรือการสั่งซื้อแบบ stateful
Mani Gandham

4
สิ่งสำคัญคือต้องตระหนักว่า "ลำดับการเริ่มต้น / อัปเกรด" เป็นเรื่องเกี่ยวกับการจำลอง Pod (เช่น 1, 2, 3 ... ) ไม่ใช่พ็อดที่แตกต่างกัน (เช่นเว็บ srv db ฯลฯ ) กล่าวอีกนัยหนึ่งไม่ใช่การทดแทนการอ้างอิงสำหรับนักเทียบท่าเขียน
HDave

73
  • การปรับใช้ - คุณระบุPersistentVolumeClaimที่แชร์โดยแบบจำลองพ็อดทั้งหมด กล่าวอีกนัยหนึ่งคือปริมาณที่ใช้ร่วมกัน

    เห็นได้ชัดว่าที่เก็บข้อมูลสำรองต้องมีReadWriteManyหรือ ReadOnlyMany accessMode หากคุณมีพ็อดจำลองมากกว่าหนึ่งรายการ

  • StatefulSet - คุณระบุvolumeClaimTemplatesเพื่อให้แต่ละพ็อดจำลองได้รับPersistentVolumeClaimเฉพาะที่ เชื่อมโยงกับมัน กล่าวอีกนัยหนึ่งคือไม่มีไดรฟ์ข้อมูลที่ใช้ร่วมกัน

    ที่นี่พื้นที่จัดเก็บข้อมูลสำรองสามารถมีReadWriteOnce accessMode

    StatefulSet มีประโยชน์สำหรับการรันสิ่งต่างๆในคลัสเตอร์เช่นคลัสเตอร์ Hadoop คลัสเตอร์ MySQL โดยที่แต่ละโหนดมีที่เก็บข้อมูลของตัวเอง


23

TL; ดร

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

Statefulsets ใช้สำหรับแอปพลิเคชัน Stateful แต่ละแบบจำลองของพ็อดจะมีสถานะของตัวเองและจะใช้ Volume ของตัวเอง

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

ผมได้เขียนเกี่ยวกับความแตกต่างระหว่างการปรับใช้รายละเอียด, StatefulSets & Daemonsets และวิธีการปรับใช้โปรแกรมตัวอย่างโดยใช้ทรัพยากรเหล่านี้K8s: ปรับเทียบ StatefulSets VS DaemonSets


5
เพื่อติดตามความคิดเห็นของคุณสำหรับฉันแล้วความแตกต่างระหว่างทั้งสองคือหนึ่งมีความสามารถในการระบุที่เก็บข้อมูลเฉพาะของพ็อด (และยังคงอยู่ในสถานะเฉพาะของพ็อด) ในขณะที่อีกรายการไม่ทำ (และสามารถคงอยู่ได้เฉพาะบริการเท่านั้น - ทั่วรัฐ) ในแง่นั้นในระดับบริการทั้งสองสามารถถูกมองว่าเป็นสถานะ แต่ในระดับพ็อดจะมีเพียง Statefulsets เท่านั้นที่เป็นสถานะ
scabbage

14

StatefulSet

ใช้ 'StatefulSet ด้วย Stateful การประยุกต์ใช้งานแบบกระจายที่ต้องใช้แต่ละโหนดจะมีรัฐถาวร StatefulSet ให้ความสามารถในการกำหนดค่าจำนวนโหนดโดยพลการสำหรับแอ็พพลิเคชัน / คอมโพเนนต์ stateful ผ่านการกำหนดค่า (แบบจำลอง = N)

แอปพลิเคชันแบบกระจายสถานะมีสองประเภท ได้แก่ Master-Master และ Master-Slave โหนดทั้งหมดในการกำหนดค่า Master-Master และโหนด Slave ในการกำหนดค่า Master-Slave สามารถใช้ StatefulSet ได้
ตัวอย่าง:
Master-Slave -> Datanodes (ทาส) ในคลัสเตอร์ Hadoop
Master-Master -> โหนดฐานข้อมูล (master-master) ในคลัสเตอร์ Cassandra

แต่ละ Pod (แบบจำลอง / โหนด) ใน StatefulSet มีเอกลักษณ์เครือข่ายที่ไม่ซ้ำใครและเสถียร ตัวอย่างเช่นใน Cassandra StatefulSet ที่มีชื่อเป็น 'Cassandra' และจำนวนโหนดจำลองเป็น N แต่ละ Cassandra pod (โหนด) มี:

  • ดัชนีลำดับสำหรับแต่ละพ็อด: 0,1, .. , N-1
  • รหัสเครือข่ายที่เสถียร: Cassandra-0, Cassandra-1, .. , Cassandra-N-1
  • ไดรฟ์ข้อมูลถาวรแยกต่างหากสำหรับแต่ละพ็อดเทียบกับเทมเพลตการอ้างสิทธิ์ไดรฟ์ข้อมูลเช่นที่เก็บข้อมูลแยกต่างหากสำหรับทุกพ็อด (โหนด)
  • พ็อดถูกสร้างขึ้นตามลำดับ 0 ถึง N-1 และสิ้นสุดในลำดับย้อนกลับ N-1 ถึง 0

อ้างอิง: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

การปรับใช้

'การปรับใช้' ในมืออื่น ๆ เหมาะสำหรับคนไร้รัฐ / งานบริการที่โหนดไม่จำเป็นต้องมีตัวตนใด ๆ เป็นพิเศษ ตัวจัดสรรภาระงานสามารถเข้าถึงโหนดใดก็ได้ที่เลือก โหนดทั้งหมดเท่ากัน การทำให้ใช้งานได้มีประโยชน์สำหรับการสร้างโหนดตามอำเภอใจจำนวนเท่าใดก็ได้ผ่านการกำหนดค่า (แบบจำลอง = N)


7

ความแตกต่างระหว่าง StatefulSet และการปรับใช้

StatefulSet เทียบเท่ากับการปรับใช้พิเศษ แต่ละพ็อดใน StatefulSet มีตัวระบุเครือข่ายที่ไม่ซ้ำกันที่เสถียรซึ่งสามารถใช้เพื่อค้นหาสมาชิกอื่น ๆ ในคลัสเตอร์ ถ้าชื่อ StatefulSet คือ Kafka พ็อดแรกจะเรียกว่า Kafka-0, Kafka-1 ที่สองและอื่น ๆ ลำดับเริ่มต้นและหยุดของสำเนาพ็อดที่ควบคุมโดย StatefulSet จะถูกควบคุม เมื่อใช้งานพ็อดที่ n พ็อด N-1 แรกกำลังทำงานอยู่แล้วและพร้อมใช้งาน Good state; พ็อดใน StatefulSet ใช้โวลุ่มจัดเก็บถาวรที่คงที่ซึ่งดำเนินการโดย PV หรือ PVC เมื่อลบพ็อดโวลุ่มหน่วยเก็บข้อมูลที่เชื่อมโยงกับ StatefulSet จะไม่ถูกลบโดยค่าเริ่มต้น (เพื่อความปลอดภัยของข้อมูล) StatefulSet ถูกผูกไว้กับโวลุ่ม PV ใช้เพื่อจัดเก็บข้อมูลสถานะพ็อดและยังใช้ร่วมกับบริการ headless โดยประกาศว่าเป็นของบริการ headless นั้น

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.