Zasady pomocy technicznej usługi Azure Red Hat OpenShift 4.0

Niektóre konfiguracje klastrów microsoft Azure Red Hat OpenShift 4 mogą mieć wpływ na możliwość obsługi klastra. Usługa Azure Red Hat OpenShift 4 umożliwia administratorom klastra wprowadzanie zmian w wewnętrznych składnikach klastra, ale nie wszystkie zmiany są obsługiwane. Poniższe zasady pomocy technicznej udostępniają, które modyfikacje naruszają zasady i unieważnią obsługę firmy Microsoft i oprogramowania Red Hat.

Wymagania dotyczące konfiguracji klastra

Compute

• Klaster musi mieć co najmniej trzy węzły robocze i trzy węzły główne.
• Nie skaluj procesów roboczych klastra do zera ani nie próbuj zamknąć klastra. Cofnięcie przydziału lub wyłączenie żadnej maszyny wirtualnej w grupie zasobów klastra nie jest obsługiwane.
• Nie twórz więcej niż 250 węzłów roboczych w klastrze. 250 to maksymalna liczba węzłów, które można utworzyć w klastrze. Aby uzyskać więcej informacji, zobacz Konfigurowanie wielu adresów IP dla modułu równoważenia obciążenia klastra Azure Red Hat OpenShift.
• Jeśli korzystasz z węzłów infrastruktury, nie uruchamiaj na nich żadnych nieoznaczonych obciążeń, ponieważ może to mieć wpływ na umowę dotyczącą poziomu usług i stabilność klastra. Ponadto zaleca się posiadanie trzech węzłów infrastruktury; jeden w każdej strefie dostępności. Aby uzyskać więcej informacji, zobacz Wdrażanie węzłów infrastruktury w klastrze usługi Azure Red Hat OpenShift.
• Węzły obliczeniowe inne niż RHCOS nie są obsługiwane. Na przykład nie można użyć węzła obliczeniowego Red Hat Enterprise Linux (RHEL).
• Nie próbuj usuwać, zastępować, dodawać ani modyfikować węzła głównego. Te zadania to operacje wysokiego ryzyka, które mogą powodować problemy z etcd, trwałą utratą sieci oraz utratą dostępu i możliwości zarządzania przez inżyniera niezawodności usługi (SRE). Jeśli uważasz, że węzeł główny powinien zostać zastąpiony lub usunięty, skontaktuj się z pomocą techniczną przed wprowadzeniem zmian.
• Upewnij się, że jest dostępny większy limit przydziału maszyn wirtualnych w przypadku, gdy węzły płaszczyzny sterowania muszą być skalowane w górę, utrzymując co najmniej dwukrotnie bieżącą liczbę dostępnych płaszczyzn vCPU sterowania.

Operatorów

• Wszystkie operatory klastra OpenShift muszą pozostać w stanie zarządzanym. Listę operatorów klastra można zwrócić, uruchamiając polecenie oc get clusteroperators.

Zarządzanie obciążeniami

• Nie dodawaj żadnych defektów, które uniemożliwią zaplanowanie żadnych domyślnych składników openShift.
• Aby uniknąć zakłóceń wynikających z konserwacji klastra, należy skonfigurować obciążenia w klastrze przy użyciu rozwiązań o wysokiej dostępności. Te praktyki obejmują, ale nie są ograniczone do preferencji i antypreferencji zasobników, budżetu zakłóceń zasobników oraz odpowiedniego skalowania.
• Nie uruchamiaj dodatkowych obciążeń w węzłach płaszczyzny sterowania. Chociaż można je zaplanować na węzłach płaszczyzny sterowania, powoduje to dodatkowe problemy z użyciem zasobów i stabilnością, które mogą mieć wpływ na cały klaster.
• Uruchamianie niestandardowych obciążeń (w tym operatorów zainstalowanych z usługi Operator Hub lub innych operatorów dostarczonych przez system Red Hat) w węzłach infrastruktury nie jest obsługiwane.

Rejestrowanie i monitorowanie

• Nie usuwaj ani nie modyfikuj domyślnej usługi Prometheus dla klastra, chyba że chodzi o modyfikację harmonogramu domyślnego wystąpienia Prometheus lub konfigurację trwałości. Jeśli konfigurujesz trwałość, nie zezwalaj na zapełnienie woluminu trwałego.
• Nie usuwaj ani nie modyfikuj domyślnej usługi klastra Alertmanager , domyślnego odbiornika ani żadnych domyślnych reguł alertów, z wyjątkiem dodawania innych odbiorników, które powiadamiają systemy zewnętrzne.
• Nie usuwaj ani nie modyfikuj rejestrowania usługi Azure Red Hat OpenShift (zasobników mdsd).

Sieć i zabezpieczenia

• Jeśli nie używasz własnej Grupy zabezpieczeń sieci przez funkcję bring your own Network Security Group, Grupa zabezpieczeń sieci dostarczona przez Azure Red Hat OpenShift nie może zostać zmodyfikowana ani zastąpiona. Każda próba zmodyfikowania lub zastąpienia NSG zostanie cofnięta.
• Wszystkie maszyny wirtualne klastra muszą mieć bezpośredni dostęp do Internetu wychodzącego, co najmniej do punktów końcowych usługi Azure Resource Manager (ARM) i rejestrowania usług (Genewa). Proksyfikacja ruchu HTTPS wymaganego do uruchomienia usługi Azure Red Hat OpenShift nie jest obsługiwana. Zobacz instrukcje dotyczące serwera proxy dla całego klastra , aby uzyskać informacje o konfiguracji powiązanej z serwerem proxy.
• Usługa Azure Red Hat OpenShift uzyskuje dostęp do klastra za pośrednictwem usługi Private Link. Nie usuwaj ani nie modyfikuj dostępu do usługi.

Zarządzanie klastrem

• Nie usuwaj ani nie modyfikuj tajnego klucza pobierania klastra arosvc.azurecr.io.
• Nie twórz nowych MachineConfig obiektów ani nie modyfikuj istniejących obiektów, chyba że są jawnie obsługiwane w dokumentacji usługi Azure Red Hat OpenShift.
• Nie twórz nowych KubeletConfig obiektów ani nie modyfikuj istniejących obiektów, chyba że są jawnie obsługiwane w dokumentacji usługi Azure Red Hat OpenShift.
• Nie ustawiaj żadnych unsupportedConfigOverrides opcji. Ustawienie tych opcji uniemożliwia uaktualnianie wersji pomocniczych.
• Nie umieszczaj zasad w ramach subskrypcji ani grupy zarządzania, które uniemożliwiają srEs normalne wykonywanie konserwacji względem klastra usługi Azure Red Hat OpenShift. Na przykład nie wymagaj tagów w grupie zasobów klastra zarządzanego przez dostawcę zasobów usługi Azure Red Hat OpenShift.
• Nie należy pomijać przypisania odmowy skonfigurowanego jako część usługi lub wykonywać zadania administracyjne zwykle zabronione przez przypisanie odmowy.
• Platforma OpenShift korzysta z możliwości automatycznego tagowania zasobów platformy Azure. Jeśli skonfigurowano zasady tagowania, nie należy stosować więcej niż 10 tagów zdefiniowanych przez użytkownika do zasobów w zarządzanej grupie zasobów.

Zarządzanie zdarzeniami

Zdarzenie to zdarzenie, które powoduje obniżenie lub awarię usług Azure Red Hat OpenShift. Zdarzenia są tworzone przez klienta lub członka customer experience and engagement (CEE) za pośrednictwem zgłoszenia do pomocy technicznej, bezpośrednio przez scentralizowany system monitorowania i zgłaszania alertów lub bezpośrednio przez członka zespołu inżyniera niezawodności lokacji (SRE).

W zależności od wpływu na usługę i klienta zdarzenie jest podzielone na kategorie pod względem ważności.

Ogólny przepływ pracy zarządzania nowym zdarzeniem jest opisany w następujący sposób:

1. Pierwsza osoba odpowiadająca za pomocą protokołu SRE jest powiadamiana o nowym zdarzeniu i rozpoczyna wstępne dochodzenie.

2. Po początkowym dochodzeniu zdarzenie jest przypisywane do osoby kierującej incydentem, która koordynuje działania naprawcze.

3. Lider zdarzenia zarządza całą komunikacją i koordynacją odzyskiwania, w tym wszelkimi odpowiednimi powiadomieniami lub aktualizacjami zgłoszenia do pomocy technicznej.

4. Po rozwiązaniu zdarzenia w bilecie pomocy technicznej zainicjowanym przez klienta znajduje się krótkie podsumowanie zdarzenia i rozwiązania. To podsumowanie pomaga klientowi lepiej zrozumieć zdarzenie i jego rozwiązanie.

Jeśli więcej informacji jest wymaganych oprócz informacji podanych w bilecie pomocy technicznej:

1. Klient musi złożyć wniosek o więcej informacji w ciągu pięciu dni roboczych od rozwiązania zdarzenia.

2. W zależności od poważności zdarzenia, klientowi w zgłoszeniu serwisowym może być udostępnione podsumowanie głównej przyczyny lub analiza źródłowej przyczyny (RCA). Dodatkowe informacje są udostępniane w ciągu siedmiu dni roboczych dla podsumowania głównej przyczyny i 30 dni roboczych na potrzeby analizy głównej przyczyny z rozwiązania zdarzenia.

Obsługiwane rozmiary maszyn wirtualnych

Usługa Azure Red Hat OpenShift 4 obsługuje wystąpienia węzłów w następujących rozmiarach maszyn wirtualnych:

Węzły płaszczyzny sterowania

* Standard_M128ms nie obsługuje szyfrowania na hoście.

Należy pamiętać, że jednostki SKU Dsv6 są obsługiwane w usłudze Azure Red Hat OpenShift w wersji 4.19 lub nowszej.

Węzły robocze

Ogólne przeznaczenie

Należy pamiętać, że jednostki SKU D*sv6 są obsługiwane w usłudze Azure Red Hat OpenShift w wersji 4.19 lub nowszej.

Zoptymalizowane wykorzystanie pamięci

Optymalizacja obliczeniowa

Zoptymalizowane pod kątem pamięci i obliczeń

* Standard_M128ms nie obsługuje szyfrowania na hoście

Optymalizacja pamięci masowej

Należy pamiętać, że jednostki SKU Lsv4 są obsługiwane w usłudze Azure Red Hat OpenShift w wersji 4.19 lub nowszej.

Obciążenie procesora GPU

* Tylko od drugiego dnia (niedostępne jako opcja podczas instalacji)

Treści powiązane

Aby uzyskać więcej informacji, zobacz Cykl wsparcia technicznego dla usługi Azure Red Hat OpenShift 4.