Przygotowywanie systemu Linux dla woluminów usługi Edge

Artykuł
11/05/2024

W tym artykule opisano sposób przygotowania systemu Linux do obsługi woluminów brzegowych przy użyciu usługi AKS włączonej przez usługę Azure Arc, Edge Essentials lub Ubuntu.

Uwaga

Minimalna obsługiwana wersja jądra systemu Linux to 5.1. Obecnie istnieją znane problemy z wersjami 6.4 i 6.2.

Wymagania wstępne

Uwaga

Usługa Azure Container Storage włączona przez usługę Azure Arc jest dostępna tylko w następujących regionach: Wschodnie stany USA, Wschodnie stany USA 2, Zachodnie stany USA, Zachodnie stany USA 2, Zachodnie stany USA 3, Europa Północna, Europa Zachodnia.

Odinstalowywanie poprzedniego wystąpienia usługi Azure Container Storage włączonego przez rozszerzenie usługi Azure Arc

Jeśli wcześniej zainstalowano wersję usługi Azure Container Storage włączoną przez usługę Azure Arc wcześniej niż 2.1.0-preview, należy odinstalować to poprzednie wystąpienie, aby zainstalować nowszą wersję. Jeśli zainstalowano wersję 1.2.0-preview lub starszą, skorzystaj z tych instrukcji. Wersje po wersji 2.1.0-preview można uaktualnić i nie wymagają tego odinstalowania.

Aby usunąć starą wersję rozszerzenia, zasoby Kubernetes zawierające odwołania do starej wersji rozszerzenia muszą zostać wyczyszczone. Wszystkie oczekujące zasoby mogą opóźnić czyszczenie rozszerzenia. Istnieją co najmniej dwa sposoby czyszczenia tych zasobów: przy użyciu metody kubectl delete <resource_type> <resource_name>lub przez "niezastosowywanie" plików YAML używanych do tworzenia zasobów. Zasoby, które należy usunąć, to zazwyczaj zasobniki, przywoływały pvc i podvolume CRD (jeśli skonfigurowano wolumin usługi Cloud Ingest Edge). Alternatywnie można przekazać następujące cztery pliki YAML przy kubectl delete -f użyciu następujących poleceń w określonej kolejności. Te zmienne muszą zostać zaktualizowane przy użyciu informacji:
- YOUR_DEPLOYMENT_FILE_NAME_HERE: Dodaj nazwy plików wdrożenia. W przykładzie w tym artykule użyta nazwa pliku to deploymentExample.yaml. Jeśli utworzono wiele wdrożeń, każdy z nich musi zostać usunięty w osobnym wierszu.
- YOUR_PVC_FILE_NAME_HERE: Dodaj trwałe nazwy plików oświadczenia woluminu. W przykładzie w tym artykule, jeśli użyto woluminu usługi Cloud Ingest Edge, użyta nazwa pliku to cloudIngestPVC.yaml. Jeśli użyto lokalnego udostępnionego woluminu krawędzi, użyta nazwa pliku to localSharedPVC.yaml. Jeśli utworzono wiele kontrolerów PVC, każdy z nich musi zostać usunięty w osobnym wierszu.
- YOUR_EDGE_SUBVOLUME_FILE_NAME_HERE: Dodaj nazwy plików podrzędnych edge. W przykładzie w tym artykule użyta nazwa pliku to edgeSubvolume.yaml. Jeśli utworzono wiele podwolułów, każdy z nich musi zostać usunięty w osobnym wierszu.
- YOUR_EDGE_STORAGE_CONFIGURATION_FILE_NAME_HERE: dodaj tutaj nazwę pliku konfiguracji magazynu edge. W przykładzie w tym artykule użyta nazwa pliku to edgeConfig.yaml.
```
kubectl delete -f "<YOUR_DEPLOYMENT_FILE_NAME_HERE.yaml>"
kubectl delete -f "<YOUR_PVC_FILE_NAME_HERE.yaml>"   
kubectl delete -f "<YOUR_EDGE_SUBVOLUME_FILE_NAME_HERE.yaml>"
kubectl delete -f "<YOUR_EDGE_STORAGE_CONFIGURATION_FILE_NAME_HERE.yaml>"
```
Po usunięciu plików dla wdrożeń, kontrolerów PVC, podvolum edge i konfiguracji magazynu usługi Edge z poprzedniego kroku można odinstalować rozszerzenie przy użyciu następującego polecenia. Zastąp YOUR_RESOURCE_GROUP_NAME_HEREwartości , YOUR_CLUSTER_NAME_HEREi YOUR_EXTENSION_NAME_HERE odpowiednimi informacjami:
```
az k8s-extension delete --resource-group YOUR_RESOURCE_GROUP_NAME_HERE --cluster-name YOUR_CLUSTER_NAME_HERE --cluster-type connectedClusters --name YOUR_EXTENSION_NAME_HERE
```

Klaster Kubernetes połączony z usługą Arc

W tych instrukcjach założono, że masz już połączony z usługą Arc klaster Kubernetes. Aby połączyć istniejący klaster Kubernetes z usługą Azure Arc, zapoznaj się z tymi instrukcjami.

Jeśli chcesz używać usługi Azure Container Storage włączonej przez usługę Azure Arc z operacjami usługi Azure IoT, postępuj zgodnie z instrukcjami, aby utworzyć klaster dla operacji usługi Azure IoT.

Klastry z jednym węzłem i wieloma węzłami

Klaster z jednym węzłem jest często używany do celów programistycznych lub testowych ze względu na prostotę konfiguracji i minimalne wymagania dotyczące zasobów. Te klastry oferują lekkie i proste środowisko dla deweloperów do eksperymentowania z platformą Kubernetes bez złożoności konfiguracji z wieloma węzłami. Ponadto w sytuacjach, w których zasoby, takie jak procesor CPU, pamięć i magazyn, są ograniczone, klaster z jednym węzłem jest bardziej praktyczny. Łatwość konfiguracji i minimalne wymagania dotyczące zasobów sprawiają, że jest to odpowiedni wybór w środowiskach ograniczonych zasobami.

Jednak klastry z jednym węzłem mają ograniczenia, głównie w postaci brakujących funkcji, w tym brak wysokiej dostępności, odporność na uszkodzenia, skalowalność i wydajność.

Konfiguracja platformy Kubernetes z wieloma węzłami jest zwykle używana w scenariuszach produkcyjnych, przejściowych lub wielkoskalowych z powodu takich funkcji jak wysoka dostępność, odporność na uszkodzenia, skalowalność i wydajność. Klaster z wieloma węzłami wprowadza również wyzwania i kompromisy, w tym złożoność, nakład pracy, koszty i wydajność. Na przykład skonfigurowanie i utrzymanie klastra z wieloma węzłami wymaga dodatkowej wiedzy, umiejętności, narzędzi i zasobów (sieć, magazyn, obliczenia). Klaster musi obsługiwać koordynację i komunikację między węzłami, co prowadzi do potencjalnych opóźnień i błędów. Ponadto uruchamianie klastra z wieloma węzłami jest bardziej obciążane zasobami i jest bardziej kosztowne niż klaster z jednym węzłem. Optymalizacja użycia zasobów między węzłami ma kluczowe znaczenie dla utrzymania wydajności i wydajności klastra oraz aplikacji.

Podsumowując, klaster Kubernetes z jednym węzłem może być odpowiedni dla środowisk programistycznych, testowych i ograniczonych zasobami. Klaster z wieloma węzłami jest bardziej odpowiedni dla wdrożeń produkcyjnych, wysokiej dostępności, skalowalności i scenariuszy, w których wymagane są aplikacje rozproszone. Ten wybór zależy ostatecznie od konkretnych potrzeb i celów wdrożenia.

Minimalne wymagania sprzętowe

Klaster z jednym węzłem lub 2 węzłem

Zalecana maszyna wirtualna Standard_D8ds_v5
Równoważne specyfikacje na węzeł:
- 4 procesory CPU
- 16 GB pamięci RAM

Klaster z wieloma węzłami

Zalecana maszyna wirtualna Standard_D8as_v5
Równoważne specyfikacje na węzeł:
- 8 procesorów CPU
- 32 GB pamięci RAM

32 GB pamięci RAM służy jako bufor; jednak 16 GB pamięci RAM powinno wystarczyć. Konfiguracje edge Essentials wymagają 8 procesorów CPU z 10 GB pamięci RAM na węzeł, co czyni 16 GB pamięci RAM minimalnym wymaganiem.

Minimalne wymagania dotyczące magazynu

Wymagania dotyczące woluminów brzegowych

W przypadku korzystania z opcji magazynu odpornego na uszkodzenia woluminy brzegowe przydziela miejsce na dysku z odpornej na uszkodzenia puli magazynów, która składa się z magazynu wyeksportowanego przez każdy węzeł w klastrze.

Pula magazynów jest skonfigurowana do używania replikacji 3-dwukierunkowej w celu zapewnienia odporności na uszkodzenia. Po aprowizacji woluminu usługi Edge przydziela miejsce na dysku z puli magazynów i przydziela magazyn na 3 replikach.

Na przykład w klastrze 3-węzłowym z 20 GB miejsca na dysku na węzeł klaster ma pulę magazynów o rozmiarze 60 GB. Jednak ze względu na replikację ma efektywny rozmiar magazynu o rozmiarze 20 GB.

Gdy wolumin usługi Edge jest aprowizowany o żądanym rozmiarze 10 GB, przydziela zarezerwowany wolumin systemowy (statycznie rozmiar do 1 GB) i wolumin danych (rozmiar do żądanego rozmiaru woluminu, na przykład 10 GB). Zarezerwowany wolumin systemowy zużywa 3 GB (3 x 1 GB) miejsca na dysku w puli magazynów, a wolumin danych zużywa 30 GB (3 x 10 GB) miejsca na dysku w puli magazynów w sumie 33 GB.

Wymagania dotyczące woluminów pamięci podręcznej

Woluminy pamięci podręcznej wymagają co najmniej 4 GB na węzeł magazynu. Jeśli na przykład masz klaster z 3 węzłami, potrzebujesz co najmniej 12 GB miejsca do magazynowania.

Udostępnij za pośrednictwem