Niektóre aplikacje również muszą przechowywać dane, ale są całkiem wygodne z faktem, że dane nie zostaną zapisane po ponownym uruchomieniu.
Na przykład usługi buforowania są ograniczone przez pamięć RAM, ale mogą również przenosić rzadko używane dane do pamięci wolniejszej niż pamięć RAM, z niewielkim wpływem na ogólną wydajność. Inne aplikacje muszą mieć świadomość, że w plikach mogą znajdować się dane wejściowe tylko do odczytu, takie jak ustawienia lub tajne klucze.
Kubernetes ma już kilka typów , ale ich funkcjonalność jest ograniczona do tego, co zaimplementowano w K8.
Efemeryczny umożliwiło rozszerzenie Kubernetesa o sterowniki CSI w celu zapewnienia obsługi lekkich woluminów lokalnych. W ten sposób można skorzystać : ustawienia, sekrety, dane identyfikacyjne, zmienne i tak dalej. Sterowniki CSI muszą zostać zmodyfikowane, aby obsługiwały tę funkcję Kubernetes, ponieważ nie oczekuje się, że zwykłe standardowe sterowniki będą działać, ale oczekuje się, że takich woluminów będzie można używać w dowolnym węźle wybranym dla poda.
Może to stanowić problem w przypadku woluminów zużywających znaczne zasoby hosta lub w przypadku pamięci masowej dostępnej tylko na niektórych hostach. Dlatego Kubernetes 1.19 wprowadza dwie nowe funkcje woluminów testowych alfa, które koncepcyjnie są podobne do woluminów PustegoDir:
-
tomy efemeryczne ogólnego przeznaczenia;
-
Śledzenie pojemności pamięci CSI.
Zalety nowego podejścia:
-
przechowywanie może być lokalne lub połączone za pośrednictwem sieci;
-
woluminy mogą mieć określony rozmiar, którego aplikacja nie może przekroczyć;
-
współpracuje z dowolnymi sterownikami CSI, które obsługują udostępnianie trwałych woluminów i (w celu obsługi śledzenia wydajności) implementują wywołanie
GetCapacity; -
woluminy mogą zawierać pewne dane początkowe w zależności od sterownika i ustawień;
-
obsługiwane są wszystkie standardowe operacje na woluminie (tworzenie migawki, zmiana rozmiaru itp.);
-
woluminów można używać z dowolnym kontrolerem aplikacji, który akceptuje specyfikację modułu lub woluminu;
-
Harmonogram Kubernetes sam wybiera odpowiednie węzły, więc nie ma już potrzeby udostępniania i konfigurowania rozszerzeń harmonogramu ani modyfikowania webhooków.
aplikacje
Dlatego woluminy efemeryczne ogólnego przeznaczenia nadają się do następujących zastosowań:
Pamięć trwała jako zamiennik pamięci RAM dla memcached
Najnowsze wersje memcached korzystanie z pamięci trwałej (Intel Optane itp., około. tłumacz) zamiast zwykłej pamięci RAM. Podczas wdrażania memcached za pośrednictwem kontrolera aplikacji można użyć woluminów efemerycznych ogólnego przeznaczenia, aby na przykład zażądać przydzielenia woluminu o danym rozmiarze z PMEM za pomocą sterownika CSI .
Lokalna pamięć masowa LVM jako obszar roboczy
Aplikacje współpracujące z danymi większymi niż pamięć RAM mogą wymagać lokalnego magazynu o rozmiarze lub wskaźnikach wydajności, których nie są w stanie zapewnić zwykłe woluminy DesertDir z Kubernetes. Na przykład w tym celu został napisany .
Dostęp tylko do odczytu dla woluminów danych
Alokacja woluminu może skutkować utworzeniem woluminu pełnego, gdy:
-
восстановлени ;
-
kreacja ;
-
praca .
Woluminy te można zamontować w trybie tylko do odczytu.
Jak to działa
Tomy efemeryczne ogólnego przeznaczenia
Kluczową cechą woluminów efemerycznych ogólnego przeznaczenia jest nowe źródło woluminów, EphemeralVolumeSource, zawierający wszystkie pola umożliwiające utworzenie żądania woluminu (historycznie zwanego trwałym żądaniem woluminu, PVC). Nowy kontroler w kube-controller-manager sprawdza pody, które tworzą takie źródło wolumenu, a następnie tworzy plik PVC dla tych podów. W przypadku sterownika CSI to żądanie wygląda tak samo jak pozostałe, więc nie jest tutaj potrzebne żadne specjalne wsparcie.
Dopóki takie kanały PVC istnieją, można ich używać jak innych żądań w wolumenie. W szczególności można się do nich odwoływać jako do źródła danych podczas kopiowania woluminu lub tworzenia migawki z woluminu. Obiekt PVC zawiera także bieżący stan woluminu.
Nazwy automatycznie tworzonych obwodów PVC są predefiniowane: stanowią kombinację nazwy pod i nazwy woluminu oddzielonych łącznikiem. Predefiniowane nazwy ułatwiają interakcję z PVC, ponieważ nie trzeba go szukać, jeśli znasz nazwę pod i nazwę woluminu. Minusem jest to, że nazwa może być już używana, co jest wykrywane przez Kubernetes i w rezultacie uruchomienie poda jest zablokowane.
Aby mieć pewność, że wolumin zostanie usunięty wraz z zasobnikiem, kontroler wysyła żądanie do woluminu należącego do właściciela. Po usunięciu poda działa standardowy mechanizm zbierania elementów bezużytecznych, który usuwa zarówno żądanie, jak i wolumin.
Żądania są dopasowywane przez sterownik pamięci masowej za pomocą normalnego mechanizmu klasy pamięci. Chociaż klasy z natychmiastowym i późnym wiązaniem (aka WaitForFirstConsumer) są obsługiwane, w przypadku woluminów efemerycznych sensowne jest użycie WaitForFirstConsumer, podczas wybierania węzła osoba planująca może uwzględnić zarówno wykorzystanie węzła, jak i dostępność pamięci. Pojawia się tutaj nowa funkcja.
Śledzenie pojemności pamięci
Zazwyczaj osoba planująca nie ma wiedzy o tym, gdzie sterownik CSI utworzy wolumin. Osoba planująca nie ma również możliwości bezpośredniego skontaktowania się z kierowcą w celu uzyskania tych informacji. Dlatego też program planujący odpytuje węzły, aż znajdzie taki, w którym można uzyskać dostęp do woluminów (późne wiązanie) lub pozostawia wybór lokalizacji całkowicie sterownikowi (natychmiastowe wiązanie).
nowy CSIStorageCapacity, który jest w fazie alfa, pozwala na przechowywanie niezbędnych danych w etcd, tak aby były dostępne dla planisty. W odróżnieniu od obsługi woluminów tymczasowych ogólnego przeznaczenia, podczas wdrażania sterownika należy włączyć śledzenie pojemności pamięci: external-provisioner powinien publikować informacje o przepustowości otrzymane od kierowcy w trybie normalnym GetCapacity.
Jeśli program planujący musi wybrać węzeł dla zasobnika z niepowiązanym woluminem, który korzysta z późnego wiązania, a sterownik włączył tę funkcję podczas wdrażania, ustawiając flagę CSIDriver.storageCapacity, węzły, które nie mają wystarczającej pojemności, zostaną automatycznie odrzucone. Działa to zarówno w przypadku woluminów efemerycznych, jak i trwałych ogólnego przeznaczenia, ale nie w przypadku woluminów efemerycznych CSI, ponieważ Kubernetes nie może odczytać ich parametrów.
Jak zwykle, przed zaplanowaniem podów tworzone są natychmiast połączone woluminy, a ich rozmieszczenie jest wybierane przez sterownik pamięci masowej, więc podczas konfigurowania external-provisioner Domyślnie pomijane są klasy pamięci z natychmiastowym wiązaniem, ponieważ te dane i tak nie będą używane.
Ponieważ program planujący Kubernetes jest zmuszony pracować z potencjalnie nieaktualnymi informacjami, nie ma gwarancji, że pojemność będzie dostępna w każdym przypadku podczas tworzenia woluminu, ale mimo to zwiększa się szansa, że zostanie on utworzony bez ponownych prób.
NB Możesz uzyskać bardziej szczegółowe informacje, a także bezpiecznie „poćwiczyć na stoisku dla kotów”, a w przypadku całkowicie niezrozumiałej sytuacji otrzymać wykwalifikowaną pomoc techniczną na intensywnych kursach - odbędzie się w dniach 28-30 września, a dla bardziej zaawansowanych specjalistów 14–16 października.
bezpieczeństwo
Pojemność magazynu CSIS
Obiekty CSIStorageCapacity znajdują się w przestrzeniach nazw; podczas wdrażania każdego sterownika CSI w jego własnej przestrzeni nazw zaleca się ograniczenie praw RBAC do CSIStorageCapacity w tej przestrzeni, ponieważ jest oczywiste, skąd pochodzą dane. Kubernetes i tak tego nie sprawdza, a zazwyczaj sterowniki umieszczane są w tej samej przestrzeni nazw, więc ostatecznie oczekuje się, że sterowniki będą działać i nie publikować nieprawidłowych danych (i tu zawiodła moja karta, około. tłumacz oparty na brodatym dowcipie)
Tomy efemeryczne ogólnego przeznaczenia
Jeśli użytkownicy mają uprawnienia do tworzenia podów (bezpośrednio lub pośrednio), będą mogli także tworzyć woluminy efemeryczne ogólnego przeznaczenia, nawet jeśli nie mają uprawnień do tworzenia żądań na woluminie. Dzieje się tak, ponieważ kontrole uprawnień RBAC dotyczą kontrolera tworzącego obwód PVC, a nie użytkownika. To jest główna zmiana, którą należy dodać , przed włączeniem tej funkcji w klastrach, w których niezaufani użytkownicy nie powinni mieć uprawnień do tworzenia woluminów.
Przykład
Oddzielny PMEM-CSI zawiera wszystkie niezbędne zmiany do uruchomienia klastra Kubernetes 1.19 na maszynach wirtualnych QEMU ze wszystkimi funkcjami w fazie alfa. Kod sterownika nie uległ zmianie, zmieniło się jedynie wdrożenie.
Na odpowiedniej maszynie (Linux, zwykły użytkownik może używać , Widzieć szczegóły) te polecenia wywołają klaster i zainstalują sterownik PMEM-CSI:
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
Gdy wszystko zadziała, dane wyjściowe będą zawierać instrukcje użytkowania:
The test cluster is ready. Log in with [...]/pmem-csi/_work/pmem-govm/ssh.0, run
kubectl once logged in. Alternatively, use kubectl directly with the
following env variable:
KUBECONFIG=[...]/pmem-csi/_work/pmem-govm/kube.config
secret/pmem-csi-registry-secrets created
secret/pmem-csi-node-secrets created
serviceaccount/pmem-csi-controller created
...
To try out the pmem-csi driver ephemeral volumes:
cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
[...]/pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -
Obiekty CSIStorageCapacity nie są przeznaczone do odczytu przez ludzi, dlatego wymagane jest pewne przetwarzanie. Filtry szablonów Golang pokażą klasy pamięci, ten przykład pokaże nazwę, topologię i pojemność:
$ 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
Pojedynczy obiekt ma następującą treść:
$ kubectl describe csistoragecapacities/csisc-6cw8j
Name: csisc-sqdnt
Namespace: default
Labels: <none>
Annotations: <none>
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: <none>
Spróbujmy stworzyć aplikację demonstracyjną z jednym woluminem efemerycznym ogólnego przeznaczenia. Zawartość pliku 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
Po utworzeniu zgodnie z instrukcją powyżej mamy teraz dodatkowy zasobnik i PCV:
$ 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 <none> <none>
$ 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
Właściciel PCV - 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
...
Oczekiwana aktualizacja informacji dla 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
Jeśli inna aplikacja potrzebuje więcej niż 26620Mi, harmonogram nie weźmie pod uwagę pmem-csi-pmem-govm-worker1 w każdym przypadku.
Co dalej?
Obie funkcje są wciąż w fazie rozwoju. Podczas testów alfa otwarto kilka aplikacji. Linki do propozycji ulepszeń dokumentują pracę, którą należy wykonać, aby przejść do etapu beta, a także to, które alternatywy zostały już rozważone i odrzucone:
Źródło: www.habr.com