Kubernetes স্টোরেজের জন্য ভলিউম প্লাগইন: Flexvolume থেকে CSI পর্যন্ত

ফিরে যখন Kubernetes এখনও v1.0.0 ছিল, ভলিউম প্লাগইন ছিল। স্থায়ী (স্থায়ী) ধারক ডেটা সঞ্চয় করার জন্য কুবারনেটসের সাথে সিস্টেমগুলিকে সংযুক্ত করার জন্য তাদের প্রয়োজন ছিল। তাদের সংখ্যা কম ছিল, এবং প্রথমগুলির মধ্যে ছিল GCE PD, Ceph, AWS EBS এবং অন্যান্যদের মতো স্টোরেজ প্রদানকারী।

প্লাগইনগুলি কুবারনেটসের সাথে বিতরণ করা হয়েছিল, এই কারণেই তারা তাদের নাম পেয়েছে - ইন-ট্রি। যাইহোক, অনেকের জন্য, এই জাতীয় প্লাগইনগুলির বিদ্যমান সেট অপর্যাপ্ত বলে প্রমাণিত হয়েছে। কারিগররা প্যাচ ব্যবহার করে Kubernetes কোরে সহজ প্লাগইন যোগ করে, তারপরে তারা তাদের নিজস্ব Kubernetes একত্রিত করে এবং তাদের সার্ভারে ইনস্টল করে। কিন্তু সময়ের সাথে সাথে, Kubernetes বিকাশকারীরা তা বুঝতে পেরেছিল মাছ সমস্যা সমাধান করা যাবে না। মানুষ প্রয়োজন মাছ ধরার ছিপ. এবং Kubernetes v1.2.0 এর প্রকাশে এটি উপস্থিত হয়েছিল ...

ফ্লেক্সভলিউম প্লাগইন: ন্যূনতম ফিশিং রড

কুবারনেটস ডেভেলপাররা ফ্লেক্সভলিউম প্লাগইন তৈরি করেছে, যা তৃতীয় পক্ষের ডেভেলপারদের দ্বারা বাস্তবায়িত ফ্লেক্সভলিউম ড্রাইভারের সাথে কাজ করার জন্য ভেরিয়েবল এবং পদ্ধতিগুলির একটি যৌক্তিক কাঠামো ছিল।

আসুন থামুন এবং ফ্লেক্সভলিউম ড্রাইভারটি কী তা ঘনিষ্ঠভাবে দেখুন। এটি একটি নির্দিষ্ট এক্সিকিউটেবল ফাইল (বাইনারী ফাইল, পাইথন স্ক্রিপ্ট, ব্যাশ স্ক্রিপ্ট, ইত্যাদি), যা কার্যকর করা হলে, ইনপুট হিসাবে কমান্ড লাইন আর্গুমেন্ট নেয় এবং JSON ফর্ম্যাটে পূর্ব-পরিচিত ক্ষেত্রগুলির সাথে একটি বার্তা প্রদান করে। নিয়ম অনুসারে, প্রথম কমান্ড লাইন আর্গুমেন্ট সর্বদা একটি পদ্ধতি, এবং অবশিষ্ট আর্গুমেন্ট হল এর পরামিতি।

OpenShift-এ CIFS শেয়ারের জন্য সংযোগ চিত্র। ফ্লেক্সভলিউম ড্রাইভার - ঠিক কেন্দ্রে

পদ্ধতির ন্যূনতম সেট এই মত দেখাচ্ছে:

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

সুতরাং, প্রকৃত এক্সিকিউটেবল ফাইল প্রস্তুত করার পরে, আপনাকে করতে হবে Kubernetes ক্লাস্টারে ড্রাইভার আপলোড করুন. ড্রাইভার একটি পূর্বনির্ধারিত পথ অনুযায়ী প্রতিটি ক্লাস্টার নোডে অবস্থিত হতে হবে। ডিফল্টরূপে এটি নির্বাচন করা হয়েছিল:

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

... কিন্তু বিভিন্ন কুবারনেটস ডিস্ট্রিবিউশন ব্যবহার করার সময় (ওপেনশিফট, রাঞ্চার...) পথ ভিন্ন হতে পারে।

ফ্লেক্সভলিউম সমস্যা: কীভাবে মাছ ধরার রড সঠিকভাবে নিক্ষেপ করবেন?

ক্লাস্টার নোডগুলিতে ফ্লেক্সভলিউম ড্রাইভার আপলোড করা একটি অ-তুচ্ছ কাজ হয়ে উঠেছে। ম্যানুয়ালি একবার অপারেশন করার পরে, ক্লাস্টারে নতুন নোডগুলি উপস্থিত হওয়ার কারণে এমন পরিস্থিতির মুখোমুখি হওয়া সহজ: একটি নতুন নোড যুক্ত করার কারণে, স্বয়ংক্রিয় অনুভূমিক স্কেলিং বা - কী খারাপ - ত্রুটির কারণে একটি নোডের প্রতিস্থাপন। এই ক্ষেত্রে, এই নোডগুলিতে স্টোরেজ নিয়ে কাজ করা উচিত অসম্ভব, যতক্ষণ না আপনি এখনও ম্যানুয়ালি Flexvolume ড্রাইভার যোগ করেন।

এই সমস্যার সমাধান ছিল কুবারনেটস আদিমদের মধ্যে একটি - DaemonSet. যখন ক্লাস্টারে একটি নতুন নোড উপস্থিত হয়, তখন এটি স্বয়ংক্রিয়ভাবে আমাদের ডেমনসেট থেকে একটি পড ধারণ করে, যার সাথে ফ্লেক্সভলিউম ড্রাইভারগুলি খুঁজে পাওয়ার পথ বরাবর একটি স্থানীয় ভলিউম সংযুক্ত থাকে। সফলভাবে তৈরি করার পরে, পড ড্রাইভারের জন্য প্রয়োজনীয় ফাইলগুলিকে ডিস্কে কাজ করার জন্য অনুলিপি করে।

এখানে একটি ফ্লেক্সভলিউম প্লাগইন রাখার জন্য এই জাতীয় ডেমনসেটের একটি উদাহরণ রয়েছে:

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>

... এবং ফ্লেক্সভলিউম ড্রাইভার লেয়ার করার জন্য একটি ব্যাশ স্ক্রিপ্টের একটি উদাহরণ:

#!/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

এটা যে কপি অপারেশন ভুলবেন না গুরুত্বপূর্ণ পারমাণবিক নয়. প্রভিশনিং প্রক্রিয়া সম্পূর্ণ হওয়ার আগেই কুবেলেট ড্রাইভার ব্যবহার করা শুরু করবে, যার ফলে সিস্টেম ক্র্যাশ হওয়ার সম্ভাবনা বেশি। সঠিক পদ্ধতি হল প্রথমে একটি ভিন্ন নামে ড্রাইভার ফাইল কপি করা, এবং তারপর একটি পারমাণবিক নাম পরিবর্তন অপারেশন ব্যবহার করুন।

রুক অপারেটরে Ceph এর সাথে কাজ করার ডায়াগ্রাম: ডায়াগ্রামে ফ্লেক্সভলিউম ড্রাইভারটি রুক এজেন্টের ভিতরে অবস্থিত

ফ্লেক্সভলিউম ড্রাইভার ব্যবহার করার সময় পরবর্তী সমস্যাটি হল একটি ক্লাস্টার নোডে বেশিরভাগ স্টোরেজের জন্য এর জন্য প্রয়োজনীয় সফটওয়্যার ইন্সটল করতে হবে (উদাহরণস্বরূপ, Ceph-এর জন্য ceph-সাধারণ প্যাকেজ)। প্রাথমিকভাবে, ফ্লেক্সভলিউম প্লাগইনটি এই ধরনের জটিল সিস্টেম বাস্তবায়নের জন্য ডিজাইন করা হয়নি।

এই সমস্যার একটি আসল সমাধান রুক অপারেটরের ফ্লেক্সভলিউম ড্রাইভার বাস্তবায়নে দেখা যেতে পারে:

ড্রাইভার নিজেই একটি RPC ক্লায়েন্ট হিসাবে ডিজাইন করা হয়েছে. যোগাযোগের জন্য IPC সকেট ড্রাইভারের মতো একই ডিরেক্টরিতে অবস্থিত। আমরা মনে রাখি যে ড্রাইভার ফাইলগুলি কপি করার জন্য ডেমনসেট ব্যবহার করা ভাল হবে, যা একটি ভলিউম হিসাবে ড্রাইভারের সাথে ডিরেক্টরিকে সংযুক্ত করে। প্রয়োজনীয় রুক ড্রাইভার ফাইলগুলি অনুলিপি করার পরে, এই পডটি মারা যায় না, তবে একটি সম্পূর্ণ RPC সার্ভার হিসাবে সংযুক্ত ভলিউমের মাধ্যমে IPC সকেটের সাথে সংযোগ করে। ceph-সাধারণ প্যাকেজটি ইতিমধ্যেই পড পাত্রের ভিতরে ইনস্টল করা আছে। আইপিসি সকেট নিশ্চিত করে যে কুবেলেট ঠিক একই নোডে অবস্থিত পডের সাথে যোগাযোগ করবে। বুদ্ধিমান সবকিছু সহজ! ..

বিদায়, আমাদের স্নেহময়... ইন-ট্রি প্লাগইন!

Kubernetes বিকাশকারীরা আবিষ্কার করেছেন যে মূলের মধ্যে স্টোরেজের জন্য প্লাগইন সংখ্যা বিশ। এবং তাদের প্রতিটিতে একটি পরিবর্তন, একটি বা অন্যভাবে, সম্পূর্ণ Kubernetes রিলিজ চক্রের মধ্য দিয়ে যায়।

দেখা যাচ্ছে যে স্টোরেজ প্লাগইনটির নতুন সংস্করণ ব্যবহার করতে, আপনাকে পুরো ক্লাস্টার আপডেট করতে হবে. এটি ছাড়াও, আপনি অবাক হতে পারেন যে কুবারনেটসের নতুন সংস্করণটি হঠাৎ করে আপনি যে লিনাক্স কার্নেলটি ব্যবহার করছেন তার সাথে বেমানান হয়ে যাবে... তাই আপনি আপনার চোখের জল মুছে ফেলুন এবং দাঁত কষাতে থাকুন, আপনার ব্যবস্থাপনা এবং ব্যবহারকারীদের সাথে সমন্বয় করুন লিনাক্স কার্নেল এবং কুবারনেটস ক্লাস্টার আপডেট করুন। পরিষেবার বিধান সম্ভাব্য ডাউনটাইম সঙ্গে.

পরিস্থিতি হাস্যকর চেয়ে বেশি, আপনি কি মনে করেন না? এটি সমগ্র সম্প্রদায়ের কাছে স্পষ্ট হয়ে উঠেছে যে পদ্ধতিটি কাজ করছে না। ইচ্ছাকৃত সিদ্ধান্তের মাধ্যমে, Kubernetes বিকাশকারীরা ঘোষণা করে যে স্টোরেজের সাথে কাজ করার জন্য নতুন প্লাগইনগুলি আর কার্নেলে গ্রহণ করা হবে না। উপরন্তু, আমরা ইতিমধ্যে জানি, ফ্লেক্সভলিউম প্লাগইন বাস্তবায়নে বেশ কয়েকটি ত্রুটি চিহ্নিত করা হয়েছিল...

Kubernetes, CSI-তে ভলিউমের জন্য সর্বশেষ যোগ করা প্লাগইনটিকে অবিরাম ডেটা স্টোরেজ সহ সমস্যাটি একবার এবং সবের জন্য বন্ধ করার আহ্বান জানানো হয়েছিল। এর আলফা সংস্করণ, যা সম্পূর্ণরূপে আউট-অফ-ট্রি সিএসআই ভলিউম প্লাগইনস হিসাবে পরিচিত, প্রকাশে ঘোষণা করা হয়েছিল কুবারনেটস 1.9.

কন্টেইনার স্টোরেজ ইন্টারফেস, বা CSI 3000 স্পিনিং রড!

প্রথমত, আমি লক্ষ্য করতে চাই যে CSI শুধুমাত্র একটি ভলিউম প্লাগইন নয়, একটি বাস্তব মান ডেটা গুদামগুলির সাথে কাজ করার জন্য কাস্টম উপাদান তৈরি করা. কন্টেইনার অর্কেস্ট্রেশন সিস্টেম যেমন Kubernetes এবং Mesos এই মান অনুযায়ী বাস্তবায়িত উপাদানগুলির সাথে কীভাবে কাজ করতে হয় তা "শিখতে" বলে মনে করা হয়েছিল। এবং এখন আমি ইতিমধ্যে কুবারনেটস শিখেছি।

Kubernetes-এ CSI প্লাগইন এর গঠন কি? CSI প্লাগইন বিশেষ ড্রাইভারের সাথে কাজ করে (সিএসআই ড্রাইভার) তৃতীয় পক্ষের বিকাশকারীদের দ্বারা লিখিত। Kubernetes-এ একজন CSI ড্রাইভারের ন্যূনতম দুটি উপাদান (পড) থাকা উচিত:

• নিয়ামক - বাহ্যিক ক্রমাগত স্টোরেজ পরিচালনা করে। এটি একটি gRPC সার্ভার হিসাবে প্রয়োগ করা হয়, যার জন্য আদিম ব্যবহার করা হয় StatefulSet.
• নোড — ক্লাস্টার নোডগুলিতে স্থায়ী স্টোরেজ মাউন্ট করার জন্য দায়ী। এটি একটি gRPC সার্ভার হিসাবেও প্রয়োগ করা হয়, তবে এটি আদিম ব্যবহার করে DaemonSet.

কিভাবে CSI প্লাগইন কুবারনেটসে কাজ করে

আপনি CSI-এর কাজের অন্যান্য কিছু বিবরণ সম্পর্কে জানতে পারেন, উদাহরণস্বরূপ, নিবন্ধটি থেকেC.S.I বোঝা।», যার অনুবাদ আমরা এক বছর আগে প্রকাশ করেছি।

যেমন একটি বাস্তবায়ন সুবিধা

• একটি নোডের জন্য ড্রাইভার নিবন্ধন করার মতো মৌলিক জিনিসগুলির জন্য, Kubernetes বিকাশকারীরা কন্টেইনারগুলির একটি সেট প্রয়োগ করে। ফ্লেক্সভলিউম প্লাগইনের জন্য যেমনটি করা হয়েছিল, আপনাকে আর নিজের ক্ষমতা সহ JSON প্রতিক্রিয়া তৈরি করতে হবে না।
• নোডগুলিতে এক্সিকিউটেবল ফাইলগুলিকে "স্লিপ" করার পরিবর্তে, আমরা এখন ক্লাস্টারে পড আপলোড করি। কুবারনেটস থেকে আমরা প্রাথমিকভাবে এটিই আশা করি: সমস্ত প্রক্রিয়াগুলি কুবারনেটস আদিম ব্যবহার করে স্থাপন করা পাত্রে ঘটে।
• জটিল ড্রাইভার বাস্তবায়নের জন্য আপনাকে আর একটি RPC সার্ভার এবং RPC ক্লায়েন্ট বিকাশ করতে হবে না। ক্লায়েন্ট আমাদের জন্য Kubernetes বিকাশকারীদের দ্বারা বাস্তবায়িত হয়েছিল।
• জিআরপিসি প্রোটোকলের উপর কাজ করার জন্য আর্গুমেন্ট পাস করা কমান্ড লাইন আর্গুমেন্টের মাধ্যমে পাস করার চেয়ে অনেক বেশি সুবিধাজনক, নমনীয় এবং নির্ভরযোগ্য। একটি প্রমিত gRPC পদ্ধতি যোগ করে CSI-তে ভলিউম ব্যবহারের মেট্রিক্সের জন্য কীভাবে সমর্থন যোগ করতে হয় তা বুঝতে, আপনি পড়তে পারেন: আমাদের টান অনুরোধ vsphere-csi ড্রাইভারের জন্য।
• আইপিসি সকেটের মাধ্যমে যোগাযোগ হয়, যাতে কুবেলেট সঠিক পডে অনুরোধটি পাঠিয়েছে কিনা তা বিভ্রান্ত না হয়।

এই তালিকাটি কি আপনাকে কিছু মনে করিয়ে দেয়? CSI এর সুবিধাগুলো হল একই সমস্যার সমাধান, যা ফ্লেক্সভলিউম প্লাগইন তৈরি করার সময় বিবেচনায় নেওয়া হয়নি।

তথ্যও

ডেটা গুদামগুলির সাথে ইন্টারঅ্যাক্ট করার জন্য কাস্টম প্লাগইনগুলি বাস্তবায়নের জন্য একটি মান হিসাবে CSI সম্প্রদায়ের দ্বারা খুব উষ্ণভাবে গ্রহণ করা হয়েছিল। তদুপরি, তাদের সুবিধা এবং বহুমুখীতার কারণে, CSI ড্রাইভারগুলি এমনকি Ceph বা AWS EBS-এর মতো স্টোরেজ সিস্টেমের জন্য তৈরি করা হয়েছে, যার সাথে কাজ করার জন্য প্লাগইনগুলি Kubernetes-এর প্রথম সংস্করণে যোগ করা হয়েছিল।

2019 এর শুরুতে, ইন-ট্রি প্লাগইন অপ্রচলিত ঘোষণা করা হয়েছে. আমরা ফ্লেক্সভলিউম প্লাগইনকে সমর্থন করা চালিয়ে যাওয়ার পরিকল্পনা করছি, কিন্তু এর জন্য নতুন কার্যকারিতা বিকাশ করব না।

আমরা ইতিমধ্যেই ceph-csi, vsphere-csi ব্যবহার করার অভিজ্ঞতা পেয়েছি এবং এই তালিকায় যোগ করতে প্রস্তুত! এখনও অবধি, CSI এটিকে অর্পিত কাজগুলিকে একটি ধাক্কা দিয়ে মোকাবেলা করছে, তবে আমরা অপেক্ষা করব এবং দেখব।

ভুলে যাবেন না যে নতুন সবকিছুই পুরানোকে নিয়ে একটি ভাল পুনর্বিবেচনা!

দ্রষ্টব্য

আমাদের ব্লগেও পড়ুন:

• «আমরা কন্টেইনার স্টোরেজ ইন্টারফেস বুঝি (কুবারনেটে এবং শুধু নয়)";
• «রুক না টু রুক - এটাই প্রশ্ন";
• «Kubernetes-এ ভলিউম স্ন্যাপশটের আলফা সংস্করণ উপস্থাপন করা হচ্ছে».

উত্স: www.habr.com