প্রকল্প সম্পর্কে

pillar-csi হলো সেলফ-হোস্টেড বেয়ার-মেটাল ক্লাস্টারের জন্য একটি Kubernetes CSI ড্রাইভার। এটি একটি ডেডিকেটেড স্টোরেজ নোডে থাকা লোকাল ZFS zvol বা LVM লজিক্যাল ভলিউম নিয়ে NVMe-oF/TCP-এর মাধ্যমে ক্লাস্টারের বাকি অংশে এক্সপোর্ট করে, এবং SSH, Python ডেমন বা এক্সটার্নাল টার্গেট CLI-এর উপর নির্ভর না করে সরাসরি configfs-এর মাধ্যমে কার্নেলে লেখে। এটি স্পষ্টভাবে কোনো ডিস্ট্রিবিউটেড ফাইলসিস্টেম নয়: এটি নোডগুলোর মধ্যে স্টোরেজ রেপ্লিকেট, স্ট্রাইপ বা পুল করে না। আর্কিটেকচার তিনটি ওয়ার্কলোড নিয়ে গঠিত। pillar-controller একটি Deployment হিসেবে চলে এবং ক্লাস্টার-স্কোপড Pillar* CRD reconcile করে। pillar-agent শুধুমাত্র স্টোরেজ নোডে একটি DaemonSet হিসেবে চলে এবং হোস্টে সমস্ত configfs লেখার দায়িত্বে থাকে। pillar-node প্রতিটি ওয়ার্কারে চলে এবং CSI Node সার্ভিস (initiator connect, mkfs, bind-mount) পরিচালনা করে। উভয় DaemonSet hostNetwork ব্যবহার করে যাতে NVMe-oF/TCP ডেটা প্লেন হোস্ট নেটওয়ার্ক নেমস্পেসে বাইন্ড করতে পারে। কনফিগারেশন CRD-এর মাধ্যমে ডিক্লারেটিভ: PillarAgent একটি স্টোরেজ এজেন্ট খুঁজে বের করে, PillarStore একটি স্টোরেজ পুল বর্ণনা করে (ZFS পুল নাম, LVM VG, ব্যাকএন্ড কনফিগ), PillarProtocol নেটওয়ার্ক প্রোটোকল কনফিগারেশন বর্ণনা করে, এবং PillarStorageClass পুল ও প্রোটোকলকে একটি স্বয়ংক্রিয়ভাবে জেনারেট করা StorageClass-এ একত্রিত করে। একটি অভ্যন্তরীণ PillarVolumeState CRD আংশিক প্রভিশনিং ব্যর্থতা থেকে পুনরুদ্ধার এবং পাবলিকেশন ট্র্যাকিংয়ের জন্য টেকসই অবস্থা রেকর্ড করে; কন্ট্রোলার সেই রেকর্ড থেকে CSI অ্যাক্সেস-মোড এক্সক্লুসিভিটি প্রয়োগ করে। একটি উল্লেখযোগ্য ডিজাইন উপাদান হলো স্টেল-অপারেশন ফেন্সিং। প্রতিটি এজেন্ট কল যা একটি ভলিউমের রিসোর্স পরিবর্তন করে, সেটি একটি ফেন্সিং টোকেন বহন করে যা ভলিউম স্টেট UID (লাইফসাইকেল আইডেন্টিটি) এবং compare-and-swap-এর মাধ্যমে বাড়ানো একটি publicationGeneration কাউন্টার দিয়ে গঠিত। এজেন্ট স্টোরেজ নোডের লোকাল ডিস্কে /var/lib/pillar-csi/agent/generations/ এর অধীনে প্রতি ভলিউমের জন্য টেকসই মার্ক রাখে, যা hostPath হিসেবে মাউন্ট করা হয় যাতে মার্কগুলো রিস্টার্ট ও রিবুটে টিকে থাকে। মার্কের চেয়ে পুরোনো, সমাপ্ত বা প্রতিস্থাপিত লাইফসাইকেল থেকে আসা, বা কোনো টোকেন না থাকা রিকোয়েস্ট FAILED_PRECONDITION দিয়ে প্রত্যাখ্যাত হয়। README একটি আপগ্রেড সতর্কতা উল্লেখ করে: আপগ্রেডের আগে সমস্ত ভলিউম ডিটাচ করুন, কারণ আগের ভার্সনগুলো কোনো পাবলিকেশন, লাইফসাইকেল বা জেনারেশন রেকর্ড করত না, এবং কোনো মাইগ্রেশন শিম প্রদান করা হয়নি। নোড স্টেজ অবস্থা ওয়ার্কারে /var/lib/pillar-csi/node/ এর অধীনে রেকর্ড করা হয়, temp-file, sync এবং rename-এর মাধ্যমে পারমাণবিকভাবে লেখা হয়। NodeUnstageVolume রেকর্ডটি আবার পড়ে কারণ CO আনস্টেজে কোনো ভলিউম ক্যাপাবিলিটি বা ভলিউম কনটেক্সট পাঠায় না। আনমাউন্ট সিদ্ধান্ত মাউন্টারের idempotent Unmount-এর উপর ছেড়ে দেওয়া হয়, এবং corrupted-mount প্রোব ত্রুটি (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-এর জন্য স্পষ্ট অপারেটর সিদ্ধান্তের উপর জোর দেওয়া হয়েছে।