Udostępnij za pośrednictwem

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).

Domyślny rozmiar dysku systemu operacyjnego

Podczas tworzenia nowego klastra lub dodawania nowej puli węzłów do istniejącego klastra liczba procesorów wirtualnych domyślnie określa rozmiar dysku systemu operacyjnego. Liczba procesorów wirtualnych jest oparta na jednostce SKU maszyny wirtualnej. W poniższej tabeli wymieniono domyślny rozmiar dysku systemu operacyjnego dla każdej jednostki SKU maszyny wirtualnej:

Rdzenie jednostek SKU maszyny wirtualnej (procesory wirtualne) Domyślna warstwa dysku systemu operacyjnego Aprowizowane operacje wy/wy na sekundę Aprowizowana przepływność (Mb/s)
1 - 7 P10/128G 500 100
8 - 15 P15/256G 1100 125
16 - 63 P20/512G 2300 150
64+ P30/1024G 5000 200

Ważne

Domyślne ustalanie rozmiaru dysku systemu operacyjnego jest używane tylko w nowych klastrach lub pulach węzłów, gdy efemeryczne dyski systemu operacyjnego nie są obsługiwane i nie określono domyślnego rozmiaru dysku systemu operacyjnego. Domyślny rozmiar dysku systemu operacyjnego może mieć wpływ na wydajność lub koszt klastra. Nie można zmienić rozmiaru dysku systemu operacyjnego po utworzeniu klastra lub puli węzłów. Ten domyślny rozmiar dysku ma wpływ na klastry lub pule węzłów utworzone w lipcu 2022 r. lub nowszym.

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 SSD w warstwie Premium (zalecane w przypadku większości obciążeń)
  • Dyski w warstwie Ultra
  • Dyski SSD w warstwie Standardowa
  • Dyski HDD w warstwie Standardowa

Napiwek

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

Ponieważ dysk platformy Azure jest zainstalowany jako ReadWriteOnce, jest dostępny 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 udziału sieciowego systemu plików (NFS). 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. Gdy usuniesz ostatni zasobnik w węźle wymagającym wpisu tajnego, wpis tajny zostanie usunięty 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.
    • Obiekty ConfigMap 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.

Aby zapewnić wolumin trwały, możesz użyć następujących usług Azure Storage:

Jak wspomniano w sekcji Woluminy , wybór dysków platformy Azure lub usługi Azure Files 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ć wolumin trwały lub wolumin można utworzyć dynamicznie przez serwer interfejsu API Kubernetes. Jeśli zasobnik jest zaplanowany i żąda magazynu, który jest obecnie niedostępny, 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 magazynu do identyfikowania typu zasobu, 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.

Jeśli chcesz w pełni zarządzane rozwiązanie do uzyskiwania dostępu na poziomie bloku do danych, rozważ użycie usługi Azure Container Storage zamiast sterowników CSI. Usługa Azure Container Storage integruje się z platformą Kubernetes, umożliwiając dynamiczną i automatyczną aprowizację trwałych woluminów. Usługa Azure Container Storage obsługuje dyski platformy Azure, dyski efemeryczne i usługę Azure Elastic SAN (wersja zapoznawcza) jako magazyn zapasowy, zapewniając elastyczność i skalowalność aplikacji stanowych uruchomionych w klastrach Kubernetes.

Klasy magazynu

Aby określić różne warstwy magazynu, takie jak Premium lub Standardowa, można utworzyć klasę magazynu.

Klasa magazynu definiuje również zasady odzyskiwania. Po usunięciu woluminu trwałego zasady odzyskiwania kontrolują zachowanie bazowego zasobu usługi Azure Storage. Zasób bazowy można usunąć lub przechowywać do użytku z przyszłym zasobnikem.

W przypadku klastrów korzystających z usługi Azure Container Storage zostanie wyświetlona dodatkowa klasa magazynu o nazwie acstor-<storage-pool-name>. Zostanie również utworzona wewnętrzna klasa magazynu.

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

Klasa magazynu opis
managed-csi Do utworzenia dysku zarządzanego jest używany magazyn lokalnie nadmiarowy SSD (LRS) w warstwie Standardowa. 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ć. Możesz edytować trwałe oświadczenie woluminu, aby określić nowy rozmiar. Począwszy od platformy Kubernetes w wersji 1.29, w klastrach usługi Azure Kubernetes Service (AKS) wdrożonych w wielu strefach dostępności ta klasa magazynu korzysta z magazynu strefowo nadmiarowego (ZRS) ssd w warstwie Standardowa w celu utworzenia dysków zarządzanych.
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. Począwszy od platformy Kubernetes w wersji 1.29, w klastrach usługi Azure Kubernetes Service (AKS) wdrożonych w wielu strefach dostępności ta klasa magazynu korzysta z magazynu strefowo nadmiarowego platformy Azure (ZRS) do tworzenia dysków zarządzanych.
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 magazynu dla woluminu trwałego, zostanie użyta domyślna klasa magazynu. 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 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.

Począwszy od platformy Kubernetes w wersji 1.29, podczas wdrażania klastrów usługi Azure Kubernetes Service (AKS) w wielu strefach dostępności usługa AKS używa teraz magazynu strefowo nadmiarowego (ZRS) do tworzenia dysków zarządzanych w wbudowanych klasach magazynu. Magazyn ZRS zapewnia synchroniczną replikację dysków zarządzanych platformy Azure w wielu strefach dostępności platformy Azure w wybranym regionie. Ta strategia nadmiarowości zwiększa odporność aplikacji i zabezpiecza dane przed awariami centrum danych.

Należy jednak pamiętać, że magazyn strefowo nadmiarowy (ZRS) jest bardziej kosztowny w porównaniu z magazynem lokalnie nadmiarowym (LRS). Jeśli optymalizacja kosztów jest priorytetem, możesz utworzyć nową klasę magazynu z parametrem ustawionym skuname na LRS. Następnie możesz użyć nowej klasy magazynu w trwałym oświadczeniu woluminu (PVC).

Możesz utworzyć klasę magazynu dla innych potrzeb przy użyciu polecenia kubectl. W poniższym przykładzie użyto dysków zarządzanych w warstwie Premium i określono, że bazowy 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

Oświadczenie trwałego woluminu (PVC) żąda przechowywania określonej klasy magazynu, 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 magazynu.

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 wolumin trwały jest powiązany z trwałym oświadczeniem woluminu. Woluminy trwałe są mapowane na oświadczenia w mapowaniu 1:1.

Poniższy przykładowy manifest YAML przedstawia trwałe oświadczenie woluminu, które używa klasy zarządzanej magazynu w warstwie Premium i żąda dysku platformy Azure o rozmiarze 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.
  • Instalacja woluminu dla aplikacji w celu 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.

Aby uzyskać więcej informacji na temat usługi Azure Container Storage, zobacz następujące artykuły:

Aby uzyskać więcej informacji na temat używania sterowników CSI, zobacz następujące artykuły:

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