Opcje magazynu dla aplikacji w usłudze Azure Kubernetes Service (AKS)

  • Artykuł

Aplikacje działające w usłudze Azure Kubernetes Service (AKS) mogą wymagać przechowywania i pobierania danych. Podczas gdy niektóre obciążenia aplikacji mogą używać lokalnego, szybkiego magazynu w niepotrzebnych, opróżnionych węzłach, inne wymagają magazynu, który utrzymuje się na bardziej regularnych woluminach danych na platformie Azure.

Może być konieczne wiele zasobników:

  • Współużytkuj te same woluminy danych.
  • Ponownie dołącz woluminy danych, jeśli zasobnik zostanie ponownie zaplanowany na innym węźle.

Może być również konieczne zbieranie i przechowywanie poufnych danych lub informacji o konfiguracji aplikacji w zasobnikach.

W tym artykule przedstawiono podstawowe pojęcia, które zapewniają magazyn do aplikacji w usłudze AKS:

Diagram opcji magazynu dla aplikacji w klastrze usługi Azure Kubernetes Services (AKS).

Efemeryczny dysk systemu operacyjnego

Domyślnie platforma Azure automatycznie replikuje dysk systemu operacyjnego dla maszyny wirtualnej do usługi Azure Storage, aby uniknąć utraty danych po przeniesieniu maszyny wirtualnej do innego hosta. Jednak ponieważ kontenery nie są zaprojektowane tak, aby stan lokalny był utrwalone, to zachowanie zapewnia ograniczoną wartość przy jednoczesnym zapewnieniu pewnych wad. Te wady obejmują, ale nie są ograniczone do wolniejszej aprowizacji węzłów i większego opóźnienia odczytu/zapisu.

Natomiast efemeryczne dyski systemu operacyjnego są przechowywane tylko na maszynie hosta, podobnie jak dysk tymczasowy. Dzięki tej konfiguracji uzyskujesz mniejsze opóźnienie odczytu/zapisu wraz z szybszym skalowaniem węzłów i uaktualnieniami klastra.

Uwaga

Jeśli nie żądasz jawnie dysków zarządzanych platformy Azure dla systemu operacyjnego, usługa AKS domyślnie używa efemerycznego systemu operacyjnego, jeśli jest to możliwe dla danej konfiguracji puli węzłów.

Wymagania dotyczące rozmiaru i zalecenia dotyczące efemerycznych dysków systemu operacyjnego są dostępne w dokumentacji maszyny wirtualnej platformy Azure. Poniżej przedstawiono niektóre ogólne zagadnienia dotyczące ustalania rozmiaru:

  • Jeśli zdecydujesz się użyć domyślnego rozmiaru maszyny wirtualnej usługi AKS Standard_DS2_v2 jednostki SKU z domyślnym rozmiarem dysku systemu operacyjnego 100 GiB, domyślny rozmiar maszyny wirtualnej obsługuje efemeryczny system operacyjny, ale ma tylko 86 GiB rozmiaru pamięci podręcznej. Ta konfiguracja będzie domyślnie używać dysków zarządzanych, jeśli nie zostanie jawnie określona. Jeśli zażądasz efemerycznego systemu operacyjnego, zostanie wyświetlony błąd weryfikacji.

  • Jeśli zażądasz tej samej jednostki SKU Standard_DS2_v2 z dyskiem systemu operacyjnego 60 GiB, ta konfiguracja będzie domyślnie miała efemeryczny system operacyjny. Żądany rozmiar 60 GiB jest mniejszy niż maksymalny rozmiar pamięci podręcznej 86 GiB.

  • Jeśli wybierzesz jednostkę SKU Standard_D8s_v3 z dyskiem systemu operacyjnego 100 GB, ten rozmiar maszyny wirtualnej obsługuje efemeryczny system operacyjny i ma 200 GiB miejsca w pamięci podręcznej. Jeśli nie określisz typu dysku systemu operacyjnego, pula węzłów domyślnie otrzyma efemeryczny system operacyjny.

Najnowsza generacja serii maszyn wirtualnych nie ma dedykowanej pamięci podręcznej, ale tylko magazynu tymczasowego. Jeśli na przykład wybrano rozmiar maszyny wirtualnej Standard_E2bds_v5 o domyślnym rozmiarze dysku systemu operacyjnego 100 GiB, obsługuje efemeryczny dysk systemu operacyjnego, ale ma tylko 75 GB magazynu tymczasowego. Ta konfiguracja będzie domyślnie używać zarządzanych dysków systemu operacyjnego, jeśli nie zostanie jawnie określona. Jeśli zażądasz efemerycznego dysku systemu operacyjnego, zostanie wyświetlony błąd weryfikacji.

  • Jeśli zażądasz tego samego rozmiaru maszyny wirtualnej Standard_E2bds_v5 z dyskiem systemu operacyjnego 60 GiB, ta konfiguracja jest domyślnie ustawiona na efemeryczny dysk systemu operacyjnego. Żądany rozmiar 60 GiB jest mniejszy niż maksymalny magazyn tymczasowy 75 GiB.

  • W przypadku wybrania Standard_E4bds_v5 jednostki SKU z dyskiem systemu operacyjnego 100 GiB ten rozmiar maszyny wirtualnej obsługuje efemeryczny system operacyjny i ma 150 GiB magazynu tymczasowego. Jeśli nie określisz typu dysku systemu operacyjnego, domyślnie platforma Azure aprowizuje efemeryczny dysk systemu operacyjnego do puli węzłów.

Klucze zarządzane przez klienta

Szyfrowanie dysku systemu operacyjnego efemerycznego można zarządzać własnymi kluczami w klastrze usługi AKS. Aby uzyskać więcej informacji, zobacz Używanie klucza zarządzanego przez klienta z dyskiem platformy Azure w usłudze AKS.

Woluminy

Platforma Kubernetes zwykle traktuje poszczególne zasobniki jako efemeryczny, jednorazowy zasób. Aplikacje mają dostępne różne podejścia do używania i utrwalania danych. Wolumin reprezentuje sposób przechowywania, pobierania i utrwalania danych między zasobnikami oraz przez cykl życia aplikacji.

Tradycyjne woluminy są tworzone jako zasoby kubernetes wspierane przez usługę Azure Storage. Możesz ręcznie utworzyć woluminy danych, które mają być przypisane bezpośrednio do zasobników lub automatycznie utworzyć je platforma Kubernetes. Woluminy danych mogą być używane: Azure Disk, Azure Files, Azure NetApp Files lub Azure Blobs.

Uwaga

W zależności od używanej jednostki SKU maszyny wirtualnej sterownik CSI dysku platformy Azure może mieć limit woluminu na węzeł. W przypadku niektórych maszyn wirtualnych o wysokiej wydajności (na przykład 16 rdzeni) limit wynosi 64 woluminy na węzeł. Aby zidentyfikować limit dla jednostki SKU maszyny wirtualnej, zapoznaj się z kolumną Maksymalna liczba dysków danych dla każdej oferowanej jednostki SKU maszyny wirtualnej. Aby uzyskać listę oferowanych jednostek SKU maszyn wirtualnych i ich odpowiednie szczegółowe limity pojemności, zobacz Rozmiary maszyn wirtualnych ogólnego przeznaczenia.

Aby ułatwić określenie najlepszego dopasowania obciążenia między usługami Azure Files i Azure NetApp Files, zapoznaj się z informacjami podanymi w artykule Porównanie usług Azure Files i Azure NetApp Files.

Dysk platformy Azure

Użyj usługi Azure Disk , aby utworzyć zasób Kubernetes DataDisk . Typy dysków obejmują:

  • Dyski w warstwie Ultra
  • Dyski SSD w warstwie Premium
  • Dyski SSD w warstwie Standardowa
  • Dyski HDD w warstwie Standardowa

Napiwek

W przypadku większości obciążeń produkcyjnych i programistycznych należy używać dysków SSD w warstwie Premium.

Ponieważ dysk platformy Azure jest zainstalowany jako ReadWriteOnce, są dostępne tylko dla jednego węzła. W przypadku woluminów magazynu dostępnych jednocześnie przez zasobniki na wielu węzłach należy użyć usługi Azure Files.

Azure Files

Użyj usługi Azure Files , aby zainstalować udział bloku komunikatów serwera (SMB) w wersji 3.1.1 lub sieciowego systemu plików (NFS) w wersji 4.1 wspieranej przez konto usługi Azure Storage do zasobników. Usługa Azure Files umożliwia udostępnianie danych między wieloma węzłami i zasobnikami i mogą być używane:

  • Usługa Azure Premium Storage wspierana przez dyski SSD o wysokiej wydajności
  • Magazyn w warstwie Standardowa platformy Azure wspierany przez zwykłe dyski HDD

Azure NetApp Files

  • Usługa Storage w warstwie Ultra
  • Premium Storage
  • Konto magazynu w warstwie Standardowa

Azure Blob Storage

Użyj usługi Azure Blob Storage , aby utworzyć kontener magazynu obiektów blob i zainstalować go przy użyciu protokołu NFS w wersji 3.0 lub blobFuse.

  • Blokowe obiekty blob

Typy woluminów

Woluminy Kubernetes reprezentują więcej niż tylko tradycyjny dysk do przechowywania i pobierania informacji. Woluminy Kubernetes mogą być również używane jako sposób wstrzykiwania danych do zasobnika do użytku przez kontenery.

Typowe typy woluminów na platformie Kubernetes obejmują:

emptyDir

Często używane 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ć tylko w pamięci węzła.

wpis tajny

Do wstrzykiwania poufnych danych do zasobników, takich jak hasła, można użyć woluminów tajnych .

  1. Utwórz wpis tajny przy użyciu interfejsu API platformy Kubernetes.
  2. Zdefiniuj zasobnik lub wdrożenie i zażądaj określonego wpisu tajnego.
    • Wpisy tajne są udostępniane tylko węzłom z zaplanowanym zasobnikiem, który ich wymaga.
    • Wpis tajny jest przechowywany w plikach tmpfs, a nie zapisywanych na dysku.
  3. Usunięcie ostatniego zasobnika w węźle wymagającego wpisu tajnego spowoduje usunięcie wpisu tajnego z plików tmpfs węzła.
    • Wpisy tajne są przechowywane w danej przestrzeni nazw i są dostępne tylko przez zasobniki w tej samej przestrzeni nazw.

configMap

Za pomocą narzędzia configMap można wstrzyknąć właściwości pary klucz-wartość do zasobników, takich jak informacje o konfiguracji aplikacji. Zdefiniuj informacje o konfiguracji aplikacji jako zasób Kubernetes, łatwe aktualizowanie i stosowanie ich do nowych wystąpień zasobników podczas ich wdrażania.

Podobnie jak w przypadku używania wpisu tajnego:

  1. Utwórz obiekt ConfigMap przy użyciu interfejsu API platformy Kubernetes.
  2. Zażądaj obiektu ConfigMap podczas definiowania zasobnika lub wdrożenia.
    • Konfiguracja Mapy są przechowywane w danej przestrzeni nazw i są 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 (PV) to zasób magazynu utworzony i zarządzany przez interfejs API Kubernetes, który może istnieć poza okresem istnienia pojedynczego zasobnika.

Następujące usługi danych usługi Azure Storage umożliwiają udostępnienie elementu PersistentVolume:

Jak wspomniano w sekcji Woluminy , wybór dysków lub plików jest często określany przez potrzebę współbieżnego dostępu do danych lub warstwy wydajności.

Diagram woluminów trwałych w klastrze usługi Azure Kubernetes Services (AKS).

Administrator klastra może statycznie utworzyć wartość PersistentVolume lub wolumin jest tworzony dynamicznie przez serwer interfejsu API Kubernetes. Jeśli zasobnik jest zaplanowany i żąda obecnie niedostępnego magazynu, platforma Kubernetes może utworzyć bazowy magazyn usługi Azure Disk lub File Storage i dołączyć go do zasobnika. Aprowizacja dynamiczna używa klasy StorageClass do identyfikowania typu magazynu platformy Azure, który należy utworzyć.

Ważne

Trwałe woluminy nie mogą być współużytkowane przez zasobniki systemów Windows i Linux ze względu na różnice w obsłudze systemu plików między dwoma systemami operacyjnymi.

Klasy magazynu

Aby zdefiniować różne warstwy magazynu, takie jak Premium i Standardowa, można utworzyć klasę StorageClass.

Klasa StorageClass definiuje również zasady odzyskiwania. Po usunięciu woluminu trwałego funkcja reclaimPolicy kontroluje zachowanie bazowego zasobu usługi Azure Storage. Podstawowy zasób magazynu można usunąć lub przechowywać do użycia z przyszłym zasobnikem.

W przypadku klastrów używających sterowników interfejsu magazynu kontenerów (CSI) tworzone są następujące dodatkowe StorageClasses elementy:

Klasa magazynu opis
managed-csi Do utworzenia dysku zarządzanego używa magazynu lokalnie nadmiarowego (LRS) usługi Azure StandardSSD. Zasady odzyskiwania zapewniają usunięcie bazowego dysku platformy Azure 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ć. Wystarczy edytować trwałe oświadczenie woluminu o nowym rozmiarze.
managed-csi-premium Używa magazynu lokalnie nadmiarowego (LRS) platformy Azure w warstwie Premium do utworzenia dysku zarządzanego. Zasady odzyskiwania ponownie zapewniają usunięcie bazowego dysku platformy Azure po usunięciu trwałego woluminu, który go użył. Podobnie ta klasa magazynu umożliwia rozszerzenie woluminów trwałych.
azurefile-csi Używa usługi Azure Standard Storage do utworzenia udziału plików platformy Azure. Zasady odzyskiwania zapewniają usunięcie bazowego udziału plików platformy Azure po usunięciu trwałego woluminu, który go użył.
azurefile-csi-premium Używa usługi Azure Premium Storage do utworzenia udziału plików platformy Azure. Zasady odzyskiwania zapewniają usunięcie bazowego udziału plików platformy Azure po usunięciu trwałego woluminu, który go użył.
azureblob-nfs-premium Używa usługi Azure Premium Storage do tworzenia kontenera usługi Azure Blob Storage i nawiązywania połączenia przy użyciu protokołu NFS w wersji 3. Zasady odzyskiwania zapewniają usunięcie bazowego kontenera usługi Azure Blob Storage po usunięciu trwałego woluminu, który go użył.
azureblob-fuse-premium Używa usługi Azure Premium Storage do tworzenia kontenera usługi Azure Blob Storage i nawiązywania połączenia przy użyciu narzędzia BlobFuse. Zasady odzyskiwania zapewniają usunięcie bazowego kontenera usługi Azure Blob Storage po usunięciu trwałego woluminu, który go użył.

Jeśli nie określisz klasy StorageClass dla woluminu trwałego, zostanie użyta domyślna klasa StorageClass. Upewnij się, że woluminy korzystają z odpowiedniego magazynu potrzebnego podczas żądania woluminów trwałych.

Ważne

Począwszy od platformy Kubernetes w wersji 1.21, usługa AKS domyślnie używa tylko sterowników CSI, a migracja CSI jest włączona. Chociaż istniejące woluminy trwałe w drzewie nadal działają, począwszy od wersji 1.26, usługa AKS nie będzie już obsługiwać woluminów utworzonych przy użyciu sterownika drzewa i magazynu aprowizowanego dla plików i dysków.

Klasa default będzie taka sama jak managed-csi.

Klasę StorageClass można utworzyć dla innych potrzeb, używając polecenia kubectl. W poniższym przykładzie użyto Dyski zarządzane Premium i określono, że podstawowy dysk platformy Azure powinien zostać zachowany podczas usuwania zasobnika:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_ZRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Uwaga

Usługa AKS uzgadnia domyślne klasy magazynu i zastąpi wszelkie zmiany wprowadzone w tych klasach magazynu.

Aby uzyskać więcej informacji na temat klas magazynu, zobacz StorageClass w usłudze Kubernetes.

Trwałe woluminy — oświadczenia

TrwałeVolumeClaim żąda przechowywania określonej klasy StorageClass, trybu dostępu i rozmiaru. Serwer interfejsu API Kubernetes może dynamicznie aprowizować bazowy zasób usługi Azure Storage, jeśli żaden istniejący zasób nie może spełnić oświadczenia na podstawie zdefiniowanej klasy StorageClass.

Definicja zasobnika zawiera instalację woluminu po nawiązaniu połączenia woluminu z zasobnikem.

Diagram oświadczeń trwałych woluminów w klastrze usługi Azure Kubernetes Services (AKS).

Po przypisaniu dostępnego zasobu magazynu do zasobnika żądającego magazynu element PersistentVolume jest powiązany z elementem PersistentVolumeClaim. Woluminy trwałe są mapowane na oświadczenia 1:1.

Poniższy przykładowy manifest YAML przedstawia trwałe oświadczenie woluminu, które używa klasy StorageClass zarządzanej w warstwie Premium i żąda rozmiaru dysku 5Gi :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-premium-retain
  resources:
    requests:
      storage: 5Gi

Podczas tworzenia definicji zasobnika należy również określić następujące elementy:

  • Oświadczenie trwałego woluminu w celu zażądania żądanego magazynu.
  • WoluminMount dla aplikacji do odczytywania i zapisywania danych.

Poniższy przykładowy manifest YAML pokazuje, jak można użyć poprzedniego trwałego oświadczenia woluminu do zainstalowania woluminu w / mnt/azure:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      volumeMounts:
      - mountPath: "/mnt/azure"
        name: volume
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: azure-managed-disk

W przypadku instalowania woluminu w kontenerze systemu Windows określ literę dysku i ścieżkę. Na przykład:

...      
       volumeMounts:
        - mountPath: "d:"
          name: volume
        - mountPath: "c:\k"
          name: k-dir
...

Następne kroki

Aby uzyskać informacje o skojarzonych najlepszych rozwiązaniach, zobacz Najlepsze rozwiązania dotyczące magazynu i tworzenia kopii zapasowych w usługach AKS i AKS Storage Considerations.

Aby zobaczyć, jak używać sterowników CSI, zobacz następujące artykuły z instrukcjami:

Aby uzyskać więcej informacji na temat podstawowych pojęć związanych z platformą Kubernetes i usługą AKS, zobacz następujące artykuły: