Opcje magazynu dla aplikacji w usłudze AKS obsługiwane przez usługę Azure Arc

Dotyczy: AKS w usłudze Azure Local

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 na niepotrzebnym węźle po usunięciu podów (Kubernetes używa podów do uruchamiania wystąpienia aplikacji).

Inne obciążenia mogą wymagać przechowywania, które jest trwałe na bardziej standardowych 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 przechowywania, jeśli zasobniki zawierają poufne dane lub dane konfiguracyjne aplikacji.

W tym artykule przedstawiono podstawowe pojęcia, które zapewniają przestrzeń do przechowywania dla Twoich aplikacji w usłudze AKS Arc, w tym:

• Objętości
• Trwałe woluminy
• Klasy pamięci masowej
• Żądania trwałych woluminów (PVC)

Objętości

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 oznacza sposób przechowywania, pobierania i utrwalania danych w zasobnikach oraz w całym cyklu życia aplikacji.

W usłudze Kubernetes woluminy mogą reprezentować więcej niż tylko tradycyjny system, na którym przechowywane i pobierane są 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 podu. Wszystkie kontenery w podzie 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 korzysta z podstawowej pamięci dyskowej lokalnego węzła, chociaż może również istnieć wyłącznie w pamięci węzła.

• tajny — ten wolumin służy do dodawania poufnych danych, takich jak hasła, do podów. Najpierw należy utworzyć sekret przy użyciu Kubernetes API. Podczas definiowania zasobnika lub wdrożenia można poprosić o określony sekret. "Tajemnice są udostępniane tylko węzłom z zaplanowanym podem, który ich wymaga, a są przechowywane w tmpfs, a nie zapisywane na dysku." Gdy ostatni zasobnik na węźle, który wymaga sekretu, zostanie usunięty, sekret jest usuwany z 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 par klucz-wartość do podów, takich jak informacje o konfiguracji aplikacji. Zamiast definiować informacje o konfiguracji aplikacji w obrazie kontenera, można je zdefiniować jako zasób Kubernetes, który można łatwo zaktualizować i zastosować do nowych instancji podów, gdy są wdrażane. 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 podu istnieją tylko do momentu usunięcia podu. Często oczekuje się, że pody zachowają swoje przechowywanie, jeśli zostaną przeniesione na inny host podczas prac konserwacyjnych, zwłaszcza w przypadku StatefulSets. Trwała pamięć masowa to zasób pamięci masowej utworzony i zarządzany przez API Kubernetes, który może istnieć poza czasem życia pojedynczego podu.

Woluminy dysków AKS obsługiwane przez VHDX, które są montowane jako ReadWriteOnce i są dostępne tylko dla jednego węzła naraz. Można też użyć woluminów plików usługi AKS opartych na udziałach 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 pod jest zaplanowany i żąda przestrzeni magazynowej, która jest obecnie niedostępna, Kubernetes może utworzyć plik VHDX i dołączyć go do poda. Aprowizacja dynamiczna używa klasy StorageClass do identyfikowania typu magazynu, który należy utworzyć.

Klasy pamięci masowej

Aby zdefiniować różne warstwy (i lokalizację) magazynu, możesz utworzyć klasę StorageClass. Klasa StorageClass definiuje również zasady odzyskiwania. Zasada reclaimPolicy kontroluje zachowanie bazowego zasobu magazynu, gdy pod zostanie usunięty, a trwały wolumin może już nie być potrzebny. Bazowy zasób magazynowy można usunąć lub zachować do użycia z przyszłym podem.

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. Polityka odzyskiwania gwarantuje, że bazowy dysk VHDX jest usuwany, gdy trwały wolumin, który go używał, zostanie usunięty. Klasa przechowywania konfiguruje również trwałe woluminy, aby można je było rozszerzać, więc wystarczy edytować żądanie przestrzeni dyskowej, aby uwzględnić nowy rozmiar.

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ą odpowiedniej pamięci masowej. Możesz utworzyć klasę StorageClass dla dodatkowych potrzeb.

Żądania trwałego wolumenu

PersistentVolumeClaim żąda pamięci ReadWriteOnce lub ReadWriteMany w określonej StorageClass i rozmiarze. Serwer API Kubernetes może dynamicznie przydzielać bazowy zasób pamięci masowej w usłudze AKS Arc, jeśli nie ma istniejącego zasobu, aby spełnić żądanie na podstawie zdefiniowanej StorageClass. Definicja zasobnika zawiera punkt montowania woluminu po nawiązaniu połączenia woluminu z zasobnikiem.

PersistentVolume jest powiązany z PersistentVolumeClaim po przypisaniu dostępnego zasobu pamięci do poda, który go żąda. Istnieje mapowanie woluminów trwałych 1:1 na oświadczenia.

Poniższy przykładowy manifest YAML przedstawia żądanie trwałego woluminu, które używa domyślnej 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ć żądanie stałego wolumenu, aby zażądać żądanej przestrzeni dyskowej. Następnie należy określić volumeMount dla waszych aplikacji, aby odczytywały i zapisywały dane. Poniższy przykładowy manifest YAML pokazuje, jak można użyć poprzedniego żądania trwałego wolumenu w celu zamontowania woluminu w /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 

Zabezpieczanie dostępu podu do zamontowanych woluminów

Aby aplikacje działały poprawnie, zasobniki powinny być uruchamiane jako zdefiniowany użytkownik lub grupa, a nie jako root. Za pomocą securityContext dla zasobnika lub kontenera można zdefiniować ustawienia, takie jak fsGroup, aby nadawać odpowiednie uprawnienia na zamontowanych woluminach.

fsGroup to pole w ramach securityContext specyfikacji podu Kubernetes. Definiuje on dodatkowy identyfikator grupy przypisywany przez platformę Kubernetes do wszystkich procesów w zasobniku i cyklicznie do plików w zainstalowanych woluminach. Dzięki temu zasobnik ma prawidłowy dostęp do poziomu grupy do współdzielonych woluminów pamięci masowej.

Po zamontowaniu woluminu platforma Kubernetes zmienia własność zawartości woluminu w celu dopasowania jej do wartości fsGroup . Jest to szczególnie przydatne, gdy kontenery są uruchamiane jako użytkownicy niebędący użytkownikami głównymi i wymagają dostępu do zapisu do udostępnionych woluminów.

Poniższy przykład YAML przedstawia wartość fsgroup :

securityContext:
  fsGroup: 2000

W tym przykładzie wszystkie pliki w zainstalowanych woluminach są dostępne przez GID 2000.

Następne kroki

• Użyj usługi AKS w sterownikach interfejsu CSI (Container Storage Interface) dysku lokalnego platformy Azure.