มีหลายวิธีในการกำหนดค่าพื้นที่จัดเก็บข้อมูลสำหรับแอปพลิเคชันที่ทำงานบนคลัสเตอร์ Kubernetes บางส่วนล้าสมัยแล้วส่วนบางส่วนก็ปรากฏขึ้นเมื่อไม่นานมานี้ ในบทความนี้เราจะดูแนวคิดของสามตัวเลือกในการเชื่อมต่อระบบจัดเก็บข้อมูลรวมถึงตัวเลือกล่าสุด - การเชื่อมต่อผ่าน Container Storage Interface
วิธีที่ 1: ระบุ PV ในรายการพ็อด
รายการทั่วไปที่อธิบายพ็อดในคลัสเตอร์ Kubernetes:
ส่วนของไฟล์ Manifest ที่อธิบายว่าวอลุ่มใดเชื่อมต่ออยู่และตำแหน่งที่ไฮไลต์ด้วยสี
ในส่วน ปริมาณเมานต์ ระบุจุดเมานต์ (mountPath) - ไดเร็กทอรีใดภายในคอนเทนเนอร์ที่จะเมานต์วอลุ่มถาวรตลอดจนชื่อของโวลุ่ม
ในส่วน x แสดงรายการวอลุ่มทั้งหมดที่ใช้ในพ็อด ระบุชื่อของแต่ละวอลุ่ม รวมถึงประเภท (ในกรณีของเรา: awsElasticBlockStore) และพารามิเตอร์การเชื่อมต่อ พารามิเตอร์ใดที่แสดงอยู่ในรายการจะขึ้นอยู่กับประเภทวอลุ่ม
ปริมาตรเดียวกันสามารถติดตั้งพร้อมกันในคอนเทนเนอร์พ็อดหลายอันได้ ด้วยวิธีนี้ กระบวนการแอปพลิเคชันที่แตกต่างกันสามารถเข้าถึงข้อมูลเดียวกันได้
วิธีการเชื่อมต่อนี้ถูกประดิษฐ์ขึ้นตั้งแต่แรกเริ่ม เมื่อ Kubernetes ยังอยู่ในช่วงเริ่มต้น และปัจจุบันวิธีดังกล่าวล้าสมัย
มีปัญหาหลายประการเมื่อใช้งาน:
- ต้องสร้างโวลุ่มทั้งหมดด้วยตนเอง Kubernetes ไม่สามารถสร้างอะไรให้เราได้
- พารามิเตอร์การเข้าถึงสำหรับแต่ละวอลุ่มนั้นไม่ซ้ำกัน และจะต้องระบุไว้ในรายการของพ็อดทั้งหมดที่ใช้โวลุ่มนั้น
- หากต้องการเปลี่ยนระบบจัดเก็บข้อมูล (เช่น ย้ายจาก AWS ไปยัง Google Cloud) คุณต้องเปลี่ยนการตั้งค่าและประเภทของไดรฟ์ข้อมูลที่ติดตั้งในไฟล์ Manifest ทั้งหมด
ทั้งหมดนี้ไม่สะดวกมาก ดังนั้นในความเป็นจริงวิธีนี้ใช้เพื่อเชื่อมต่อวอลุ่มพิเศษบางประเภทเท่านั้น: configMap, Secret, EmptyDir, HostPath:
-
configMap และ Secret คือวอลลุมบริการที่ช่วยให้คุณสามารถสร้างวอลลุมที่มีไฟล์จาก Manifest ของ Kubernetes ในคอนเทนเนอร์ได้
-
EmptyDir เป็นวอลุ่มชั่วคราวที่สร้างขึ้นตลอดอายุการใช้งานของพ็อดเท่านั้น สะดวกในการใช้งานสำหรับการทดสอบหรือจัดเก็บข้อมูลชั่วคราว เมื่อพ็อดถูกลบ วอลุ่ม EmptyDir ก็จะถูกลบไปด้วย และข้อมูลทั้งหมดจะสูญหาย
-
hostPath - อนุญาตให้คุณเมานต์ไดเร็กทอรีใด ๆ บนดิสก์ในเครื่องของเซิร์ฟเวอร์ที่แอปพลิเคชันทำงานอยู่ภายในคอนเทนเนอร์ด้วยแอปพลิเคชัน รวมถึง /etc/kubernetes นี่เป็นคุณลักษณะที่ไม่ปลอดภัย ดังนั้น นโยบายความปลอดภัยจึงมักห้ามไม่ให้ใช้วอลุ่มประเภทนี้ มิฉะนั้น แอปพลิเคชันของผู้โจมตีจะสามารถติดตั้งไดเร็กทอรี HTC Kubernetes ภายในคอนเทนเนอร์และขโมยใบรับรองคลัสเตอร์ทั้งหมดได้ โดยทั่วไปแล้ว วอลุ่ม HostPath จะได้รับอนุญาตให้ใช้โดยแอปพลิเคชันระบบที่ทำงานในเนมสเปซของระบบ kube เท่านั้น
วิธีที่ 2. การเชื่อมต่อกับเตา SC/PVC/PV
วิธีการเชื่อมต่อทางเลือกอื่นคือแนวคิดของคลาส Storage, PersistentVolumeClaim, PersistentVolume
ชั้นเก็บของ เก็บพารามิเตอร์การเชื่อมต่อไปยังระบบจัดเก็บข้อมูล
การอ้างสิทธิ์ปริมาณต่อเนื่อง อธิบายข้อกำหนดสำหรับสิ่งที่แอปพลิเคชันต้องการ
ปริมาณคงที่ เก็บพารามิเตอร์การเข้าถึงและสถานะปริมาณ
สาระสำคัญของแนวคิด: ในไฟล์ Manifest จะระบุปริมาณประเภท PersistentVolumeClaim และระบุชื่อของเอนทิตีนี้ในพารามิเตอร์ ClaimName
รายการ 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 จะมีตัวเลือกในการทำงานกับระบบจัดเก็บข้อมูลมากกว่าไดรเวอร์ในตัว
- การสร้างดิสก์แบบไดนามิก โดยทั่วไปแล้ว ดิสก์ RBD จะใช้ในโหมด RWO เท่านั้น แต่ CSI สำหรับ Ceph อนุญาตให้ใช้ในโหมด RWX ได้ พ็อดหลายตัวบนโหนดที่แตกต่างกันสามารถติดตั้งดิสก์ RDB เดียวกันบนโหนดของตนและทำงานร่วมกับพ็อดเหล่านั้นแบบขนานได้ พูดตามตรงไม่ใช่ทุกอย่างจะสว่างนัก - ดิสก์นี้สามารถเชื่อมต่อเป็นอุปกรณ์บล็อกเท่านั้นซึ่งหมายความว่าคุณจะต้องปรับแอปพลิเคชันให้ทำงานกับมันในโหมดการเข้าถึงหลายรายการ
- การสร้างภาพรวม ในคลัสเตอร์ Kubernetes คุณสามารถสร้างรายการที่มีข้อกำหนดในการสร้างสแนปชอตได้ ปลั๊กอิน CSI จะมองเห็นและถ่ายภาพสแนปชอตจากดิสก์ จากนั้นคุณสามารถสำรองข้อมูลหรือคัดลอก PersistentVolume ได้
- การเพิ่มขนาดดิสก์ บนพื้นที่จัดเก็บข้อมูลและ PersistentVolume ในคลัสเตอร์ Kubernetes
- โควต้า ไดรเวอร์ CephFS ที่สร้างใน Kubernetes ไม่รองรับโควต้า แต่ปลั๊กอิน CSI ใหม่ที่มี Ceph Nautilus ล่าสุดสามารถเปิดใช้งานโควต้าบนพาร์ติชัน CephFS ได้
- เมทริคิ. ปลั๊กอิน CSI สามารถให้ข้อมูลการวัดต่างๆ แก่ Prometheus เกี่ยวกับปริมาณที่เชื่อมต่อ การสื่อสารที่กำลังเกิดขึ้น ฯลฯ
- โทโพโลยีตระหนักถึง ช่วยให้คุณระบุใน Manifest ว่าคลัสเตอร์มีการกระจายทางภูมิศาสตร์อย่างไร และหลีกเลี่ยงการเชื่อมต่อระบบจัดเก็บข้อมูลในอัมสเตอร์ดัมกับพ็อดที่ทำงานในลอนดอน
วิธีเชื่อมต่อ Ceph กับคลัสเตอร์ Kubernetes ผ่าน CSI โปรดดู
ผู้เขียนบทความ: Sergey Bondarev สถาปนิกฝึกหัดที่ Southbridge ผู้ดูแลระบบ Kubernetes ที่ผ่านการรับรอง หนึ่งในผู้พัฒนา kubespray
Post Scriptum เล็กๆ น้อยๆ ไม่ได้เพื่อการโฆษณา แต่เพื่อผลประโยชน์...
PS Sergey Bondarev เป็นผู้นำหลักสูตรเร่งรัดสองหลักสูตร: อัปเดต
ที่มา: will.com