Opcje magazynu dla aplikacji w usłudze AKS włączone przez usługę Azure Arc

  • Artykuł

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 Azure Kubernetes Service włączone 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.

Obraz magazynu architektury przedstawiający wzorzec i węzeł klastra.

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łe woluminów (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 cyklu życia aplikacji.

W usłudze Kubernetes woluminy mogą reprezentować więcej niż tylko tradycyjne informacje, które są przechowywane i pobierane. 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 przez cykl życia zasobnika — po usunięciu zasobnika wolumin zostanie usunięty. Ten wolumin zazwyczaj używa bazowego magazynu dyskowego 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 zasobnikem, 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ć je 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 kubernetes. Ten element ConfigMap można następnie 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, szczególnie 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.

Można użyć woluminów dysku usługi AKS wspieranych przez dysk VHDX, które są instalowane jako ReadWriteOnce i są dostępne dla jednego węzła naraz. 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 być dynamicznie tworzony 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 steruje zachowaniem bazowego zasobu magazynu po usunięciu zasobnika, 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ć oświadczenie trwałego woluminu przy użyciu nowego rozmiaru.

Jeśli dla woluminu trwałego nie określono klasy StorageClass , zostanie użyta domyślna klasa StorageClass . Podczas żądania woluminów trwałych upewnij się, że używają odpowiedniego magazynu. Możesz utworzyć klasę StorageClass dla dodatkowych potrzeb.

Trwałe woluminy — oświadczenia

Żądania PersistentVolumeClaim żądają magazynu ReadWriteOnce lub ReadWriteMany 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.

Element PersistentVolume jest powiązany 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 oświadczenie trwałego 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 jest określane trwałe oświadczenie woluminu w celu żądania żą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 oświadczenia trwałego woluminu do zainstalowania woluminu w lokalizacji /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

Następne kroki