Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
DOTYCZY:
Azure Stack Edge Pro — GPU
Azure Stack Edge Pro 2
Azure Stack Edge Pro — R
Azure Stack Edge Mini R
Na urządzeniu Azure Stack Edge Pro klaster Kubernetes jest tworzony podczas konfigurowania roli obliczeniowej. Po utworzeniu klastra Kubernetes konteneryzowane aplikacje można wdrożyć w klastrze Kubernetes w zasobnikach. Istnieją różne sposoby zapewniania przestrzeni zasobnikom w klastrze Kubernetes.
W tym artykule opisano metody aprowizowania magazynu w klastrze Kubernetes ogólnie i w szczególności w kontekście urządzenia Azure Stack Edge Pro.
Wymagania dotyczące magazynu dla zasobników Kubernetes
Zasobniki Kubernetes są bezstanowe, ale aplikacje, które uruchamiają, są zwykle stanowe. Ponieważ zasobniki mogą być krótkotrwałe i ponownie uruchamiają się, przechodzą w tryb failover lub przechodzą między węzłami Kubernetes, należy spełnić następujące wymagania dotyczące magazynu skojarzonego z zasobnikiem.
Magazyn musi:
- Żyj poza kapsułą.
- Być niezależny od cyklu życia zasobnika.
- Być dostępny ze wszystkich węzłów platformy Kubernetes.
Aby zrozumieć, jak magazyn jest zarządzany dla platformy Kubernetes, należy poznać dwa zasoby interfejsu API:
PersistentVolume (PV): jest to fragment magazynu w klastrze Kubernetes. Magazyn Kubernetes może być statycznie aprowizowany jako
PersistentVolume. Można go również dynamicznie aprowizować jakoStorageClass.PersistentVolumeClaim (PVC): jest to żądanie przechowywania od użytkownika. PvCs zużywają zasoby PV. PVC mogą żądać określonego rozmiaru i trybów dostępu.
Ponieważ użytkownicy potrzebują
PersistentVolumeso różnych właściwościach dla różnych problemów, administratorzy klastra muszą mieć możliwość zaoferowania różnychPersistentVolumesz różnicami wykraczającymi poza same rozmiar i tryby dostępu. Do tych potrzeb potrzebujesz zasobuStorageClass.
Aprowizacja magazynu może być statyczna lub dynamiczna. Każdy z typów przydzielania zasobów jest omówiony w poniższych sekcjach.
Statyczne zaprovisionowanie
Administratorzy klastrów Kubernetes mogą statycznie aprowizować magazyn. W tym celu mogą używać zaplecza magazynu opartego na systemach plików SMB/NFS lub używać dysków iSCSI, które są dołączane lokalnie przez sieć w środowisku lokalnym, a nawet korzystać z usług Azure Files lub Azure Disks w chmurze. Ten typ magazynu nie jest domyślnie aprowizowany, a administratorzy klastra muszą planować tę aprowizację i zarządzać nią.
Oto diagram przedstawiający sposób, w jaki statycznie zarządzane zasoby pamięciowe są wykorzystywane w środowisku Kubernetes.
Są wykonywane następujące czynności:
Aprowizuj magazyn: administrator klastra aprowizuje magazyn. W tym przykładzie administrator klastra tworzy jeden lub więcej udziałów SMB, które automatycznie tworzą obiekty trwałych woluminów w klastrze Kubernetes, odpowiadające każdemu z tych udziałów.
Rejestr magazynowy: należy przesłać wdrożenie Persistent Volume Claim (PVC), które żąda zasobów magazynowych. To oświadczenie dotyczące magazynu to PersistentVolumeClaim (PVC). Jeśli rozmiar i tryb dostępu PV są zgodne z PVC, to PVC jest powiązane z PV. PVC i PV mapować jeden do jednego.
Zamontować PVC w kontenerze: po powiązaniu PVC z PV można zamontować ten PVC na ścieżce w kontenerze. Gdy logika aplikacji w kontenerze odczytuje/zapisuje z/do tej ścieżki, dane są zapisywane w magazynie SMB.
Dynamiczne przydzielanie
Oto diagram przedstawiający sposób, w jaki statycznie przydzielone zasoby pamięci są używane w Kubernetes.
Są wykonywane następujące czynności:
Definiowanie klasy magazynu: administrator klastra definiuje klasę magazynu w zależności od środowiska operacyjnego klastra Kubernetes. Administrator klastra wdraża również provisionera, który jest kolejnym zasobnikiem lub aplikacją wdrożonym w klastrze Kubernetes. Dostawca ma wszystkie szczegóły dotyczące dynamicznego udostępniania zasobów.
Zgłoszenie roszczenia do magazynu: przesyłasz aplikację, która ubiega się o przyznanie magazynu. Po utworzeniu elementu PVC przy użyciu tego odwołania do klasy magazynu zostaje wywołany aprowizator.
Dynamiczne przydzielanie magazynu: aprowizator dynamicznie tworzy udostępniony zasób skojarzony z magazynem dysku lokalnego. Po utworzeniu udziału tworzy on również obiekt PV automatycznie odpowiadający temu udziałowi.
Zamontować PVC do kontenera: Po powiązaniu PVC z PV można zamontować PVC do kontenera do ścieżki w taki sam sposób jak statyczne prowizjonowanie i odczytywać lub zapisywać do zasobu.
Przydzielanie zasobów pamięci masowej w usłudze Azure Stack Edge Pro
Na urządzeniu Azure Stack Edge Pro statycznie przydzielone PersistentVolumes są tworzone przy użyciu możliwości przechowywania danych urządzenia. Po aprowizacji udziału i włączeniu opcji Użyj udziału z Edge compute, ta akcja powoduje automatyczne utworzenie zasobu PV w klastrze Kubernetes.
Aby użyć warstwowania w chmurze, możesz utworzyć udział w chmurze dla Edge z włączoną opcją użycia z obliczeniami Edge. Dla tego udziału ponownie zostanie automatycznie utworzony PV. Wszystkie dane aplikacji zapisywane w udziale usługi Edge są warstwowe w chmurze.
Można utworzyć udziały SMB i NFS, aby statycznie udostępniać woluminy trwałe (PVs) na urządzeniu Azure Stack Edge Pro. Po aprowizowaniu jednostki PV należy przesłać żądanie PVC, aby ubiegać się o tę przestrzeń dyskową. Oto przykład wdrożenia yaml PVC, który zgłasza roszczenie do magazynu i wykorzystuje przydzielone udziały.
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: pvc-smb-flexvol
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 10Gi
volumeName: <nfs-or-smb-share-name-here>
storageClassName: ""
Aby uzyskać wartość pola volumeName, wybierz punkt montowania lokalnego dla modułów obliczeniowych Edge po utworzeniu udziału SMB lub NFS. To jest takie samo jak nazwa udziału.
Aby uzyskać więcej informacji, zobacz Wdrażanie aplikacji stanowej za pomocą statycznej aprowizacji na Azure Stack Edge Pro za pomocą kubectl.
Aby uzyskać dostęp do tej samej statycznie aprowizowanej pamięci, odpowiednie opcje montowania woluminu dla powiązań pamięci dla IoT są następujące. To /home/input ścieżka, w której wolumin jest dostępny w kontenerze.
{
"HostConfig": {
"Mounts": [
{
"Target": "/home/input",
"Source": "<nfs-or-smb-share-name-here>",
"Type": "volume"
},
{
"Target": "/home/output",
"Source": "<nfs-or-smb-share-name-here>",
"Type": "volume"
}]
}
}
Azure Stack Edge Pro ma również wbudowaną funkcję StorageClass zwaną ase-node-local, która używa pamięci dysku danych dołączonego do węzła Kubernetes. Ten StorageClass obsługuje dynamiczną aprowizację. Możesz utworzyć StorageClass odwołanie w aplikacjach zasobników, a PV zostanie automatycznie utworzone. Aby uzyskać więcej informacji, zobacz pulpit nawigacyjny platformy Kubernetes do wykonywania zapytań dotyczących usługi ase-node-local StorageClass.
Aby uzyskać więcej informacji, zobacz Wdrażanie aplikacji stanowej przy użyciu dynamicznego aprowizowania na Azure Stack Edge Pro przy użyciu kuebctl.
Wybieranie typu magazynu
W zależności od wdrażanych obciążeń może być konieczne wybranie typu magazynu.
Jeśli chcesz
ReadWriteManyużyć trybu dostępu dlaPersistentVolumes, gdzie wolumeny są montowane jako odczyt-zapis przez wiele węzłów wdrażających, użyj statycznego przydziału dla udziałów SMB/NFS.Jeśli wdrażane aplikacje mają na przykład wymagania dotyczące zgodności z rozwiązaniem POSIX, takie jak MongoDB, PostgreSQL, MySQL lub Prometheus, użyj wbudowanej klasy StorageClass. Tryby dostępu to
ReadWriteOncelub wolumin jest instalowany jako odczyt-zapis przez jeden węzeł.
Aby uzyskać więcej informacji na temat trybów dostępu, zobacz Tryb dostępu do woluminów Kubernetes.
Następne kroki
Aby dowiedzieć się, jak statycznie aprowizować element PersistentVolume, zobacz:
Aby dowiedzieć się, jak dynamicznie aprowizować element StorageClass, zobacz: