કુબરનેટ્સ સ્ટોરેજ માટે વોલ્યુમ પ્લગઈન્સ: ફ્લેક્સવોલ્યુમથી CSI સુધી

જ્યારે Kubernetes હજુ પણ v1.0.0 હતું, ત્યાં વોલ્યુમ પ્લગઇન્સ હતા. સતત (કાયમી) કન્ટેનર ડેટા સ્ટોર કરવા માટે સિસ્ટમોને કુબરનેટ્સ સાથે કનેક્ટ કરવા માટે તેમની જરૂર હતી. તેમની સંખ્યા ઓછી હતી, અને પ્રથમમાં GCE PD, Ceph, AWS EBS અને અન્ય જેવા સ્ટોરેજ પ્રદાતાઓ હતા.

પ્લગઇન્સ કુબરનેટ્સ સાથે વિતરિત કરવામાં આવ્યા હતા, તેથી જ તેમને તેમનું નામ મળ્યું - ઇન-ટ્રી. જો કે, ઘણા લોકો માટે, આવા પ્લગિન્સનો હાલનો સેટ અપૂરતો હોવાનું બહાર આવ્યું છે. કારીગરોએ પેચનો ઉપયોગ કરીને કુબરનેટીસ કોરમાં સરળ પ્લગઈનો ઉમેર્યા, ત્યારબાદ તેઓએ તેમના પોતાના કુબરનેટ્સ એસેમ્બલ કર્યા અને તેને તેમના સર્વર પર ઇન્સ્ટોલ કર્યા. પરંતુ સમય જતાં, કુબરનેટ્સ ડેવલપર્સને તે સમજાયું માછલી સમસ્યા હલ થઈ શકતી નથી. લોકોને જરૂર છે માછીમારી લાકડી. અને Kubernetes v1.2.0 ના પ્રકાશનમાં તે દેખાયું...

ફ્લેક્સવોલ્યુમ પ્લગઇન: ન્યૂનતમ ફિશિંગ રોડ

Kubernetes વિકાસકર્તાઓએ FlexVolume પ્લગઇન બનાવ્યું, જે તૃતીય-પક્ષ વિકાસકર્તાઓ દ્વારા અમલમાં મૂકવામાં આવેલા Flexvolume ડ્રાઇવરો સાથે કામ કરવા માટેની ચલ અને પદ્ધતિઓનું તાર્કિક માળખું હતું.

ચાલો બંધ કરીએ અને ફ્લેક્સવોલ્યુમ ડ્રાઈવર શું છે તેના પર નજીકથી નજર કરીએ. આ ચોક્કસ છે એક્ઝિક્યુટેબલ ફાઇલ (દ્વિસંગી ફાઇલ, પાયથોન સ્ક્રિપ્ટ, બેશ સ્ક્રિપ્ટ, વગેરે), જે, જ્યારે એક્ઝિક્યુટ થાય છે, ત્યારે ઇનપુટ તરીકે કમાન્ડ લાઇન દલીલો લે છે અને JSON ફોર્મેટમાં પૂર્વ-જાણીતા ફીલ્ડ્સ સાથેનો સંદેશ પરત કરે છે. સંમેલન દ્વારા, પ્રથમ આદેશ વાક્ય દલીલ હંમેશા એક પદ્ધતિ છે, અને બાકીની દલીલો તેના પરિમાણો છે.

ઓપનશિફ્ટમાં 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

તેથી, વાસ્તવિક એક્ઝેક્યુટેબલ ફાઇલ તૈયાર કર્યા પછી, તમારે જરૂર છે ડ્રાઇવરને કુબરનેટ્સ ક્લસ્ટરમાં અપલોડ કરો. ડ્રાઈવર દરેક ક્લસ્ટર નોડ પર પૂર્વનિર્ધારિત પાથ અનુસાર સ્થિત હોવો જોઈએ. મૂળભૂત રીતે તે પસંદ કરવામાં આવ્યું હતું:

/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-સામાન્ય પેકેજ). શરૂઆતમાં, ફ્લેક્સવોલ્યુમ પ્લગઇન આવી જટિલ સિસ્ટમોને લાગુ કરવા માટે ડિઝાઇન કરવામાં આવ્યું ન હતું.

આ સમસ્યાનો મૂળ ઉકેલ રૂક ઓપરેટરના ફ્લેક્સવોલ્યુમ ડ્રાઈવર અમલીકરણમાં જોઈ શકાય છે:

ડ્રાઈવર પોતે RPC ક્લાયન્ટ તરીકે રચાયેલ છે. સંદેશાવ્યવહાર માટે IPC સોકેટ એ જ ડિરેક્ટરીમાં સ્થિત છે જે ડ્રાઇવર પોતે છે. અમે યાદ રાખીએ છીએ કે ડ્રાઇવર ફાઇલોની નકલ કરવા માટે ડેમનસેટનો ઉપયોગ કરવો સારું રહેશે, જે ડાયરેક્ટરીને વોલ્યુમ તરીકે ડ્રાઇવર સાથે જોડે છે. જરૂરી રૂક ડ્રાઈવર ફાઈલોની નકલ કર્યા પછી, આ પોડ મૃત્યુ પામતું નથી, પરંતુ સંપૂર્ણ RPC સર્વર તરીકે જોડાયેલ વોલ્યુમ દ્વારા IPC સોકેટ સાથે જોડાય છે. ceph-સામાન્ય પેકેજ પોડ કન્ટેનરની અંદર પહેલેથી જ ઇન્સ્ટોલ કરેલું છે. IPC સોકેટ એ સુનિશ્ચિત કરે છે કે કુબેલેટ એ જ નોડ પર સ્થિત પોડ સાથે બરાબર વાતચીત કરશે. બુદ્ધિશાળી બધું સરળ છે! ..

ગુડબાય, અમારા સ્નેહી... ઇન-ટ્રી પ્લગઇન્સ!

કુબરનેટ્સ ડેવલપર્સે શોધ્યું કે કોર અંદર સ્ટોરેજ માટે પ્લગિન્સની સંખ્યા વીસ છે. અને તેમાંના દરેકમાં ફેરફાર, એક યા બીજી રીતે, સંપૂર્ણ કુબરનેટ્સ પ્રકાશન ચક્રમાંથી પસાર થાય છે.

તે તારણ આપે છે કે સ્ટોરેજ પ્લગઇનના નવા સંસ્કરણનો ઉપયોગ કરવા માટે, તમારે સમગ્ર ક્લસ્ટરને અપડેટ કરવાની જરૂર છે. આ ઉપરાંત, તમને આશ્ચર્ય થશે કે કુબરનેટ્સનું નવું સંસ્કરણ તમે ઉપયોગમાં લઈ રહ્યાં છો તે Linux કર્નલ સાથે અચાનક અસંગત બની જશે... તેથી તમે તમારા આંસુ લૂછી લો અને, દાંત પીસીને, તમારા મેનેજમેન્ટ અને વપરાશકર્તાઓ સાથે સમયસર સંકલન કરો. Linux કર્નલ અને Kubernetes ક્લસ્ટરને અપડેટ કરો. સેવાઓની જોગવાઈમાં સંભવિત ડાઉનટાઇમ સાથે.

પરિસ્થિતિ હાસ્યજનક કરતાં વધુ છે, તમને નથી લાગતું? તે સમગ્ર સમુદાયને સ્પષ્ટ થઈ ગયું કે અભિગમ કામ કરતું નથી. ઇરાદાપૂર્વકના નિર્ણય દ્વારા, કુબરનેટ્સ ડેવલપર્સ જાહેરાત કરે છે કે સ્ટોરેજ સાથે કામ કરવા માટેના નવા પ્લગિન્સ હવે કર્નલમાં સ્વીકારવામાં આવશે નહીં. વધુમાં, જેમ આપણે પહેલાથી જ જાણીએ છીએ, ફ્લેક્સવોલ્યુમ પ્લગઇનના અમલીકરણમાં સંખ્યાબંધ ખામીઓ ઓળખવામાં આવી હતી...

Kubernetes, CSI માં વોલ્યુમો માટે નવીનતમ ઉમેરાયેલ પ્લગઇન, સતત ડેટા સ્ટોરેજ સાથે સમસ્યાને એકવાર અને બધા માટે બંધ કરવા માટે કહેવામાં આવ્યું હતું. તેનું આલ્ફા વર્ઝન, વધુ સંપૂર્ણ રીતે આઉટ-ઓફ-ટ્રી CSI વોલ્યુમ પ્લગઇન્સ તરીકે ઓળખાય છે, તેની જાહેરાત પ્રકાશનમાં કરવામાં આવી હતી. કુબર્નીટ્સ 1.9.

કન્ટેનર સ્ટોરેજ ઇન્ટરફેસ, અથવા CSI 3000 સ્પિનિંગ રોડ!

સૌ પ્રથમ, હું એ નોંધવા માંગુ છું કે CSI માત્ર વોલ્યુમ પ્લગઇન નથી, પરંતુ વાસ્તવિક છે માનક ડેટા વેરહાઉસ સાથે કામ કરવા માટે કસ્ટમ ઘટકો બનાવવા પર. કન્ટેનર ઓર્કેસ્ટ્રેશન સિસ્ટમ્સ જેમ કે કુબરનેટ્સ અને મેસોસને આ ધોરણ અનુસાર અમલમાં મૂકાયેલા ઘટકો સાથે કેવી રીતે કાર્ય કરવું તે "શીખવું" હતું. અને હવે હું પહેલેથી જ કુબરનેટ્સ શીખી ગયો છું.

કુબરનેટ્સમાં CSI પ્લગઇનનું માળખું શું છે? CSI પ્લગઈન ખાસ ડ્રાઈવરો સાથે કામ કરે છે (CSI ડ્રાઇવરો) તૃતીય પક્ષ વિકાસકર્તાઓ દ્વારા લખાયેલ. કુબરનેટ્સમાં CSI ડ્રાઇવરમાં ઓછામાં ઓછા બે ઘટકો (પોડ્સ) હોવા જોઈએ:

• નિયંત્રક - બાહ્ય સતત સ્ટોરેજનું સંચાલન કરે છે. તે gRPC સર્વર તરીકે અમલમાં મૂકવામાં આવે છે, જેના માટે આદિમનો ઉપયોગ થાય છે StatefulSet.
• નોડ — ક્લસ્ટર નોડ્સમાં સતત સંગ્રહને માઉન્ટ કરવા માટે જવાબદાર છે. તે gRPC સર્વર તરીકે પણ અમલમાં છે, પરંતુ તે આદિમનો ઉપયોગ કરે છે DaemonSet.

કુબરનેટ્સમાં CSI પ્લગઇન કેવી રીતે કાર્ય કરે છે

તમે CSI ના કાર્યની કેટલીક અન્ય વિગતો વિશે શીખી શકો છો, ઉદાહરણ તરીકે, લેખમાંથીC.S.I ને સમજવું.», જેનો અનુવાદ અમે એક વર્ષ પહેલા પ્રકાશિત કર્યું.

આવા અમલીકરણના ફાયદા

• નોડ માટે ડ્રાઇવરની નોંધણી કરવા જેવી મૂળભૂત બાબતો માટે, કુબરનેટ્સ ડેવલપર્સે કન્ટેનરનો સમૂહ અમલમાં મૂક્યો હતો. તમારે હવે ક્ષમતાઓ સાથે JSON પ્રતિસાદ જનરેટ કરવાની જરૂર નથી, જેમ કે Flexvolume પ્લગઇન માટે કરવામાં આવ્યું હતું.
• નોડ્સ પર એક્ઝિક્યુટેબલ ફાઇલોને "સ્લિપ" કરવાને બદલે, અમે હવે ક્લસ્ટર પર પોડ્સ અપલોડ કરીએ છીએ. કુબરનેટસ પાસેથી આપણે શરૂઆતમાં આની અપેક્ષા રાખીએ છીએ: બધી પ્રક્રિયાઓ કુબરનેટ્સ પ્રિમિટિવ્સનો ઉપયોગ કરીને જમાવવામાં આવેલા કન્ટેનરની અંદર થાય છે.
• જટિલ ડ્રાઇવરોને અમલમાં મૂકવા માટે તમારે હવે RPC સર્વર અને RPC ક્લાયંટ વિકસાવવાની જરૂર નથી. ક્લાયંટ અમારા માટે કુબરનેટ્સ ડેવલપર્સ દ્વારા લાગુ કરવામાં આવ્યું હતું.
• gRPC પ્રોટોકોલ પર કામ કરવા માટે દલીલો પસાર કરવી એ કમાન્ડ લાઇન દલીલોમાંથી પસાર થવા કરતાં વધુ અનુકૂળ, લવચીક અને વિશ્વસનીય છે. પ્રમાણિત gRPC પદ્ધતિ ઉમેરીને CSI માં વોલ્યુમ વપરાશ મેટ્રિક્સ માટે સમર્થન કેવી રીતે ઉમેરવું તે સમજવા માટે, તમે વાંચી શકો છો: અમારી ખેંચવાની વિનંતી vsphere-csi ડ્રાઇવર માટે.
• સંચાર IPC સોકેટ્સ દ્વારા થાય છે, જેથી કુબેલેટે યોગ્ય પોડને વિનંતી મોકલી છે કે કેમ તે મૂંઝવણમાં ન આવે.

શું આ સૂચિ તમને કંઈપણ યાદ અપાવે છે? CSI ના ફાયદા છે સમાન સમસ્યાઓનું નિરાકરણ, જે Flexvolume પ્લગઇન વિકસાવતી વખતે ધ્યાનમાં લેવામાં આવ્યા ન હતા.

તારણો

ડેટા વેરહાઉસીસ સાથે ક્રિયાપ્રતિક્રિયા કરવા માટે કસ્ટમ પ્લગિન્સ લાગુ કરવા માટેના ધોરણ તરીકે CSI ને સમુદાય દ્વારા ખૂબ જ ઉષ્માભર્યું આવકાર મળ્યો હતો. તદુપરાંત, તેમના ફાયદા અને વર્સેટિલિટીને લીધે, CSI ડ્રાઇવરો સેફ અથવા AWS EBS જેવી સ્ટોરેજ સિસ્ટમ્સ માટે પણ બનાવવામાં આવે છે, જેની સાથે કામ કરવા માટેના પ્લગઇન્સ કુબરનેટ્સના પ્રથમ સંસ્કરણમાં ઉમેરવામાં આવ્યા હતા.

2019 ની શરૂઆતમાં, ઇન-ટ્રી પ્લગઇન્સ અપ્રચલિત જાહેર કરવામાં આવ્યા છે. અમે Flexvolume પ્લગઇનને સમર્થન આપવાનું ચાલુ રાખવાની યોજના બનાવીએ છીએ, પરંતુ તેના માટે નવી કાર્યક્ષમતા વિકસાવીશું નહીં.

અમને પહેલેથી જ ceph-csi, vsphere-csi નો ઉપયોગ કરવાનો અનુભવ છે અને અમે આ સૂચિમાં ઉમેરવા માટે તૈયાર છીએ! અત્યાર સુધી, CSI તેને સોંપવામાં આવેલા કાર્યોનો સામનો કરી રહી છે, પરંતુ અમે રાહ જોઈશું અને જોઈશું.

ભૂલશો નહીં કે બધું નવું એ જૂના પર ફરીથી વિચારવું છે!

PS

અમારા બ્લોગ પર પણ વાંચો:

• «અમે કન્ટેનર સ્ટોરેજ ઈન્ટરફેસ સમજીએ છીએ (કુબરનેટ્સમાં અને માત્ર નહીં)»;
• «રુક માટે કે રુક માટે નહીં - તે પ્રશ્ન છે»;
• «Kubernetes માં વોલ્યુમ સ્નેપશોટના આલ્ફા સંસ્કરણનો પરિચય».

સોર્સ: www.habr.com