इस प्रोजेक्ट के बारे में

pillar-csi स्व-होस्टेड बेयर-मेटल क्लस्टर के लिए एक Kubernetes CSI ड्राइवर है। यह एक समर्पित स्टोरेज नोड पर स्थानीय ZFS zvols या LVM लॉजिकल वॉल्यूम लेता है और उन्हें NVMe-oF/TCP के माध्यम से बाकी क्लस्टर में एक्सपोर्ट करता है, SSH, Python डेमॉन, या बाहरी टारगेट CLI पर निर्भर रहने के बजाय सीधे configfs के माध्यम से कर्नेल में लिखता है। यह स्पष्ट रूप से एक वितरित फाइलसिस्टम नहीं है: यह नोड्स के बीच स्टोरेज को रेप्लिकेट, स्ट्राइप, या पूल नहीं करता है। आर्किटेक्चर में तीन वर्कलोड होते हैं। pillar-controller एक Deployment के रूप में चलता है और क्लस्टर-स्कोप्ड Pillar* CRDs को रिकंसाइल करता है। pillar-agent केवल स्टोरेज नोड्स पर एक DaemonSet के रूप में चलता है और होस्ट पर सभी configfs राइट्स का स्वामी है। pillar-node हर वर्कर पर चलता है और CSI Node सेवा (इनिशिएटर कनेक्ट, mkfs, बाइंड-माउंट) को संभालता है। दोनों DaemonSets hostNetwork का उपयोग करते हैं ताकि NVMe-oF/TCP डेटा प्लेन होस्ट नेटवर्क नेमस्पेस से बाइंड हो सके। कॉन्फ़िगरेशन CRDs के माध्यम से डिक्लेरेटिव है: PillarAgent एक स्टोरेज एजेंट का पता लगाता है, PillarStore एक स्टोरेज पूल (ZFS पूल नाम, LVM VG, बैकएंड कॉन्फ़िग) का वर्णन करता है, PillarProtocol नेटवर्क प्रोटोकॉल कॉन्फ़िगरेशन का वर्णन करता है, और PillarStorageClass पूल और प्रोटोकॉल को एक ऑटो-जनरेटेड StorageClass में संयोजित करता है। एक आंतरिक PillarVolumeState CRD आंशिक प्रोविजनिंग विफलताओं से रिकवरी और पब्लिकेशन ट्रैकिंग के लिए टिकाऊ स्थिति रिकॉर्ड करता है; कंट्रोलर उस रिकॉर्ड से CSI एक्सेस-मोड एक्सक्लूसिविटी लागू करता है। एक उल्लेखनीय डिज़ाइन तत्व स्टेल-ऑपरेशन फेंसिंग है। प्रत्येक एजेंट कॉल जो वॉल्यूम के संसाधनों को बदलती है, उसमें वॉल्यूम स्टेट UID (लाइफसाइकल आइडेंटिटी) और कंपेयर-एंड-स्वैप के माध्यम से बढ़ाए गए publicationGeneration काउंटर से बना एक फेंसिंग टोकन होता है। एजेंट स्टोरेज नोड की स्थानीय डिस्क पर /var/lib/pillar-csi/agent/generations/ के अंतर्गत प्रति वॉल्यूम टिकाऊ मार्क रखता है, जिसे hostPath के रूप में माउंट किया जाता है ताकि मार्क रीस्टार्ट और रीबूट के बाद भी बने रहें। मार्क से पुराने, समाप्त या प्रतिस्थापित लाइफसाइकल से आने वाले, या बिना टोकन वाले अनुरोध FAILED_PRECONDITION के साथ अस्वीकार कर दिए जाते हैं। README एक अपग्रेड चेतावनी नोट करता है: अपग्रेड से पहले सभी वॉल्यूम डिटैच करें, क्योंकि पुराने संस्करणों ने कोई पब्लिकेशन, लाइफसाइकल, या जेनरेशन रिकॉर्ड नहीं किया, और कोई माइग्रेशन शिम प्रदान नहीं किया गया है। नोड स्टेज स्टेट वर्कर पर /var/lib/pillar-csi/node/ के अंतर्गत रिकॉर्ड की जाती है, जिसे टेम्प-फाइल, सिंक, और रीनेम के माध्यम से एटॉमिकली लिखा जाता है। NodeUnstageVolume रिकॉर्ड को वापस पढ़ता है क्योंकि CO अनस्टेज पर न तो वॉल्यूम कैपेबिलिटी और न ही वॉल्यूम कॉन्टेक्स्ट भेजता है। अनमाउंट निर्णय माउंटर के आइडेम्पोटेंट Unmount को सौंपे जाते हैं, जो करप्टेड-माउंट प्रोब त्रुटियों (EIO, ENOTCONN, ESTALE, EACCES) को अभी भी-माउंटेड मानते हैं ताकि kubelet उन पॉड्स को रीप कर सके जिनका फाइलसिस्टम कर्नेल शटडाउन में चला गया है। समर्थित मैट्रिक्स: NVMe-oF/TCP पर ZFS zvol और LVM LV शिप किए गए हैं; iSCSI डिज़ाइन किया गया है लेकिन अभी तक शिप नहीं हुआ; ZFS डेटासेट के लिए NFS डिज़ाइन किया गया है लेकिन अभी तक शिप नहीं हुआ। CSI ऑपरेशन्स में CreateVolume, DeleteVolume, ControllerPublish/Unpublish, ControllerExpandVolume, NodeStage/Unstage, NodePublish/Unpublish, NodeExpandVolume, NodeGetVolumeStats, ValidateVolumeCapabilities, और GetCapacity शामिल हैं। एक्सेस मोड ReadWriteOnce, ReadWriteOncePod, और ReadOnlyMany हैं; वॉल्यूम मोड Filesystem (ext4/xfs) और Block हैं। इंस्टॉलेशन Helm के माध्यम से है। कंट्रोलर और एजेंट के बीच mTLS ऑप्ट-इन है (cert-manager मोड या सप्लाई किया गया Secret मोड); डिफ़ॉल्ट प्लेनटेक्स्ट gRPC है। Kubernetes 1.24 या नया आवश्यक है। स्टोरेज नोड्स को nvmet और nvmet_tcp कर्नेल मॉड्यूल चाहिए; वर्कर नोड्स को nvme_tcp और nvme_fabrics चाहिए; init-containers स्टार्टअप पर modprobe चलाते हैं। README में CRD YAML उदाहरणों के साथ एक क्विकस्टार्ट, मानक kubectl describe और लॉग्स के माध्यम से ट्रबलशूटिंग, और ExportSpecMissing पर अटके लीगेसी वॉल्यूम के लिए एक विस्तृत रिकवरी प्रक्रिया शामिल है, जो bindAddress, port, और aclEnabled के लिए रनटाइम अवलोकनों से अनुमान लगाने के बजाय स्पष्ट ऑपरेटर निर्णयों पर जोर देती है।