Istnieje kilka sposobów konfiguracji magazynu danych dla aplikacji działających w klastrze Kubernetes. Niektóre z nich są już przestarzałe, inne pojawiły się całkiem niedawno. W tym artykule przyjrzymy się koncepcji trzech opcji łączenia systemów magazynowych, w tym najnowszego - połączenia poprzez interfejs Container Storage.
Metoda 1: Określ PV w manifeście pod
Typowy manifest opisujący pod w klastrze Kubernetes:
Części manifestu opisujące, który wolumen jest podłączony i gdzie, są wyróżnione kolorem.
W sekcji głośnośćMocowania wskaż punkty montowania (mountPath) - w którym katalogu wewnątrz kontenera zostanie zamontowany wolumin stały, a także nazwę woluminu.
W sekcji x wyświetla listę wszystkich woluminów używanych w zasobniku. Podaj nazwę każdego woluminu, a także typ (w naszym przypadku: awsElasticBlockStore) i parametry połączenia. To, które parametry są wymienione w manifeście, zależy od typu woluminu.
Tę samą objętość można zamontować jednocześnie w wielu pojemnikach na kapsuły. W ten sposób różne procesy aplikacji mogą uzyskać dostęp do tych samych danych.
Ta metoda połączenia została wynaleziona na samym początku, gdy Kubernetes był dopiero w powijakach, a dziś metoda jest już przestarzała.
Używanie go wiąże się z kilkoma problemami:
- wszystkie woluminy trzeba utworzyć ręcznie, Kubernetes nie może nic za nas stworzyć;
- parametry dostępu dla każdego woluminu są unikalne i muszą być określone w manifeście wszystkich podów korzystających z woluminu;
- aby zmienić system przechowywania (na przykład przejść z AWS do Google Cloud), musisz zmienić ustawienia i typ zamontowanych woluminów we wszystkich manifestach.
Wszystko to jest bardzo niewygodne, więc w rzeczywistości ta metoda służy do łączenia tylko niektórych specjalnych typów woluminów: configMap, secret, pustyDir, hostPath:
-
configMap i secret to woluminy usług, które umożliwiają utworzenie woluminu z plikami z manifestów Kubernetes w kontenerze.
-
pustyDir to wolumin tymczasowy, tworzony tylko na czas życia poda. Wygodny w użyciu do testowania lub przechowywania danych tymczasowych. Po usunięciu poda wolumin pustyDir również zostanie usunięty, a wszystkie dane zostaną utracone.
-
hostPath - umożliwia zamontowanie dowolnego katalogu na dysku lokalnym serwera, na którym działa aplikacja, wewnątrz kontenera z aplikacją, w tym /etc/kubernetes. Jest to niebezpieczna funkcja, dlatego zasady bezpieczeństwa zazwyczaj zabraniają używania woluminów tego typu. W przeciwnym razie aplikacja atakującego będzie mogła zamontować katalog HTC Kubernetes w swoim kontenerze i ukraść wszystkie certyfikaty klastra. Zazwyczaj woluminy hostPath mogą być używane tylko przez aplikacje systemowe działające w przestrzeni nazw kube-system.
podane są w dokumentacji.
Metoda 2. Podłączenie do palenisk SC/PVC/PV
Alternatywną metodą połączenia jest koncepcja klasy Storage, PersistentVolumeClaim, PersistentVolume.
Klasa pamięci przechowuje parametry połączenia z systemem przechowywania danych.
Trwałe roszczenie dotyczące wolumenu opisuje wymagania dotyczące potrzeb aplikacji.
Trwała objętość przechowuje parametry dostępu i status woluminu.
Istota pomysłu: w manifeście pod wskazują wolumen typu PersistentVolumeClaim i wskazują nazwę tej jednostki w parametrze ClaimName.
Manifest PersistentVolumeClaim opisuje wymagania dotyczące ilości danych wymaganych przez aplikację. W tym:
- rozmiar dysku;
- metoda dostępu: ReadWriteOnce lub ReadWriteMany;
- link do klasy Storage - w jakim systemie przechowywania danych chcemy utworzyć wolumen.
Manifest klasy Storage przechowuje typ i parametry połączenia z systemem pamięci masowej. Kostkalet potrzebuje ich do zamontowania woluminu na swoim węźle.
Manifesty PersistentVolume wskazują klasę magazynu i parametry dostępu dla określonego woluminu (identyfikator woluminu, ścieżka itp.).
Podczas tworzenia obwodu PVC Kubernetes sprawdza, jaki rozmiar woluminu i jaka klasa pamięci jest wymagana, a następnie wybiera wolny wolumen PersistentVolume.
Jeżeli takie PV nie są dostępne, Kubernetes może uruchomić specjalny program – Provisioner (jego nazwa jest podana w klasie Storage). Program ten łączy się z systemem Storage, tworzy wolumen o wymaganej wielkości, odbiera identyfikator i tworzy manifest PersistentVolume w klastrze Kubernetes, który jest powiązany z PersistentVolumeClaim.
Cały ten zestaw abstrakcji pozwala na usunięcie informacji o tym, z jakim systemem przechowywania danych współpracuje aplikacja, z poziomu manifestu aplikacji na poziom administracyjny.
Wszystkie parametry umożliwiające połączenie z systemem przechowywania danych znajdują się w klasie Storage, za którą odpowiadają administratorzy klastra. Jedyne, co musisz zrobić w przypadku przejścia z AWS do Google Cloud, to zmienić w manifeście aplikacji nazwę klasy Storage na PVC. Wolumin trwały do przechowywania danych zostanie utworzony w klastrze automatycznie przy użyciu programu Provisioner.
Metoda 3: Interfejs przechowywania kontenerów
Cały kod współpracujący z różnymi systemami pamięci masowej jest częścią rdzenia Kubernetes. Wydanie poprawek błędów lub nowej funkcjonalności jest powiązane z nowymi wydaniami; kod musi zostać zmieniony dla wszystkich obsługiwanych wersji Kubernetes. Wszystko to jest trudne w utrzymaniu i dodaniu nowych funkcjonalności.
Aby rozwiązać problem, programiści z Cloud Foundry, Kubernetes, Mesos i Docker stworzyli Container Storage Interface (CSI) – prosty, ujednolicony interfejs opisujący interakcję systemu zarządzania kontenerami oraz specjalnego sterownika (CSI Driver) współpracującego z konkretnym System magazynowania. Cały kod interakcji z systemami pamięci masowej został przeniesiony z rdzenia Kubernetes do osobnego systemu.
.
Zazwyczaj sterownik CSI składa się z dwóch komponentów: wtyczki węzła i wtyczki kontrolera.
Wtyczka Node działa na każdym węźle i odpowiada za montowanie woluminów i wykonywanie na nich operacji. Wtyczka Controller współdziała z systemem przechowywania: tworzy lub usuwa woluminy, przypisuje prawa dostępu itp.
Na razie stare sterowniki pozostają w jądrze Kubernetesa, jednak nie jest już zalecane ich używanie i każdemu zaleca się zainstalowanie sterownika CSI specjalnie pod system, z którym będą współpracować.
Innowacja może przestraszyć tych, którzy są już przyzwyczajeni do konfigurowania przechowywania danych poprzez klasę Storage, ale tak naprawdę nie wydarzyło się nic strasznego. Dla programistów tak naprawdę nic się nie zmienia – pracowali tylko z nazwą Storage class i nadal będą to robić. Dla administratorów dodano instalację mapy steru i zmieniono strukturę ustawień. Jeśli wcześniej ustawienia były wprowadzane bezpośrednio do klasy Storage, teraz należy je ustawić najpierw w schemacie steru, a następnie w klasie Storage. Jeśli się temu przyjrzeć, nic złego się nie wydarzyło.
Weźmy przykład, aby przyjrzeć się korzyściom, jakie można uzyskać przechodząc na podłączenie systemów pamięci masowej Ceph za pomocą sterownika CSI.
Podczas pracy z Ceph wtyczka CSI zapewnia więcej opcji pracy z systemami pamięci masowej niż wbudowane sterowniki.
- Dynamiczne tworzenie dysku. Zazwyczaj dyski RBD są używane tylko w trybie RWO, ale CSI dla Ceph pozwala na używanie ich w trybie RWX. Kilka podów w różnych węzłach może zamontować ten sam dysk RDB w swoich węzłach i pracować z nimi równolegle. Żeby było uczciwie, nie wszystko jest takie jasne – ten dysk można podłączyć jedynie jako urządzenie blokowe, co oznacza, że trzeba będzie dostosować aplikację do pracy z nim w trybie wielodostępu.
- Tworzenie migawek. W klastrze Kubernetes możesz utworzyć manifest z wymogiem utworzenia migawki. Wtyczka CSI to zobaczy i zrobi zrzut ekranu z dysku. Na jego podstawie możesz wykonać kopię zapasową lub kopię PersistentVolume.
- Zwiększanie rozmiaru dysku w magazynie i PersistentVolume w klastrze Kubernetes.
- Kwoty. Sterowniki CephFS wbudowane w Kubernetes nie obsługują przydziałów, ale świeże wtyczki CSI z najnowszym Ceph Nautilusem mogą włączyć przydziały na partycjach CephFS.
- Metryk. Wtyczka CSI może zapewnić Prometheusowi różne wskaźniki dotyczące tego, które woluminy są podłączone, jaka komunikacja ma miejsce itp.
- Świadomość topologii. Umożliwia określenie w manifestach sposobu geograficznego rozmieszczenia klastra i uniknięcie łączenia systemu pamięci masowej zlokalizowanego w Amsterdamie z modułami działającymi w Londynie.
Jak podłączyć Ceph do klastra Kubernetes poprzez CSI, zobacz . Możesz także subskrybować , który wystartuje 15 października.
Autor artykułu: Sergey Bondarev, praktykujący architekt w Southbridge, Certyfikowany Administrator Kubernetes, jeden z twórców kubespray.
Małe Post Scriptum nie dla reklamy, ale dla pożytku...
PS Sergey Bondarev prowadzi dwa intensywne kursy: aktualizacja 28-30 września i zaawansowane 14–16 października.
Źródło: www.habr.com