پرو ہوسٹر > بلاگ > انتظامیہ > Kubernetes اسٹوریج کے لیے والیوم پلگ ان: Flexvolume سے CSI تک

Kubernetes اسٹوریج کے لیے والیوم پلگ ان: Flexvolume سے CSI تک

Kubernetes اسٹوریج کے لیے والیوم پلگ ان: Flexvolume سے CSI تک

واپس جب Kubernetes اب بھی v1.0.0 تھا، وہاں والیوم پلگ ان موجود تھے۔ مستقل (مستقل) کنٹینر ڈیٹا کو ذخیرہ کرنے کے لیے انہیں سسٹمز کوبرنیٹس سے مربوط کرنے کی ضرورت تھی۔ ان کی تعداد کم تھی، اور سب سے پہلے ایسے اسٹوریج فراہم کرنے والے تھے جیسے GCE PD، Ceph، AWS EBS اور دیگر۔

پلگ انز کوبرنیٹس کے ساتھ ڈیلیور کیا گیا تھا، اسی لیے انہیں ان کا نام - درخت میں ملا۔ تاہم، بہت سے لوگوں کے لیے، اس طرح کے پلگ ان کا موجودہ سیٹ ناکافی نکلا۔ کاریگروں نے پیچ کا استعمال کرتے ہوئے Kubernetes کور میں سادہ پلگ ان شامل کیے، جس کے بعد انہوں نے اپنے Kubernetes کو جمع کیا اور اسے اپنے سرورز پر انسٹال کیا۔ لیکن وقت گزرنے کے ساتھ، Kubernetes کے ڈویلپرز کو اس کا احساس ہوا۔ مچھلی مسئلہ حل نہیں ہو سکتا. لوگوں کی ضرورت ہے۔ مچھلی کی بنسی. اور Kubernetes v1.2.0 کی ریلیز میں یہ ظاہر ہوا...

Flexvolume پلگ ان: کم سے کم ماہی گیری کی چھڑی

Kubernetes ڈویلپرز نے FlexVolume پلگ ان بنایا، جو کہ تھرڈ پارٹی ڈویلپرز کے ذریعے نافذ کردہ Flexvolume ڈرائیورز کے ساتھ کام کرنے کے متغیرات اور طریقوں کا ایک منطقی فریم ورک تھا۔

آئیے رکیں اور قریب سے دیکھیں کہ FlexVolume ڈرائیور کیا ہے۔ یہ ایک یقینی ہے۔ قابل عمل فائل (بائنری فائل، پائتھون اسکرپٹ، باش اسکرپٹ، وغیرہ)، جو، جب عمل میں آتا ہے، کمانڈ لائن آرگیومینٹس کو بطور ان پٹ لیتا ہے اور JSON فارمیٹ میں پہلے سے معلوم فیلڈز کے ساتھ ایک پیغام لوٹاتا ہے۔ کنونشن کے مطابق، پہلی کمانڈ لائن دلیل ہمیشہ ایک طریقہ ہے، اور باقی دلائل اس کے پیرامیٹرز ہیں۔

Kubernetes اسٹوریج کے لیے والیوم پلگ ان: Flexvolume سے CSI تک
OpenShift میں CIFS شیئرز کے لیے کنکشن کا خاکہ۔ Flexvolume ڈرائیور - دائیں مرکز میں

طریقوں کا کم از کم سیٹ ایسا لگتا ہے:

flexvolume_driver mount # отвечает за присоединение тома к pod'у
# Формат возвращаемого сообщения:
{
  "status": "Success"/"Failure"/"Not supported",
  "message": "По какой причине был возвращен именно такой статус",
}

flexvolume_driver unmount # отвечает за отсоединение тома от pod'а
# Формат возвращаемого сообщения:
{
  "status": "Success"/"Failure"/"Not supported",
  "message": "По какой причине был возвращен именно такой статус",
}

flexvolume_driver init # отвечает за инициализацию плагина
# Формат возвращаемого сообщения:
{
  "status": "Success"/"Failure"/"Not supported",
  "message": "По какой причине был возвращен именно такой статус",
  // Определяет, использует ли драйвер методы attach/deatach
  "capabilities":{"attach": True/False}
}

طریقوں کا استعمال کرتے ہوئے attach и detach اس منظر نامے کی وضاحت کرے گا جس میں کبلیٹ ڈرائیور کو کال کرتے وقت مستقبل میں کام کرے گا۔ خاص طریقے بھی ہیں۔ expandvolume и expandfsجو کہ متحرک طور پر حجم کا سائز تبدیل کرنے کے ذمہ دار ہیں۔

ان تبدیلیوں کی مثال کے طور پر جو طریقہ شامل کرتا ہے۔ expandvolume، اور اس کے ساتھ حقیقی وقت میں حجم کا سائز تبدیل کرنے کی صلاحیت، آپ خود کو واقف کر سکتے ہیں۔ ہماری کھینچنے کی درخواست روک سیف آپریٹر میں۔

اور یہاں NFS کے ساتھ کام کرنے کے لیے Flexvolume ڈرائیور کے نفاذ کی ایک مثال ہے۔

usage() {
    err "Invalid usage. Usage: "
    err "t$0 init"
    err "t$0 mount <mount dir> <json params>"
    err "t$0 unmount <mount dir>"
    exit 1
}

err() {
    echo -ne $* 1>&2
}

log() {
    echo -ne $* >&1
}

ismounted() {
    MOUNT=`findmnt -n ${MNTPATH} 2>/dev/null | cut -d' ' -f1`
    if [ "${MOUNT}" == "${MNTPATH}" ]; then
        echo "1"
    else
        echo "0"
    fi
}

domount() {
    MNTPATH=$1

    NFS_SERVER=$(echo $2 | jq -r '.server')
    SHARE=$(echo $2 | jq -r '.share')

    if [ $(ismounted) -eq 1 ] ; then
        log '{"status": "Success"}'
        exit 0
    fi

    mkdir -p ${MNTPATH} &> /dev/null

    mount -t nfs ${NFS_SERVER}:/${SHARE} ${MNTPATH} &> /dev/null
    if [ $? -ne 0 ]; then
        err "{ "status": "Failure", "message": "Failed to mount ${NFS_SERVER}:${SHARE} at ${MNTPATH}"}"
        exit 1
    fi
    log '{"status": "Success"}'
    exit 0
}

unmount() {
    MNTPATH=$1
    if [ $(ismounted) -eq 0 ] ; then
        log '{"status": "Success"}'
        exit 0
    fi

    umount ${MNTPATH} &> /dev/null
    if [ $? -ne 0 ]; then
        err "{ "status": "Failed", "message": "Failed to unmount volume at ${MNTPATH}"}"
        exit 1
    fi

    log '{"status": "Success"}'
    exit 0
}

op=$1

if [ "$op" = "init" ]; then
    log '{"status": "Success", "capabilities": {"attach": false}}'
    exit 0
fi

if [ $# -lt 2 ]; then
    usage
fi

shift

case "$op" in
    mount)
        domount $*
        ;;
    unmount)
        unmount $*
        ;;
    *)
        log '{"status": "Not supported"}'
        exit 0
esac

exit 1

لہذا، اصل قابل عمل فائل کی تیاری کے بعد، آپ کو ضرورت ہے۔ ڈرائیور کو کوبرنیٹس کلسٹر میں اپ لوڈ کریں۔. ڈرائیور کا ہر کلسٹر نوڈ پر پہلے سے طے شدہ راستے کے مطابق ہونا ضروری ہے۔ پہلے سے طے شدہ طور پر اسے منتخب کیا گیا تھا:

/usr/libexec/kubernetes/kubelet-plugins/volume/exec/имя_поставщика_хранилища~имя_драйвера/

... لیکن جب مختلف Kubernetes تقسیم (OpenShift، Rancher...) استعمال کرتے ہیں تو راستہ مختلف ہوسکتا ہے۔

فلیکس حجم کے مسائل: ماہی گیری کی چھڑی کو صحیح طریقے سے کیسے ڈالا جائے؟

Flexvolume ڈرائیور کو کلسٹر نوڈس پر اپ لوڈ کرنا ایک غیر معمولی کام نکلا۔ ایک بار دستی طور پر آپریشن کرنے کے بعد، ایسی صورت حال کا سامنا کرنا آسان ہے جہاں کلسٹر میں نئے نوڈ ظاہر ہوتے ہیں: ایک نئے نوڈ کے اضافے کی وجہ سے، خودکار افقی اسکیلنگ، یا - کیا برا ہے - خرابی کی وجہ سے نوڈ کی تبدیلی۔ اس صورت میں، ان نوڈس پر سٹوریج کے ساتھ کام کیا جانا چاہئے ناممکن ہے، جب تک کہ آپ ابھی بھی دستی طور پر Flexvolume ڈرائیور کو ان میں شامل نہیں کرتے ہیں۔

اس مسئلے کا حل Kubernetes پرائمیٹوز میں سے ایک تھا۔ DaemonSet. جب کلسٹر میں ایک نیا نوڈ ظاہر ہوتا ہے، تو اس میں ہمارے ڈیمون سیٹ سے خود بخود ایک پوڈ ہوتا ہے، جس کے ساتھ Flexvolume ڈرائیوروں کو تلاش کرنے کے راستے میں ایک مقامی حجم منسلک ہوتا ہے۔ کامیاب تخلیق پر، پوڈ ڈرائیور کے لیے ضروری فائلوں کو ڈسک پر کام کرنے کے لیے کاپی کرتا ہے۔

Flexvolume پلگ ان کو ترتیب دینے کے لئے اس طرح کے ڈیمون سیٹ کی ایک مثال یہ ہے:

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: flex-set
spec:
  template:
    metadata:
      name: flex-deploy
      labels:
        app: flex-deploy
    spec:
      containers:
        - image: <deployment_image>
          name: flex-deploy
          securityContext:
              privileged: true
          volumeMounts:
            - mountPath: /flexmnt
              name: flexvolume-mount
      volumes:
        - name: flexvolume-mount
          hostPath:
            path: <host_driver_directory>

... اور Flexvolume ڈرائیور کو ترتیب دینے کے لیے Bash اسکرپٹ کی ایک مثال:

#!/bin/sh

set -o errexit
set -o pipefail

VENDOR=k8s.io
DRIVER=nfs

driver_dir=$VENDOR${VENDOR:+"~"}${DRIVER}
if [ ! -d "/flexmnt/$driver_dir" ]; then
  mkdir "/flexmnt/$driver_dir"
fi

cp "/$DRIVER" "/flexmnt/$driver_dir/.$DRIVER"
mv -f "/flexmnt/$driver_dir/.$DRIVER" "/flexmnt/$driver_dir/$DRIVER"

while : ; do
  sleep 3600
done

یہ ضروری ہے کہ کاپی آپریشن کو نہ بھولیں۔ جوہری نہیں ہے. اس بات کا بہت زیادہ امکان ہے کہ کیوبلیٹ اپنے پروویژننگ کے عمل کے مکمل ہونے سے پہلے ہی ڈرائیور کو استعمال کرنا شروع کر دے گا، جس سے سسٹم کریش ہو جائے گا۔ صحیح طریقہ یہ ہے کہ پہلے ڈرائیور فائلوں کو کسی مختلف نام سے کاپی کریں، اور پھر ایٹمک نام تبدیل کرنے کا آپریشن استعمال کریں۔

Kubernetes اسٹوریج کے لیے والیوم پلگ ان: Flexvolume سے CSI تک
Rook آپریٹر میں Ceph کے ساتھ کام کرنے کا خاکہ: ڈایاگرام میں Flexvolume ڈرائیور Rook ایجنٹ کے اندر واقع ہے۔

Flexvolume ڈرائیور استعمال کرتے وقت اگلا مسئلہ یہ ہے کہ کلسٹر نوڈ پر زیادہ تر اسٹوریج کے لیے اس کے لیے ضروری سافٹ ویئر انسٹال کرنا ضروری ہے۔ (مثال کے طور پر، Ceph کے لیے ceph-common پیکیج)۔ ابتدائی طور پر، Flexvolume پلگ ان ایسے پیچیدہ نظاموں کو نافذ کرنے کے لیے ڈیزائن نہیں کیا گیا تھا۔

اس مسئلے کا اصل حل Rook آپریٹر کے Flexvolume ڈرائیور کے نفاذ میں دیکھا جا سکتا ہے:

ڈرائیور خود ایک RPC کلائنٹ کے طور پر ڈیزائن کیا گیا ہے۔ مواصلات کے لئے IPC ساکٹ اسی ڈائرکٹری میں واقع ہے جس میں خود ڈرائیور ہے۔ ہمیں یاد ہے کہ ڈرائیور فائلوں کو کاپی کرنے کے لیے ڈیمون سیٹ کا استعمال کرنا اچھا ہو گا، جو ڈائرکٹری کو ایک والیوم کے طور پر ڈرائیور سے جوڑتا ہے۔ ضروری روک ڈرائیور فائلوں کو کاپی کرنے کے بعد، یہ پوڈ نہیں مرتا ہے، لیکن ایک مکمل RPC سرور کے طور پر منسلک والیوم کے ذریعے IPC ساکٹ سے جڑ جاتا ہے۔ سیف کامن پیکیج پوڈ کنٹینر کے اندر پہلے سے ہی انسٹال ہے۔ IPC ساکٹ اس بات کو یقینی بناتا ہے کہ کیوبلیٹ بالکل اسی پوڈ کے ساتھ بات چیت کرے گا جو اسی نوڈ پر واقع ہے۔ ہر چیز آسان ہے! ..

الوداع، ہمارے پیارے... درخت میں پلگ ان!

Kubernetes ڈویلپرز نے دریافت کیا کہ کور کے اندر اسٹوریج کے لیے پلگ ان کی تعداد بیس ہے۔ اور ان میں سے ہر ایک میں تبدیلی، کسی نہ کسی طرح، مکمل Kubernetes ریلیز سائیکل سے گزرتی ہے۔

یہ پتہ چلتا ہے کہ اسٹوریج پلگ ان کا نیا ورژن استعمال کرنے کے لیے، آپ کو پورے کلسٹر کو اپ ڈیٹ کرنے کی ضرورت ہے۔. اس کے علاوہ، آپ حیران ہوں گے کہ کبرنیٹس کا نیا ورژن آپ کے استعمال کردہ لینکس کرنل سے اچانک مطابقت نہیں رکھتا... اس لیے آپ اپنے آنسو پونچھتے ہیں اور دانت پیستے ہیں، اپنی انتظامیہ اور صارفین کے ساتھ ہم آہنگی پیدا کرتے ہیں۔ لینکس کرنل اور کبرنیٹس کلسٹر کو اپ ڈیٹ کریں۔ خدمات کی فراہمی میں ممکنہ کمی کے ساتھ۔

صورتحال مزاحیہ سے زیادہ ہے، کیا آپ نہیں سوچتے؟ یہ پوری کمیونٹی پر واضح ہو گیا کہ طریقہ کار کام نہیں کر رہا ہے۔ جان بوجھ کر فیصلہ کرتے ہوئے، Kubernetes کے ڈویلپرز نے اعلان کیا ہے کہ اسٹوریج کے ساتھ کام کرنے کے لیے نئے پلگ انز اب دانا میں قبول نہیں کیے جائیں گے۔ اس کے علاوہ، جیسا کہ ہم پہلے ہی جانتے ہیں، Flexvolume پلگ ان کے نفاذ میں متعدد کوتاہیوں کی نشاندہی کی گئی تھی...

Kubernetes، CSI میں حجم کے لیے تازہ ترین شامل کردہ پلگ ان کو مستقل ڈیٹا اسٹوریج کے ساتھ مسئلہ کو ایک بار اور ہمیشہ کے لیے بند کرنے کے لیے کہا گیا تھا۔ اس کا الفا ورژن، جسے مکمل طور پر آؤٹ آف ٹری CSI والیوم پلگ انز کہا جاتا ہے، ریلیز میں اعلان کیا گیا تھا۔ کبرنیٹس 1.9.

کنٹینر اسٹوریج انٹرفیس، یا CSI 3000 اسپننگ راڈ!

سب سے پہلے، میں یہ نوٹ کرنا چاہوں گا کہ CSI صرف ایک والیوم پلگ ان نہیں ہے، بلکہ ایک حقیقی ہے۔ معیار ڈیٹا گوداموں کے ساتھ کام کرنے کے لیے حسب ضرورت اجزاء بنانے پر. کنٹینر آرکیسٹریشن سسٹم جیسے کہ Kubernetes اور Mesos کو اس معیار کے مطابق نافذ کردہ اجزاء کے ساتھ کام کرنے کا طریقہ "سیکھنا" تھا۔ اور اب میں پہلے ہی Kubernetes سیکھ چکا ہوں۔

Kubernetes میں CSI پلگ ان کی ساخت کیا ہے؟ CSI پلگ ان خصوصی ڈرائیوروں کے ساتھ کام کرتا ہے (CSI ڈرائیورز) تیسرے فریق کے ڈویلپرز کے ذریعہ لکھا گیا ہے۔ Kubernetes میں ایک CSI ڈرائیور کو کم سے کم دو اجزاء (pods) پر مشتمل ہونا چاہیے:

  • کنٹرولر - بیرونی مستقل اسٹوریج کا انتظام کرتا ہے۔ یہ ایک gRPC سرور کے طور پر لاگو کیا جاتا ہے، جس کے لیے قدیم استعمال کیا جاتا ہے۔ StatefulSet.
  • نوڈ - کلسٹر نوڈس میں مسلسل ذخیرہ کرنے کے لیے ذمہ دار ہے۔ یہ ایک gRPC سرور کے طور پر بھی لاگو کیا جاتا ہے، لیکن یہ قدیم استعمال کرتا ہے۔ DaemonSet.

Kubernetes اسٹوریج کے لیے والیوم پلگ ان: Flexvolume سے CSI تک
کبرنیٹس میں CSI پلگ ان کیسے کام کرتا ہے۔

آپ CSI کے کام کی کچھ دیگر تفصیلات کے بارے میں جان سکتے ہیں، مثال کے طور پر، مضمون سےC.S.I کو سمجھنا' جس کا ترجمہ ہم نے ایک سال پہلے شائع کیا.

اس طرح کے نفاذ کے فوائد

  • نوڈ کے لیے ڈرائیور کو رجسٹر کرنے جیسی بنیادی چیزوں کے لیے، Kubernetes ڈویلپرز نے کنٹینرز کا ایک سیٹ نافذ کیا۔ اب آپ کو خود صلاحیتوں کے ساتھ JSON جواب تیار کرنے کی ضرورت نہیں ہے، جیسا کہ Flexvolume پلگ ان کے لیے کیا گیا تھا۔
  • قابل عمل فائلوں کو نوڈس پر "سلپ" کرنے کے بجائے، ہم اب پوڈز کو کلسٹر پر اپ لوڈ کرتے ہیں۔ یہ وہی ہے جس کی ہم ابتدائی طور پر Kubernetes سے توقع کرتے ہیں: تمام عمل Kubernetes پرائمیٹوز کا استعمال کرتے ہوئے تعینات کنٹینرز کے اندر ہوتے ہیں۔
  • پیچیدہ ڈرائیوروں کو نافذ کرنے کے لیے اب آپ کو RPC سرور اور RPC کلائنٹ تیار کرنے کی ضرورت نہیں ہے۔ کلائنٹ کو ہمارے لیے Kubernetes ڈویلپرز نے لاگو کیا تھا۔
  • جی آر پی سی پروٹوکول پر کام کرنے کے لیے دلائل کو پاس کرنا کمانڈ لائن آرگیومینٹس سے گزرنے سے کہیں زیادہ آسان، لچکدار اور قابل اعتماد ہے۔ معیاری gRPC طریقہ شامل کر کے CSI میں حجم کے استعمال کے میٹرکس کے لیے سپورٹ کیسے شامل کرنا ہے یہ سمجھنے کے لیے، آپ پڑھ سکتے ہیں: ہماری کھینچنے کی درخواست vsphere-csi ڈرائیور کے لیے۔
  • مواصلت آئی پی سی ساکٹ کے ذریعے ہوتی ہے، تاکہ اس الجھن میں نہ پڑے کہ آیا کبلیٹ نے درست پوڈ کو درخواست بھیجی ہے۔

کیا یہ فہرست آپ کو کچھ یاد دلاتی ہے؟ CSI کے فوائد یہ ہیں۔ انہی مسائل کو حل کرنا، جس کو Flexvolume پلگ ان تیار کرتے وقت مدنظر نہیں رکھا گیا تھا۔

نتائج

ڈیٹا گوداموں کے ساتھ تعامل کے لیے اپنی مرضی کے مطابق پلگ ان کو لاگو کرنے کے معیار کے طور پر CSI کو کمیونٹی کی طرف سے بہت گرمجوشی سے پذیرائی ملی۔ مزید برآں، ان کے فوائد اور استعداد کی وجہ سے، CSI ڈرائیورز کو اسٹوریج سسٹمز جیسے Ceph یا AWS EBS کے لیے بھی بنایا گیا ہے، جس کے ساتھ کام کرنے کے لیے پلگ ان جو Kubernetes کے پہلے ورژن میں شامل کیے گئے تھے۔

2019 کے آغاز میں، درختوں میں پلگ انز متروک قرار دیے گئے ہیں۔. ہم Flexvolume پلگ ان کی حمایت جاری رکھنے کا ارادہ رکھتے ہیں، لیکن اس کے لیے نئی فعالیت تیار نہیں کریں گے۔

ہمارے پاس پہلے ہی ceph-csi، vsphere-csi استعمال کرنے کا تجربہ ہے اور ہم اس فہرست میں شامل کرنے کے لیے تیار ہیں! ابھی تک، CSI اس کو تفویض کردہ کاموں کا مقابلہ کر رہا ہے، لیکن ہم انتظار کریں گے اور دیکھیں گے۔

یہ نہ بھولیں کہ ہر نئی چیز پرانے کے بارے میں سوچنا اچھا ہے!

PS

ہمارے بلاگ پر بھی پڑھیں:

ماخذ: www.habr.com

نیا تبصرہ شامل کریں