Można skonfigurować przechowywanie danych aplikacji uruchomionych w klastrze Kubernetes na kilka sposobów. Niektóre z nich są już nieaktualne, inne pojawiły się całkiem niedawno. W tym artykule omówimy koncepcję trzech sposobów podłączenia pamięci masowej, w tym najnowszy — podłączenie przez Container Storage Interface.
Sposób 1. Określenie PV w manifeście poda
Typowy manifest opisujący pod w klastrze Kubernetes:
Części manifestu, gdzie opisano, który wolumin jest podłączany i gdzie, są wyróżnione kolorem.
W sekcji volumeMounts określa się punkty montowania (mountPath) — do jakiego katalogu wewnątrz kontenera będzie montowany trwały wolumin, a także nazwę woluminu.
W sekcji x wymienia się wszystkie woluminy używane w podzie. Określa się nazwę każdego woluminu, a także typ (w naszym przypadku: awsElasticBlockStore) i parametry podłączenia. Jakie konkretnie parametry są wymieniane w manifeście, zależy od typu woluminu.
Ten sam wolumin może być zamontowany jednocześnie w kilku kontenerach poda. Dzięki temu różne procesy aplikacji mogą mieć dostęp do tych samych danych.
Ten sposób podłączenia wymyślono na samym początku, kiedy Kubernetes dopiero powstawał, i jest już przestarzały.
Podczas jego użycia pojawia się kilka problemów:
- wszystkie woluminy muszą być tworzone ręcznie, Kubernetes nie będzie mógł nic stworzyć za nas;
- parametry dostępu do każdego z woluminów są unikalne i muszą być podawane w manifestach wszystkich podów, które korzystają z woluminu;
- aby zmienić system pamięci masowej (na przykład przenieść się z AWS do Google Cloud), trzeba zmienić ustawienia i typ podłączonych woluminów we wszystkich manifestach.
Wszystko to jest bardzo niewygodne, dlatego w rzeczywistości ten sposób jest używany tylko do podłączenia niektórych specjalnych typów woluminów: configMap, secret, emptyDir, hostPath:
configMap i secret — to woluminy systemowe, pozwalają stworzyć w kontenerze wolumin z plikami z manifestów Kubernetes.
emptyDir — to tymczasowy wolumin, tworzony tylko na czas życia poda. Wygodnie jest go używać do testowania lub przechowywania danych tymczasowych. Gdy pod zostanie usunięty, wolumin typu emptyDir także zostaje usunięty, a wszystkie dane znikają.
hostPath — umożliwia zamontowanie dowolnego katalogu lokalnego dysku serwera, na którym działa aplikacja, wewnątrz kontenera aplikacji, w tym /etc/kubernetes. Jest to niebezpieczna funkcja, dlatego zwykle polityki bezpieczeństwa zabraniają używania woluminów tego typu. W przeciwnym razie aplikacja hakerów może zamontować katalog HTC Kubernetes wewnątrz swojego kontenera i ukraść wszystkie certyfikaty klastra. Zazwyczaj woluminy hostPath mogą być używane tylko przez aplikacje systemowe, które uruchamiają się w przestrzeni nazw kube-system.
są opisane w dokumentacji.
Sposób 2. Połączenie z podami SC/PVC/PV
Alternatywnym sposobem połączenia jest koncepcja klasy pamięci masowej, PersistentVolumeClaim, PersistentVolume.
Klasa pamięci masowej przechowuje parametry połączenia z systemem przechowywania danych.
PersistentVolumeClaim opisuje wymagania dotyczące woluminu, który jest potrzebny aplikacji.
PersistentVolume przechowuje parametry dostępu i statusu woluminu.
Idea polega na tym, że w manifeście poda wskazują wolumin typu PersistentVolumeClaim i podają nazwę tej jednostki w parametrze claimName.
W manifeście PersistentVolumeClaim opisują wymagania dotyczące woluminu danych, który jest potrzebny aplikacji. W tym m.in.:
- rozmiar dysku;
- sposób dostępu: ReadWriteOnce lub ReadWriteMany;
- odniesienie do klasy pamięci masowej — w jakim systemie przechowywania danych chcemy stworzyć wolumin.
W manifeście klasy pamięci masowej przechowywane są typ i parametry połączenia z systemem przechowywania danych. Są one potrzebne kubeletowi, aby zamontować wolumin do siebie na węzeł.
W manifestach PersistentVolume wskazywana jest klasa pamięci masowej i parametry dostępu do konkretnego woluminu (ID woluminu, ścieżka itd.).
Tworząc PVC, Kubernetes sprawdza, jaki wolumin i z jakiej klasy pamięci masowej jest potrzebny, i dobiera dostępny PersistentVolume.
Jeśli nie ma dostępnych PV, Kubernetes może uruchomić specjalny program — Provisioner (jego nazwę wskazuje się w klasie pamięci masowej). Program ten łączy się z systemem przechowywania, tworzy wolumin potrzebnego rozmiaru, uzyskuje identyfikator i tworzy w klastrze Kubernetes manifest PersistentVolume, który jest powiązany z PersistentVolumeClaim.
Wszystkie te abstrakcje pozwalają usunąć informacje o tym, z jakim systemem przechowywania działa aplikacja, z poziomu manifestu aplikacji do poziomu administracji.
Wszystkie parametry połączenia z systemem przechowywania danych znajdują się w klasie przechowywania, za którą odpowiadają administratorzy klastra. Wszystko, co trzeba zrobić przy migracji z AWS do Google Cloud, to zmienić nazwę klasy przechowywania w PVC w manifestach aplikacji. Wolumeny persystencji dla przechowywania danych zostaną automatycznie utworzone w klastrze za pomocą programu Provisioner.
Metoda 3. Interfejs przechowywania kontenerów
Cały kod, który współdziała z różnymi systemami przechowywania danych, jest częścią jądra Kubernetes. Wydania poprawek błędów lub nowej funkcjonalności są związane z nowymi wersjami, więc kod musi być zmieniany dla wszystkich wspieranych wersji Kubernetes. Cały ten proces jest trudny do utrzymania i dodawania nowej funkcjonalności.
Aby rozwiązać problem, deweloperzy z Cloud Foundry, Kubernetes, Mesos i Docker stworzyli Interfejs przechowywania kontenerów (CSI) — prosty, zunifikowany interfejs, który opisuje interakcję systemu zarządzania kontenerami z konkretnego sterownika (CSI Driver) pracującego z danym systemem przechowywania. Cały kod dotyczący interakcji z systemem przechowywania został wyodrębniony z jądra Kubernetes do osobnego systemu.
.
Zwykle sterownik CSI składa się z dwóch komponentów: Node Plugin i Controller Plugin.
Node Plugin jest uruchamiany na każdym węźle i odpowiada za montowanie wolumenów oraz operacje na nich. Controller Plugin współdziała z systemem przechowywania: tworzy lub usuwa wolumeny, przyznaje prawa dostępu itp.
W jądra Kubernetes pozostają stare sterowniki, ale ich użycie nie jest już zalecane, i wszystkim radzi się instalację sterownika CSI specyficznego dla systemu, z którym mają pracować.
Nowość może przerazić tych, którzy przyzwyczaili się do konfigurowania przechowywania danych przez klasę przechowywania, ale tak naprawdę nic strasznego się nie wydarzyło. Dla programistów nic się nie zmienia — będą nadal pracować tylko z nazwą klasy przechowywania. Dla administratorów pojawiła się instalacja helm chart oraz zmieniła się struktura ustawień. Jeśli wcześniej ustawienia wprowadzano bezpośrednio w klasie przechowywania, to teraz najpierw trzeba je zdefiniować w helm chart, a potem dopiero w klasie przechowywania. Po zrozumieniu, nic strasznego się nie wydarzyło.
Rozważmy na przykładzie, jakie korzyści można uzyskać, przechodząc na połączenie systemu przechowywania Ceph za pomocą sterownika CSI.
Przy pracy z Ceph wtyczka CSI oferuje więcej możliwości pracy z systemem przechowywania niż wbudowane sterowniki.
- Dynamiczne tworzenie dysków. Zazwyczaj dyski RBD są używane tylko w trybie RWO, podczas gdy CSI dla Ceph pozwala na ich użycie w trybie RWX. Kilka pod’ów na różnych węzłach może zamontować ten sam dysk RBD i pracować z nim równolegle. Słusznie należy jednak dodać, że ten dysk można podłączyć tylko jako urządzenie blokowe, co oznacza, że trzeba dostosować aplikację do pracy z nim w trybie dostępu wielokrotnego.
- Tworzenie migawki. W klastrze Kubernetes można stworzyć manifest z wymaganiem utworzenia migawki. Wtyczka CSI ją zobaczy i stworzy migawkę z dysku. Na jej podstawie będzie można zrobić kopię zapasową lub kopię PersistentVolume.
- Zwiększenie rozmiaru dysku na macierzy dyskowej i PersistentVolume w klastrze Kubernetes.
- Kwoty. Wbudowane w Kubernetes sterowniki CephFS nie obsługują kwot, a nowe wtyczki CSI z nowym Ceph Nautilus potrafią włączyć kwoty na partycjach CephFS.
- Metryki. Wtyczka CSI może dostarczać do Prometheus wiele metryk dotyczących tego, jakie wolumeny są podłączone, jakie są interakcje itp.
- Świadomość topologii. Pozwala określić w manifestach, jak geograficznie rozmieszczony jest klaster, i unikać łączenia do podów uruchomionych w Londynie z systemem pamięci masowej znajdującym się w Amsterdamie.
Jak podłączyć Ceph do klastra Kubernetes przez CSI, zobacz . Można również zapisać się na , który rozpocznie się 15 października.
Autor artykułu: Sergey Bondarev, praktykujący architekt w Southbridge, Certyfikowany Administrator Kubernetes, jeden z twórców kubespray.
Trochę Post Scriptum dla korzyści, a nie reklamy…
P.S. Sergey Bondarev prowadzi dwa intensywy: zaktualizowany 28-30 września i zaawansowany 14-16 października.
Źródło: habr.com
