🥇Volymplugins för lagring i Kubernetes: från Flexvolume till CSI

När Kubernetes var version v1.0.0 fanns det volympluggar (volume plugins). De behövdes för att koppla Kubernetes-system till lagringslösningar för persistenta (beständiga) data i containrar. Antalet var begränsat, och bland de första var lagringsleverantörer som GCE PD, Ceph, AWS EBS och andra.

Pluggarna levererades tillsammans med Kubernetes, vilket gav dem namnet in-tree. Men många ansåg att den befintliga uppsättningen av sådana pluggar var otillräcklig. Hantverkare lade till enkla pluggar i Kubernetes-kärnan med hjälp av patchar, och byggde sedan sin egen version av Kubernetes för att installera den på sina servrar. Men med tiden insåg Kubernetes-utvecklarna att fisket problemet inte kunde lösas. Människor behövde en fiskespö. Och i versionen Kubernetes v1.2.0 dök det upp...

Flexvolume-plugin: ett enkelt fiskespö

Kubernetes-utvecklarna skapade FlexVolume-plugin, som var en logisk omslutning av variabler och metoder för att arbeta med Flexvolume-drivrutiner implementerade av tredjepartsutvecklare.

Låt oss stanna upp och titta närmare på vad FlexVolume-drivrutinen representerar. Det är en exekveringsfil (binarfil, Python-skript, Bash-skript, etc.), som vid körning tar emot kommandoradsargument och returnerar ett meddelande med förutbestämda fält i JSON-format. Första kommandoradsargumentet är alltid metoden, och de övriga argumenten är dess parametrar.

Anslutningsschema för CIFS-delningar i OpenShift. Flexvolume-drivrutinen ligger mitt i centrum.

Minimalt antal metoder ser ut så här:

flexvolume_driver mount # ansvarar för att ansluta volymen till podden
# Format för det returnerade meddelandet:
{
  "status": "Success"/"Failure"/"Not supported",
  "message": "Anledningen till att denna status returnerades",
}

flexvolume_driver unmount # ansvarar för att koppla ifrån volymen från podden
# Format för det returnerade meddelandet:
{
  "status": "Success"/"Failure"/"Not supported",
  "message": "Anledningen till att denna status returnerades",
}

flexvolume_driver init # ansvarar för att initiera pluginet
# Format för det returnerade meddelandet:
{
  "status": "Success"/"Failure"/"Not supported",
  "message": "Anledningen till att denna status returnerades",
  // Anger om drivrutinen använder metoderna attach/detach
  "capabilities":{"attach": True/False}
}

Användning av metoder attach och detach bestämmer vilket scenario kubelet kommer att agera i när drivrutinen anropas. Det finns också specifika metoder expandvolume och expandfs, som ansvarar för dynamisk storleksändring av volymen.

Som exempel på de förändringar som metoden tillför expandvolume, och tillsammans med den - möjligheten att ändra storlek på volymer i realtid kan du läsa om vår pull request. i Rook Ceph Operator.

Här är ett exempel på implementering av Flexvolume-drivrutinen för att arbeta med NFS:

usage() {
    err "Ogiltig användning. Användning: "
    err "t$0 init"
    err "t$0 mount <monteringskatalog> <json parametrar>"
    err "t$0 unmount <monteringskatalog>"
    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": "Framgång"}'
        exit 0
    fi

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

    mount -t nfs ${NFS_SERVER}:\/ ${SHARE} ${MNTPATH} &> \/dev\/null
    if [ $? -ne 0 ]; then
        err "{ "status": "Misslyckande", "message": "Misslyckades med att montera ${NFS_SERVER}:${SHARE} vid ${MNTPATH}"}"
        exit 1
    fi
    log '{"status": "Framgång"}'
    exit 0
}

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

    umount ${MNTPATH} &> \/dev\/null
    if [ $? -ne 0 ]; then
        err "{ "status": "Misslyckades", "message": "Misslyckades med att avmontera volymen vid ${MNTPATH}"}"
        exit 1
    fi

    log '{"status": "Framgång"}'
    exit 0
}

op=$1

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

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

shift

case "$op" in
    mount)
        domount $*
        ;;
    unmount)
        unmount $*
        ;;
    *)
        log '{"status": "Inte stödd"}'
        exit 0
esac

exit 1

Så efter att ha förberett den körbara filen behöver du ladda upp drivrutinen till Kubernetes-klustret. Drivrutinen ska finnas på varje nod i klustret enligt den förutbestämda sökvägen. Som standard valdes:

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

… men vid användning av olika distributioner av Kubernetes (OpenShift, Rancher…) kan sökvägen vara annorlunda.

Problematik med Flexvolume: hur ska man rätt hantera det?

Att distribuera Flexvolume-drivrutinen på noderna i klustret visade sig vara en utmaning. Om du gör operationen en gång för hand är det lätt att stöta på situationen där nya noder läggs till i klustret: på grund av tillsättning av en ny nod, automatisk horisontell skalning eller - vilket är värre - att en nod byts ut på grund av fel. I detta fall måste du arbeta med lagring på dessa noder är omöjligt, så länge du fortfarande manuellt lägger till Flexvolume-drivrutinen på dem.

Lösningen på detta problem var en av Kubernetes-primitiverna - DaemonSet. När en ny nod läggs till i klustret tilldelas en pod automatiskt från vår DaemonSet, som kopplar ett lokalt volym på sökvägen för att hitta Flexvolume-drivrutiner. Vid framgångsrik skapelse kopierar pod nödvändiga filer för drivrutinens funktion på disken.

Här är ett exempel på en sådan DaemonSet för att distribuera Flexvolume-plugin:

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

… och ett exempel på ett Bash-skript för att distribuera Flexvolume-drivrutinen:

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

Viktigt att komma ihåg är att kopieringsoperationen inte är atomär. Det finns stor risk att kubelet börjar använda drivrutinen innan förberedelseprocessen är klar, vilket kan orsaka fel i systemets funktion. En korrekt strategi skulle vara att först kopiera drivrutinsfilerna under ett annat namn, och därefter använda en atomär byteoperation.

Arbetsschema för Ceph i Rook-operatören: Flexvolume-drivrutinen i diagrammet är belägen inom Rook-agenten.

Ett annat problem vid användning av Flexvolume-drivrutiner är att för de flesta lagringslösningar på noden i klustret måste nödvändig programvara installeras (till exempel paketet ceph-common för Ceph). Ursprungligen var Flexvolume-pluginet inte tänkt att implementera så komplexa system.

Den ursprungliga lösningen på detta problem kan ses i implementationen av Flexvolume-drivrutinen hos Rook-operatören:

Själva drivrutinen är utformad som en RPC-klient. IPC-socketen för kommunikation ligger i samma katalog som själva drivrutinen. Vi minns att det vore bra att använda en DaemonSet för att kopiera drivrutinsfiler, vilket kopplar en katalog med drivrutinen som volym. Efter kopiering av nödvändiga drivrutinsfiler överlever rook den här podden, och ansluter till IPC-socketen via den anslutna volymen som en fullständig RPC-server. Paketet ceph-common är redan installerat inuti poddcontainern. IPC-socketen ger säkerhet för att kubelet kommer att kommunicera med just den podden som finns på samma nod. Allt genialt är enkelt!..

Farväl, våra kära... in-tree plugins!

Utvecklare av Kubernetes har upptäckt att antalet lagringsplugins i kärnan är tjugo. Förändringar i var och en av dem går igenom hela releasescykeln för Kubernetes på ett eller annat sätt.

Det visar sig att för att använda en ny version av lagringsplugin, måste hela klustret uppgraderas. Dessutom kan du kanske bli förvånad över att den nya versionen av Kubernetes plötsligt blir inkompatibel med den Linux-kärna som används... Så du torkar bort tårarna och, medan du biter i läpparna, diskuterar du med chefer och användare om när uppgraderingen av Linux-kärnan och Kubernetes-klustret ska göras. Med en möjlig stilleståndstid för tjänsterna.

Situationen är mer än komisk, eller hur? Hela gemenskapen har insett att detta förfarande inte fungerar. Genom en kraftfull åtgärd har utvecklarna av Kubernetes meddelat att nya plugins för lagring inte längre kommer att accepteras i kärnan. Dessutom, som vi redan vet, har flera brister upptäckts i implementeringen av Flexvolume-pluginet...

Den senaste pluginen som tillsats för att för alltid reda ut frågan om persistenta datalagringar är CSI. Dess alfa-version, som mer fullständigt kallas Utanför-Träd CSI Volym Plugins, presenterades i release Kubernetes 1.9.

Container Storage Interface, eller snurrande CSI 3000!

Först och främst vill jag påpeka att CSI inte bara är en volymplugin, utan en riktig standarden för skapande av användarspecifika komponenter för datalagring.Det förväntades att system för containerorkestrering, såsom Kubernetes och Mesos, skulle "lära sig" att arbeta med komponenter implementerade enligt denna standard. Och nu har Kubernetes redan lärt sig.

Hur fungerar CSI-pluginet i Kubernetes? CSI-pluginet arbetar med speciella drivrutiner (CSI-drivrutiner) skrivna av tredjepartsutvecklare. En CSI-drivrutin i Kubernetes måste minst bestå av två komponenter (poddar):

Controller — hanterar externa persistenta lagringar. Det distribueras som en gRPC-server, där den primära användningen är StatefulSet.
Node — ansvarar för montering av persistenta lagringar till klusterknutar. Också implementerat som en gRPC-server, men för den används den primära användningen DaemonSet.

Arbetsflödet för CSI-pluginet i Kubernetes

Du kan läsa om några andra detaljer om CSI:s funktionalitet, till exempel i artikeln "Understanding the CSI», vars översättning vi publicerade för ett år sedan.

Fördelarna med en sådan implementering

För grundläggande saker — som till exempel registrering av drivrutiner för noder — har utvecklarna av Kubernetes implementerat en uppsättning containrar. Det är inte längre nödvändigt att själva generera JSON-svar med capabilities, som gjordes för Flexvolume-plugin.
Istället för att "lasta" körbara filer på noderna lägger vi nu ut poddar i klustret. Detta är vad vi från början förväntar oss av Kubernetes: alla processer sker inom containrar som deployas med hjälp av Kubernetes-primitiver.
För att implementera komplexa drivrutiner behöver vi inte längre utveckla en RPC-server och RPC-klient. Klienten har utvecklarna av Kubernetes implementerat åt oss.
Överföring av argument för arbete via gRPC-protokollet är mycket enklare, mer flexibelt och mer pålitligt än att överföra dem via kommandoradsargument. För att förstå hur man lägger till stöd för mätningar av volymanvändning i CSI genom att lägga till en standardiserad gRPC-metod kan man bekanta sig med vår pull request. för drivrutinen vsphere-csi.
Kommunikationen sker via IPC-sockets för att undvika förvirring om till vilken pod kubelet har skickat begäran.

Den här listan påminner dig kanske om något? Fördelarna med CSI är lösningen på de problemen, som inte beaktades vid utvecklingen av Flexvolume-plugin.

Slutsatser

CSI som standard för implementering av anpassade plugins för interaktion med datalagring har mottagits mycket varmt av samhället. Dessutom, tack vare sina fördelar och mångsidighet, skapas CSI-drivrutiner även för lagringssystem som Ceph eller AWS EBS, plugins för vilka lades till redan i den första versionen av Kubernetes.

I början av 2019 meddelades att in-tree plugins har blivit föråldrade. Stödet för Flexvolume-plugin kommer att fortsätta, men utvecklingen av nya funktioner för det kommer att upphöra.

Vi har redan erfarenhet av att använda ceph-csi, vsphere-csi och är redo att lägga till den här listan! Så här långt klarar CSI de uppgifter som ålagts den utmärkt, och vi får se vad som händer därnäst.

Kom ihåg att allt nytt är väl omprövat gammalt!