Đừng đơn giản hóa đoạn mã này

Bộ điều khiển Persistent Volume của Kubernetes

Tổng quan

• Bộ điều khiển đồng bộ hóa PersistentVolume (PV) và PersistentVolumeClaim (PVC) của Kubernetes
• Quản lý các “con trỏ” hai chiều giữa PVC và PV để ngăn mất dữ liệu
• Hoạt động ở chế độ khả dụng cao, đồng thời hỗ trợ trường hợp PVC yêu cầu một PV cụ thể hoặc PV được dành trước cho một PVC cụ thể

Chức năng chính

• Đồng bộ định kỳ trạng thái của PVC và PV
• Nếu PVC không yêu cầu một PV cụ thể, tìm PV phù hợp nhất và thực hiện bind
• Nếu PVC yêu cầu một PV cụ thể, kiểm tra PV đó có tồn tại và có đáp ứng các điều kiện hay không rồi mới bind
• Nếu PVC đã được bind, kiểm tra trạng thái và chỉnh sửa khi cần

Cách hoạt động

• Khi PVC được tạo hoặc cập nhật, gọi phương thức syncClaim
• Nếu PVC chưa được bind, gọi phương thức syncUnboundClaim
• Nếu PVC đã được bind, gọi phương thức syncBoundClaim
• Khi PV được tạo hoặc cập nhật, gọi phương thức syncVolume

Các phương thức chính

syncClaim

• Gọi syncUnboundClaim hoặc syncBoundClaim tùy theo trạng thái của PVC

syncUnboundClaim

• Nếu PVC không yêu cầu một PV cụ thể, tìm PV phù hợp nhất và thử bind
• Nếu PVC yêu cầu một PV cụ thể, kiểm tra PV đó có tồn tại và có đáp ứng các điều kiện hay không rồi mới bind

syncBoundClaim

• Nếu PVC đã được bind, kiểm tra trạng thái và chỉnh sửa khi cần

syncVolume

• Thực hiện hành động phù hợp tùy theo trạng thái của PV
• Nếu PV chưa được sử dụng, cập nhật trạng thái thành "Available"
• Nếu PV được bind với một PVC cụ thể, kiểm tra trạng thái của PVC đó và chỉnh sửa khi cần

Tóm tắt của GN⁺

• Tài liệu này cung cấp phần giải thích chi tiết về bộ điều khiển Persistent Volume của Kubernetes
• Giúp hiểu logic bind giữa Persistent Volume và Persistent Volume Claim
• Đề cập đến cách hoạt động trong chế độ khả dụng cao và cách xử lý nhiều tình huống ngoại lệ khác nhau
• Là tài liệu hữu ích cho các nhà phát triển quan tâm đến quản lý lưu trữ trong Kubernetes
• Một số dự án khác cung cấp chức năng tương tự gồm có OpenEBS, Rook

[GN⁺]

Ý kiến Hacker News

• Phần mềm của Space Shuttle rất ổn định và hầu như không có lỗi

  • Ba phiên bản gần đây nhất, mỗi phiên bản chỉ có đúng một lỗi trong tổng số 420.000 dòng mã
  • Số lỗi ít hơn rất nhiều so với các chương trình thương mại

• Mã khá thông thường và được viết bằng Go nên có phần dài dòng

  • Có thể là do quen với phần mềm doanh nghiệp nên cảm nhận được sự khác biệt với phần mềm hệ thống
  • Với những người đóng góp cho dự án k8s, có thể sẽ thấy có quá nhiều chú thích không cần thiết

• Codebase ở công ty mới được tổ chức rất tốt nên việc khám phá khá thú vị

  • Có nhiều chú thích và mã được cấu trúc tốt
  • Vì là một đội nhỏ nên chất lượng mã cao

• Thành tích an toàn của Space Shuttle không tốt nên hiện không còn được vận hành nữa

  • Không rõ sau 10 năm nữa mọi người có còn nhớ về Space Shuttle theo hướng tích cực hay không

• Nếu dùng structural pattern matching thì có thể đơn giản hóa các khối if/else

  • Có công cụ có thể kiểm tra tại thời điểm biên dịch xem việc matching đã đầy đủ hay chưa

• Mã không tệ và đang tuân theo một quy tắc duy nhất

  • Tốt hơn nhiều so với mã có đủ loại phong cách khác nhau

• Cung cấp liên kết đến cuộc thảo luận năm 2018

• Viết Kubernetes CSI driver là một trải nghiệm thú vị

  • EFS hoặc EBS CSI driver của Amazon là ví dụ tốt về một codebase nhỏ
  • Bản thân driver thì đơn giản nhưng có chứa logic phức tạp

• Việc mỗi câu lệnh if đều có else được xem là một thực hành an toàn

  • Module 2.000 dòng và method 200 dòng là có hại
  • Chú thích chỉ để giải thích mã đang làm gì thì không hữu ích

• Chia sẻ cách liên kết đến một phạm vi dòng cụ thể trong file GitHub