Udostępnij za pośrednictwem

Najlepsze rozwiązania dotyczące wydajności i skalowania dla małych i średnich obciążeń w usłudze Azure Kubernetes Service (AKS)

  • Artykuł

Uwaga

Ten artykuł koncentruje się na ogólnych najlepszych rozwiązaniach dotyczących małych i średnich obciążeń. Aby uzyskać najlepsze rozwiązania specyficzne dla dużych obciążeń, zobacz Performance and scaling best practices for large workloads in Azure Kubernetes Service (AKS) (Najlepsze rozwiązania dotyczące wydajności i skalowania dużych obciążeń w usłudze Azure Kubernetes Service (AKS).

Podczas wdrażania i obsługi klastrów w usłudze AKS można użyć następujących najlepszych rozwiązań, aby ułatwić optymalizację wydajności i skalowania.

Z tego artykułu dowiesz się więcej o:

  • Kompromisy i zalecenia dotyczące skalowania automatycznego obciążeń.
  • Zarządzanie skalowaniem i wydajnością węzłów na podstawie wymagań dotyczących obciążeń.
  • Zagadnienia dotyczące sieci dla ruchu przychodzącego i wychodzącego.
  • Monitorowanie i rozwiązywanie problemów z wydajnością płaszczyzny sterowania i węzła.
  • Planowanie pojemności, scenariusze wzrostu i uaktualnienia klastra.
  • Zagadnienia dotyczące magazynowania i sieci pod kątem wydajności płaszczyzny danych.

Skalowanie automatyczne aplikacji a skalowanie automatyczne infrastruktury

Skalowanie automatyczne aplikacji

Skalowanie automatyczne aplikacji jest przydatne podczas pracy z optymalizacją kosztów lub ograniczeniami infrastruktury. Dobrze skonfigurowany autoskalator utrzymuje wysoką dostępność aplikacji, jednocześnie minimalizując koszty. Płacisz tylko za zasoby wymagane do utrzymania dostępności, niezależnie od zapotrzebowania.

Jeśli na przykład istniejący węzeł ma miejsce, ale nie ma wystarczającej liczby adresów IP w podsieci, może być w stanie pominąć tworzenie nowego węzła i zamiast tego natychmiast uruchomić aplikację na nowym zasobniku.

Skalowanie automatyczne zasobnika poziomego

Implementowanie skalowania automatycznego zasobników w poziomie jest przydatne w przypadku aplikacji ze stałym i przewidywalnym zapotrzebowaniem na zasoby. Narzędzie Horizontal Pod Autoscaler (HPA) dynamicznie skaluje liczbę replik zasobników, co skutecznie rozkłada obciążenie na wiele zasobników i węzłów. Ten mechanizm skalowania jest zazwyczaj najbardziej korzystny w przypadku aplikacji, które mogą być rozłożone na mniejsze, niezależne składniki, które mogą działać równolegle.

Narzędzie HPA domyślnie udostępnia metryki wykorzystania zasobów. Możesz również zintegrować metryki niestandardowe lub korzystać z narzędzi, takich jak narzędzie Kubernetes Event-Driven Autoscaler (KEDA) (wersja zapoznawcza). Te rozszerzenia umożliwiają hpa podejmowanie decyzji dotyczących skalowania na podstawie wielu perspektyw i kryteriów, zapewniając bardziej całościowy widok wydajności aplikacji. Jest to szczególnie przydatne w przypadku aplikacji o różnych złożonych wymaganiach dotyczących skalowania.

Uwaga

Jeśli utrzymanie wysokiej dostępności aplikacji jest priorytetem, zalecamy pozostawienie nieco wyższego buforu dla minimalnej liczby zasobników dla hpa, aby uwzględnić czas skalowania.

Skalowanie automatyczne pionowych zasobników

Implementowanie skalowania automatycznego zasobników w pionie jest przydatne w przypadku aplikacji ze zmiennymi i nieprzewidywalnymi wymaganiami dotyczącymi zasobów. Narzędzie Do automatycznego skalowania zasobników pionowych (VPA) umożliwia precyzyjne dostosowywanie żądań zasobów, w tym procesora CPU i pamięci, dla poszczególnych zasobników, co umożliwia dokładną kontrolę nad alokacją zasobów. Ten stopień szczegółowości minimalizuje straty zasobów i zwiększa ogólną wydajność wykorzystania klastra. VpA usprawnia również zarządzanie aplikacjami, automatyzując alokację zasobów, zwalniając zasoby pod kątem krytycznych zadań.

Ostrzeżenie

Nie należy używać vpA w połączeniu z HPA na tych samych metrykach procesora CPU lub pamięci. Ta kombinacja może prowadzić do konfliktów, ponieważ obie autoskalatory próbują reagować na zmiany zapotrzebowania przy użyciu tych samych metryk. Można jednak użyć vpA dla procesora CPU lub pamięci w połączeniu z HPA dla metryk niestandardowych, aby zapobiec nakładaniu się i upewnić się, że każdy moduł skalowania automatycznego koncentruje się na różnych aspektach skalowania obciążenia.

Uwaga

VpA działa na podstawie danych historycznych. Zalecamy odczekanie co najmniej 24 godzin po wdrożeniu vpA przed zastosowaniem wszelkich zmian, aby dać mu czas na zbieranie danych rekomendacji.

Skalowanie automatyczne infrastruktury

Skalowanie automatyczne klastra

Implementowanie skalowania automatycznego klastra jest przydatne, jeśli istniejące węzły nie mają wystarczającej pojemności, ponieważ ułatwia skalowanie w górę i aprowizowanie nowych węzłów.

Rozważając skalowanie automatyczne klastra, decyzja o tym, kiedy usunąć węzeł, wiąże się z kompromisem między optymalizacją wykorzystania zasobów a zapewnieniem dostępności zasobów. Wyeliminowanie nie w pełni używanych węzłów zwiększa wykorzystanie klastra, ale może spowodować, że nowe obciążenia muszą czekać na aprowizację zasobów przed ich wdrożeniem. Ważne jest, aby znaleźć równowagę między tymi dwoma czynnikami, które są zgodne z wymaganiami klastra i obciążenia i odpowiednio skonfigurować ustawienia profilu skalowania automatycznego klastra.

Ustawienia profilu automatycznego skalowania klastra są stosowane uniwersalnie do wszystkich pul węzłów z obsługą skalowania automatycznego w klastrze. Oznacza to, że wszelkie akcje skalowania występujące w jednej puli węzłów z obsługą skalowania automatycznego mogą mieć wpływ na zachowanie skalowania automatycznego w innej puli węzłów. Ważne jest, aby zastosować spójne i zsynchronizowane ustawienia profilu we wszystkich odpowiednich pulach węzłów, aby upewnić się, że narzędzie do automatycznego skalowania działa zgodnie z oczekiwaniami.

Nadmierna aprowizacja

Nadmierna aprowizacja to strategia, która pomaga ograniczyć ryzyko użycia aplikacji przez zapewnienie nadmiaru łatwo dostępnych zasobów. Takie podejście jest szczególnie przydatne w przypadku aplikacji, które mają bardzo zmienne obciążenia i wzorce skalowania klastrów, które pokazują częste skalowanie w górę i skalowanie w dół.

Aby określić optymalną ilość nadmiernej aprowizacji, możesz użyć następującej formuły:

1-buffer/1+traffic

Załóżmy na przykład, że chcesz uniknąć osiągnięcia 100% wykorzystania procesora CPU w klastrze. Możesz wybrać bufor o 30%, aby zachować margines bezpieczeństwa. Jeśli przewidujesz średni współczynnik wzrostu ruchu wynoszący 40%, możesz rozważyć nadmierną aprowizowanie przez 50%, zgodnie z formułą:

1-30%/1+40%=50%

Efektywna metoda nadmiernej aprowizacji obejmuje użycie zasobników wstrzymywania. Wstrzymywanie zasobników to wdrożenia o niskim priorytcie, które można łatwo zastąpić wdrożeniami o wysokim priorytcie. Tworzy się zasobniki o niskim priorytcie, które służą wyłącznie do rezerwowania miejsca buforu. Gdy zasobnik o wysokim priorytecie wymaga miejsca, zasobniki wstrzymania zostaną usunięte i ponownie zaplanowane na innym węźle lub nowym węźle, aby pomieścić zasobnik o wysokim priorytecie.

Poniższy kod YAML przedstawia przykładowy manifest wstrzymania zasobnika:

apiVersion: scheduling.k8s.io/v1 
kind: PriorityClass 
metadata: 
  name: overprovisioning 
value: -1 
globalDefault: false 
description: "Priority class used by overprovisioning." 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: overprovisioning 
  namespace: kube-system 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      run: overprovisioning 
  template: 
    metadata: 
      labels: 
        run: overprovisioning 
    spec: 
      priorityClassName: overprovisioning 
      containers: 
      - name: reserve-resources 
        image: your-custome-pause-image 
        resources: 
          requests: 
            cpu: 1 
            memory: 4Gi

Skalowanie i wydajność węzłów

Wskazówki dotyczące najlepszych rozwiązań:

Uważnie monitoruj użycie zasobów i zasady planowania, aby zapewnić efektywne wykorzystanie węzłów.

Skalowanie węzłów umożliwia dynamiczne dostosowywanie liczby węzłów w klastrze na podstawie zapotrzebowania na obciążenia. Ważne jest, aby zrozumieć, że dodawanie większej liczby węzłów do klastra nie zawsze jest najlepszym rozwiązaniem do poprawy wydajności. Aby zapewnić optymalną wydajność, należy uważnie monitorować użycie zasobów i zasady planowania, aby zapewnić efektywne wykorzystanie węzłów.

Obrazy węzłów

Wskazówki dotyczące najlepszych rozwiązań:

Użyj najnowszej wersji obrazu węzła, aby upewnić się, że masz najnowsze poprawki zabezpieczeń i poprawki błędów.

Użycie najnowszej wersji obrazu węzła zapewnia najlepsze środowisko wydajności. Usługa AKS dostarcza ulepszenia wydajności w cotygodniowych wydaniach obrazów. Najnowsze obrazy demonaonset są buforowane na najnowszym obrazie dysku VHD, co zapewnia mniejsze opóźnienia dla aprowizacji węzłów i uruchamiania. Spadek liczby aktualizacji może mieć negatywny wpływ na wydajność, dlatego ważne jest, aby uniknąć dużych przerw między wersjami.

Azure Linux

Host kontenera systemu Linux platformy Azure w usłudze AKS używa natywnego obrazu usługi AKS i udostępnia jedno miejsce do programowania w systemie Linux. Każdy pakiet jest kompilowany na podstawie źródła i weryfikowany, zapewniając, że usługi działają na sprawdzonych składnikach.

Platforma Azure Linux jest uproszczona, w tym tylko niezbędny zestaw pakietów do uruchamiania obciążeń kontenerów. Zapewnia ograniczoną powierzchnię ataków i eliminuje stosowanie poprawek i konserwację niepotrzebnych pakietów. W warstwie podstawowej ma jądro ze wzmocnionym zabezpieczeniami firmy Microsoft dla platformy Azure. Ten obraz jest idealny dla obciążeń wrażliwych na wydajność i inżynierów platformy lub operatorów, którzy zarządzają flotami klastrów usługi AKS.

Ubuntu 2204

Obraz ubuntu 2204 jest domyślnym obrazem węzła dla usługi AKS. Jest to lekki i wydajny system operacyjny zoptymalizowany pod kątem uruchamiania konteneryzowanych obciążeń. Oznacza to, że może pomóc zmniejszyć użycie zasobów i zwiększyć ogólną wydajność. Obraz zawiera najnowsze poprawki zabezpieczeń i aktualizacje, które pomagają zapewnić ochronę obciążeń przed lukami w zabezpieczeniach.

Obraz ubuntu 2204 jest w pełni obsługiwany przez firmę Microsoft, Canonical i społeczność systemu Ubuntu oraz może pomóc w osiągnięciu lepszej wydajności i bezpieczeństwa dla konteneryzowanych obciążeń.

Maszyny wirtualne (VM)

Wskazówki dotyczące najlepszych rozwiązań:

Podczas wybierania maszyny wirtualnej upewnij się, że rozmiar i wydajność dysku systemu operacyjnego i jednostki SKU maszyny wirtualnej nie mają dużej rozbieżności. Rozbieżność rozmiaru lub wydajności może spowodować problemy z wydajnością i rywalizację o zasoby.

Wydajność aplikacji jest ściśle powiązana z jednostkami SKU maszyn wirtualnych używanymi w obciążeniach. Większe i bardziej wydajne maszyny wirtualne, ogólnie zapewniają lepszą wydajność. W przypadku obciążeń o znaczeniu krytycznym lub produktowym zalecamy używanie maszyn wirtualnych z co najmniej 8-rdzeniowym procesorem CPU. Maszyny wirtualne z nowszymi generacjami sprzętu, takimi jak v4 i v5, mogą również pomóc zwiększyć wydajność. Należy pamiętać, że opóźnienie tworzenia i skalowania może się różnić w zależności od używanych jednostek SKU maszyn wirtualnych.

Korzystanie z dedykowanych pul węzłów systemowych

W celu skalowania wydajności i niezawodności zalecamy użycie dedykowanej puli węzłów systemowych. Dzięki tej konfiguracji dedykowana pula węzłów systemu rezerwuje miejsce dla krytycznych zasobów systemu, takich jak demony systemu operacyjnego systemu operacyjnego. Obciążenie aplikacji może następnie działać w puli węzłów użytkownika, aby zwiększyć dostępność zasobów możliwych do przysłaniania dla aplikacji. Ta konfiguracja pomaga również ograniczyć ryzyko konkurencji zasobów między systemem a aplikacją.

Tworzenie operacji

Przejrzyj rozszerzenia i dodatki, które zostały włączone podczas tworzenia aprowizacji. Rozszerzenia i dodatki mogą zwiększać opóźnienie do ogólnego czasu trwania operacji tworzenia. Jeśli nie potrzebujesz rozszerzenia lub dodatku, zalecamy usunięcie go w celu zwiększenia opóźnienia tworzenia.

Strefy dostępności umożliwiają również zapewnienie wyższego poziomu dostępności w celu ochrony przed potencjalnymi awariami sprzętowymi lub zdarzeniami planowanej konserwacji. Klastry usługi AKS dystrybuują zasoby w logicznych sekcjach podstawowej infrastruktury platformy Azure. Strefy dostępności fizycznie oddzielają węzły od innych węzłów, aby zapewnić, że pojedynczy błąd nie ma wpływu na dostępność aplikacji. Strefy dostępności są dostępne tylko w niektórych regionach. Aby uzyskać więcej informacji, zobacz Availability zones in Azure (Strefy dostępności na platformie Azure).

Serwer interfejsu API usługi Kubernetes

Operacje LIST i WATCH

Platforma Kubernetes używa operacji LIST i WATCH do interakcji z serwerem interfejsu API Kubernetes i monitorowania informacji o zasobach klastra. Te operacje mają podstawowe znaczenie dla sposobu, w jaki platforma Kubernetes wykonuje zarządzanie zasobami.

Operacja LIST pobiera listę zasobów, które mieszczą się w określonych kryteriach, takich jak wszystkie zasobniki w określonej przestrzeni nazw lub wszystkich usługach w klastrze. Ta operacja jest przydatna, gdy chcesz zapoznać się z omówieniem zasobów klastra lub użyć operatora na wielu zasobach jednocześnie.

Operacja LIST może pobierać duże ilości danych, szczególnie w dużych klastrach z wieloma zasobami. Należy pamiętać o tym, że wykonywanie niezwiązanych lub częstych wywołań LIST powoduje znaczne obciążenie serwera interfejsu API i może zamknąć czasy odpowiedzi.

Operacja WATCH wykonuje monitorowanie zasobów w czasie rzeczywistym. Po skonfigurowaniu elementu WATCH w zasobie serwer interfejsu API wysyła aktualizacje za każdym razem, gdy wystąpią zmiany w tym zasobie. Jest to ważne w przypadku kontrolerów, takich jak kontroler ReplicaSet, który polega na funkcji WATCH do obsługi żądanego stanu zasobów.

Należy pamiętać o tym, że oglądanie zbyt wielu zasobów modyfikowalnych lub wykonywanie zbyt wielu współbieżnych żądań WATCH może przeciążyć serwer interfejsu API i spowodować nadmierne użycie zasobów.

Aby uniknąć potencjalnych problemów i zapewnić stabilność płaszczyzny sterowania platformy Kubernetes, możesz użyć następujących strategii:

Limity przydziałów zasobów

Zaimplementuj przydziały zasobów, aby ograniczyć liczbę zasobów, które mogą być wyświetlane lub obserwowane przez określonego użytkownika lub przestrzeń nazw, aby zapobiec nadmiernemu wywołaniu.

Priorytet i sprawiedliwość interfejsu API

Platforma Kubernetes wprowadziła koncepcję priorytetu interfejsu API i sprawiedliwości (APF), aby określić priorytety żądań interfejsu API i zarządzać nimi. Możesz użyć platformy APF na platformie Kubernetes, aby chronić serwer interfejsu API klastra i zmniejszyć liczbę HTTP 429 Too Many Requests odpowiedzi widocznych przez aplikacje klienckie.

Zasób niestandardowy Kluczowe cechy i funkcje
PriorityLevelConfigurations • Definiowanie różnych poziomów priorytetu dla żądań interfejsu API.
• Określa unikatową nazwę i przypisuje wartość całkowitą reprezentującą poziom priorytetu. Wyższe poziomy priorytetu mają niższe wartości całkowite, co oznacza, że są one bardziej krytyczne.
• Może używać wielu do kategoryzowania żądań na różne poziomy priorytetów na podstawie ich znaczenia.
• Umożliwia określenie, czy żądania na określonym poziomie priorytetu powinny podlegać limitom szybkości.
Schematy przepływu • Definiowanie sposobu kierowania żądań interfejsu API do różnych poziomów priorytetów na podstawie atrybutów żądania.
• Określ reguły zgodne z żądaniami na podstawie kryteriów, takich jak grupy interfejsów API, wersje i zasoby.
• Gdy żądanie pasuje do danej reguły, żądanie jest kierowane do poziomu priorytetu określonego w skojarzonej konfiguracji PriorityLevelConfiguration.
• Może służyć do ustawiania kolejności oceny, gdy wiele flowSchemas pasuje do żądania, aby upewnić się, że niektóre reguły mają pierwszeństwo.

Konfigurowanie interfejsu API przy użyciu parametrów PriorityLevelConfigurations i FlowSchemas umożliwia ustalanie priorytetów krytycznych żądań interfejsu API w przypadku mniej ważnych żądań. Dzięki temu podstawowe operacje nie będą głodne ani nie występują opóźnienia z powodu żądań o niższym priorytcie.

Optymalizowanie etykiet i selektorów

W przypadku korzystania z operacji LIST zoptymalizuj selektory etykiet, aby zawęzić zakres zasobów, które chcesz wykonać zapytanie, aby zmniejszyć ilość zwracanych danych i obciążenie serwera interfejsu API.

W obszarze Operacje TWORZENIA i aktualizacji platformy Kubernetes odwołują się do akcji, które zarządzają zasobami klastra i modyfikują je.

OPERACJE CREATE i UPDATE

Operacja CREATE tworzy nowe zasoby w klastrze Kubernetes, takie jak zasobniki, usługi, wdrożenia, mapy konfiguracji i wpisy tajne. Podczas operacji CREATE klient, taki jak kubectl lub kontroler, wysyła żądanie do serwera interfejsu API Kubernetes w celu utworzenia nowego zasobu. Serwer interfejsu API weryfikuje żądanie, zapewnia zgodność z dowolnymi zasadami kontrolera dostępu, a następnie tworzy zasób w żądanym stanie klastra.

Operacja UPDATE modyfikuje istniejące zasoby w klastrze Kubernetes, w tym zmiany specyfikacji zasobów, takie jak liczba replik, obrazy kontenerów, zmienne środowiskowe lub etykiety. Podczas operacji UPDATE klient wysyła żądanie do serwera interfejsu API w celu zaktualizowania istniejącego zasobu. Serwer interfejsu API weryfikuje żądanie, stosuje zmiany do definicji zasobu i aktualizuje zasób klastra.

Operacje CREATE i UPDATE mogą mieć wpływ na wydajność serwera interfejsu API Kubernetes w następujących warunkach:

  • Wysoka współbieżność: gdy wielu użytkowników lub aplikacji tworzy współbieżne żądania CREATE lub UPDATE, może to prowadzić do wzrostu liczby żądań interfejsu API przychodzących na serwer w tym samym czasie. Może to podkreślić wydajność przetwarzania serwera interfejsu API i powodować problemy z wydajnością.
  • Złożone definicje zasobów: definicje zasobów, które są nadmiernie złożone lub obejmują wiele zagnieżdżonych obiektów, mogą zwiększyć czas potrzebny serwerowi interfejsu API do weryfikowania i przetwarzania żądań CREATE i UPDATE, co może prowadzić do obniżenia wydajności.
  • Sprawdzanie poprawności zasobów i kontroli dostępu: platforma Kubernetes wymusza różne zasady kontroli dostępu i sprawdzanie poprawności przychodzących żądań CREATE i UPDATE. Duże definicje zasobów, takie jak te z rozbudowanymi adnotacjami lub konfiguracjami, mogą wymagać więcej czasu przetwarzania.
  • Kontrolery niestandardowe: kontrolery niestandardowe, które obserwują zmiany w zasobach, takich jak wdrożenia lub kontrolery StatefulSet, mogą generować znaczną liczbę aktualizacji podczas skalowania lub wprowadzania zmian. Te aktualizacje mogą obciążać zasoby serwera interfejsu API.

Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z serwerem interfejsu API i etcd w usłudze AKS.

Wydajność płaszczyzny danych

Płaszczyzna danych platformy Kubernetes jest odpowiedzialna za zarządzanie ruchem sieciowym między kontenerami i usługami. Problemy z płaszczyzną danych mogą prowadzić do powolnego czasu odpowiedzi, obniżonej wydajności i przestoju aplikacji. Ważne jest, aby uważnie monitorować i optymalizować konfiguracje płaszczyzny danych, takie jak opóźnienie sieci, alokacja zasobów, gęstość kontenerów i zasady sieci, aby zapewnić bezproblemowe i wydajne działanie konteneryzowanych aplikacji.

Typy magazynu

Usługa AKS zaleca i domyślnie używa efemerycznych dysków systemu operacyjnego. Efemeryczne dyski systemu operacyjnego są tworzone w lokalnym magazynie maszyn wirtualnych i nie są zapisywane w zdalnym magazynie platformy Azure, takich jak dyski zarządzanego systemu operacyjnego. Są one szybsze podczas ponownego tworzenia i uruchamiania, umożliwiając szybsze operacje klastra i zapewniają mniejsze opóźnienie odczytu/zapisu na dysku systemu operacyjnego węzłów agenta usługi AKS. Efemeryczne dyski systemu operacyjnego działają dobrze w przypadku obciążeń bezstanowych, w przypadku których aplikacje są odporne na awarie poszczególnych maszyn wirtualnych, ale nie czasu wdrożenia maszyny wirtualnej lub ponownego tworzenia poszczególnych wystąpień maszyn wirtualnych. Tylko niektóre jednostki SKU maszyn wirtualnych obsługują efemeryczne dyski systemu operacyjnego, dlatego należy upewnić się, że żądana generacja i rozmiar jednostki SKU są zgodne. Aby uzyskać więcej informacji, zobacz Efemeryczne dyski systemu operacyjnego w usłudze Azure Kubernetes Service (AKS).

Jeśli obciążenie nie może używać efemerycznych dysków systemu operacyjnego, usługa AKS domyślnie używa dysków systemu operacyjnego SSD w warstwie Premium. Jeśli dyski systemu operacyjnego SSD w warstwie Premium nie są zgodne z obciążeniem, usługa AKS domyślnie korzysta z dysków SSD w warstwie Standardowa. Obecnie jedynym innym dostępnym typem dysku systemu operacyjnego jest hdd w warstwie Standardowa. Aby uzyskać więcej informacji, zobacz Opcje magazynu w usłudze Azure Kubernetes Service (AKS).

Poniższa tabela zawiera podział sugerowanych przypadków użycia dla dysków systemu operacyjnego obsługiwanych w usłudze AKS:

Typ dysku systemu operacyjnego Kluczowe cechy i funkcje Sugerowane przypadki użycia
Efemeryczne dyski systemu operacyjnego • Szybsze ponowne projektowanie i czasy rozruchu.
• Mniejsze opóźnienie odczytu/zapisu na dysku systemu operacyjnego węzłów agenta usługi AKS.
• Wysoka wydajność i dostępność.		 • Wymagające obciążenia przedsiębiorstwa, takie jak SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite itp.
• Bezstanowe obciążenia produkcyjne, które wymagają wysokiej dostępności i małych opóźnień.
Dyski systemu operacyjnego SSD w warstwie Premium • Spójna wydajność i małe opóźnienia.
• Wysoka dostępność.		 • Wymagające obciążenia przedsiębiorstwa, takie jak SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite itp.
• Obciążenia przedsiębiorstwa intensywnie korzystające z danych wejściowych/wyjściowych (we/wy).
Dyski systemu operacyjnego SSD w warstwie Standardowa • Spójna wydajność.
• Lepsza dostępność i opóźnienie w porównaniu z dyskami HDD w warstwie Standardowa.		 • Serwery internetowe.
• Małe operacje wejścia/wyjścia na sekundę (IOPS) serwerów aplikacji.
• Lekko używane aplikacje dla przedsiębiorstw.
• Obciążenia tworzenia i testowania.
Dyski HDD w warstwie Standardowa • Niski koszt.
• Wykazuje zmienność wydajności i opóźnień.		 • Magazyn kopii zapasowych.
• Magazyn masowy z rzadkim dostępem.

Liczba operacji we/wy na sekundę i przepływność

Operacje wejścia/wyjścia na sekundę (IOPS) odnoszą się do liczby operacji odczytu i zapisu, które dysk może wykonać w ciągu sekundy. Przepływność odnosi się do ilości danych, które można przesyłać w danym okresie.

Dyski systemu operacyjnego są odpowiedzialne za przechowywanie systemu operacyjnego i skojarzonych z nim plików, a maszyny wirtualne są odpowiedzialne za uruchamianie aplikacji. Podczas wybierania maszyny wirtualnej upewnij się, że rozmiar i wydajność dysku systemu operacyjnego i jednostki SKU maszyny wirtualnej nie mają dużej rozbieżności. Rozbieżność rozmiaru lub wydajności może spowodować problemy z wydajnością i rywalizację o zasoby. Jeśli na przykład dysk systemu operacyjnego jest znacznie mniejszy niż maszyny wirtualne, może ograniczyć ilość miejsca dostępnego dla danych aplikacji i spowodować, że system zabraknie miejsca na dysku. Jeśli dysk systemu operacyjnego ma niższą wydajność niż maszyny wirtualne, może stać się wąskim gardłem i ograniczyć ogólną wydajność systemu. Upewnij się, że rozmiar i wydajność są zrównoważone, aby zapewnić optymalną wydajność na platformie Kubernetes.

Poniższe kroki umożliwiają monitorowanie liczby operacji we/wy na sekundę i mierników przepustowości na dyskach systemu operacyjnego w witrynie Azure Portal:

  1. Przejdź do Portalu Azure.
  2. Wyszukaj pozycję Zestawy skalowania maszyn wirtualnych i wybierz zestaw skalowania maszyn wirtualnych.
  3. W obszarze Monitorowanie wybierz pozycję Metryki.

Efemeryczne dyski systemu operacyjnego mogą zapewnić dynamiczną operację we/wy na sekundę i przepływność dla aplikacji, natomiast dyski zarządzane mają ograniczone operacje we/wy na sekundę i przepływność. Aby uzyskać więcej informacji, zobacz Efemeryczny dysk systemu operacyjnego dla maszyn wirtualnych platformy Azure.

Usługa Azure Premium SSD w wersji 2 jest przeznaczona dla obciążeń intensywnie korzystających z operacji we/wy, które wymagają opóźnień dysku w milisekundach oraz wysokiej przepływności i liczby operacji we/wy przy niskich kosztach. Jest ona odpowiednia dla szerokiego zakresu obciążeń, takich jak SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, big data/analiza, gry i nie tylko. Ten typ dysku jest obecnie najlepszą opcją dostępną dla woluminów trwałych.

Planowanie zasobników

Zasoby pamięci i procesora CPU przydzielone do maszyny wirtualnej mają bezpośredni wpływ na wydajność zasobników uruchomionych na maszynie wirtualnej. Po utworzeniu zasobnika jest przypisywana pewna ilość pamięci i zasobów procesora CPU, które są używane do uruchamiania aplikacji. Jeśli maszyna wirtualna nie ma wystarczającej ilości dostępnej pamięci lub zasobów procesora CPU, może to spowodować spowolnienie zasobników, a nawet awarię. Jeśli maszyna wirtualna ma za dużo dostępnej pamięci lub zasobów procesora CPU, może to spowodować nieefektywne uruchamianie zasobników, marnowanie zasobów i zwiększanie kosztów. Zalecamy monitorowanie łącznych żądań zasobników w ramach obciążeń względem łącznych zasobów możliwych do przysyłania w celu uzyskania najlepszej przewidywalności i wydajności planowania. Można również ustawić maksymalne zasobniki na węzeł na podstawie planowania pojemności przy użyciu polecenia --max-pods.