Amazon EKS poprawia skalowanie płaszczyzny kontrolnej i szybkość aktualizacji nawet 4-krotnie

Na wiele lat przed udostępnieniem usługi Amazon Elastic Kubernetes Service (EKS) klienci zwrócili się do twórców, że chcą usługi, która uprości zarządzanie Kubernetes.

Wielu z nich korzystało z samozarządzających się klastrów w Amazon Elastic Computer Cloud (EC2) i napotykało na wyzwania związane z aktualizacją, skalowaniem i utrzymaniem płaszczyzny sterowania Kubernetes. Kiedy EKS został uruchomiony w 2018 roku, miał na celu zmniejszenie obciążenia operacyjnego klientów, oferując zarządzaną płaszczyznę kontroli dla Kubernetes. Początkowo obejmowało to automatyczne aktualizacje, poprawki i kopie zapasowe, które często funkcjonują jako termin „undifferentiated heavy lifting”. Dlatego też autorzy przeanalizowali wolumeny danych, aby móc stworzyć płaszczyznę kontroli, która będzie działać dla zdecydowanej większości ich klientów.

Jednakże wraz ze wzrostem użycia EKS twórcy odkryli, że zdarzali się klienci, którzy czasami przekraczali zaopatrywaną pojemność klastra. Kiedy doszło do takiej sytuacji, musieli złożyć zgłoszenie z obsługą AWS, aby zmienić rozmiar płaszczyzny kontroli klastra. Nie da się ukryć, że nie było to idealne doświadczenie dla użytkownika.

Obecnie płaszczyzna kontroli jest skalowana automatycznie po przekroczeniu określonych metryk. Początkowo do skalowania używano podstawowych wskaźników, takich jak CPU/memory. Gdy autorzy dowiedzieli się, jak płaszczyzna sterowania zachowywała się w różnych warunkach, dostosowali swoje metryki, aby skalowanie było bardziej czułe. Teraz do skalowania płaszczyzny kontroli wykorzystują różne metryki, w tym liczby węzłów roboczych i rozmiaru bazy danych etcd. Te ulepszenia są doskonałym przykładem efektu koła zamachowego, w którym AWS udostępnia funkcję w odpowiedzi na opinie klientów, zwraca się do użytkowników końcowych o informacje zwrotne na temat jej wpływu i wykorzystuje te informacje do dalszego ulepszania doświadczeń klientów.

Najnowsze ulepszenia

Od czasu wprowadzenia automatycznego skalowania płaszczyzny sterowania twórcy szukają sposobów na dalsze usprawnienie skalowania dla swoich klientów. Najnowsze ulepszenie polega na skróceniu czasu potrzebnego na skalowanie płaszczyzny sterowania.

Do tej pory skalowanie płaszczyzny sterującej mogło trwać nawet 50 minut. Ten czas najdotkliwiej odczuli ci klienci, których prośby do kube-apiserver systematycznie wzrastały (przyrost liniowy). Długie opóźnienia skalowania mogą spowodować wzrost opóźnień API i etcd, a nawet spowodować, że serwer API przestanie odpowiadać.

Dzięki najnowszym aktualizacjom płaszczyznę sterowania można teraz skalować w ciągu 10 minut lub mniej, co oznacza aż czterokrotną poprawę. Wiele zespołów inżynierskich wdrożyło kilka zmian, które razem zwiększyły szybkość. Zmiany te obejmują:

• Równoległe aktualizacje serwera API i etcd: W przeszłości skalowano serwer API dopiero po skalowaniu etcd. Dokonano tego z dużą ostrożnością. Dzięki ostatnim ulepszeniom autorów można teraz równolegle aktualizować serwer API i etcd bez narażania dostępności płaszczyzny sterowania EKS.
• Aktualizacje metodą blue/green dla serwera API: Aby osiągnąć wysoką dostępność i spełnić zobowiązania dotyczące umowy o poziomie usług, Amazon EKS wymaga, aby przez cały czas działała minimalna liczba węzłów płaszczyzny sterowania. W przeszłości, gdy niezbędne było skalowanie płaszczyzny kontrolnej, twórcy zwiększali rozmiar grupy autoskalowania (ASG) i przeprowadzali stopniowe wdrażanie instancji w ASG, pojedynczo. Dzięki najnowszym aktualizacjom logika niestandardowa wykonuje wdrożenie metodą blue/green, w której wszystkie nowe, większe wystąpienia są uruchamiane równolegle. Tylko wtedy, gdy nowe węzły są w dobrej kondycji i są gotowe do rozpoczęcia obsługi ruchu, stare węzły są zakańczane.
• Skróć czas uruchamiania instancji etcd: Gdy nowy węzeł etcd jest dołączany do klastra, potrzebuje czasu na odbieranie i przetwarzanie aktualizacji od innych członków klastra. Dopóki nie zostanie w pełni zsynchronizowany, nie może obsługiwać żądań klientów. Wcześniej czekano cztery minuty, aby umożliwić propagację zmian etcd do nowo przyłączonego węzła. W najnowszych aktualizacjach autorzy zastąpili okres oczekiwania kontrolą kondycji, która określa, czy węzeł jest gotowy.
• Przyspiesz ładowanie instancji serwera API: skrócono czas potrzebny na ładowanie nowych węzłów płaszczyzny sterowania, pobierając z wyprzedzeniem duże pliki, zamiast powolnego ładowania ich z Amazon Simple Storage Service (S3). To pozwoliło autorom skrócić czas ładowania początkowego o połowę.
• Dostosuj szybkości QPS i burst rates: W miarę skalowania klastra zwiększa się liczba żądań Kubernetes API i burst rates dla Kubernetes Controller Manager i Kubernetes Scheduler. Oznacza to, że będziesz mniej podatny na spowolnienie podczas tworzenia, aktualizowania lub usuwania podów.

Płaszczyznę sterowania klastra można skalować w górę i w dół wielokrotnie przez cały okres jego istnienia. Gdy jest skalowany w górę, skalowanie jest stopniowe, za każdym razem przy użyciu coraz większych instancji, aż osiągnie maksymalny rozmiar. Po przeskalowaniu klastra w górę nie zostanie on skalowany, chyba że wykorzystanie przez kilka dni pozostanie poniżej progu skalowania. Ten okres oczekiwania pomaga upewnić się, że płaszczyzna sterowania jest odpowiednio dostosowana do działających na niej obciążeń.

Dodatkowe korzyści

Praca wykonana przez autorów w celu zwiększania szybkości, z jaką klaster może się skalować, wpływa również na to, jak szybko aktualizacje są stosowane do płaszczyzny kontrolnej EKS. W przeszłości, gdy w klastrze zastosowano pewne aktualizacje, EKS wykonywał stopniowe zastępowanie płaszczyzny kontrolnej kopii zapasowych wystąpień EC2. Dzięki aktualizacjom metodą blue/green dla serwera interfejsu API i innym najnowszym ulepszeniom, aktualizacje wszystkich obecnie obsługiwanych wersji EKS można teraz ukończyć w ciągu 10 minut lub mniej. Te krótsze czasy aktualizacji oznaczają, że klienci EKS mogą wrócić do wykonywania operacji na swoich klastrach i szybciej niż wcześniej korzystać z najnowszych zabezpieczeń i funkcji. Inne typy aktualizacji EKS wkrótce skorzystają z tych zmian, w tym włączenie szyfrowania kluczy tajnych usługi AWS Key Management Service (KMS) w istniejących klastrach i kojarzenie zewnętrznego dostawcy OIDC w celu uwierzytelniania użytkowników.

Przyszłość

W nadchodzących miesiącach twórcy będą wprowadzać więcej stopniowych ulepszeń, aby kontrolować automatyczne skalowanie płaszczyzn, aby jeszcze bardziej poprawić wrażenia użytkownika EKS. Podobnie jak w przypadku poprzednich aktualizacji, będą one dyskretne i wydane bez wielkiego celebrowania, ponieważ autorzy uważają, że skalowalność jest podstawową zasadą EKS. Aktualizacje te zostaną automatycznie zastosowane do wszystkich nowych i istniejących klastrów, bez konieczności interwencji klienta. Ostatecznie te ulepszenia pozwolą EKS na obsługę klastrów o wielkości do 15 000 węzłów roboczych i/lub uruchomienie aż 450 000 podów.

Feedback

Jak zawsze, jeśli masz jakiekolwiek uwagi lub sugestie dotyczące skalowania w EKS, odwiedź containers roadmap na GitHub i otwórz dyskusję. Autorów zawsze interesuje to, w jaki sposób mogą uczynić AWS najlepszym miejscem do obsługi Kubernetes.

źródło: AWS