Opcje magazynu dla aplikacji w usłudze AKS włączone przez usługę Azure Arc
Dotyczy: usługa AKS w usłudze Azure Stack HCI 22H2, AKS w systemie Windows Server
Aplikacje uruchamiane we wdrożeniach usługi AKS przy użyciu usługi Azure Kubernetes Service włączonej przez usługę Azure Arc mogą wymagać przechowywania i pobierania danych. W przypadku niektórych obciążeń aplikacji dane mogą używać lokalnego, szybkiego magazynu w niepotrzebnym węźle po usunięciu zasobników (platforma Kubernetes używa zasobników do uruchamiania wystąpienia aplikacji).
Inne obciążenia mogą wymagać magazynu, który utrzymuje się na bardziej regularnych woluminach danych. Wiele zasobników może wymagać współużytkowania tych samych woluminów danych lub ponownego dołączenia woluminów danych, jeśli zasobnik zostanie ponownie zaplanowany na innym węźle. Ponadto może być potrzebna opcja magazynu, jeśli zasobniki zawierają poufne dane lub informacje o konfiguracji aplikacji.
W tym artykule przedstawiono podstawowe pojęcia, które zapewniają magazyn aplikacji w usłudze AKS Arc, w tym:
- Woluminy
- Trwałe woluminy
- Klasy magazynu
- Oświadczenia trwałego woluminu (PVC)
Woluminy
Aplikacje często muszą mieć możliwość przechowywania i pobierania danych. Ponieważ platforma Kubernetes zwykle traktuje poszczególne zasobniki jako tymczasowe, jednorazowe zasoby, różne podejścia są dostępne dla aplikacji do używania i utrwalania danych. Wolumin reprezentuje sposób przechowywania, pobierania i utrwalania danych między zasobnikami oraz przez cykl życia aplikacji.
W usłudze Kubernetes woluminy mogą reprezentować więcej niż tylko tradycyjny, na którym są przechowywane i pobierane informacje. Woluminy Kubernetes mogą być również używane jako sposób wstawiania danych do zasobnika na potrzeby kontenerów. Oto niektóre typowe typy woluminów Kubernetes:
emptyDir — ten wolumin jest często używany jako miejsce tymczasowe dla zasobnika. Wszystkie kontenery w zasobniku mogą uzyskiwać dostęp do danych na woluminie. Dane zapisywane w tym typie woluminu są utrwalane tylko w ciągu cyklu życia zasobnika — po usunięciu zasobnika wolumin zostanie usunięty. Ten wolumin zazwyczaj używa bazowego magazynu dysku węzła lokalnego, chociaż może również istnieć wyłącznie w pamięci węzła.
wpis tajny — ten wolumin służy do dołączania poufnych danych, takich jak hasła, do zasobników. Najpierw należy utworzyć wpis tajny przy użyciu interfejsu API platformy Kubernetes. Podczas definiowania zasobnika lub wdrożenia można zażądać określonego wpisu tajnego. Wpisy tajne są udostępniane tylko węzłom z zaplanowanym zasobnikiem, który go wymaga, a wpis tajny jest przechowywany w plikach tmpfs, a nie zapisywanych na dysku. Gdy ostatni zasobnik w węźle, który wymaga wpisu tajnego, zostanie usunięty z plików tmpfs węzła. Wpisy tajne są przechowywane w danej przestrzeni nazw i mogą być dostępne tylko przez zasobniki w tej samej przestrzeni nazw.
configMap — ten typ woluminu służy do wstrzykiwania właściwości pary klucz-wartość do zasobników, takich jak informacje o konfiguracji aplikacji. Zamiast definiować informacje o konfiguracji aplikacji w obrazie kontenera, można zdefiniować go jako zasób Kubernetes, który można łatwo zaktualizować i zastosować do nowych wystąpień zasobników podczas wdrażania. Podobnie jak w przypadku używania wpisu tajnego, należy najpierw utworzyć obiekt ConfigMap przy użyciu interfejsu API platformy Kubernetes. Tę ConfigMap można zażądać podczas definiowania zasobnika lub wdrożenia. Obiekty ConfigMap są przechowywane w danej przestrzeni nazw i mogą być dostępne tylko przez zasobniki w tej samej przestrzeni nazw.
Trwałe woluminy
Woluminy zdefiniowane i utworzone w ramach cyklu życia zasobnika istnieją tylko do momentu usunięcia zasobnika. Zasobniki często oczekują, że magazyn pozostanie, jeśli zasobnik zostanie ponownie zaplanowany na innym hoście podczas zdarzenia konserwacji, zwłaszcza w przypadku stanowych zestawów. Wolumin trwały to zasób magazynu utworzony i zarządzany przez interfejs API Kubernetes, który może istnieć poza okresem istnienia pojedynczego zasobnika.
Woluminy dysków usługi AKS obsługiwane przez dysk VHDX, które są instalowane jako ReadWriteOnce i są dostępne dla jednego węzła w danym momencie. Można też użyć woluminów plików usługi AKS wspieranych przez udziały plików SMB lub NFS. Są one instalowane jako ReadWriteMany i są dostępne dla wielu węzłów jednocześnie.
Administrator klastra może statycznie utworzyć wolumin trwały lub wolumin może zostać dynamicznie utworzony przez serwer interfejsu API Kubernetes. Jeśli zasobnik jest zaplanowany i żąda magazynu, który jest obecnie niedostępny, platforma Kubernetes może utworzyć źródłowy plik VHDX, a następnie dołączyć go do zasobnika. Aprowizacja dynamiczna używa klasy StorageClass do identyfikowania typu magazynu, który należy utworzyć.
Klasy magazynu
Aby zdefiniować różne warstwy (i lokalizację) magazynu, możesz utworzyć klasę StorageClass. Klasa StorageClass definiuje również zasady odzyskiwania. To polecenie reclaimPolicy kontroluje zachowanie bazowego zasobu magazynu, gdy zasobnik zostanie usunięty, a trwały wolumin może już nie być wymagany. Bazowy zasób magazynu można usunąć lub zachować do użycia z przyszłym zasobnikem.
W usłudze AKS Arc domyślna klasa magazynu jest tworzona automatycznie i używa woluminów CSV do tworzenia woluminów opartych na dysku VHDX. Zasady odzyskiwania zapewniają usunięcie bazowego dysku VHDX po usunięciu trwałego woluminu, który go użył. Klasa magazynu konfiguruje również woluminy trwałe, aby można je było rozszerzać, więc wystarczy edytować trwałe oświadczenie woluminu o nowym rozmiarze.
Jeśli dla woluminu trwałego nie określono żadnej klasy StorageClass , zostanie użyta domyślna klasa StorageClass . Podczas żądania woluminów trwałych upewnij się, że używają odpowiedniego magazynu. Klasę StorageClass można utworzyć w celu uzyskania dodatkowych potrzeb.
Trwałe woluminy — oświadczenia
Żądanie PersistentVolumeClaim żądań ReadWriteOnce lub ReadWriteMany dla określonej klasy StorageClass i rozmiaru. Serwer interfejsu API Kubernetes może dynamicznie aprowizować bazowy zasób magazynu w usłudze AKS Arc, jeśli nie ma istniejącego zasobu do spełnienia oświadczenia na podstawie zdefiniowanej klasy StorageClass. Definicja zasobnika zawiera instalację woluminu po nawiązaniu połączenia woluminu z zasobnikem.
Wartość PersistentVolume jest powiązana z elementem PersistentVolumeClaim po przypisaniu dostępnego zasobu magazynu do zasobnika żądającego go. Istnieje mapowanie woluminów trwałych 1:1 na oświadczenia.
Poniższy przykładowy manifest YAML przedstawia trwałe oświadczenie woluminu, które używa domyślnej klasy StorageClass i żąda dysku 5Gi:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: aks-hci-vhdx
spec:
accessModes:
- ReadWriteOnce
storageClassName: default
resources:
requests:
storage: 5Gi
Podczas tworzenia definicji zasobnika należy określić trwałe oświadczenie woluminu, aby zażądać żądanego magazynu. Następnie należy określić, czy volumeMount aplikacje będą odczytywać i zapisywać dane. Poniższy przykładowy manifest YAML pokazuje, jak można użyć poprzedniego trwałego oświadczenia woluminu do zainstalowania woluminu w programie /mnt/aks-hci:
kind: Pod
apiVersion: v1
metadata:
name: nginx
spec:
containers:
- name: myfrontend
image: k8s.gcr.io/nginx
volumeMounts:
- mountPath: "/mnt/aks-hci"
name: volume
nodeSelector:
kubernetes.io/os: linux
volumes:
- name: volume
persistentVolumeClaim:
claimName: aks-hci-vhdx
W poniższym przykładzie pokazano, jak zainstalować wolumin w kontenerze systemu Windows i określić literę dysku i ścieżkę:
volumeMounts:
- mountPath: "d:"
name: volume
- mountPath: "c:\k"
name: k-dir