కుబెర్నెట్స్ నిల్వ కోసం వాల్యూమ్ ప్లగిన్‌లు: Flexvolume నుండి CSI వరకు

కుబెర్నెటెస్ ఇప్పటికీ v1.0.0గా ఉన్నప్పుడు, వాల్యూమ్ ప్లగిన్‌లు ఉన్నాయి. నిరంతర (శాశ్వత) కంటైనర్ డేటాను నిల్వ చేయడానికి సిస్టమ్‌లను కుబెర్నెట్‌లకు కనెక్ట్ చేయడానికి అవి అవసరం. వారి సంఖ్య తక్కువగా ఉంది మరియు మొదటి వాటిలో GCE PD, Ceph, AWS EBS మరియు ఇతర నిల్వ ప్రొవైడర్లు ఉన్నాయి.

ప్లగిన్‌లు కుబెర్నెట్స్‌తో పాటు డెలివరీ చేయబడ్డాయి, అందుకే వాటికి వాటి పేరు వచ్చింది - ఇన్-ట్రీ. అయినప్పటికీ, చాలా మందికి, ఇప్పటికే ఉన్న అటువంటి ప్లగిన్‌ల సెట్ సరిపోదు. హస్తకళాకారులు కుబెర్నెటెస్ కోర్‌కు ప్యాచ్‌లను ఉపయోగించి సాధారణ ప్లగిన్‌లను జోడించారు, ఆ తర్వాత వారు తమ స్వంత కుబెర్నెట్‌లను సమీకరించారు మరియు దానిని వారి సర్వర్‌లలో ఇన్‌స్టాల్ చేసుకున్నారు. కానీ కాలక్రమేణా, కుబెర్నెట్స్ డెవలపర్లు దానిని గ్రహించారు చేపలు సమస్య పరిష్కరించబడదు. ప్రజలకు కావాలి ఫిషింగ్ రాడ్. మరియు కుబెర్నెట్స్ v1.2.0 విడుదలలో అది కనిపించింది...

Flexvolume ప్లగ్ఇన్: కనిష్ట ఫిషింగ్ రాడ్

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, మరియు దానితో నిజ సమయంలో వాల్యూమ్‌ల పరిమాణాన్ని మార్చగల సామర్థ్యం, ​​మీరు మీ గురించి తెలుసుకోవచ్చు మా పుల్ అభ్యర్థన రూక్ సెఫ్ ఆపరేటర్‌లో.

మరియు ఇక్కడ 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. క్లస్టర్‌లో కొత్త నోడ్ కనిపించినప్పుడు, అది స్వయంచాలకంగా మా 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 డ్రైవర్‌ను వేయడానికి బాష్ స్క్రిప్ట్‌కి ఉదాహరణ:

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

కాపీ ఆపరేషన్ అని మర్చిపోకూడదు పరమాణువు కాదు. kubelet దాని ప్రొవిజనింగ్ ప్రక్రియ పూర్తయ్యేలోపు డ్రైవర్‌ని ఉపయోగించడం ప్రారంభించే అవకాశం ఉంది, దీని వలన సిస్టమ్ క్రాష్ అవుతుంది. ముందుగా డ్రైవర్ ఫైల్‌లను వేరే పేరుతో కాపీ చేసి, ఆపై అటామిక్ రీనేమ్ ఆపరేషన్‌ని ఉపయోగించడం సరైన విధానం.

రూక్ ఆపరేటర్‌లో సెఫ్‌తో పనిచేసే రేఖాచిత్రం: రేఖాచిత్రంలో ఫ్లెక్స్‌వాల్యూమ్ డ్రైవర్ రూక్ ఏజెంట్ లోపల ఉంది

ఫ్లెక్స్‌వాల్యూమ్ డ్రైవర్‌లను ఉపయోగిస్తున్నప్పుడు తదుపరి సమస్య ఏమిటంటే క్లస్టర్ నోడ్‌లో ఎక్కువ నిల్వ కోసం దీనికి అవసరమైన సాఫ్ట్‌వేర్‌ను తప్పనిసరిగా ఇన్‌స్టాల్ చేయాలి (ఉదాహరణకు, Ceph కోసం ceph-కామన్ ప్యాకేజీ). ప్రారంభంలో, అటువంటి సంక్లిష్ట వ్యవస్థలను అమలు చేయడానికి Flexvolume ప్లగ్ఇన్ రూపొందించబడలేదు.

ఈ సమస్యకు అసలు పరిష్కారం రూక్ ఆపరేటర్ యొక్క Flexvolume డ్రైవర్ అమలులో చూడవచ్చు:

డ్రైవర్ స్వయంగా RPC క్లయింట్‌గా రూపొందించబడింది. కమ్యూనికేషన్ కోసం IPC సాకెట్ డ్రైవర్ ఉన్న అదే డైరెక్టరీలో ఉంది. డ్రైవర్ ఫైల్‌లను కాపీ చేయడానికి డెమోన్‌సెట్‌ని ఉపయోగించడం మంచిదని మేము గుర్తుంచుకోవాలి, ఇది డైరెక్టరీని డ్రైవర్‌తో వాల్యూమ్‌గా కనెక్ట్ చేస్తుంది. అవసరమైన రూక్ డ్రైవర్ ఫైల్‌లను కాపీ చేసిన తర్వాత, ఈ పాడ్ చనిపోదు, కానీ పూర్తి స్థాయి RPC సర్వర్‌గా జోడించిన వాల్యూమ్ ద్వారా IPC సాకెట్‌కి కనెక్ట్ అవుతుంది. ceph-common ప్యాకేజీ ఇప్పటికే పాడ్ కంటైనర్ లోపల ఇన్‌స్టాల్ చేయబడింది. IPC సాకెట్ అదే నోడ్‌లో ఉన్న పాడ్‌తో కుబెలెట్ కమ్యూనికేట్ చేస్తుందని నిర్ధారిస్తుంది. తెలివిగల ప్రతిదీ సులభం! ..

వీడ్కోలు, మా ఆప్యాయత... ఇన్-ట్రీ ప్లగిన్‌లు!

కోర్ లోపల నిల్వ కోసం ప్లగిన్‌ల సంఖ్య ఇరవై అని Kubernetes డెవలపర్‌లు కనుగొన్నారు. మరియు వాటిలో ప్రతి ఒక్కదానిలో మార్పు, ఒక మార్గం లేదా మరొకటి, పూర్తి కుబెర్నెట్స్ విడుదల చక్రం గుండా వెళుతుంది.

నిల్వ ప్లగిన్ యొక్క క్రొత్త సంస్కరణను ఉపయోగించడానికి ఇది మారుతుంది, మీరు మొత్తం క్లస్టర్‌ను అప్‌డేట్ చేయాలి. దీనితో పాటుగా, మీరు ఉపయోగిస్తున్న లైనక్స్ కెర్నల్‌తో కుబెర్నెటెస్ యొక్క కొత్త వెర్షన్ అకస్మాత్తుగా అననుకూలంగా మారిందని మీరు ఆశ్చర్యపోవచ్చు... కాబట్టి మీరు మీ కన్నీళ్లను తుడిచివేయండి మరియు మీ పళ్ళు కరుచుకుంటూ, మీ మేనేజ్‌మెంట్ మరియు వినియోగదారులతో సమన్వయం చేసుకోండి. Linux కెర్నల్ మరియు Kubernetes క్లస్టర్‌ను నవీకరించండి. సేవలను అందించడంలో సాధ్యమైన పనికిరాని సమయంతో.

పరిస్థితి హాస్యాస్పదంగా ఉంది, మీరు అనుకోలేదా? ఈ విధానం పనికిరాదని మొత్తం సమాజానికి స్పష్టమైంది. ఉద్దేశపూర్వక నిర్ణయం ద్వారా, నిల్వతో పని చేయడానికి కొత్త ప్లగిన్‌లు ఇకపై కెర్నల్‌లోకి అంగీకరించబడవని కుబెర్నెట్స్ డెవలపర్‌లు ప్రకటించారు. అదనంగా, మనకు ఇప్పటికే తెలిసినట్లుగా, Flexvolume ప్లగ్ఇన్ అమలులో అనేక లోపాలు గుర్తించబడ్డాయి...

కుబెర్నెట్స్, CSIలో వాల్యూమ్‌ల కోసం తాజా జోడించిన ప్లగ్ఇన్, నిరంతర డేటా నిల్వతో సమస్యను ఒకసారి మరియు అందరికీ మూసివేయాలని కోరింది. దాని ఆల్ఫా వెర్షన్, పూర్తిగా అవుట్-ఆఫ్-ట్రీ CSI వాల్యూమ్ ప్లగిన్‌లుగా సూచించబడింది, విడుదలలో ప్రకటించబడింది కుబెర్నెట్స్ 1.9.

కంటైనర్ స్టోరేజ్ ఇంటర్‌ఫేస్ లేదా CSI 3000 స్పిన్నింగ్ రాడ్!

అన్నింటిలో మొదటిది, CSI అనేది కేవలం వాల్యూమ్ ప్లగ్ఇన్ మాత్రమే కాదు, నిజమైనది అని నేను గమనించాలనుకుంటున్నాను ప్రామాణిక డేటా గిడ్డంగులతో పని చేయడానికి అనుకూల భాగాలను సృష్టించడం. కుబెర్నెటెస్ మరియు మెసోస్ వంటి కంటైనర్ ఆర్కెస్ట్రేషన్ సిస్టమ్‌లు ఈ ప్రమాణం ప్రకారం అమలు చేయబడిన భాగాలతో ఎలా పని చేయాలో "నేర్చుకోవలసి ఉంటుంది". మరియు ఇప్పుడు నేను ఇప్పటికే కుబెర్నెట్స్ నేర్చుకున్నాను.

కుబెర్నెట్స్‌లో CSI ప్లగిన్ నిర్మాణం ఏమిటి? CSI ప్లగిన్ ప్రత్యేక డ్రైవర్లతో పనిచేస్తుంది (CSI డ్రైవర్లు) థర్డ్ పార్టీ డెవలపర్‌లచే వ్రాయబడింది. కుబెర్నెట్స్‌లోని CSI డ్రైవర్ కనీసం రెండు భాగాలను (పాడ్‌లను) కలిగి ఉండాలి:

• కంట్రోలర్ - బాహ్య నిరంతర నిల్వలను నిర్వహిస్తుంది. ఇది gRPC సర్వర్‌గా అమలు చేయబడుతుంది, దీని కోసం ఆదిమ ఉపయోగించబడుతుంది StatefulSet.
• నోడ్ — క్లస్టర్ నోడ్‌లకు నిరంతర నిల్వను అమర్చడానికి బాధ్యత వహిస్తుంది. ఇది gRPC సర్వర్‌గా కూడా అమలు చేయబడుతుంది, అయితే ఇది ఆదిమాన్ని ఉపయోగిస్తుంది DaemonSet.

కుబెర్నెట్స్‌లో CSI ప్లగ్ఇన్ ఎలా పని చేస్తుంది

మీరు CSI పనికి సంబంధించిన కొన్ని ఇతర వివరాల గురించి తెలుసుకోవచ్చు, ఉదాహరణకు, "" వ్యాసం నుండిC.S.Iని అర్థం చేసుకోవడం" దీని అనువాదం మేము ఒక సంవత్సరం క్రితం ప్రచురించాము.

అటువంటి అమలు యొక్క ప్రయోజనాలు

• నోడ్ కోసం డ్రైవర్‌ను నమోదు చేయడం వంటి ప్రాథమిక విషయాల కోసం, కుబెర్నెట్స్ డెవలపర్‌లు కంటైనర్‌ల సమితిని అమలు చేశారు. Flexvolume ప్లగ్ఇన్ కోసం చేసినట్లుగా, మీరు ఇకపై మీరే సామర్థ్యాలతో JSON ప్రతిస్పందనను రూపొందించాల్సిన అవసరం లేదు.
• నోడ్‌లలోకి ఎక్జిక్యూటబుల్ ఫైల్‌లను "జారడం" కాకుండా, మేము ఇప్పుడు పాడ్‌లను క్లస్టర్‌కి అప్‌లోడ్ చేస్తాము. మేము మొదట్లో కుబెర్నెటెస్ నుండి ఆశించేది ఇదే: అన్ని ప్రక్రియలు కుబెర్నెట్స్ ఆదిమాలను ఉపయోగించి అమర్చబడిన కంటైనర్‌లలో జరుగుతాయి.
• సంక్లిష్ట డ్రైవర్లను అమలు చేయడానికి మీరు ఇకపై RPC సర్వర్ మరియు RPC క్లయింట్‌ను అభివృద్ధి చేయవలసిన అవసరం లేదు. క్లయింట్ మాకు Kubernetes డెవలపర్‌ల ద్వారా అమలు చేయబడింది.
• gRPC ప్రోటోకాల్‌పై పని చేయడానికి ఆర్గ్యుమెంట్‌లను పాస్ చేయడం కమాండ్ లైన్ ఆర్గ్యుమెంట్‌ల ద్వారా వాటిని పాస్ చేయడం కంటే చాలా సౌకర్యవంతంగా, అనువైనది మరియు నమ్మదగినది. ప్రామాణిక gRPC పద్ధతిని జోడించడం ద్వారా CSIకి వాల్యూమ్ వినియోగ కొలమానాలకు మద్దతును ఎలా జోడించాలో అర్థం చేసుకోవడానికి, మీరు చదవగలరు: మా పుల్ అభ్యర్థన vsphere-csi డ్రైవర్ కోసం.
• IPC సాకెట్ల ద్వారా కమ్యూనికేషన్ జరుగుతుంది, తద్వారా kubelet సరైన పాడ్‌కి అభ్యర్థనను పంపిందా లేదా అనే గందరగోళానికి గురికాకూడదు.

ఈ జాబితా మీకు ఏదైనా గుర్తు చేస్తుందా? CSI యొక్క ప్రయోజనాలు అదే సమస్యలను పరిష్కరించడం, Flexvolume ప్లగ్ఇన్‌ను అభివృద్ధి చేస్తున్నప్పుడు పరిగణనలోకి తీసుకోబడలేదు.

కనుగొన్న

డేటా గిడ్డంగులతో పరస్పర చర్య చేయడానికి అనుకూల ప్లగిన్‌లను అమలు చేయడానికి CSI ఒక ప్రమాణంగా సంఘం ద్వారా చాలా హృదయపూర్వకంగా స్వీకరించబడింది. అంతేకాకుండా, వాటి ప్రయోజనాలు మరియు పాండిత్యము కారణంగా, CSI డ్రైవర్లు Ceph లేదా AWS EBS వంటి స్టోరేజ్ సిస్టమ్‌ల కోసం కూడా సృష్టించబడతాయి, వాటితో పని చేయడానికి ప్లగిన్‌లు కుబెర్నెట్స్ యొక్క మొదటి వెర్షన్‌లో జోడించబడ్డాయి.

2019 ప్రారంభంలో, ఇన్-ట్రీ ప్లగిన్‌లు వాడుకలో లేనివిగా ప్రకటించబడ్డాయి. మేము Flexvolume ప్లగ్‌ఇన్‌కు మద్దతుని కొనసాగించాలని ప్లాన్ చేస్తున్నాము, కానీ దాని కోసం కొత్త కార్యాచరణను అభివృద్ధి చేయము.

మేము ఇప్పటికే ceph-csi, vsphere-csiని ఉపయోగించిన అనుభవం కలిగి ఉన్నాము మరియు ఈ జాబితాకు జోడించడానికి సిద్ధంగా ఉన్నాము! ఇప్పటి వరకు, CSI తనకు కేటాయించిన విధులను ఒక బ్యాంగ్‌తో ఎదుర్కొంటోంది, అయితే మేము వేచి ఉండి చూద్దాం.

కొత్తదంతా పాతవాటికి మంచి పునరాలోచన అని మర్చిపోవద్దు!

PS

మా బ్లాగులో కూడా చదవండి:

• «మేము కంటైనర్ స్టోరేజ్ ఇంటర్‌ఫేస్‌ను అర్థం చేసుకున్నాము (కుబెర్నెట్స్‌లో మరియు మాత్రమే కాదు)";
• «రూక్‌కు లేదా రూక్‌కు కాదు - ఇది ప్రశ్న";
• «కుబెర్నెట్స్‌లో వాల్యూమ్ స్నాప్‌షాట్‌ల ఆల్ఫా వెర్షన్‌ను పరిచయం చేస్తున్నాము".

మూలం: www.habr.com