Kubernetes ਸਟੋਰੇਜ਼ ਲਈ ਵਾਲੀਅਮ ਪਲੱਗਇਨ: Flexvolume ਤੋਂ CSI ਤੱਕ

ਜਦੋਂ ਕੁਬਰਨੇਟਸ ਅਜੇ ਵੀ v1.0.0 ਸੀ, ਉੱਥੇ ਵਾਲੀਅਮ ਪਲੱਗਇਨ ਸਨ। ਉਹਨਾਂ ਨੂੰ ਸਥਾਈ (ਸਥਾਈ) ਕੰਟੇਨਰ ਡੇਟਾ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਸਿਸਟਮਾਂ ਨੂੰ ਕੁਬਰਨੇਟਸ ਨਾਲ ਜੋੜਨ ਦੀ ਲੋੜ ਸੀ। ਉਹਨਾਂ ਦੀ ਗਿਣਤੀ ਬਹੁਤ ਘੱਟ ਸੀ, ਅਤੇ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਅਜਿਹੇ ਸਟੋਰੇਜ ਪ੍ਰਦਾਤਾ ਸਨ ਜਿਵੇਂ ਕਿ GCE PD, Ceph, AWS EBS ਅਤੇ ਹੋਰ।

ਪਲੱਗਇਨਾਂ ਨੂੰ ਕੁਬਰਨੇਟਸ ਦੇ ਨਾਲ ਡਿਲੀਵਰ ਕੀਤਾ ਗਿਆ ਸੀ, ਜਿਸ ਕਰਕੇ ਉਹਨਾਂ ਨੂੰ ਉਹਨਾਂ ਦਾ ਨਾਮ ਮਿਲਿਆ - ਇਨ-ਟਰੀ. ਹਾਲਾਂਕਿ, ਕਈਆਂ ਲਈ, ਅਜਿਹੇ ਪਲੱਗਇਨਾਂ ਦਾ ਮੌਜੂਦਾ ਸੈੱਟ ਨਾਕਾਫੀ ਸਾਬਤ ਹੋਇਆ। ਕਾਰੀਗਰਾਂ ਨੇ ਪੈਚਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕੁਬਰਨੇਟਸ ਕੋਰ ਵਿੱਚ ਸਧਾਰਨ ਪਲੱਗਇਨ ਸ਼ਾਮਲ ਕੀਤੇ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਉਨ੍ਹਾਂ ਨੇ ਆਪਣੇ ਖੁਦ ਦੇ ਕੁਬਰਨੇਟਸ ਨੂੰ ਇਕੱਠਾ ਕੀਤਾ ਅਤੇ ਇਸਨੂੰ ਆਪਣੇ ਸਰਵਰਾਂ 'ਤੇ ਸਥਾਪਿਤ ਕੀਤਾ। ਪਰ ਸਮੇਂ ਦੇ ਨਾਲ, ਕੁਬਰਨੇਟਸ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇਹ ਅਹਿਸਾਸ ਹੋਇਆ ਮੱਛੀ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਲੋਕਾਂ ਦੀ ਲੋੜ ਹੈ ਫੜਨ ਦੀ ਛੜੀ. ਅਤੇ ਕੁਬਰਨੇਟਸ v1.2.0 ਦੀ ਰਿਲੀਜ਼ ਵਿੱਚ ਇਹ ਪ੍ਰਗਟ ਹੋਇਆ ...

ਫਲੈਕਸਵੋਲਿਊਮ ਪਲੱਗਇਨ: ਨਿਊਨਤਮ ਫਿਸ਼ਿੰਗ ਰਾਡ

Kubernetes ਡਿਵੈਲਪਰਾਂ ਨੇ FlexVolume ਪਲੱਗਇਨ ਬਣਾਇਆ, ਜੋ ਕਿ ਥਰਡ-ਪਾਰਟੀ ਡਿਵੈਲਪਰਾਂ ਦੁਆਰਾ ਲਾਗੂ ਕੀਤੇ ਗਏ FlexVolume ਡਰਾਈਵਰਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਵੇਰੀਏਬਲਾਂ ਅਤੇ ਤਰੀਕਿਆਂ ਦਾ ਇੱਕ ਲਾਜ਼ੀਕਲ ਫਰੇਮਵਰਕ ਸੀ।

ਆਓ ਰੁਕੀਏ ਅਤੇ ਇਸ 'ਤੇ ਡੂੰਘਾਈ ਨਾਲ ਵਿਚਾਰ ਕਰੀਏ ਕਿ FlexVolume ਡਰਾਈਵਰ ਕੀ ਹੈ। ਇਹ ਇੱਕ ਨਿਸ਼ਚਿਤ ਹੈ ਚੱਲਣਯੋਗ ਫਾਈਲ (ਬਾਈਨਰੀ ਫਾਈਲ, ਪਾਈਥਨ ਸਕ੍ਰਿਪਟ, ਬੈਸ਼ ਸਕ੍ਰਿਪਟ, ਆਦਿ), ਜੋ, ਜਦੋਂ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਕਮਾਂਡ ਲਾਈਨ ਆਰਗੂਮੈਂਟਾਂ ਨੂੰ ਇਨਪੁਟ ਵਜੋਂ ਲੈਂਦਾ ਹੈ ਅਤੇ 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, ਅਤੇ ਇਸਦੇ ਨਾਲ ਰੀਅਲ ਟਾਈਮ ਵਿੱਚ ਵਾਲੀਅਮ ਨੂੰ ਮੁੜ ਆਕਾਰ ਦੇਣ ਦੀ ਸਮਰੱਥਾ, ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਜਾਣੂ ਕਰ ਸਕਦੇ ਹੋ ਸਾਡੀ ਪੁੱਲ ਬੇਨਤੀ Rook Ceph ਆਪਰੇਟਰ ਵਿੱਚ.

ਅਤੇ ਇੱਥੇ 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. ਜਦੋਂ ਕਲੱਸਟਰ ਵਿੱਚ ਇੱਕ ਨਵਾਂ ਨੋਡ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਇਸ ਵਿੱਚ ਸਾਡੇ ਡੈਮਨਸੈੱਟ ਤੋਂ ਇੱਕ ਪੌਡ ਆਟੋਮੈਟਿਕ ਹੀ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਫਲੈਕਸਵੋਲਿਊਮ ਡਰਾਈਵਰਾਂ ਨੂੰ ਲੱਭਣ ਲਈ ਮਾਰਗ ਦੇ ਨਾਲ ਇੱਕ ਸਥਾਨਕ ਵਾਲੀਅਮ ਜੁੜ ਜਾਂਦਾ ਹੈ। ਸਫਲ ਬਣਾਉਣ 'ਤੇ, ਪੌਡ ਡਰਾਇਵਰ ਲਈ ਡਿਸਕ 'ਤੇ ਕੰਮ ਕਰਨ ਲਈ ਲੋੜੀਂਦੀਆਂ ਫਾਈਲਾਂ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ।

ਇੱਥੇ ਇੱਕ 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

ਇਹ ਨਾ ਭੁੱਲੋ ਕਿ ਕਾਪੀ ਕਾਰਵਾਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਪਰਮਾਣੂ ਨਹੀਂ ਹੈ. ਇਸ ਗੱਲ ਦੀ ਬਹੁਤ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਕੁਬੇਲੇਟ ਆਪਣੀ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਪ੍ਰਕਿਰਿਆ ਪੂਰੀ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਡਰਾਈਵਰ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦੇਵੇਗਾ, ਜਿਸ ਨਾਲ ਸਿਸਟਮ ਵਿੱਚ ਇੱਕ ਗਲਤੀ ਆਵੇਗੀ। ਸਹੀ ਪਹੁੰਚ ਇਹ ਹੈ ਕਿ ਪਹਿਲਾਂ ਡਰਾਈਵਰ ਫਾਈਲਾਂ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਨਾਮ ਹੇਠ ਕਾਪੀ ਕਰੋ, ਅਤੇ ਫਿਰ ਇੱਕ ਪਰਮਾਣੂ ਨਾਮ ਬਦਲਣ ਦੀ ਕਾਰਵਾਈ ਦੀ ਵਰਤੋਂ ਕਰੋ।

ਰੁਕ ਆਪਰੇਟਰ ਵਿੱਚ ਸੇਫ ਨਾਲ ਕੰਮ ਕਰਨ ਦਾ ਚਿੱਤਰ: ਚਿੱਤਰ ਵਿੱਚ ਫਲੈਕਸਵੋਲਿਊਮ ਡਰਾਈਵਰ ਰੂਕ ਏਜੰਟ ਦੇ ਅੰਦਰ ਸਥਿਤ ਹੈ

ਫਲੈਕਸਵੋਲਿਊਮ ਡਰਾਈਵਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਅਗਲੀ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਕਲੱਸਟਰ ਨੋਡ 'ਤੇ ਜ਼ਿਆਦਾਤਰ ਸਟੋਰੇਜ ਲਈ ਇਸਦੇ ਲਈ ਲੋੜੀਂਦਾ ਸਾਫਟਵੇਅਰ ਇੰਸਟਾਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, Ceph ਲਈ ceph-ਆਮ ਪੈਕੇਜ)। ਸ਼ੁਰੂ ਵਿੱਚ, Flexvolume ਪਲੱਗਇਨ ਅਜਿਹੇ ਗੁੰਝਲਦਾਰ ਸਿਸਟਮਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਤਿਆਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ।

ਇਸ ਸਮੱਸਿਆ ਦਾ ਅਸਲ ਹੱਲ ਰੂਕ ਆਪਰੇਟਰ ਦੇ ਫਲੈਕਸਵੋਲਿਊਮ ਡਰਾਈਵਰ ਲਾਗੂਕਰਨ ਵਿੱਚ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ:

ਡਰਾਈਵਰ ਖੁਦ ਇੱਕ RPC ਕਲਾਇੰਟ ਵਜੋਂ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਸੰਚਾਰ ਲਈ IPC ਸਾਕਟ ਉਸੇ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਸਥਿਤ ਹੈ ਜਿਵੇਂ ਕਿ ਡਰਾਈਵਰ ਖੁਦ। ਸਾਨੂੰ ਯਾਦ ਹੈ ਕਿ ਡਰਾਈਵਰ ਫਾਈਲਾਂ ਦੀ ਨਕਲ ਕਰਨ ਲਈ ਡੈਮਨਸੈੱਟ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਚੰਗਾ ਹੋਵੇਗਾ, ਜੋ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਵਾਲੀਅਮ ਦੇ ਰੂਪ ਵਿੱਚ ਡਰਾਈਵਰ ਨਾਲ ਜੋੜਦਾ ਹੈ। ਲੋੜੀਂਦੇ ਰੂਕ ਡਰਾਈਵਰ ਫਾਈਲਾਂ ਦੀ ਨਕਲ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਇਹ ਪੌਡ ਨਹੀਂ ਮਰਦਾ, ਪਰ ਇੱਕ ਪੂਰੇ ਆਰਪੀਸੀ ਸਰਵਰ ਦੇ ਰੂਪ ਵਿੱਚ ਅਟੈਚ ਵਾਲੀਅਮ ਦੁਆਰਾ IPC ਸਾਕਟ ਨਾਲ ਜੁੜਦਾ ਹੈ। ਪੌਡ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਸੀਫ-ਕਾਮਨ ਪੈਕੇਜ ਪਹਿਲਾਂ ਹੀ ਸਥਾਪਿਤ ਹੈ। IPC ਸਾਕਟ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਕੁਬੇਲੇਟ ਉਸੇ ਪੋਡ ਨਾਲ ਸੰਚਾਰ ਕਰੇਗਾ ਜੋ ਉਸੇ ਨੋਡ 'ਤੇ ਸਥਿਤ ਹੈ। ਹਰ ਚੀਜ਼ ਸਧਾਰਣ ਹੈ! ..

ਅਲਵਿਦਾ, ਸਾਡੇ ਪਿਆਰੇ... ਇਨ-ਟਰੀ ਪਲੱਗਇਨ!

ਕੁਬਰਨੇਟਸ ਡਿਵੈਲਪਰਾਂ ਨੇ ਖੋਜ ਕੀਤੀ ਕਿ ਕੋਰ ਦੇ ਅੰਦਰ ਸਟੋਰੇਜ ਲਈ ਪਲੱਗਇਨਾਂ ਦੀ ਗਿਣਤੀ ਵੀਹ ਹੈ। ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਵਿੱਚ ਇੱਕ ਤਬਦੀਲੀ, ਇੱਕ ਜਾਂ ਦੂਜੇ ਤਰੀਕੇ ਨਾਲ, ਪੂਰੇ ਕੁਬਰਨੇਟਸ ਰੀਲੀਜ਼ ਚੱਕਰ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ।

ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਸਟੋਰੇਜ ਪਲੱਗਇਨ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਪੂਰੇ ਕਲੱਸਟਰ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਤੁਸੀਂ ਹੈਰਾਨ ਹੋ ਸਕਦੇ ਹੋ ਕਿ ਕੁਬਰਨੇਟਸ ਦਾ ਨਵਾਂ ਸੰਸਕਰਣ ਤੁਹਾਡੇ ਦੁਆਰਾ ਵਰਤੇ ਜਾ ਰਹੇ ਲੀਨਕਸ ਕਰਨਲ ਨਾਲ ਅਚਾਨਕ ਅਸੰਗਤ ਹੋ ਜਾਵੇਗਾ... ਇਸ ਲਈ ਤੁਸੀਂ ਆਪਣੇ ਹੰਝੂ ਪੂੰਝਦੇ ਹੋ ਅਤੇ, ਆਪਣੇ ਦੰਦ ਪੀਸਦੇ ਹੋਏ, ਆਪਣੇ ਪ੍ਰਬੰਧਨ ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਨਾਲ ਤਾਲਮੇਲ ਕਰੋ ਲੀਨਕਸ ਕਰਨਲ ਅਤੇ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ। ਸੇਵਾਵਾਂ ਦੇ ਪ੍ਰਬੰਧ ਵਿੱਚ ਸੰਭਵ ਡਾਊਨਟਾਈਮ ਦੇ ਨਾਲ.

ਸਥਿਤੀ ਹਾਸੋਹੀਣੀ ਤੋਂ ਵੱਧ ਹੈ, ਕੀ ਤੁਸੀਂ ਨਹੀਂ ਸੋਚਦੇ? ਇਹ ਸਮੁੱਚੇ ਭਾਈਚਾਰੇ ਨੂੰ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਪਹੁੰਚ ਕੰਮ ਨਹੀਂ ਕਰ ਰਹੀ ਸੀ। ਇੱਕ ਜਾਣਬੁੱਝ ਕੇ ਫੈਸਲੇ ਦੁਆਰਾ, ਕੁਬਰਨੇਟਸ ਡਿਵੈਲਪਰ ਘੋਸ਼ਣਾ ਕਰਦੇ ਹਨ ਕਿ ਸਟੋਰੇਜ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਨਵੇਂ ਪਲੱਗਇਨ ਹੁਣ ਕਰਨਲ ਵਿੱਚ ਸਵੀਕਾਰ ਨਹੀਂ ਕੀਤੇ ਜਾਣਗੇ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਹਾਂ, ਫਲੈਕਸਵੋਲਿਊਮ ਪਲੱਗਇਨ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਕਮੀਆਂ ਦੀ ਪਛਾਣ ਕੀਤੀ ਗਈ ਸੀ...

ਕੁਬਰਨੇਟਸ, ਸੀਐਸਆਈ ਵਿੱਚ ਵੌਲਯੂਮ ਲਈ ਨਵੀਨਤਮ ਜੋੜਿਆ ਗਿਆ ਪਲੱਗਇਨ, ਇੱਕ ਵਾਰ ਅਤੇ ਸਭ ਲਈ ਨਿਰੰਤਰ ਡੇਟਾ ਸਟੋਰੇਜ ਨਾਲ ਮੁੱਦੇ ਨੂੰ ਬੰਦ ਕਰਨ ਲਈ ਕਿਹਾ ਗਿਆ ਸੀ। ਇਸਦੇ ਅਲਫ਼ਾ ਸੰਸਕਰਣ, ਜਿਸਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਆਊਟ-ਆਫ-ਟਰੀ CSI ਵਾਲੀਅਮ ਪਲੱਗਇਨ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਨੂੰ ਰਿਲੀਜ਼ ਵਿੱਚ ਘੋਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਕੁਬਰਨੇਟਸ 1.9..XNUMX.

ਕੰਟੇਨਰ ਸਟੋਰੇਜ ਇੰਟਰਫੇਸ, ਜਾਂ CSI 3000 ਸਪਿਨਿੰਗ ਰਾਡ!

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਮੈਂ ਇਹ ਨੋਟ ਕਰਨਾ ਚਾਹਾਂਗਾ ਕਿ ਸੀਐਸਆਈ ਕੇਵਲ ਇੱਕ ਵਾਲੀਅਮ ਪਲੱਗਇਨ ਨਹੀਂ ਹੈ, ਪਰ ਇੱਕ ਅਸਲੀ ਹੈ ਮਾਨਕ ਡਾਟਾ ਵੇਅਰਹਾਊਸਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਕਸਟਮ ਕੰਪੋਨੈਂਟ ਬਣਾਉਣ 'ਤੇ. ਕੰਟੇਨਰ ਆਰਕੈਸਟਰੇਸ਼ਨ ਪ੍ਰਣਾਲੀਆਂ ਜਿਵੇਂ ਕਿ ਕੁਬਰਨੇਟਸ ਅਤੇ ਮੇਸੋਸ ਨੂੰ "ਸਿੱਖਣਾ" ਚਾਹੀਦਾ ਸੀ ਕਿ ਇਸ ਮਿਆਰ ਦੇ ਅਨੁਸਾਰ ਲਾਗੂ ਕੀਤੇ ਭਾਗਾਂ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ। ਅਤੇ ਹੁਣ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਕੁਬਰਨੇਟਸ ਸਿੱਖ ਲਿਆ ਹੈ।

ਕੁਬਰਨੇਟਸ ਵਿੱਚ 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 ਡ੍ਰਾਈਵਰ ਸਟੋਰੇਜ ਪ੍ਰਣਾਲੀਆਂ ਜਿਵੇਂ ਕਿ Ceph ਜਾਂ AWS EBS, ਕੰਮ ਕਰਨ ਲਈ ਪਲੱਗਇਨਾਂ ਲਈ ਵੀ ਬਣਾਏ ਗਏ ਹਨ ਜਿਨ੍ਹਾਂ ਨਾਲ ਕੁਬਰਨੇਟਸ ਦੇ ਪਹਿਲੇ ਸੰਸਕਰਣ ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਸੀ।

2019 ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ, ਇਨ-ਟਰੀ ਪਲੱਗਇਨ ਨੂੰ ਅਪ੍ਰਚਲਿਤ ਘੋਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ. ਅਸੀਂ Flexvolume ਪਲੱਗਇਨ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਜਾਰੀ ਰੱਖਣ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ, ਪਰ ਇਸਦੇ ਲਈ ਨਵੀਂ ਕਾਰਜਸ਼ੀਲਤਾ ਵਿਕਸਿਤ ਨਹੀਂ ਕਰਾਂਗੇ।

ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ceph-csi, vsphere-csi ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਤਜਰਬਾ ਹੈ ਅਤੇ ਅਸੀਂ ਇਸ ਸੂਚੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਤਿਆਰ ਹਾਂ! ਹੁਣ ਤੱਕ, ਸੀਐਸਆਈ ਇਸ ਨੂੰ ਸੌਂਪੇ ਗਏ ਕੰਮਾਂ ਦਾ ਡੱਟ ਕੇ ਮੁਕਾਬਲਾ ਕਰ ਰਿਹਾ ਹੈ, ਪਰ ਅਸੀਂ ਉਡੀਕ ਕਰਾਂਗੇ ਅਤੇ ਦੇਖਾਂਗੇ।

ਇਹ ਨਾ ਭੁੱਲੋ ਕਿ ਹਰ ਚੀਜ਼ ਨਵੀਂ ਪੁਰਾਣੀ ਦੀ ਚੰਗੀ ਪੁਨਰ ਵਿਚਾਰ ਹੈ!

PS

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਅਸੀਂ ਕੰਟੇਨਰ ਸਟੋਰੇਜ ਇੰਟਰਫੇਸ ਨੂੰ ਸਮਝਦੇ ਹਾਂ (ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਹੀ ਨਹੀਂ)";
• «Rook ਜਾਂ ਨਹੀਂ Rook, ਇਹ ਸਵਾਲ ਹੈ";
• «ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਵੌਲਯੂਮ ਸਨੈਪਸ਼ਾਟ ਦਾ ਅਲਫ਼ਾ ਸੰਸਕਰਣ ਪੇਸ਼ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ".

ਸਰੋਤ: www.habr.com