Konfiguracja usługi Storage

Artykuł
11/05/2024

Pojęcia dotyczące magazynu Kubernetes

Platforma Kubernetes udostępnia warstwę abstrakcji infrastruktury na bazowym stosie technologicznym wirtualizacji (opcjonalnie) i sprzęcie. Sposób, w jaki platforma Kubernetes wyodrębnia magazyn, odbywa się za pomocą klas magazynu. Podczas aprowizacji zasobnika można określić klasę magazynu dla każdego woluminu. W momencie aprowizacji zasobnika aprowizacja klasy magazynu jest wywoływana w celu aprowizacji magazynu, a następnie na tym aprowizowanej pamięci jest tworzony wolumin trwały, a następnie zasobnik jest instalowany do woluminu trwałego przez trwałe oświadczenie woluminu.

Platforma Kubernetes umożliwia dostawcom infrastruktury magazynu podłączenie sterowników (nazywanych również "Addons"), które rozszerzają platformę Kubernetes. Dodatki magazynu muszą być zgodne ze standardem interfejsu magazynu kontenera. Istnieje kilkadziesiąt dodatków, które można znaleźć na tej niejednoznacznej liście sterowników CSI. Określony używany sterownik CSI zależy od czynników, takich jak to, czy korzystasz z usługi Kubernetes hostowanej w chmurze, czy też od dostawcy OEM używanego na potrzeby sprzętu.

Aby wyświetlić klasy magazynu skonfigurowane w klastrze Kubernetes, uruchom następujące polecenie:

kubectl get storageclass

Przykładowe dane wyjściowe z klastra usługi Azure Kubernetes Service (AKS):

NAME                PROVISIONER                AGE
azurefile           kubernetes.io/azure-file   15d
azurefile-premium   kubernetes.io/azure-file   15d
default (default)   kubernetes.io/azure-disk   4d3h
managed-premium     kubernetes.io/azure-disk   4d3h

Aby uzyskać szczegółowe informacje o klasie magazynu, uruchom następujące polecenie:

kubectl describe storageclass/<storage class name>

Przykład:

kubectl describe storageclass/azurefile

Name:            azurefile
IsDefaultClass:  No
Annotations:     kubectl.kubernetes.io/last-applied-configuration={"allowVolumeExpansion":true,"apiVersion":"storage.k8s.io/v1beta1","kind":"StorageClass","metadata":{"annotations":{},"labels":{"kubernetes.io/cluster-service":"true"},"name":"azurefile"},"parameters":{"sku
Name":"Standard_LRS"},"provisioner":"kubernetes.io/azure-file"}

Provisioner:           kubernetes.io/azure-file
Parameters:            skuName=Standard_LRS
AllowVolumeExpansion:  True
MountOptions:          <none>
ReclaimPolicy:         Delete
VolumeBindingMode:     Immediate
Events:                <none>

Obecnie aprowizowania woluminów trwałych i oświadczeń woluminów trwałych można wyświetlić, uruchamiając następujące polecenia:

kubectl get persistentvolumes -n <namespace>

kubectl get persistentvolumeclaims -n <namespace>

Przykład przedstawiający woluminy trwałe:


kubectl get persistentvolumes -n arc

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                      STORAGECLASS   REASON   AGE
pvc-07fc7b9f-9a37-4796-9442-4405147120da   15Gi       RWO            Delete           Bound    arc/sqldemo11-data-claim   default                 7d3h
pvc-3e772f20-ed89-4642-b34d-8bb11b088afa   15Gi       RWO            Delete           Bound    arc/data-metricsdb-0       default                 7d14h
pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665   10Gi       RWO            Delete           Bound    arc/sqldemo11-logs-claim   default                 7d3h
pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad   15Gi       RWO            Delete           Bound    arc/data-controller        default                 7d14h
pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91   10Gi       RWO            Delete           Bound    arc/logs-controller        default                 7d14h
pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493   10Gi       RWO            Delete           Bound    arc/logs-metricsdb-0       default                 7d14h
pvc-8e2cacbc-e953-4901-8591-e77df9af309c   10Gi       RWO            Delete           Bound    arc/sqldemo10-logs-claim   default                 7d14h
pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513   15Gi       RWO            Delete           Bound    arc/sqldemo10-data-claim   default                 7d14h
pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5   15Gi       RWO            Delete           Bound    arc/data-controldb         default                 7d14h
pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb   10Gi       RWO            Delete           Bound    arc/logs-controldb         default                 7d14h
pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4   10Gi       RWO            Delete           Bound    arc/logs-logsdb-0          default                 7d14h
pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd   15Gi       RWO            Delete           Bound    arc/data-logsdb-0          default                 7d14h

Przykład przedstawiający oświadczenia trwałego woluminu:


kubectl get persistentvolumeclaims -n arc

NAME                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
data-controldb         Bound    pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5   15Gi       RWO            default        7d14h
data-controller        Bound    pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad   15Gi       RWO            default        7d14h
data-logsdb-0          Bound    pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd   15Gi       RWO            default        7d14h
data-metricsdb-0       Bound    pvc-3e772f20-ed89-4642-b34d-8bb11b088afa   15Gi       RWO            default        7d14h
logs-controldb         Bound    pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb   10Gi       RWO            default        7d14h
logs-controller        Bound    pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91   10Gi       RWO            default        7d14h
logs-logsdb-0          Bound    pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4   10Gi       RWO            default        7d14h
logs-metricsdb-0       Bound    pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493   10Gi       RWO            default        7d14h
sqldemo10-data-claim   Bound    pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513   15Gi       RWO            default        7d14h
sqldemo10-logs-claim   Bound    pvc-8e2cacbc-e953-4901-8591-e77df9af309c   10Gi       RWO            default        7d14h
sqldemo11-data-claim   Bound    pvc-07fc7b9f-9a37-4796-9442-4405147120da   15Gi       RWO            default        7d4h
sqldemo11-logs-claim   Bound    pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665   10Gi       RWO            default        7d4h

Czynniki, które należy wziąć pod uwagę podczas wybierania konfiguracji magazynu

Wybranie odpowiedniej klasy magazynu jest ważne dla odporności i wydajności danych. Wybranie niewłaściwej klasy magazynu może spowodować ryzyko całkowitej utraty danych w przypadku awarii sprzętu lub spowodować mniej optymalną wydajność.

Zazwyczaj istnieją dwa typy magazynów:

Magazyn lokalny — magazyn aprowizowany na lokalnych dyskach twardych w danym węźle. Ten rodzaj magazynu może być idealny pod względem wydajności, ale wymaga w szczególności projektowania nadmiarowości danych przez replikowanie danych między wieloma węzłami.
Zdalny, udostępniony magazyn — magazyn aprowizowany na niektórych zdalnych urządzeniach magazynujących — na przykład usługa SAN, NAS lub magazynu w chmurze, na przykład EBS lub Azure Files. Ten rodzaj magazynu zwykle zapewnia nadmiarowość danych automatycznie, ale nie jest tak szybki, jak magazyn lokalny może być.

Klasy magazynu oparte na systemie plików NFS

W zależności od konfiguracji serwera NFS i dostawcy obsługi administracyjnej klasy magazynu może być konieczne ustawienie supplementalGroups w konfiguracjach zasobnika dla wystąpień bazy danych i może być konieczne zmianę konfiguracji serwera NFS w celu używania identyfikatorów grup przekazanych przez klienta (w przeciwieństwie do wyszukiwania identyfikatorów grup na serwerze przy użyciu przekazanego identyfikatora użytkownika). Skontaktuj się z administratorem systemu plików NFS, aby ustalić, czy tak jest.

Właściwość supplementalGroups przyjmuje tablicę wartości, które można ustawić we wdrożeniu. Kontroler danych usługi Azure Arc stosuje je do wszystkich tworzonych wystąpień bazy danych.

Aby ustawić tę właściwość, uruchom następujące polecenie:

az arcdata dc config add --path custom/control.json --json-values 'spec.security.supplementalGroups="1234556"'

Konfiguracja magazynu kontrolera danych

Niektóre usługi w usłudze Azure Arc dla usług danych zależą od skonfigurowania do korzystania ze zdalnego magazynu udostępnionego, ponieważ usługi nie mają możliwości replikowania danych. Te usługi znajdują się w kolekcji zasobników kontrolera danych:

Usługa	Oświadczenia trwałego woluminu
OpenSearch	`<namespace>/logs-logsdb-0`, `<namespace>/data-logsdb-0`
InfluxDB	`<namespace>/logs-metricsdb-0`, `<namespace>/data-metricsdb-0`
Wystąpienie SQL kontrolera	`<namespace>/logs-controldb`, `<namespace>/data-controldb`
Usługa interfejsu API kontrolera	`<namespace>/data-controller`

W momencie aprowizacji kontrolera danych klasa magazynu, która ma być używana dla każdego z tych woluminów trwałych, jest określana przez przekazanie klasy --storage-| -sc parametr polecenia az arcdata dc create lub przez ustawienie klas magazynu w control.json pliku szablonu wdrożenia, który jest używany. Jeśli używasz witryny Azure Portal do utworzenia kontrolera danych w trybie bezpośrednio połączonego, wybrany szablon wdrożenia ma wstępnie zdefiniowaną klasę magazynu w szablonie lub możesz wybrać szablon, który nie ma wstępnie zdefiniowanej klasy magazynu. Jeśli szablon nie definiuje klasy magazynu, w portalu zostanie wyświetlony monit o podanie tej klasy. Jeśli używasz niestandardowego szablonu wdrażania, możesz określić klasę magazynu.

Szablony wdrażania, które są dostarczane poza ramką, mają domyślną klasę magazynu określoną, która jest odpowiednia dla środowiska docelowego, ale można ją przesłonić podczas wdrażania. Zobacz szczegółowe kroki tworzenia niestandardowych szablonów konfiguracji w celu zmiany konfiguracji klasy magazynu dla zasobników kontrolera danych w czasie wdrażania.

Jeśli ustawisz klasę magazynu przy użyciu parametru --storage-class lub -sc, ta klasa magazynu jest używana zarówno dla klas magazynu dzienników, jak i danych. Jeśli ustawisz klasy magazynu w pliku szablonu wdrożenia, możesz określić różne klasy magazynu dla dzienników i danych.

Ważne czynniki, które należy wziąć pod uwagę podczas wybierania klasy magazynu dla zasobników kontrolera danych:

Należy użyć zdalnej, udostępnionej klasy magazynu, aby zapewnić trwałość danych i tak, aby w przypadku śmierci zasobnika lub węzła, gdy zasobnik zostanie przywrócony, może ponownie nawiązać połączenie z woluminem trwałym.
Dane zapisywane w wystąpieniu SQL kontrolera, metrykach BAZY danych i bazie danych dzienników są zwykle dość małe i nie są wrażliwe na opóźnienia, dzięki czemu magazyn o bardzo szybkiej wydajności nie ma krytycznego znaczeniu. Jeśli masz użytkowników, którzy często korzystają z interfejsów Grafana i Kibana i masz dużą liczbę wystąpień bazy danych, użytkownicy mogą korzystać z szybszego magazynowania.
Wymagana pojemność magazynu jest zmienna z liczbą wdrożonych wystąpień bazy danych, ponieważ dzienniki i metryki są zbierane dla każdego wystąpienia bazy danych. Dane są przechowywane w dziennikach i bazie danych metryk przez dwa (2) tygodnie przed ich przeczyszczeniem.
Zmiana klasy magazynu po wdrożeniu jest trudna, nie udokumentowana i nieobsługiwana. Pamiętaj, aby poprawnie wybrać klasę magazynu w czasie wdrażania.

Uwaga

Jeśli nie określono żadnej klasy magazynu, zostanie użyta domyślna klasa magazynu. Dla klastra Kubernetes może istnieć tylko jedna domyślna klasa magazynu. Możesz zmienić domyślną klasę magazynu.

Konfiguracja magazynu wystąpienia bazy danych

Każde wystąpienie bazy danych ma dane, dzienniki i kopie zapasowe woluminów trwałych. Klasy magazynu dla tych trwałych woluminów można określić w czasie wdrażania. Jeśli nie określono żadnej klasy magazynu, zostanie użyta domyślna klasa magazynu.

Podczas tworzenia wystąpienia przy użyciu metody az sql mi-arc create lub az postgres server-arc createistnieją cztery parametry, których można użyć do ustawiania klas magazynu:

Nazwa parametru, krótka nazwa	Sposób użycia
`--storage-class-data`, `-d`	Klasa magazynu dla wszystkich plików danych (.mdf, ndf). Jeśli nie zostanie określony, domyślnie zostanie ustawiona klasa magazynu dla kontrolera danych.
`--storage-class-logs`, `-g`	Klasa magazynu dla wszystkich plików dziennika. Jeśli nie zostanie określony, domyślnie zostanie ustawiona klasa magazynu dla kontrolera danych.
`--storage-class-data-logs`	Klasa magazynu dla plików dziennika transakcji bazy danych. Jeśli nie zostanie określony, domyślnie zostanie ustawiona klasa magazynu dla kontrolera danych.
`--storage-class-backups`	Klasa magazynu dla wszystkich plików kopii zapasowych. Jeśli nie zostanie określony, domyślnie zostanie ustawiona klasa magazynu dla danych (`--storage-class-data`). Do tworzenia kopii zapasowych należy użyć klasy magazynu obsługującej funkcję ReadWriteMany (RWX). Dowiedz się więcej o trybach dostępu.

Ostrzeżenie

Jeśli nie określisz klasy magazynu dla kopii zapasowych, wdrożenie używa klasy magazynu określonej dla danych. Jeśli ta klasa magazynu nie jest w stanie RWX, przywracanie do punktu w czasie może nie działać zgodnie z potrzebami.

W poniższej tabeli wymieniono ścieżki wewnątrz kontenera usługi Azure SQL Managed Instance zamapowanego na trwały wolumin dla danych i dzienników:

Nazwa parametru, krótka nazwa	Ścieżka wewnątrz `mssql-miaa` kontenera	opis
`--storage-class-data`, `-d`	/var/opt	Zawiera katalogi instalacji mssql i innych procesów systemowych. Katalog mssql zawiera dane domyślne (w tym dzienniki transakcji), dziennik błędów i katalogi kopii zapasowych
`--storage-class-logs`, `-g`	/var/log	Zawiera katalogi przechowujące dane wyjściowe konsoli (stderr, stdout), inne informacje rejestrowania procesów wewnątrz kontenera

W poniższej tabeli wymieniono ścieżki wewnątrz kontenera wystąpienia bazy danych PostgreSQL, które są mapowane na trwały wolumin dla danych i dzienników:

Nazwa parametru, krótka nazwa	Ścieżka wewnątrz kontenera postgres	opis
`--storage-class-data`, `-d`	/var/opt/postgresql	Zawiera katalogi danych i dzienników dla instalacji postgres
`--storage-class-logs`, `-g`	/var/log	Zawiera katalogi przechowujące dane wyjściowe konsoli (stderr, stdout), inne informacje rejestrowania procesów wewnątrz kontenera

Każde wystąpienie bazy danych ma oddzielny trwały wolumin dla plików danych, dzienników i kopii zapasowych. Oznacza to, że istnieje separacja operacji we/wy dla każdego z tych typów plików podlegających sposobie aprowizowania magazynu przez aprowizator woluminów. Każde wystąpienie bazy danych ma własne oświadczenia trwałego woluminu i woluminy trwałe.

Jeśli w danym wystąpieniu bazy danych istnieje wiele baz danych, wszystkie bazy danych używają tego samego trwałego oświadczenia woluminu, trwałego woluminu i klasy magazynu. Wszystkie kopie zapasowe — zarówno różnicowe kopie zapasowe dziennika, jak i pełne kopie zapasowe używają tego samego trwałego oświadczenia woluminu i trwałego woluminu. Oświadczenia trwałego woluminu dla zasobników wystąpienia bazy danych są pokazane poniżej:

Wystąpienie	Oświadczenia trwałego woluminu
Wystąpienie zarządzane Azure SQL	`<namespace>/logs-<instance name>-0`, `<namespace>/data-<instance name>-0`
Wystąpienie usługi Azure Database for PostgreSQL	`<namespace>/logs--<instance name>-0`, `<namespace>/data--<instance name>-0`
Azure PostgreSQL	`<namespace>/logs-<instance name>-<ordinal>`, `<namespace>/data-<instance name>-0`

Ważne czynniki, które należy wziąć pod uwagę podczas wybierania klasy magazynu dla zasobników wystąpień bazy danych:

Począwszy od wersji usług danych Azure Arc z lutego 2022 r., należy określić klasę magazynu z obsługą funkcji ReadWriteMany (RWX) na potrzeby tworzenia kopii zapasowych. Dowiedz się więcej o trybach dostępu. Jeśli dla kopii zapasowych nie określono żadnej klasy magazynu, zostanie użyta domyślna klasa magazynu na platformie Kubernetes, a jeśli nie jest to możliwe, wdrożenie wystąpienia zarządzanego usługi Azure SQL może zakończyć się niepowodzeniem.
Wystąpienia bazy danych można wdrożyć w pojedynczym wzorcu zasobnika lub w wielu wzorcach zasobników. Przykładem pojedynczego wzorca zasobnika jest warstwa cenowa Ogólnego przeznaczenia wystąpienie zarządzane usługi Azure SQL. Przykładem wzorca wielokrotnego zasobnika jest wystąpienie zarządzane usługi Azure SQL o wysokiej dostępności Krytyczne dla działania firmy warstwy cenowej. Wystąpienia bazy danych wdrożone przy użyciu pojedynczego wzorca zasobnika muszą używać zdalnej, udostępnionej klasy magazynu, aby zapewnić trwałość danych i tak, aby w przypadku śmierci zasobnika lub węzła, gdy zasobnik zostanie przywrócony, może ponownie nawiązać połączenie z woluminem trwałym. Z kolei wystąpienie zarządzane usługi Azure SQL o wysokiej dostępności używa zawsze włączonych grup dostępności do replikowania danych z jednego wystąpienia do innego synchronicznie lub asynchronicznie. Szczególnie w przypadku, gdy dane są replikowane synchronicznie, zawsze istnieje wiele kopii danych — zwykle trzy kopie. W związku z tym można użyć magazynu lokalnego lub zdalnych klas magazynu udostępnionego dla plików danych i dzienników. Jeśli korzystasz z magazynu lokalnego, dane są nadal zachowywane nawet w przypadku awarii zasobnika, węzła lub sprzętu magazynu, ponieważ istnieje wiele kopii danych. Biorąc pod uwagę tę elastyczność, możesz użyć magazynu lokalnego w celu uzyskania lepszej wydajności.
Wydajność bazy danych jest w dużej mierze funkcją przepływności we/wy danego urządzenia magazynowego. Jeśli baza danych jest duża w przypadku operacji odczytu lub dużego obciążenia, należy wybrać klasę magazynu ze sprzętem przeznaczonym dla tego typu obciążenia. Jeśli na przykład baza danych jest używana głównie do zapisu, możesz wybrać magazyn lokalny z macierzą RAID 0. Jeśli baza danych jest używana głównie do odczytu niewielkiej ilości "gorących danych", ale istnieje duża całkowita ilość magazynowania zimnych danych, możesz wybrać urządzenie SAN obsługujące magazyn warstwowy. Wybór odpowiedniej klasy magazynu nie różni się od wyboru typu magazynu, który ma być używany dla dowolnej bazy danych.
Jeśli używasz lokalnego modułu aprowizacji woluminów magazynu, upewnij się, że woluminy lokalne, które są aprowidowane na potrzeby danych, dzienników i kopii zapasowych, są przeznaczone dla różnych bazowych urządzeń magazynujących, aby uniknąć rywalizacji o we/wy dysku. System operacyjny powinien również znajdować się na woluminie zainstalowanym na osobnych dyskach. Jest to zasadniczo takie same wskazówki, jak w przypadku wystąpienia bazy danych na sprzęcie fizycznym.
Ponieważ wszystkie bazy danych w danym wystąpieniu współużytkują trwałe oświadczenie woluminu i trwały wolumin, pamiętaj, aby nie przenosić zajętych wystąpień bazy danych w tym samym wystąpieniu bazy danych. Jeśli to możliwe, należy oddzielić zajęte bazy danych na własne wystąpienia bazy danych, aby uniknąć rywalizacji o we/wy. Ponadto użyj etykiety węzła przeznaczonej do lądowania wystąpień bazy danych na oddzielnych węzłach, aby dystrybuować ogólny ruch we/wy między wieloma węzłami. Jeśli używasz wirtualizacji, rozważ dystrybucję ruchu we/wy nie tylko na poziomie węzła, ale także połączone działanie we/wy wykonywane przez wszystkie maszyny wirtualne węzłów na danym hoście fizycznym.

Szacowanie wymagań dotyczących magazynu

Każdy zasobnik zawierający dane stanowe używa co najmniej dwóch trwałych woluminów — jednego trwałego woluminu dla danych i innego trwałego woluminu dla dzienników. W poniższej tabeli wymieniono liczbę woluminów trwałych wymaganych dla pojedynczego kontrolera danych, wystąpienia zarządzanego usługi Azure SQL, wystąpienia usługi Azure Database for PostgreSQL i wystąpienia usługi Azure PostgreSQL w warstwie HiperSkala:

Typ zasobu	Liczba zasobników stanowych	Wymagana liczba woluminów trwałych
Kontroler danych	4 (`control`, `controldb`, `logsdb`, `metricsdb`)	4 * 2 = 8
Wystąpienie zarządzane Azure SQL	1	2
Azure PostgreSQL	1	2

W poniższej tabeli przedstawiono łączną liczbę woluminów trwałych wymaganych do wdrożenia przykładowego:

Typ zasobu	Liczba wystąpień	Wymagana liczba woluminów trwałych
Kontroler danych	1	4 * 2 = 8
Wystąpienie zarządzane Azure SQL	5	5 * 2 = 10
Azure PostgreSQL	5	5 * 2 = 10
Łączna liczba woluminów trwałych		8 + 10 + 10 = 28

To obliczenie może służyć do planowania magazynu dla klastra Kubernetes na podstawie aprowizacji magazynu lub środowiska. Jeśli na przykład lokalny program aprowizacji magazynu jest używany dla klastra Kubernetes z pięcioma węzłami (5), w przypadku przykładowego wdrożenia powyżej każdego węzła wymagany jest co najmniej magazyn dla 10 woluminów trwałych. Podobnie podczas aprowizowania klastra usługi Azure Kubernetes Service (AKS) z pięcioma węzłami (5) wybierając odpowiedni rozmiar maszyny wirtualnej dla puli węzłów, tak aby można było dołączyć 10 dysków danych, ma kluczowe znaczenie. Więcej informacji na temat sposobu rozmiaru węzłów na potrzeby magazynu dla węzłów usługi AKS można znaleźć tutaj.

Wybieranie odpowiedniej klasy magazynu

Lokacje lokalne i brzegowe

Firma Microsoft i jej partnerzy OEM, OS i Kubernetes mają program weryfikacji usług danych Azure Arc. Ten program zapewnia porównywalne wyniki testu z zestawu narzędzi do testowania certyfikacji. Testy oceniają zgodność funkcji, wyniki testów obciążeniowych oraz wydajność i skalowalność. Wyniki testu wskazują używany system operacyjny, używana dystrybucja Kubernetes, używana funkcja HW, używany dodatek CSI i używane klasy magazynu. Pomaga to klientom wybrać najlepszą klasę magazynu, system operacyjny, dystrybucję Kubernetes i sprzęt dla swoich wymagań. Więcej informacji na temat tego programu i wyników testów można znaleźć tutaj.

Chmura publiczna, zarządzane usługi Kubernetes

W przypadku usług Kubernetes opartych na chmurze publicznej możemy wprowadzić następujące zalecenia:

Usługa w chmurze publicznej	Zalecenie
Azure Kubernetes Service (AKS)	Usługa Azure Kubernetes Service (AKS) ma dwa typy magazynu — Azure Files i Azure Dyski zarządzane. Każdy typ magazynu ma dwie warstwy cenowe/wydajność — Standardowa (HDD) i Premium (SSD). W związku z tym cztery klasy magazynu dostępne w usłudze AKS to `azurefile` (warstwa Standardowa usługi Azure Files), `azurefile-premium` (warstwa Premium usługi Azure Files), `default` (warstwa Standardowa usługi Azure Disks) i `managed-premium` (warstwa Premium usługi Azure Disks). Domyślna klasa magazynu to `default` (warstwa Standardowa usługi Azure Disks). Istnieją znaczne różnice cenowe między typami i warstwami, które należy wziąć pod uwagę. W przypadku obciążeń produkcyjnych z wymaganiami o wysokiej wydajności zalecamy użycie `managed-premium` dla wszystkich klas magazynu. W przypadku obciążeń tworzenia i testowania, weryfikacji koncepcji itp., gdy koszt jest brany pod uwagę, jest to `azurefile` najmniej kosztowna opcja. Wszystkie cztery opcje mogą być używane w sytuacjach wymagających zdalnego magazynu udostępnionego, ponieważ są to wszystkie urządzenia magazynujące dołączone do sieci na platformie Azure. Przeczytaj więcej o usłudze AKS Storage.
AWS Elastic Kubernetes Service (EKS)	Usługa Elastic Kubernetes Service firmy Amazon ma jedną podstawową klasę magazynu — opartą na sterowniku magazynu EBS CSI. Jest to zalecane w przypadku obciążeń produkcyjnych. Istnieje nowy sterownik magazynu — sterownik magazynu EFS CSI — który można dodać do klastra EKS, ale jest obecnie w fazie beta i może ulec zmianie. Mimo że platforma AWS twierdzi, że ten sterownik magazynu jest obsługiwany w środowisku produkcyjnym, nie zalecamy używania go, ponieważ jest on nadal w wersji beta i podlega zmianie. Klasa magazynu EBS jest domyślna i nosi nazwę `gp2`. Przeczytaj więcej na temat usługi EKS Storage.
Google Kubernetes Engine (GKE)	Aparat Google Kubernetes Engine (GKE) ma tylko jedną klasę magazynu o nazwie `standard`. Ta klasa jest używana dla dysków trwałych GCE. Jest jedyną, jest to również wartość domyślna. Chociaż istnieje lokalny, statyczny moduł aprowizacji woluminów dla GKE, którego można używać z bezpośrednio dołączonymi dyskami SSD, nie zalecamy używania go, ponieważ nie jest on obsługiwany ani obsługiwany przez firmę Google. Przeczytaj więcej na temat magazynu GKE.

Udostępnij za pośrednictwem