Rozwiązywanie znanych problemów i błędów podczas zarządzania magazynem w usłudze AKS Arc

Ten błąd odmowy uprawnień wskazuje, że domyślna klasa magazynu może nie być odpowiednia dla obciążeń i występuje w obciążeniach systemu Linux uruchomionych na platformie Kubernetes w wersji 1.19.x lub nowszej. Zgodnie z najlepszymi rozwiązaniami w zakresie zabezpieczeń wiele obciążeń systemu Linux określa securityContext fsGroup ustawienie zasobnika. Nie można uruchomić obciążeń w usłudze AKS w usłudze Azure Local, ponieważ domyślna klasa magazynu nie określa parametru fstype (=ext4) , więc platforma Kubernetes nie może zmienić własności plików i woluminów trwałych na podstawie żądanego fsGroup obciążenia.

Aby rozwiązać ten problem, zdefiniuj niestandardową klasę magazynu, której można użyć do aprowizacji kontrolerów PVC.

Utworzono nowy klaster obciążeń Kubernetes w wersji 1.16.10, a następnie zaktualizowano go do wersji 1.16.15. Po aktualizacji csi-msk8scsi-node-9x47m zasobnik został zablokowany w stanie ContainerCreating i zasobnik został zablokowany w stanie Zakończenie, kube-proxy-qqnkr jak pokazano w poniższych danych wyjściowych:

Error: kubectl.exe get nodes  
NAME              STATUS     ROLES    AGE     VERSION 
moc-lf22jcmu045   Ready      <none>   5h40m   v1.16.15 
moc-lqjzhhsuo42   Ready      <none>   5h38m   v1.16.15 
moc-lwan4ro72he   NotReady   master   5h44m   v1.16.15

\kubectl.exe get pods -A 

NAMESPACE     NAME                        READY   STATUS              RESTARTS   AGE 
    5h38m 
kube-system   csi-msk8scsi-node-9x47m     0/3     ContainerCreating   0          5h44m 
kube-system   kube-proxy-qqnkr            1/1     Terminating         0          5h44m  

Ponieważ kubelet skończyło się na złym stanie i nie może już komunikować się z serwerem interfejsu API, jedynym rozwiązaniem jest ponowne uruchomienie kubelet usługi. Po ponownym uruchomieniu klaster przechodzi w stan działania .

Magazyn dyskowy można wypełnić z utworzonych dzienników zrzutu awaryjnego. Jest to spowodowane wygasłym certyfikatem klienta agenta Geneva. Objawy mogą być następujące:

• Nie można uruchomić usług.
• Nie można uruchomić zasobników, wdrożeń itp. kubernetes z powodu niewystarczającej ilości zasobów.

Ten problem może mieć wpływ na dowolną operację, która polega na przydzielaniu miejsca na dysku lub zapisywaniu nowych plików, więc każdy błąd "za mało miejsca na dysku/zasobów" jest dobrą wskazówką. Aby sprawdzić, czy ten problem występuje w danym węźle, uruchom następujące polecenie powłoki:

clouduser@moc-lwm2oudnskl $ sudo du -h /var/lib/systemd/coredump/

To polecenie zgłasza miejsce do magazynowania używane przez pliki diagnostyczne.

Główna przyczyna

Wygaśnięcie certyfikatu klienta używanego do uwierzytelniania agenta Genewskiego w punkcie końcowym usługi powoduje awarię agenta, co powoduje awarię zrzutu. Pętla awarii/ponawiania prób agenta wynosi około 5 sekund podczas początkowego uruchamiania i nie ma limitu czasu. Oznacza to, że nowy plik (około 330 MB) jest tworzony w systemie plików węzła co kilka sekund, co może szybko korzystać z magazynu dyskowego.

Czynności zapobiegawcze

Preferowanym ograniczeniem ryzyka jest uaktualnienie do najnowszej wersji 1.10.18.10425, która ma zaktualizowany certyfikat. W tym celu należy najpierw ręcznie uaktualnić klastry obciążeń do dowolnej obsługiwanej wersji pomocniczej przed zaktualizowaniem hosta lokalnego platformy Azure.

Aby uzyskać więcej informacji o wydaniach usługi AKS Arc i wszystkich najnowszych wiadomościach usługi AKS w usłudze Azure Local, zasubskrybuj stronę wydań usługi AKS.

Jeśli uaktualnienie nie jest opcją, możesz wyłączyć usługę mdsd . Dla każdego węzła Mariner:

1. Wyłącz agenta Genewa przy użyciu następujących poleceń powłoki:

   sudo systemctl disable --now mdsd
   

2. Sprawdź, czy agent Genewa został pomyślnie wyłączony:

   sudo systemctl status mdsd
   

3. Usuń zebrane pliki za pomocą następującego polecenia:

   sudo find /var/lib/systemd/coredump/ -type f -mmin +1 -exec rm -f {} \;
   sudo find /run/systemd/propagate -name 'systemd-coredump@*' -delete
   sudo journalctl --rotate && sudo journalctl --vacuum-size=500M
   

4. Uruchom ponownie węzeł:

   sudo reboot
   

Błąd może wystąpić, jeśli masz sterownik SMB lub NFS CSI zainstalowany we wdrożeniu i uaktualnisz do kompilacji may ze starszej wersji. Jeden z parametrów o nazwie createSubDirnie jest już akceptowany. Jeśli dotyczy to wdrożenia, postępuj zgodnie z poniższymi instrukcjami, aby rozwiązać problem z błędem klasy magazynu.

Jeśli wystąpi ten błąd, zasobnik magazynu ulegnie awarii, a dzienniki wskazują, że createSubDir parametr jest nieprawidłowy.

Utwórz ponownie klasę magazynu.

Po usunięciu woluminu trwałego lub trwałego oświadczenia woluminu w środowisku usługi AKS Arc zostanie utworzony nowy wolumin trwały do mapowania na ten sam udział. Jednak podczas próby zainstalowania woluminu instalacja kończy się niepowodzeniem i upłynął limit czasu zasobnika z powodu błędu NewSmbGlobalMapping failed.

Aby obejść błąd instalacji nowego woluminu, możesz uruchomić Remove-SMBGlobalMapping protokół SSH w węźle systemu Windows i udostępnić udział odpowiadający woluminowi. Po uruchomieniu tego polecenia próby zainstalowania woluminu powinny zakończyć się powodzeniem.

Następne kroki

• Omówienie rozwiązywania problemów
• Znane problemy z programem Windows Admin Center