Einigen Anwendungen ist es ebenfalls wichtig, Daten zu speichern, aber sie sind relativ gelassen, wenn diese Daten nach einem Neustart nicht erhalten bleiben.
Beispielsweise sind Caching-Dienste in Bezug auf den Arbeitsspeicher begrenzt, können aber auch Daten, die selten verwendet werden, in einen langsameren Speicher verschieben, der weniger Einfluss auf die Gesamteffizienz hat. Andere Anwendungen müssen wissen, dass in Dateien einige Daten nur lesbar sind, wie Einstellungen oder geheime Schlüssel.
In Kubernetes gibt es bereits einige Typen , aber ihre Funktionalität ist auf das beschränkt, was in K8s implementiert ist.
Flüchtige ermöglichen es, Kubernetes mit CSI-Treibern zu erweitern, um die Unterstützung von leichten lokalen Volumes zu gewährleisten. Auf diese Weise können : Einstellungen, Geheimnisse, Identifikationsdaten, Variablen und so weiter. Die CSI-Treiber müssen angepasst werden, um diese Kubernetes-Funktion zu unterstützen, da angenommen wird, dass herkömmliche standardisierte Treiber nicht funktionieren — es wird jedoch erwartet, dass solche Volumes auf jedem Knoten, der für den Pod ausgewählt wird, verwendet werden können.
Dies kann problematisch für Volumes sein, die erhebliche Ressourcen des Knotens verbrauchen oder für Speicher, der nur auf bestimmten Knoten verfügbar ist. Daher wurden in Kubernetes 1.19 zwei neue Volume-Funktionen zur Alpha-Testung eingeführt, die konzeptionell den EmptyDir-Volumes ähnlich sind:
ephemere allgemein verwendbare Volumes;
Kapazitätsverfolgung für CSI-Speicher.
Vorteile des neuen Ansatzes:
Der Speicher kann lokal oder netzwerkgebunden sein;
Volumes können eine festgelegte Größe haben, die von der Anwendung nicht überschritten werden kann;
Funktioniert mit allen CSI-Treibern, die die Bereitstellung von PersistentVolumes unterstützen und (zur Unterstützung der Kapazitätsverfolgung) den Aufruf
GetCapacity;Volumes können einige initiale Daten enthalten, abhängig vom Treiber und den Parametern;
Alle gängigen Operationen mit Volumen (Snapshot-Erstellung, Größenänderung usw.) werden unterstützt.
Volumen können mit jedem Anwendungscontroller verwendet werden, der die Modulspezifikation oder Volumenspezifikation akzeptiert.
Der Kubernetes-Planer wählt selbständig geeignete Nodes aus, wodurch die Notwendigkeit entfällt, Planerweiterungen zu verwalten und Webhooks zu ändern.
Anwendungsvarianten
Somit eignen sich ephemere Allgemeinvolumen für folgende Anwendungsvarianten:
Persistent Memory als Ersatz für den Arbeitsspeicher für memcached
Die neuesten Versionen von memcached von persistentem Speicher (Intel Optane usw., Anm. der Übersetzer) anstelle von herkömmlichem Arbeitsspeicher. Bei der Bereitstellung von memcached über einen Anwendungscontroller kann mit ephemeren Allgemeinvolumen ein Antrag auf Zuteilung eines bestimmten Volumens aus PMEM über den CSI-Treiber gestellt werden, beispielsweise .
Lokaler LVM-Speicher als Arbeitsbereich
Anwendungen, die mit Daten arbeiten, deren Größe den verfügbaren Arbeitsspeicher überschreitet, können auf einen lokalen Speicher zugreifen, dessen Größe oder Leistungsmerkmale von herkömmlichen Kubernetes EmptyDir-Volumes nicht bereitgestellt werden können. Zum Beispiel wurde dafür .
Schreibgeschützter Zugriff für Datenvolumes
Die Zuweisung eines Volumes kann zur Erstellung eines voll belegten Volumes führen bei:
Wiederherstellung ;
Erstellung ;
im Job .
Diese Volumes können im Nur-Lese-Modus gemountet werden.
Wie es funktioniert
Ephemere Volumes für allgemeine Zwecke
Ein Hauptmerkmal ephemerer Volumes für allgemeine Zwecke ist die neue Volume-Quelle, EphemeralVolumeSource, die alle Felder für die Erstellung einer Anfrage an das Volume enthält (historisch als Anfrage für ein beständiges Volume, PVC, bezeichnet). Ein neuer Controller in kube-controller-manager überwacht Pods, die eine solche Volume-Quelle erstellen, und erstellt dann ein PVC für diese Pods. Für den CSI-Treiber sieht diese Anfrage genauso aus wie die anderen, daher ist hier keine besondere Unterstützung erforderlich.
So lange es solche PVC gibt, können sie wie alle anderen Anfragen an das Volume verwendet werden. Insbesondere können sie als Datenquelle beim Kopieren eines Volumes oder beim Erstellen eines Snapshots von einem Volume dienen. Das PVC-Objekt enthält ebenfalls den aktuellen Zustand des Volumes.
Die Namen der automatisch erstellten PVCs sind vordefiniert: Es handelt sich um eine Kombination aus dem Podnamen und dem Volume-Namen, die durch einen Bindestrich getrennt sind. Diese Vordefiniertheit der Namen erleichtert die Interaktion mit PVCs, da man sie nicht suchen muss, wenn der Podnamen und der Volume-Namen bekannt sind. Ein Nachteil besteht darin, dass der Name bereits verwendet werden könnte, was von Kubernetes erkannt wird und in der Folge den Start des Pods blockiert.
Um sicherzustellen, dass das Volume zusammen mit dem Pod gelöscht wird, macht der Controller den Pod zum Besitzer der Volume-Anfrage. Wenn der Pod gelöscht wird, wird der Standardmechanismus zur Müllbeseitigung aktiviert, der sowohl die Anfrage als auch das Volume entfernt.
Anfragen werden über den üblichen Storage-Klassenmechanismus mit dem entsprechenden Speicher-Driver verknüpft. Obwohl Klassen mit sofortiger und verzögerter Bindung (auch bekannt als WaitForFirstConsumer) unterstützt werden, ist es für flüchtige Volumes sinnvoll, WaitForFirstConsumer, dann kann der Scheduler sowohl die Nutzung des Knotens als auch die Verfügbarkeit des Speichers bei der Auswahl des Knotens berücksichtigen. Hier tritt eine neue Funktion auf.
Überwachung der Speicherkapazität
Normalerweise hat der Scheduler keine Informationen darüber, wo der CSI-Treiber das Volume erstellen wird. Der Scheduler hat auch keine Möglichkeit, direkt mit dem Treiber zu kommunizieren, um diese Informationen anzufordern. Daher befragt der Scheduler die Knoten, bis er einen findet, auf dem die Volumes verfügbar sein könnten (spätere Bindung), oder überlässt die Wahl des Standorts vollständig dem Treiber (sofortige Bindung).
Neu CSIStorageCapacity, das sich im Alpha-Stadium befindet, ermöglicht die Speicherung der benötigten Daten in etcd, sodass sie dem Scheduler zur Verfügung stehen. Im Gegensatz zur Unterstützung von flüchtigen Volumes für allgemeine Zwecke muss bei der Bereitstellung des Treibers die Überwachung der Speicherkapazität aktiviert werden: external-provisioner muss die Kapazitätsinformationen veröffentlichen, die vom Treiber über die übliche GetCapacity.
Wenn der Scheduler einen Knoten für einen Pod mit einem ungebundenen Volume wählen muss, das die späte Bindung verwendet, und der Treiber beim Bereitstellen diese Funktion aktiviert hat, indem er das Flag CSIDriver.storageCapacity, werden Knoten mit unzureichendem Speicherplatz automatisch ausgeschlossen. Dies gilt sowohl für ephemere allgemeine als auch für permanente Volumes, jedoch nicht für ephemere CSI-Volumes, da deren Parameter von Kubernetes nicht ausgelesen werden können.
Wie üblich werden Volumes mit sofortiger Bindung vor der Planung von Pods erstellt, und ihre Platzierung wird vom Storage-Treiber ausgewählt, deshalb beim Setup external-provisioner werden standardmäßig Klassen mit sofortiger Bindung übersprungen, da diese Daten ohnehin nicht genutzt werden.
Da der Kubernetes-Planer gezwungen ist, mit potenziell veralteten Informationen zu arbeiten, gibt es keine Garantie, dass der Speicherplatz zum Zeitpunkt der Erstellung des Volumes verfügbar ist. Dennoch steigen die Chancen, dass es ohne erneute Versuche erstellt wird.
N.B. Für detailliertere Informationen können Sie sich außerdem sicher im „Trainingsumfeld“ ausprobieren und im Falle von komplizierten Situationen fachkundige Unterstützung vom Support während der Intensivkurse erhalten - die vom 28. bis 30. September stattfinden, und für fortgeschrittene Fachleute vom 14. bis 16. Oktober.
Sicherheit
CSIStorageCapacity
Die CSIStorageCapacity-Objekte befinden sich in Namespaces. Bei der Bereitstellung jedes CSI-Treibers wird empfohlen, die RBAC-Rechte für die CSIStorageCapacity in diesem Namespace einzuschränken, da offensichtlich ist, woher die Daten kommen. Kubernetes überprüft dies jedoch nicht, und in der Regel werden Treiber in einem einzigen Namespace installiert, sodass letztendlich erwartet wird, dass die Treiber funktionieren und keine falschen Daten veröffentlichen (und hier hatte ich Glück). Anmerkung des Übersetzers inspiriert von einem schäbigen Witz.)
Ephemere Volumes für allgemeine Zwecke
Wenn Benutzer die Berechtigungen zum Erstellen eines Pods haben (direkt oder indirekt), können sie auch flüchtige allgemeine Volumes erstellen, selbst wenn sie keine Berechtigungen zum Erstellen eines Bereitstellungsantrags haben. Das liegt daran, dass die RBAC-Berechtigungsprüfungen auf den Controller angewendet werden, der die PVC erstellt, und nicht auf den Benutzer. Dies ist die grundlegende Änderung, die hinzugefügt werden muss. , bevor diese Funktion in Clustern aktiviert wird, wenn unzuverlässige Benutzer keine Berechtigung zum Erstellen von Volumes haben sollen.
Beispiel
Einzelne PMEM-CSI enthält alle erforderlichen Änderungen zum Starten eines Kubernetes 1.19 Clusters innerhalb von QEMU virtuellen Maschinen mit allen Funktionen, die sich in der Alpha-Phase befinden. Der Treibercode wurde nicht verändert, lediglich die Bereitstellung wurde angepasst.
Auf einem geeigneten Gerät (Linux, ein normaler Benutzer kann verwenden , siehe Details) werden diese Befehle den Cluster hochfahren und den PMEM-CSI-Treiber installieren:
git clone --branch=kubernetes-1-19-blog-post https://github.com/intel/pmem-csi.git
cd pmem-csi
export TEST_KUBERNETES_VERSION=1.19 TEST_FEATURE_GATES=CSIStorageCapacity=true,GenericEphemeralVolume=true TEST_PMEM_REGISTRY=intel
make start && echo && test/setup-deployment.sh
Sobald alles funktioniert, enthält die Ausgabe Anweisungen zur Nutzung:
Der Testcluster ist bereit. Melden Sie sich an mit [...]/pmem-csi/_work/pmem-govm/ssh.0 und führen Sie
kubectl aus, sobald Sie angemeldet sind. Alternativ können Sie kubectl direkt mit der
folgendem Umgebungsvariable verwenden:
KUBECONFIG=[...]/pmem-csi/_work/pmem-govm/kube.config
secret/pmem-csi-registry-secrets erstellt
secret/pmem-csi-node-secrets erstellt
serviceaccount/pmem-csi-controller erstellt
...
Um die ephemeral Volumes des pmem-csi Treibers auszuprobieren:
cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
[...]/pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -
Die Objekte CSIStorageCapacity sind nicht für menschliches Lesen gedacht, daher ist eine Verarbeitung erforderlich. Mit Hilfe von Template-Filtern in Golang werden die Speicherklassen angezeigt, in diesem Beispiel werden Name, Topologie und Kapazität angezeigt:
$ kubectl get
-o go-template='{{range .items}}{{if eq .storageClassName "pmem-csi-sc-late-binding"}}{{.metadata.name}} {{.nodeTopology.matchLabels}} {{.capacity}}
{{end}}{{end}}'
csistoragecapacities
csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 30716Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi
Ein einzelnes Objekt hat den folgenden Inhalt:
$ kubectl describe csistoragecapacities/csisc-6cw8j
Name: csisc-sqdnt
Namespace: default
Labels:
Annotations:
API Version: storage.k8s.io/v1alpha1
Capacity: 30716Mi
Kind: CSIStorageCapacity
Metadata:
Creation Timestamp: 2020-08-11T15:41:03Z
Generate Name: csisc-
Managed Fields:
...
Owner References:
API Version: apps/v1
Controller: true
Kind: StatefulSet
Name: pmem-csi-controller
UID: 590237f9-1eb4-4208-b37b-5f7eab4597d1
Resource Version: 2994
Self Link: /apis/storage.k8s.io/v1alpha1/namespaces/default/csistoragecapacities/csisc-sqdnt
UID: da36215b-3b9d-404a-a4c7-3f1c3502ab13
Node Topology:
Match Labels:
pmem-csi.intel.com/node: pmem-csi-pmem-govm-worker1
Storage Class Name: pmem-csi-sc-late-binding
Events:
Lassen Sie uns versuchen, eine Demo-Anwendung mit einem ephemeral Persistent Volume zu erstellen. Der Inhalt der Datei pmem-app-ephemeral.yaml:
# This example Pod definition demonstrates
# how to use generic ephemeral inline volumes
# with a PMEM-CSI storage class.
kind: Pod
apiVersion: v1
metadata:
name: my-csi-app-inline-volume
spec:
containers:
- name: my-frontend
image: intel/pmem-csi-driver-test:v0.7.14
command: [ "sleep", "100000" ]
volumeMounts:
- mountPath: "/data"
name: my-csi-volume
volumes:
- name: my-csi-volume
ephemeral:
volumeClaimTemplate:
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 4Gi
storageClassName: pmem-csi-sc-late-binding
Nachdem wir wie oben beschrieben erstellt haben, haben wir einen zusätzlichen Pod und PVC erhalten:
$ kubectl get pods/my-csi-app-inline-volume -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
my-csi-app-inline-volume 1/1 Running 0 6m58s 10.36.0.2 pmem-csi-pmem-govm-worker1
$ kubectl get pvc/my-csi-app-inline-volume-my-csi-volume
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
my-csi-app-inline-volume-my-csi-volume Bound pvc-c11eb7ab-a4fa-46fe-b515-b366be908823 4Gi RWO pmem-csi-sc-late-binding 9m21s
Besitzer des PVC — Pod:
$ kubectl get -o yaml pvc/my-csi-app-inline-volume-my-csi-volume
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
annotations:
pv.kubernetes.io/bind-completed: "yes"
pv.kubernetes.io/bound-by-controller: "yes"
volume.beta.kubernetes.io/storage-provisioner: pmem-csi.intel.com
volume.kubernetes.io/selected-node: pmem-csi-pmem-govm-worker1
creationTimestamp: "2020-08-11T15:44:57Z"
finalizers:
- kubernetes.io/pvc-protection
managedFields:
...
name: my-csi-app-inline-volume-my-csi-volume
namespace: default
ownerReferences:
- apiVersion: v1
blockOwnerDeletion: true
controller: true
kind: Pod
name: my-csi-app-inline-volume
uid: 75c925bf-ca8e-441a-ac67-f190b7a2265f
...
Die Informationen für die erwartete Aktualisierung pmem-csi-pmem-govm-worker1:
csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 26620Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi
Wenn eine andere Anwendung mehr als 26620Mi benötigt, wird der Scheduler dies nicht berücksichtigen pmem-csi-pmem-govm-worker1 unter allen Umständen.
Wie geht es weiter?
Beide Funktionen befinden sich noch in der Entwicklung. Mehrere Anfragen wurden während der Alpha-Testphase eröffnet. Über Links mit Verbesserungsvorschlägen wird dokumentiert, welche Arbeiten erforderlich sind, um in die Beta-Phase zu übergehen und welche Alternativen bereits geprüft und abgelehnt wurden:
Quelle: habr.com
