🥇Volume Plugins fir Späicheren a Kubernetes: vu Flexvolume op CSI

Zréck wann Kubernetes nach v1.0.0 war, goufen et Volumen Plugins. Si waren néideg fir Systemer mat Kubernetes ze verbannen fir persistent (permanent) Containerdaten ze späicheren. Hir Zuel war kleng, an ënnert den éischte waren esou Stockage Ubidder wéi GCE PD, Ceph, AWS EBS an anerer.

D'Plugins goufen zesumme mat Kubernetes geliwwert, dofir kruten se hiren Numm - am Bam. Wéi och ëmmer, fir vill ass de existente Set vu sou Plugins net genuch. Handwierker hunn einfache Plugins zum Kubernetes Kär mat Patches bäigefüügt, duerno hunn se hir eege Kubernetes zesummegesat an op hire Server installéiert. Awer mat der Zäit hunn d'Kubernetes Entwéckler dat realiséiert Fësch de Problem kann net geléist ginn. Leit brauchen Fëscherei Staang. An an der Verëffentlechung vu Kubernetes v1.2.0 erschéngt ...

Flexvolume Plugin: minimal Fëscherei Staang

Kubernetes Entwéckler hunn de FlexVolume Plugin erstallt, deen e logesche Kader vu Variablen a Methoden war fir mat Flexvolume Treiber ze schaffen, déi vun Drëtt-Entwéckler implementéiert goufen.

Loosst eis ophalen a kucke méi genau wat de FlexVolume Chauffer ass. Dëst ass bestëmmt ausführbar Datei (binär Datei, Python Skript, Bash Skript, etc.), déi, wann se ausgefouert ginn, Kommandozeilargumenter als Input hëlt an e Message mat virbekannte Felder am JSON Format zréckginn. Duerch Konventioun ass dat éischt Kommandozeilargument ëmmer eng Method, an déi verbleiwen Argumenter sinn seng Parameteren.

Verbindungsdiagramm fir CIFS Aktien an OpenShift. Flexvolume Driver - Recht am Zentrum

Minimum Set vu Methoden gesäit aus wéi:

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}
}

Benotzt Methoden attach и detach wäert de Szenario definéieren an deem de Kubelet an Zukunft handelt wann de Chauffer rufft. Et ginn och speziell Methoden expandvolume и expandfs, déi verantwortlech sinn fir dynamesch d'Gréisst vum Volume ze änneren.

Als e Beispill vun den Ännerungen déi d'Method bäidréit expandvolume, a mat der Fähegkeet Volumen an Echtzäit z'änneren, kënnt Dir Iech vertraut maachen eis Pull Ufro am Rook Ceph Bedreiwer.

An hei ass e Beispill vun der Implementatioun vum Flexvolume Chauffer fir mat NFS ze schaffen:

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

Also, nodeems Dir déi aktuell ausführbar Datei virbereet hutt, musst Dir lued de Chauffer op de Kubernetes Cluster. De Chauffer muss op all Cluster Node no engem virbestëmmten Wee sinn. Par défaut gouf se gewielt:

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

... awer wann Dir verschidde Kubernetes Verdeelungen benotzt (OpenShift, Rancher ...) kann de Wee anescht sinn.

Flexvolume Probleemer: wéi eng Fëschstang richteg ze werfen?

D'Eroplueden vum Flexvolume Chauffer op Clusternoden huet sech als net-trivial Aufgab erausgestallt. Wann Dir d'Operatioun eemol manuell gemaach hutt, ass et einfach eng Situatioun ze begéinen, wou nei Wirbelen am Stärekoup erschéngen: duerch d'Zousatz vun engem neie Node, automatesch horizontale Skala, oder - wat méi schlëmm ass - Ersatz vun engem Node wéinst enger Feelfunktioun. An dësem Fall soll d'Aarbecht mat der Späichere op dësen Wirbelen gemaach ginn ass net méiglech, bis Dir nach ëmmer manuell de Flexvolume-Treiber derbäi setzt.

D'Léisung fir dëse Problem war ee vun de Kubernetes Primitiv - DaemonSet. Wann en neien Node am Cluster erschéngt, enthält en automatesch e Pod aus eisem DaemonSet, un deem e lokale Volumen laanscht de Wee befestegt ass fir Flexvolume Treiber ze fannen. No der erfollegräicher Kreatioun kopéiert de Pod déi néideg Dateie fir datt de Chauffer op Disk funktionnéiert.

Hei ass e Beispill vu sou engem DaemonSet fir e Flexvolume Plugin auszeleeën:

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>

... an e Beispill vun engem Bash Skript fir de Flexvolume Chauffer auszeleeën:

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

Et ass wichteg net ze vergiessen datt d'Kopie Operatioun ass net atomar. Et gëtt eng grouss Chance datt de Kubelet de Chauffer ufänkt ze benotzen ier säi Versuergungsprozess fäerdeg ass, wat de System veruersaacht. Déi richteg Approche ass fir d'éischt d'Treiberdateien ënner engem aneren Numm ze kopéieren, an dann eng Atomombenennungsoperatioun ze benotzen.

Diagramm fir mam Ceph am Rook Bedreiwer ze schaffen: de Flexvolume Chauffer am Diagramm ass am Rook Agent lokaliséiert

Den nächste Problem wann Dir Flexvolume Treiber benotzt ass dat fir déi meescht Späicheren op engem Cluster Node déi néideg Software fir dës muss installéiert ginn (zum Beispill de Ceph-gemeinsame Package fir Ceph). Am Ufank war de Flexvolume Plugin net entwéckelt fir sou komplex Systemer ëmzesetzen.

Eng originell Léisung fir dëse Problem kann an der Flexvolume Driver Implementatioun vum Rook Bedreiwer gesi ginn:

De Chauffer selwer ass als RPC Client entworf. Den IPC Socket fir Kommunikatioun ass am selwechte Verzeechnes wéi de Chauffer selwer. Mir erënnere mech drun datt fir Chaufferdateien ze kopéieren et gutt wier DaemonSet ze benotzen, deen den Verzeechnes mam Chauffer als Volume verbënnt. Nodeems Dir déi néideg Rook Driver Dateien kopéiert, stierft dëse Pod net, awer verbënnt mat der IPC Socket duerch de befestegt Volumen als e vollwäertege RPC Server. De Ceph-Common Package ass schonn am Pod Container installéiert. Den IPC Socket garantéiert datt de Kubelet mat genau de Pod kommunizéiere wäert, deen um selwechten Node läit. Alles genial ass einfach! ..

Äddi, eis léif ... In-Baum Plugins!

Kubernetes Entwéckler entdeckt datt d'Zuel vun de Plugins fir d'Späichere am Kär zwanzeg ass. An eng Ännerung an jiddereng vun hinnen, déi eng oder aner Manéier, geet duerch de komplette Kubernetes Verëffentlechungszyklus.

Et stellt sech eraus datt fir déi nei Versioun vum Späichere Plugin ze benotzen, Dir musst de ganze Cluster aktualiséieren. Zousätzlech zu dësem, kënnt Dir iwwerrascht sinn datt déi nei Versioun vu Kubernetes op eemol inkompatibel gëtt mam Linux Kernel deen Dir benotzt ... Also wäscht Dir Är Tréinen an, dréckt Är Zänn, koordinéiert mat Ärem Management a Benotzer d'Zäit fir Update de Linux Kernel a Kubernetes Cluster. Mat méiglech Ënnerbriechungen an der Dispositioun vun Servicer.

D'Situatioun ass méi wéi komesch, mengt Dir net? Et gouf der ganzer Gemeng kloer datt d'Approche net funktionnéiert. Duerch eng bewosst Entscheedung kënne Kubernetes Entwéckler annoncéieren datt nei Plugins fir mat der Späichere schaffen net méi an de Kernel akzeptéiert ginn. Zousätzlech, wéi mir scho wëssen, goufen eng Rei Mängel an der Ëmsetzung vum Flexvolume Plugin identifizéiert ...

De leschten addéierte Plugin fir Bänn a Kubernetes, CSI, gouf opgeruff fir d'Thema mat persistent Datelagerung eemol a fir all zouzemaachen. Seng Alpha Versioun, méi komplett als Out-of-Tree CSI Volume Plugins bezeechent, gouf an der Verëffentlechung ugekënnegt Kubernetes 1.9.

Container Storage Interface, oder CSI 3000 Spinning Staang!

Als éischt wëll ech bemierken datt CSI net nëmmen e Volume Plugin ass, awer e richtege Standard iwwer d'Schafe vu personaliséierte Komponenten fir mat Datelager ze schaffen. Container Orchestratiounssystemer wéi Kubernetes a Mesos sollten "léiere" wéi een mat Komponenten schafft, déi no dësem Standard ëmgesat ginn. An elo hunn ech scho Kubernetes geléiert.

Wat ass d'Struktur vum CSI Plugin zu Kubernetes? Den CSI Plugin funktionnéiert mat speziellen Treiber (CSI Chauffeuren) geschriwwen vun Drëttubidder Entwéckler. E CSI Chauffer an Kubernetes soll minimal aus zwee Komponenten (Pods) besteet:

spiller - geréiert extern persistent Späicheren. Et gëtt als gRPC Server implementéiert, fir deen de Primitiv benotzt gëtt StatefulSet.
Node sinn - ass verantwortlech fir persistent Lagerung op Clusternoden ze montéieren. Et gëtt och als gRPC Server implementéiert, awer et benotzt de primitiv DaemonSet.

Wéi den CSI Plugin an Kubernetes funktionnéiert

Dir kënnt iwwer e puer aner Detailer vun der Aarbecht vum CSI léieren, zum Beispill aus dem Artikel "Den C.S.I.», Iwwersetzung vun deem mir publizéiert virun engem Joer.

D'Virdeeler vun esou enger Ëmsetzung

Fir Basis Saache wéi e Chauffer fir en Node registréieren, hunn d'Kubernetes Entwéckler eng Rei vu Container implementéiert. Dir braucht net méi eng JSON Äntwert mat Fäegkeeten selwer ze generéieren, wéi et fir de Flexvolume Plugin gemaach gouf.
Anstatt ausféierbar Dateien op Noden ze "rutschen", lued mir elo Pods an de Cluster erop. Dëst ass wat mir ufanks vu Kubernetes erwaarden: all Prozesser geschéien a Container déi mat Kubernetes Primitiv ofgesat ginn.
Dir braucht net méi en RPC Server an RPC Client z'entwéckelen fir komplex Chauffeuren ëmzesetzen. De Client gouf fir eis vun Kubernetes Entwéckler ëmgesat.
Argumenter weiderginn fir iwwer de gRPC Protokoll ze schaffen ass vill méi praktesch, flexibel an zouverlässeg wéi se duerch Kommandozeilargumenter weiderginn. Fir ze verstoen wéi Dir Ënnerstëtzung fir Volumenverbrauchsmetriken op CSI addéiere kënnt andeems Dir eng standardiséierter gRPC Method bäidréit, kënnt Dir liesen: eis Pull Ufro fir vsphere-csi Chauffer.
Kommunikatioun geschitt iwwer IPC Sockets, fir net duercherneen ze ginn, ob de Kubelet d'Ufro un de richtege Pod geschéckt huet.

Erënnert dës Lëscht Iech un eppes? D'Virdeeler vum CSI sinn déi selwecht Problemer ze léisen, déi net bei der Entwécklung vum Flexvolume Plugin berücksichtegt goufen.

Conclusiounen

CSI als Standard fir d'Ëmsetzung vun personaliséierte Plugins fir Interaktioun mat Datelager gouf ganz häerzlech vun der Gemeinschaft ugeholl. Ausserdeem, duerch hir Virdeeler a Villsäitegkeet, ginn CSI Treiber erstallt souguer fir Späichersystemer wéi Ceph oder AWS EBS, Plugins fir ze schaffen mat deenen an der alleréischter Versioun vu Kubernetes bäigefüügt goufen.

Am Ufank vum 2019, In-Baum Plugins als obsolet erkläert ginn. Mir plangen weider de Flexvolume Plugin z'ënnerstëtzen, awer wäerte keng nei Funktionalitéit dofir entwéckelen.

Mir selwer hu schonn Erfahrung mat ceph-csi, vsphere-csi a si prett fir dës Lëscht ze addéieren! Bis elo këmmert sech CSI mat den Aufgaben, déi him zougewisen sinn, mat engem Knall, awer mir waarden a gesinn.

Vergiesst net datt alles Neies e gudden Iwwerdenken vum alen ass!

PS

Liest och op eisem Blog:

Source: will.com

Volume Plugins fir Kubernetes Stockage: vu Flexvolume op CSI