Einige Anwendungen müssen ebenfalls Daten speichern, sind jedoch damit einverstanden, dass die Daten nach einem Neustart nicht mehr vorhanden sind.
Zum Beispiel sind Caching-Dienste in Bezug auf den Arbeitsspeicher begrenzt, können jedoch Daten, die selten verwendet werden, in langsamer arbeitende Speicher verschieben, ohne die Gesamtleistung stark zu beeinträchtigen. Andere Anwendungen müssen wissen, dass in den Dateien einige Eingabedaten nur zum Lesen vorhanden sein können, wie z.B. Einstellungen oder geheime Schlüssel.
In Kubernetes gibt es bereits mehrere Typen , deren Funktionalität jedoch durch das, was in K8s implementiert ist, begrenzt ist.
Ephemerale haben es ermöglicht, Kubernetes mithilfe von CSI-Treibern zu erweitern, um die Unterstützung von leichten lokalen Volumes bereitzustellen. Auf diese Weise ist es möglich, : Einstellungen, Geheimnisse, Identifikationsdaten, Variablen usw. CSI-Treiber müssen für diese Funktion von Kubernetes angepasst werden, da angenommen wird, dass herkömmliche standardisierte Treiber nicht funktionieren werden – es wird jedoch davon ausgegangen, dass solche Volumes auf jedem Knoten genutzt werden können, der für den Pod ausgewählt wird.
Dies kann problematisch sein für Volumes mit hohem Ressourcenverbrauch auf dem Knoten oder für Speicher, der nur auf einigen Knoten verfügbar ist. Daher wurden in Kubernetes 1.19 zwei neue volumetrische Funktionen zur Alpha-Testung eingeführt, die konzeptionell ähnlich wie EmptyDir-Volumes sind:
allgemeine ephemerale Volumes;
Überwachung der Speicher-Kapazität von CSI.
Die Vorteile des neuen Ansatzes:
Der Speicher kann lokal oder netzwerkgebunden sein;
Volumes können eine bestimmte Größe haben, die von der Anwendung nicht überschritten werden kann;
funktioniert mit allen CSI-Treibern, die die Bereitstellung von persistenten Volumes unterstützen und (zur Unterstützung der Überwachung der Kapazität) den Aufruf
GetCapacity;Volumes können einige anfängliche Daten haben, abhängig von den Treibern und Parametern;
alle typischen Volume-Operationen (z.B. Snapshot-Erstellung, Größenänderung usw.) werden unterstützt;
Volumes können mit jedem Anwendungscontroller verwendet werden, der die Spezifikation des Moduls oder Volumes annimmt;
Der Kubernetes-Planer wählt selbst geeignete Knoten aus, sodass das Bereitstellen und Konfigurieren von Planerweiterungen sowie das Ändern von Webhooks nicht mehr erforderlich ist.
Einsatzmöglichkeiten
Somit sind ephemeral Volumes für folgende Anwendungen geeignet:
Persistente Speicher als Ersatz für den Arbeitsspeicher bei Memcached
Neueste Versionen von Memcached für den Einsatz von persistentem Speicher (Intel Optane usw., Anm. des Übersetzers) anstelle von gewöhnlichem Arbeitsspeicher. Bei der Bereitstellung von Memcached über einen Anwendungscontroller kann man mit Hilfe von ephemeral Volumes eine Anfrage zur Zuteilung eines Volumes in einer bestimmten Größe aus PMEM über den CSI-Treiber stellen, beispielsweise .
Lokaler Speicher LVM als Arbeitsbereich
Anwendungen, die mit Daten arbeiten, deren Größe den Arbeitsspeicher übersteigt, können lokalen Speicher mit Größen oder Leistungsmetriken anfordern, die von regulären Kubernetes-Volumes (EmptyDir) nicht bereitgestellt werden können. Beispielsweise wurde dafür .
Nur-Lese-Zugriff für Datenvolumes
Die Zuweisung eines Volumes kann zur Erstellung eines gefüllten Volumes führen, wenn:
eine Wiederherstellung ;
eine Kopie des Volumes ;
Arbeit .
Ephemeral Volumes für allgemeine Zwecke
Die DANE-Spezifikation ist in
Ein Hauptmerkmal von ephemeral Volumes für allgemeine Zwecke ist die neue Volume-Quelle,
EphemeralVolumeSource , die alle Felder für eine Anfrage an das Volume enthält (historisch als Anfrage für ein persistentes Volume, PVC, bezeichnet). Ein neuer Controller imkube-controller-manager überwacht die Pods, die eine solche Volume-Quelle erstellen, und erstellt dann PVCs für diese Pods. Für den CSI-Treiber sieht diese Anfrage genauso aus wie andere, daher ist hier keine spezielle Unterstützung erforderlich. Solange solche PVCs existieren, können sie wie jede andere Volumenanfrage verwendet werden. Insbesondere können sie als Datenquelle beim Kopieren eines Volumes oder beim Erstellen eines Snapshots von einem Volume referenziert werden. Das PVC-Objekt enthält ebenfalls den aktuellen Status des Volumes.
Solange solche PVC existieren, können sie wie jede andere Abfrage auf dem verwendet werden. Insbesondere können sie als Datenquelle beim Kopieren des Volumes oder beim Erstellen eines Snapshots von dem Volumen dienen. Das PVC-Objekt enthält auch den aktuellen Zustand des Volumes.
Die Namen der automatisch erstellten PVC sind vordefiniert: es handelt sich um eine Kombination aus dem Pod-Namen und dem Volumen-Namen, die durch einen Bindestrich getrennt sind. Diese Vordefiniertheit der Namen erleichtert die Interaktion mit PVC, da man es nicht suchen muss, wenn der Pod-Namen und der Volumen-Namen bekannt sind. Ein Nachteil ist, dass der Name bereits verwendet worden sein kann, was von Kubernetes festgestellt wird und dazu führt, dass der Pod-Start blockiert wird.
Um sicherzustellen, dass das Volumen zusammen mit dem Pod gelöscht wird, macht der Controller den Pod zum Eigentümer des Volumen-Antrags. Wenn der Pod gelöscht wird, wird der normale Garbage-Collection-Mechanismus aktiviert, der sowohl den Antrag als auch das Volumen löscht.
Anträgen wird über einen normalen Mechanismus der Speicherklasse der Speicher-Driver zugeordnet. Obwohl Klassen mit sofortiger und späterer Bindung (d.h. WaitForFirstConsumer) unterstützt werden, macht es für flüchtige Volumen Sinn, 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 kommt eine neue Funktion ins Spiel.
Überwachung der Speicher-Kapazität
Normalerweise hat der Scheduler keine Informationen darüber, wo der CSI-Driver das Volumen erstellen wird. Der Scheduler hat auch keine Möglichkeit, direkt mit dem Driver zu kommunizieren, um diese Informationen abzurufen. Daher fragt der Scheduler die Knoten ab, bis er einen findet, bei dem die Volumen verfügbar sein können (spätere Bindung) oder er überlässt die Standortwahl vollständig dem Driver (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 flüchtiger Volumen mit allgemeinem Zweck muss bei der Bereitstellung des Drivers die Überwachung der Speicher-Kapazität aktiviert werden: external-provisioner muss Informationen über die Kapazität veröffentlichen, die vom Driver über eine gängige GetCapacity.
Wenn der Scheduler einen Knoten für einen Pod mit einem nicht zugeordneten Volumen auswählen muss, das spätere Bindung verwendet und der Driver bei seiner Bereitstellung diese Funktion aktiviert hat, indem er das Flag CSIDriver.storageCapacity, dann werden automatisch Knoten abgelehnt, die nicht über ausreichend Speicher-Kapazität verfügen. Dies funktioniert sowohl für flüchtige Volumen mit allgemeinem Zweck als auch für permanente Volumen, jedoch nicht für flüchtige CSI-Volumen, da deren Parameter von Kubernetes nicht ausgelesen werden können.
Wie üblich werden Volumes mit sofortiger Bindung vor der Pod-Planung erstellt, und ihre Platzierung wird vom Speicherdreiber ausgewählt, weshalb bei der Konfiguration external-provisioner standardmäßig Speicherungsklassen mit sofortiger Bindung übersprungen werden, da diese Daten ohnehin nicht verwendet werden.
Da der Kubernetes-Planer gezwungen ist, mit potenziell veralteten Informationen zu arbeiten, gibt es keine Garantie, dass die Kapazität in jedem Fall verfügbar sein wird, wenn das Volume erstellt wird. Dennoch erhöhen sich die Chancen, dass es ohne Wiederholungsversuche erstellt wird.
N.B. Weitere Informationen erhalten Sie, und können sicher im "Katze-auf-dem-Ständer-trainieren"-Modus üben, und im Falle einer unklaren Situation qualifizierte Hilfe vom technischen 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 Objekte CSIStorageCapacity befinden sich in Namensräumen. Beim Bereitstellen jedes CSI-Treibers in seinem eigenen Namensraum wird empfohlen, die RBAC-Rechte für CSIStorageCapacity in diesem Namensraum einzuschränken, da offensichtlich ist, woher die Daten stammen. In jedem Fall überprüft Kubernetes dies nicht, und normalerweise werden Treiber in einem Namensraum installiert, sodass letztlich erwartet wird, dass die Treiber funktionieren und keine falschen Daten veröffentlicht werden (und hier bin ich vom Thema abgekommen, Anmerkung des Übersetzers inspiriert von einem alten Witz)
Ein Hauptmerkmal von ephemeral Volumes für allgemeine Zwecke ist die neue Volume-Quelle,
Wenn Benutzer die Berechtigungen haben, um einen Pod zu erstellen (direkt oder indirekt) — können sie auch temporäre allgemein verwendbare Volumes erstellen, selbst wenn sie keine Berechtigung haben, eine Anfrage für ein Volume zu erstellen. Das liegt daran, dass die RBAC-Rechtsprüfungen auf den Controller angewendet werden, der das 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 Berechtigungen zum Erstellen von Volumes haben sollen.
Beispiel
Eine separate in PMEM-CSI enthält alle notwendigen Änderungen, um einen Kubernetes-Cluster 1.19 innerhalb von QEMU-VMs mit allen Funktionen, die sich im Alpha-Stadium befinden, zu betreiben. Der Treibercode wurde nicht geändert, nur das Deployment wurde angepasst.
Auf einem geeigneten Rechner (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
Nachdem alles funktioniert hat, wird die Ausgabe Anleitungen zur Verwendung enthalten:
Der Testcluster ist bereit. Melden Sie sich mit [...]\/pmem-csi\/work\/pmem-govm\/ssh.0 an und führen
kubectl nach dem Einloggen aus. Alternativ können Sie kubectl direkt mit der
folgenden Umgebungsvariablen 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 den pmem-csi-Treiber für efemere Volumes auszuprobieren:
cat deploy\/kubernetes-1.19\/pmem-app-ephemeral.yaml |
[...]\/pmem-csi\/work\/pmem-govm\/ssh.0 kubectl create -f -
Objekte vom Typ CSIStorageCapacity sind nicht für die menschliche Lesbarkeit 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
Kapazität: 30716Mi
Art: CSIStorageCapacity
Metadaten:
Erstellungszeitpunkt: 2020-08-11T15:41:03Z
Erzeugter Name: csisc-
Verwaltete Felder:
...
Eigentümerreferenzen:
API Version: apps\/v1
Controller: true
Art: StatefulSet
Name: pmem-csi-controller
UID: 590237f9-1eb4-4208-b37b-5f7eab4597d1
Ressourcen Version: 2994
Selbstlink: \/apis\/storage.k8s.io\/v1alpha1\/namespaces\/default\/csistoragecapacities\/csisc-sqdnt
UID: da36215b-3b9d-404a-a4c7-3f1c3502ab13
Knotentopologie:
Übereinstimmende Labels:
pmem-csi.intel.com/node: pmem-csi-pmem-govm-worker1
Speicherklassename: pmem-csi-sc-late-binding
Ereignisse:
Lassen Sie uns versuchen, eine Demonstrationsanwendung mit einem efemeren allgemeinen 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
Nach der Erstellung, wie oben in der Anleitung gezeigt, 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 KAPAZITÄT ZUGRIFFSMODI SPEICHERKLASSE ALTER
my-csi-app-inline-volume-my-csi-volume Bound pvc-c11eb7ab-a4fa-46fe-b515-b366be908823 4Gi RWO pmem-csi-sc-late-binding 9m21s
Der Eigentümer des PVC ist der 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: "ja"
pv.kubernetes.io/bound-by-controller: "ja"
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 wurden wie erwartet aktualisiert 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.
Was folgt jetzt?
Beide Funktionen sind noch in der Entwicklung. Es wurden mehrere Anfragen während der Alpha-Testphase geöffnet. Die Links zu den Verbesserungsvorschlägen dokumentieren die Arbeiten, die erforderlich sind, um in die Beta-Phase überzugehen, sowie welche Alternativen bereits geprüft und abgelehnt wurden:
Quelle: habr.com
