อย่าทำให้โค้ดนี้ง่ายเกินไป

 (github.com/kubernetes)
2 คะแนน โดย GN⁺ 2024-08-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

คอนโทรลเลอร์ Persistent Volume ของ Kubernetes

ภาพรวม

  • คอนโทรลเลอร์ที่ซิงก์ PersistentVolume (PV) และ PersistentVolumeClaim (PVC) ของ Kubernetes
  • จัดการ "พอยน์เตอร์" แบบสองทางระหว่าง PVC และ PV เพื่อป้องกันการสูญหายของข้อมูล
  • ทำงานในโหมด High Availability และรองรับกรณีที่ PVC ร้องขอ PV เฉพาะตัว หรือ PV ถูกจองไว้ให้ PVC เฉพาะตัว

ฟังก์ชันหลัก

  • ซิงก์สถานะของ PVC และ PV เป็นระยะ
  • หาก PVC ไม่ได้ร้องขอ PV เฉพาะตัว จะค้นหา PV ที่เหมาะสมที่สุดแล้วทำการ bind
  • หาก PVC ร้องขอ PV เฉพาะตัว จะตรวจสอบว่า PV นั้นมีอยู่และตรงตามเงื่อนไข ก่อนทำการ bind
  • หาก PVC ถูก bind อยู่แล้ว จะตรวจสอบสถานะและแก้ไขเมื่อจำเป็น

วิธีการทำงาน

  • เมื่อ PVC ถูกสร้างหรืออัปเดต จะเรียกเมธอด syncClaim
  • หาก PVC ยังไม่ได้ bind จะเรียกเมธอด syncUnboundClaim
  • หาก PVC ถูก bind แล้ว จะเรียกเมธอด syncBoundClaim
  • เมื่อ PV ถูกสร้างหรืออัปเดต จะเรียกเมธอด syncVolume

เมธอดสำคัญ

syncClaim

  • เรียก syncUnboundClaim หรือ syncBoundClaim ตามสถานะของ PVC

syncUnboundClaim

  • หาก PVC ไม่ได้ร้องขอ PV เฉพาะตัว จะค้นหา PV ที่เหมาะสมที่สุดและพยายาม bind
  • หาก PVC ร้องขอ PV เฉพาะตัว จะตรวจสอบว่า PV นั้นมีอยู่และตรงตามเงื่อนไข ก่อนทำการ bind

syncBoundClaim

  • หาก PVC ถูก bind อยู่แล้ว จะตรวจสอบสถานะและแก้ไขเมื่อจำเป็น

syncVolume

  • ดำเนินการที่เหมาะสมตามสถานะของ PV
  • หาก PV ยังไม่ถูกใช้งาน จะอัปเดตสถานะเป็น "Available"
  • หาก PV ถูก bind กับ PVC เฉพาะตัว จะตรวจสอบสถานะของ PVC นั้นและแก้ไขเมื่อจำเป็น

สรุปโดย GN⁺

  • เอกสารนี้อธิบายคอนโทรลเลอร์ Persistent Volume ของ Kubernetes อย่างละเอียด
  • ช่วยให้เข้าใจตรรกะการ bind ระหว่าง Persistent Volume และ Persistent VolumeClaim ได้ดีขึ้น
  • ครอบคลุมวิธีการทำงานในโหมด High Availability และการจัดการสถานการณ์ยกเว้นหลากหลายรูปแบบ
  • เป็นเอกสารที่มีประโยชน์สำหรับนักพัฒนาที่สนใจการจัดการสตอเรจของ Kubernetes
  • โปรเจ็กต์อื่นที่มีความสามารถคล้ายกัน ได้แก่ OpenEBS และ Rook

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-08-07
ความคิดเห็นจาก Hacker News

  • ซอฟต์แวร์ของ Space Shuttle มีความเสถียรมาก และแทบไม่มีบั๊ก

    • สามเวอร์ชันล่าสุดมีข้อผิดพลาดเพียงอย่างละหนึ่งจุดจากทั้งหมด 420,000 บรรทัด
    • เมื่อเทียบกับโปรแกรมเชิงพาณิชย์แล้ว จำนวนข้อผิดพลาดน้อยมาก

  • โค้ดมีลักษณะทั่วไป และเขียนด้วยภาษา Go จึงค่อนข้างยืดเยื้อ

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

  • codebase ของบริษัทใหม่เป็นระเบียบมาก ทำให้การสำรวจเป็นเรื่องน่าเพลิดเพลิน

    • มีคอมเมนต์จำนวนมาก และโค้ดมีโครงสร้างที่ดี
    • เป็นทีมขนาดเล็ก จึงทำให้คุณภาพโค้ดสูง

  • Space Shuttle มีประวัติด้านความปลอดภัยที่ไม่ดีนัก จึงไม่ได้ใช้งานอยู่ในปัจจุบัน

    • น่าสงสัยว่าอีก 10 ปีข้างหน้า ผู้คนจะยังจดจำ Space Shuttle ในแง่บวกหรือไม่

  • หากใช้ structural pattern matching ก็อาจทำให้บล็อก if/else เรียบง่ายขึ้นได้

    • มีเครื่องมือที่สามารถตรวจสอบได้ตอนคอมไพล์ว่าการจับคู่นั้นครอบคลุมครบถ้วนหรือไม่

  • โค้ดไม่ได้แย่ และยึดตามกฎเพียงข้อเดียว

    • ดีกว่าโค้ดที่มีหลายสไตล์ปะปนกันมาก

  • มีการให้ลิงก์ไปยังการอภิปรายในปี 2018

  • การเขียน Kubernetes CSI driver เป็นเรื่องสนุก

    • CSI driver ของ Amazon EFS หรือ EBS เป็นตัวอย่างที่ดีของ codebase ขนาดเล็ก
    • ตัว driver เองเรียบง่าย แต่มีตรรกะที่ซับซ้อนอยู่ภายใน

  • การมี else ในทุกประโยค if ถูกมองว่าเป็นแนวปฏิบัติเพื่อความปลอดภัย

    • โมดูล 2,000 บรรทัดและเมธอด 200 บรรทัดเป็นสิ่งที่ส่งผลเสีย
    • คอมเมนต์ที่อธิบายว่าโค้ดทำอะไรนั้นไม่มีประโยชน์

  • มีการอธิบายวิธีลิงก์ไฟล์บน GitHub ไปยังช่วงบรรทัดที่ต้องการ