การจัดเก็บข้อมูลในคลัสเตอร์ Kubernetes

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

การจัดเก็บข้อมูลในคลัสเตอร์ Kubernetes

วิธีที่ 1: ระบุ PV ในรายการพ็อด

รายการทั่วไปที่อธิบายพ็อดในคลัสเตอร์ Kubernetes:

การจัดเก็บข้อมูลในคลัสเตอร์ Kubernetes

ส่วนของไฟล์ Manifest ที่อธิบายว่าวอลุ่มใดเชื่อมต่ออยู่และตำแหน่งที่ไฮไลต์ด้วยสี

ในส่วน ปริมาณเมานต์ ระบุจุดเมานต์ (mountPath) - ไดเร็กทอรีใดภายในคอนเทนเนอร์ที่จะเมานต์วอลุ่มถาวรตลอดจนชื่อของโวลุ่ม

ในส่วน x แสดงรายการวอลุ่มทั้งหมดที่ใช้ในพ็อด ระบุชื่อของแต่ละวอลุ่ม รวมถึงประเภท (ในกรณีของเรา: awsElasticBlockStore) และพารามิเตอร์การเชื่อมต่อ พารามิเตอร์ใดที่แสดงอยู่ในรายการจะขึ้นอยู่กับประเภทวอลุ่ม

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

วิธีการเชื่อมต่อนี้ถูกประดิษฐ์ขึ้นตั้งแต่แรกเริ่ม เมื่อ Kubernetes ยังอยู่ในช่วงเริ่มต้น และปัจจุบันวิธีดังกล่าวล้าสมัย

มีปัญหาหลายประการเมื่อใช้งาน:

  1. ต้องสร้างโวลุ่มทั้งหมดด้วยตนเอง Kubernetes ไม่สามารถสร้างอะไรให้เราได้
  2. พารามิเตอร์การเข้าถึงสำหรับแต่ละวอลุ่มนั้นไม่ซ้ำกัน และจะต้องระบุไว้ในรายการของพ็อดทั้งหมดที่ใช้โวลุ่มนั้น
  3. หากต้องการเปลี่ยนระบบจัดเก็บข้อมูล (เช่น ย้ายจาก AWS ไปยัง Google Cloud) คุณต้องเปลี่ยนการตั้งค่าและประเภทของไดรฟ์ข้อมูลที่ติดตั้งในไฟล์ Manifest ทั้งหมด

ทั้งหมดนี้ไม่สะดวกมาก ดังนั้นในความเป็นจริงวิธีนี้ใช้เพื่อเชื่อมต่อวอลุ่มพิเศษบางประเภทเท่านั้น: configMap, Secret, EmptyDir, HostPath:

  • configMap และ Secret คือวอลลุมบริการที่ช่วยให้คุณสามารถสร้างวอลลุมที่มีไฟล์จาก Manifest ของ Kubernetes ในคอนเทนเนอร์ได้

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

  • hostPath - อนุญาตให้คุณเมานต์ไดเร็กทอรีใด ๆ บนดิสก์ในเครื่องของเซิร์ฟเวอร์ที่แอปพลิเคชันทำงานอยู่ภายในคอนเทนเนอร์ด้วยแอปพลิเคชัน รวมถึง /etc/kubernetes นี่เป็นคุณลักษณะที่ไม่ปลอดภัย ดังนั้น นโยบายความปลอดภัยจึงมักห้ามไม่ให้ใช้วอลุ่มประเภทนี้ มิฉะนั้น แอปพลิเคชันของผู้โจมตีจะสามารถติดตั้งไดเร็กทอรี HTC Kubernetes ภายในคอนเทนเนอร์และขโมยใบรับรองคลัสเตอร์ทั้งหมดได้ โดยทั่วไปแล้ว วอลุ่ม HostPath จะได้รับอนุญาตให้ใช้โดยแอปพลิเคชันระบบที่ทำงานในเนมสเปซของระบบ kube เท่านั้น

ระบบจัดเก็บข้อมูลที่ Kubernetes ใช้งานได้ทันทีเมื่อแกะกล่อง ระบุไว้ในเอกสารประกอบ

วิธีที่ 2. การเชื่อมต่อกับเตา SC/PVC/PV

วิธีการเชื่อมต่อทางเลือกอื่นคือแนวคิดของคลาส Storage, PersistentVolumeClaim, PersistentVolume

ชั้นเก็บของ เก็บพารามิเตอร์การเชื่อมต่อไปยังระบบจัดเก็บข้อมูล

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

สาระสำคัญของแนวคิด: ในไฟล์ Manifest จะระบุปริมาณประเภท PersistentVolumeClaim และระบุชื่อของเอนทิตีนี้ในพารามิเตอร์ ClaimName

การจัดเก็บข้อมูลในคลัสเตอร์ Kubernetes

รายการ PersistentVolumeClaim อธิบายข้อกำหนดสำหรับปริมาณข้อมูลที่แอปพลิเคชันต้องการ รวมทั้ง:

  • ขนาดดิสก์
  • วิธีการเข้าถึง: ReadWriteOnce หรือ ReadWriteMany;
  • ลิงก์ไปยังคลาส Storage - ในระบบจัดเก็บข้อมูลที่เราต้องการสร้างโวลุ่ม

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

รายการ PersistentVolume ระบุคลาส Storage และพารามิเตอร์การเข้าถึงสำหรับไดรฟ์ข้อมูลที่ระบุ (ID ไดรฟ์ข้อมูล เส้นทาง ฯลฯ)

เมื่อสร้าง PVC Kubernetes จะพิจารณาขนาดปริมาตรและคลาส Storage ที่ต้องการ และเลือก PersistentVolume ฟรี

หากไม่มี PV ดังกล่าว Kubernetes สามารถเปิดโปรแกรมพิเศษ - Provisioner (ชื่อจะระบุไว้ในคลาส Storage) โปรแกรมนี้เชื่อมต่อกับระบบจัดเก็บข้อมูล สร้างวอลุ่มตามขนาดที่ต้องการ รับตัวระบุ และสร้างรายการ PersistentVolume ในคลัสเตอร์ Kubernetes ซึ่งเชื่อมโยงกับ PersistentVolumeClaim

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

พารามิเตอร์ทั้งหมดสำหรับการเชื่อมต่อกับระบบจัดเก็บข้อมูลจะอยู่ในคลาส Storage ซึ่งผู้ดูแลระบบคลัสเตอร์รับผิดชอบ สิ่งที่คุณต้องทำเมื่อย้ายจาก AWS ไปยัง Google Cloud คือการเปลี่ยนชื่อคลาส Storage เป็น PVC ในรายการแอปพลิเคชัน Persistance Volume สำหรับการจัดเก็บข้อมูลจะถูกสร้างขึ้นในคลัสเตอร์โดยอัตโนมัติโดยใช้โปรแกรม Provisioner

วิธีที่ 3: อินเทอร์เฟซการจัดเก็บคอนเทนเนอร์

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

เพื่อแก้ปัญหานี้ นักพัฒนาจาก Cloud Foundry, Kubernetes, Mesos และ Docker ได้สร้าง Container Storage Interface (CSI) ซึ่งเป็นอินเทอร์เฟซแบบรวมที่เรียบง่ายที่อธิบายการทำงานร่วมกันของระบบการจัดการคอนเทนเนอร์และไดรเวอร์พิเศษ (ไดรเวอร์ CSI) ที่ทำงานร่วมกับเฉพาะ ระบบจัดเก็บข้อมูล โค้ดทั้งหมดสำหรับการโต้ตอบกับระบบจัดเก็บข้อมูลถูกย้ายจากแกน Kubernetes ไปยังระบบที่แยกจากกัน

เอกสารประกอบอินเทอร์เฟซการจัดเก็บข้อมูลคอนเทนเนอร์.

โดยทั่วไปแล้ว CSI Driver ประกอบด้วยสององค์ประกอบ: ปลั๊กอินโหนดและปลั๊กอินตัวควบคุม

ปลั๊กอินโหนดทำงานบนแต่ละโหนดและรับผิดชอบในการติดตั้งวอลุ่มและดำเนินการกับโหนดเหล่านั้น ปลั๊กอินคอนโทรลเลอร์โต้ตอบกับระบบจัดเก็บข้อมูล: สร้างหรือลบโวลุ่ม กำหนดสิทธิ์การเข้าถึง ฯลฯ

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

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

มาดูตัวอย่างเพื่อดูประโยชน์ที่คุณจะได้รับจากการเปลี่ยนไปใช้การเชื่อมต่อระบบจัดเก็บข้อมูล Ceph โดยใช้ไดรเวอร์ CSI

เมื่อทำงานกับ Ceph ปลั๊กอิน CSI จะมีตัวเลือกในการทำงานกับระบบจัดเก็บข้อมูลมากกว่าไดรเวอร์ในตัว

  1. การสร้างดิสก์แบบไดนามิก โดยทั่วไปแล้ว ดิสก์ RBD จะใช้ในโหมด RWO เท่านั้น แต่ CSI สำหรับ Ceph อนุญาตให้ใช้ในโหมด RWX ได้ พ็อดหลายตัวบนโหนดที่แตกต่างกันสามารถติดตั้งดิสก์ RDB เดียวกันบนโหนดของตนและทำงานร่วมกับพ็อดเหล่านั้นแบบขนานได้ พูดตามตรงไม่ใช่ทุกอย่างจะสว่างนัก - ดิสก์นี้สามารถเชื่อมต่อเป็นอุปกรณ์บล็อกเท่านั้นซึ่งหมายความว่าคุณจะต้องปรับแอปพลิเคชันให้ทำงานกับมันในโหมดการเข้าถึงหลายรายการ
  2. การสร้างภาพรวม ในคลัสเตอร์ Kubernetes คุณสามารถสร้างรายการที่มีข้อกำหนดในการสร้างสแนปชอตได้ ปลั๊กอิน CSI จะมองเห็นและถ่ายภาพสแนปชอตจากดิสก์ จากนั้นคุณสามารถสำรองข้อมูลหรือคัดลอก PersistentVolume ได้
  3. การเพิ่มขนาดดิสก์ บนพื้นที่จัดเก็บข้อมูลและ PersistentVolume ในคลัสเตอร์ Kubernetes
  4. โควต้า ไดรเวอร์ CephFS ที่สร้างใน Kubernetes ไม่รองรับโควต้า แต่ปลั๊กอิน CSI ใหม่ที่มี Ceph Nautilus ล่าสุดสามารถเปิดใช้งานโควต้าบนพาร์ติชัน CephFS ได้
  5. เมทริคิ. ปลั๊กอิน CSI สามารถให้ข้อมูลการวัดต่างๆ แก่ Prometheus เกี่ยวกับปริมาณที่เชื่อมต่อ การสื่อสารที่กำลังเกิดขึ้น ฯลฯ
  6. โทโพโลยีตระหนักถึง ช่วยให้คุณระบุใน Manifest ว่าคลัสเตอร์มีการกระจายทางภูมิศาสตร์อย่างไร และหลีกเลี่ยงการเชื่อมต่อระบบจัดเก็บข้อมูลในอัมสเตอร์ดัมกับพ็อดที่ทำงานในลอนดอน

วิธีเชื่อมต่อ Ceph กับคลัสเตอร์ Kubernetes ผ่าน CSI โปรดดู ในภาคปฏิบัติของการบรรยายภาคค่ำของ Slurm. คุณยังสามารถสมัครสมาชิกได้ หลักสูตรวิดีโอของ Cephซึ่งจะเปิดตัวในวันที่ 15 ตุลาคม

ผู้เขียนบทความ: Sergey Bondarev สถาปนิกฝึกหัดที่ Southbridge ผู้ดูแลระบบ Kubernetes ที่ผ่านการรับรอง หนึ่งในผู้พัฒนา kubespray

Post Scriptum เล็กๆ น้อยๆ ไม่ได้เพื่อการโฆษณา แต่เพื่อผลประโยชน์...

PS Sergey Bondarev เป็นผู้นำหลักสูตรเร่งรัดสองหลักสูตร: อัปเดต ฐาน Kubernetes 28-30 กันยายน และขั้นสูง Kubernetes เมกะ 14–16 ตุลาคม

การจัดเก็บข้อมูลในคลัสเตอร์ Kubernetes

ที่มา: will.com

เพิ่มความคิดเห็น