K8s/Kubernetes: AWS vs. GCP vs. Azure

Kubernetes (często stylizowany na „K8”) wygrał bitwę na narzędzia do orkiestracji kontenerów lata temu. Niemniej jednak wciąż istnieje wiele sposobów na zaimplementowanie Kubernetes dzisiaj i sprawienie, by działał z różnymi infrastrukturami i wieloma narzędziami — niektóre lepiej utrzymane niż inne. Być może najciekawszym osiągnięciem na tym froncie jest to, że najlepsi dostawcy chmury zdecydowali się wydać własne zarządzane wersje Kubernetes:

• Microsoft Azure oferuje usługę Azure Kubernetes Service (AKS)
• AWS oferuje usługę Amazon Elastic Kubernetes Service (EKS)
• Google Cloud oferuje Google Kubernetes Engine (GKE)

Co oferują te platformy z perspektywy DevOps? Czy dotrzymują obietnic? Jak wypada czas ich powstania i inne testy porównawcze? Jak dobrze integrują się z odpowiednimi platformami, zwłaszcza z narzędziami CLI? Jak to jest utrzymywać i pracować z nimi? Poniżej zagłębimy się w te pytania i nie tylko.

Uwaga: Czytelnikom, którzy chcieliby wyjaśnić koncepcje klastra Kubernetes przed dalszym czytaniem, Dmitriy Kononov oferuje doskonałe wprowadzenie.

AKS vs. EKS vs. GKE: Reklamowane funkcje

Zdecydowaliśmy się pogrupować różne funkcje dostępne dla każdej zarządzanej wersji Kubernetes w silosy:

• Przegląd globalny
• Sieć
• Skalowalność i wydajność
• Bezpieczeństwo i monitorowanie
• Ekosystem
• cennik

Uwaga: te dane mogą się zmieniać z czasem, ponieważ dostawcy usług w chmurze regularnie aktualizują swoje produkty.

Przegląd globalny

Sam Kubernetes był projektem Google, więc ma sens, że jako pierwsi zaproponowali hostowaną wersję w 2014 roku.

Z trzech porównywanych tutaj, Azure była następna z AKS i miała trochę czasu na ulepszenie: jeśli pamiętasz silnik acs, który był używany do udostępniania Kubernetes na platformie Azure kilka lat temu, docenisz wysiłek Microsoftu w jego zastąpieniu, Aks-silnik.

AWS był ostatnim, który wdrożył własną wersję, EKS, więc czasami może wydawać się, że jest za późno na froncie funkcji, ale nadrabiają zaległości.

Jeśli chodzi o ceny, oczywiście wszystko się zmienia, a Google zdecydowało się dołączyć do AWS w cenie 0,10 USD za godzinę, obowiązującej w czerwcu 2020 r. Azure jest tutaj outsiderem, udostępniając za darmo usługę AKS, ale nie jest jasne, w jaki sposób długo, który może trwać.

Kolejna główna różnica polega na funkcji aktualizacji klastra. Większość automatycznych uaktualnień znajduje się w GKE i są one domyślnie włączone. Jednak AKS i EKS są tutaj podobne do siebie, w tym sensie, że oba wymagają ręcznych żądań, aby móc uaktualnić węzły główne lub robocze.

Sieć

Jeśli chodzi o sieć, trzej dostawcy usług w chmurze są bardzo blisko siebie. Wszystkie pozwalają klientom wdrażać zasady sieciowe na przykład za pomocą Calico. Jeśli chodzi o równoważenie obciążenia, wszyscy wdrażają swoją integrację z własnymi zasobami równoważenia obciążenia i dają inżynierom wybór, czego użyć.

Główna różnica znaleziona tutaj opiera się na wartości dodanej siatki usług. AKS nie obsługuje żadnej siatki usług po wyjęciu z pudełka (chociaż inżynierowie mogą ręcznie zainstalować Istio). AWS opracował własną siatkę usług o nazwie App Mesh. Wreszcie, Google wydało własną integrację z Istio (choć wciąż w wersji beta), którą klienci mogą dodawać bezpośrednio podczas tworzenia klastra.

Najlepszy zakład: GKE

Skalowalność i wydajność

Jeśli chodzi o wydajność i skalowalność GKE vs. AKS vs. EKS, GKE wydaje się być na czele. W rzeczywistości obsługuje największą liczbę węzłów (5000) i oferuje obszerną dokumentację dotyczącą prawidłowego skalowania klastra. Wszystkie funkcje zapewniające wysoką dostępność są dostępne i łatwe do dostrojenia. Co więcej, GKE niedawno wydało Anthos, projekt tworzenia ekosystemu wokół GKE i jego funkcji; dzięki Anthos możesz wdrożyć GKE lokalnie.

AWS ma jednak kluczową zaletę: jako jedyny umożliwia węzłom bare-metal uruchamianie klastra Kubernetes.

Od czerwca 2020 r. AKS nie ma wysokiej dostępności dla urządzenia głównego, co jest ważnym aspektem do rozważenia. Ale, jak zawsze, może się to wkrótce zmienić.

Najlepszy zakład: GKE

Bezpieczeństwo i monitorowanie

Pod względem zgodności wszyscy trzej dostawcy usług w chmurze są równoważni. Jednak pod względem bezpieczeństwa EKS i GKE zapewniają kolejną warstwę bezpieczeństwa dzięki wbudowanym usługom zarządzania kluczami.

Jeśli chodzi o monitorowanie, Azure i Google Cloud zapewniają własny ekosystem monitorowania wokół Kubernetes. Warto zauważyć, że ten od Google został niedawno zaktualizowany, aby używać Kubernetes Engine Monitoring, który jest specjalnie zaprojektowany dla Kubernetes.

Platforma Azure zapewnia własny system monitorowania kontenerów, który pierwotnie został stworzony dla podstawowego ekosystemu kontenerów spoza Kubernetes. Dodali monitorowanie niektórych metryk i zasobów specyficznych dla Kubernetes (kondycja klastra, wdrożenia) — w trybie podglądu od czerwca 2020 r.

AWS oferuje lekkie monitorowanie płaszczyzny sterowania bezpośrednio w Cloudwatch. Aby monitorować pracowników, możesz użyć Kubernetes Container Insights Metrics udostępnianych za pośrednictwem konkretnego agenta CloudWatch, który możesz zainstalować w klastrze.

Najlepszy zakład: GKE

Ekosystem

Pod względem ekosystemów trzej dostawcy mają różne mocne strony i atuty. AKS ma teraz bardzo kompletną dokumentację dotyczącą swojej platformy i jest drugim pod względem postów w Stack Overflow. EKS ma najmniejszą liczbę postów na Stack Overflow, ale korzysta z siły AWS Marketplace. GKE, jako najstarsza platforma, ma najwięcej postów na Stack Overflow i przyzwoitą liczbę aplikacji na swoim rynku, ale także najbardziej wszechstronną dokumentację.

Najlepsze zakłady: GKE i EKS

cennik

Jeśli chodzi o ogólną cenę, nawet przy posunięciu GKE do wdrożenia punktu cenowego 0,10 USD za godzinę dla dowolnego klastra, pozostaje ona zdecydowanie najtańszą chmurą. Dzieje się tak dzięki czemuś specyficznemu dla Google — zniżkom za długotrwałe użytkowanie, które są stosowane, gdy miesięczne zużycie zasobów na żądanie osiąga określone minimum.

Należy zauważyć, że przykładowy wiersz ceny nie uwzględnia ruchu do klastra Kubernetes, za który dostawca chmury może pobierać opłaty.

Powodem, dla którego AWS nie zezwala na używanie ich bezpłatnej warstwy do testowania klastra EKS, jest to, że EKS wymaga większych maszyn niż warstwa tX.micro, a cennik godzinowy EKS nie znajduje się w warstwie bezpłatnej.

Niemniej jednak nadal może być opłacalne testowanie dowolnej z tych zarządzanych opcji Kubernetes z przyzwoitym obciążeniem przy użyciu węzłów spot/preemptible każdego dostawcy chmury — taka taktyka z łatwością pozwoli zaoszczędzić od 80 do 90 procent ceny końcowej. (Oczywiście nie zaleca się uruchamiania stanowych obciążeń produkcyjnych na takich maszynach!)

Reklamowane funkcje i przewaga Google

Patrząc na różne reklamowane funkcje online, wydaje się, że istnieje korelacja między tym, jak długo zarządzana wersja Kubernetes jest dostępna na rynku, a liczbą funkcji. Jak wspomniano, Google będąc inicjatorem projektu Kubernetes wydaje się być niezaprzeczalnym atutem, skutkującym coraz lepszą integracją z własną platformą chmurową.

Ale AKS i EKS nie należy lekceważyć w miarę dojrzewania; oba mogą korzystać z ich unikalnych funkcji. Na przykład AWS jest jedynym, który ma integrację z węzłem bare-metal, a także oferuje największą liczbę aplikacji na swoim rynku.

Teraz, gdy reklamowane funkcje dla każdej oferty Kubernetes są jasne, przyjrzyjmy się dokładniej, wykonując praktyczne testy.

Kubernetes: AWS vs. GCP vs. Azure w praktyce

Reklama to jedno, ale jak wypada porównanie różnych platform, jeśli chodzi o obsługę obciążeń produkcyjnych? Jako inżynier zajmujący się chmurą wiem, jak ważne jest, jak długo trwa tworzenie i usuwanie klastra podczas egzekwowania infrastruktury jako kodu. Ale chciałem również zbadać możliwości każdego CLI i skomentować, jak łatwo (lub nie) każdy dostawca chmury umożliwia tworzenie klastra.

Doświadczenie użytkownika w tworzeniu klastra

AKS

W AKS tworzenie klastra jest podobne do tworzenia wystąpienia w AWS. Po prostu znajdź menu AKS i przejrzyj szereg różnych menu. Po sprawdzeniu poprawności konfiguracji można utworzyć klaster, co jest procesem dwuetapowym. Jest to bardzo proste, a inżynierowie mogą łatwo i szybko uruchomić klaster z ustawieniami domyślnymi.

EKS

Tworzenie klastrów jest zdecydowanie bardziej złożone w EKS vs. AKS. Przede wszystkim i domyślnie AWS wymaga najpierw przejścia do IAM, aby utworzyć nową rolę dla płaszczyzny sterowania Kubernetes i przypisać do niej inżyniera. Należy również zauważyć, że tworzenie klastra nie obejmuje tworzenia węzłów, więc gdy mierzyłem średnio 11 minut, dotyczy to tylko tworzenia wzorca. Utworzenie grupy węzłów to kolejny krok dla administratora, który ponownie potrzebuje roli dla pracowników z trzema niezbędnymi politykami, które należy wprowadzić za pośrednictwem panelu sterowania IAM.

GKE

Dla mnie wrażenia z ręcznego tworzenia klastra są najprzyjemniejsze w GKE. Po znalezieniu Kubernetes Engine w Google Cloud Console kliknij, aby utworzyć klaster. W menu po lewej stronie pojawiają się różne kategorie ustawień. Google wstępnie wypełni nowy klaster domyślną pulą węzłów, którą można łatwo modyfikować. Wreszcie, GKE ma najszybszy czas odradzania się klastra, co prowadzi nas do następnej tabeli.

Czas stworzyć klaster

Wykonałem te testy w tym samym regionie (Frankfurt i Europa Zachodnia dla AKS), aby usunąć możliwy wpływ tej różnicy na czas odradzania. Próbowałem również wybrać ten sam rozmiar dla węzłów dla klastra: trzy węzły, każdy z dwoma procesorami wirtualnymi i siedmioma lub ośmioma GB pamięci, standardowy rozmiar do uruchomienia małego obciążenia na Kubernetes i rozpoczęcia eksperymentów. Każdy klaster utworzyłem trzy razy, aby obliczyć średnią.

W tych testach GKE pozostawał daleko w czołówce, z czasem odradzania się zawsze poniżej trzech minut.

Kubernetes: AWS a GCP a Azure CLI — omówienie

Nie wszystkie interfejsy CLI są sobie równe, ale w tym przypadku wszystkie trzy interfejsy CLI są w rzeczywistości modułami większego CLI. Jak to jest rozpocząć pracę z łańcuchem narzędzi CLI każdego dostawcy chmury?

AKS CLI (przez az )

Po zainstalowaniu narzędzi az , a następnie modułu AKS (za pośrednictwem az aks install-cli ), inżynierowie muszą autoryzować interfejs wiersza polecenia do komunikacji z kontem platformy Azure projektu. Jest to kwestia uzyskania poświadczeń w celu zaktualizowania lokalnego pliku kubeconfig za pomocą prostego polecenia az aks get-credentials --resource-group myResourceGroup --name myAKSCluster .

Podobnie, aby utworzyć klaster: az aks create --resource-group myResourceGroup --name myAKSCluster

EKS CLI (przez aws lub eksctl )

W AWS znajdujemy inne podejście — istnieją dwa różne oficjalne narzędzia CLI do zarządzania klastrami EKS. Jak zawsze, aws może łączyć się z zasobami AWS, w szczególności z klastrami. Pobranie danych uwierzytelniających do lokalnego kubeconfig można wykonać poprzez: aws eks update-kubeconfig --name cluster-test .

Jednak inżynierowie mogą również używać eksctl , opracowanego przez Weaveworks i napisanego w Go, aby łatwo tworzyć i zarządzać klastrem EKS. Głównym dobrodziejstwem, jakie EKS zapewnia inżynierom chmury, jest możliwość łączenia go z plikami konfiguracyjnymi YAML w celu tworzenia infrastruktury jako kodu (IaC), ponieważ współpracuje z CloudFormation. Jest to zdecydowanie atut do rozważenia podczas integrowania klastra EKS z większą infrastrukturą w AWS.

Tworzenie klastra za pomocą eksctl jest tak proste, jak eksctl create cluster , nie są wymagane żadne inne parametry.

GKE CLI (przez gcloud )

W przypadku GKE kroki są bardzo podobne: zainstaluj gcloud , a następnie uwierzytelnij się za pomocą gcloud init . Możliwości stamtąd: Inżynierowie mogą tworzyć, usuwać, opisywać, uzyskiwać poświadczenia, zmieniać rozmiar, aktualizować lub uaktualniać klaster lub wyświetlać listę klastrów.

Składnia tworzenia klastra za pomocą gcloud jest prosta: gcloud container clusters create myGCloudCluster --num-nodes=1

AKS vs. EKS vs. GKE: wyniki jazdy testowej

W praktyce widzimy, że GKE z pewnością najszybciej uruchamia podstawowy klaster, zarówno pod względem prostoty konsoli, jak i czasu odradzania klastra. Z punktu widzenia UX, z przyciskiem połączenia obok klastra, dzięki czemu najłatwiej jest również połączyć się z klastrem.

Jeśli chodzi o narzędzia CLI, trzej dostawcy usług w chmurze wdrożyli podobne funkcjonalności; jednak możemy położyć nacisk na dodatkowe narzędzie dostarczane przez Weaveworks dla EKS. eksctl jest idealnym narzędziem do implementacji infrastruktury jako kodu na istniejącej infrastrukturze AWS, łącząc inne usługi z EKS.

Zarządzane oferty Kubernetes rozwijają się naprzód: AWS, GCP i Azure

Dla tych, którzy dopiero zaczynają w świecie Kubernetes, najważniejszą implementacją jest dla mnie GKE, ponieważ jest to najprostsze. Jest łatwy w konfiguracji, ma prosty i szybki interfejs użytkownika do odradzania się i jest dobrze zintegrowany z ekosystemem Google Cloud Platform.

Mimo że AWS dołączył do wyścigu jako ostatni, ma kilka niezaprzeczalnych zalet, takich jak gołe metalowe węzły i prosty fakt, że jest zintegrowany z dostawcą, który ma największy udział w umysłach.

Wreszcie AKS poczynił ogromne postępy od czasu jego utworzenia. Parzystość narzędzi i funkcji prawdopodobnie nie zajmie dużo czasu, pozostawiając w tym czasie miejsce na innowacje. Podobnie jak w przypadku każdej zarządzanej oferty Kubernetes, dla osób już korzystających z platformy nadrzędnej integracja będzie punktem sprzedaży.

Gdy zespół wybierze dostawcę chmury Kubernetes, warto przyjrzeć się doświadczeniom innych zespołów, zwłaszcza awariom. Te sekcje zwłok są odzwierciedleniem rzeczywistych przypadków — zawsze stanowią dobry punkt wyjścia do opracowania własnych najnowocześniejszych najlepszych praktyk. Czekam na Wasze komentarze poniżej!