Kubernetes zrewolucjonizował sposób zarządzania aplikacjami kontenerowymi, a jego dominacja w świecie chmur nie słabnie. W dobie rosnącej popularności środowisk hybrydowych i cloud-native coraz więcej firm sięga po gotowe, zarządzane rozwiązania dostarczane przez największych graczy chmurowych. W pierwszej części cyklu przyjrzymy się trzem liderom rynku – Amazon Web Services (EKS), Google Cloud Platform (GKE) i Microsoft Azure (AKS) – by porównać ich podejście do wdrażania i zarządzania Kubernetesem. Sprawdzimy, jakie oferują możliwości, w czym się różnią i jak dobrać optymalne rozwiązanie do potrzeb swojej organizacji.
Kubernetes, od momentu zaprezentowania w 2014 roku i wydania stabilnej wersji rok później, stał się standardem w świecie orkiestracji. Trudno szukać innego rozwiązania, z wykorzystaniem którego w sposób kompleksowy bylibyśmy w stanie stworzyć ekosystem stanowiący środowisko działania aplikacji kontenerowych. Chociaż istnieją inne rozwiązania, jak Nomad, OpenShift czy Rancher, w pewnym stopniu stanowią one rozwinięcie Kubernetesa i opierają się na nim. Jego skalowalność i elastyczność pozwalają organizacjom efektywnie zarządzać aplikacjami w środowiskach chmurowych, hybrydowych czy on-premise. Alternatywne platformy, dla których Kubernetes jest bazą, dodatkowo potwierdzają jego kluczową rolę, co sprawia, że trudno podważyć tę tezę.
Wybór platformy, na której zbudujemy ten ekosystem, nie jest rzeczą łatwą. Mamy do dyspozycji zarówno rozwiązania umożliwiające tworzenie chmur prywatnych (OpenStack, VMWare czy Harvester), jak również dostawców chmur publicznych. Zapewniają oni rozwiązania gotowe do pracy bez konieczności wdrażania oraz zarządzania infrastrukturą. Jednocześnie udostępniają środowisko w pełni konfigurowalne, które bez przeszkód możemy dostosować do własnych potrzeb.
Chmury publiczne z dnia na dzień zyskują na popularności. Dlatego też, aby wyjść naprzeciw oczekiwaniom i trendom dzisiejszego świata, przyjrzymy się najważniejszym usługom Kubernetes oferowanym przez trzech największych dostawców. Mowa o: Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE) oraz Azure Kubernetes Service (AKS). Omówimy ich architekturę, kluczowe funkcje oraz sposoby integracji z natywnymi usługami chmurowymi. Zwrócę uwagę na wsparcie dla procesów CI/CD, zarządzanie sekretami czy wsparcie dla wspomnianych wcześniej alternatywnych platform jak Rancher czy OpenShift. Na koniec porównam wszystkie rozwiązania, przedstawię scenariusze ich zastosowania i podpowiem, kiedy warto wybrać konkretne podejście. Bez względu na to, czy jesteś administratorem chmury, inżynierem DevOps czy architektem IT – artykuł ten pomoże Ci lepiej zrozumieć, jak skutecznie wdrażać Kubernetes w chmurze.
Korzyści z uruchamiania Kubernetes w chmurze publicznej
Utrzymanie Kubernetesa w środowisku on-premise może być skomplikowane i kosztowne. Poza pełną infrastrukturą serwerową i sieciową, jaką musimy zapewnić, dochodzą jeszcze koszty zasobów ludzkich, które musimy ponieść, aby zagwarantować stabilność, ciągłość działania i bezpieczeństwo naszej platformy. Chmury publiczne oferują nam rozwiązania upraszczające te operacje do minimum i bazujące na modelu, w którym ponosimy jedynie koszty korzystania z dostarczanych usług. Dostawcy usług chmurowych posługują się modelami Saas, czyli Software-as-a-Service oraz CaaS, czyli Container-as-a-Service. Provider zapewnia w nich platformę do uruchamiania i zarządzania kontenerami, eliminując potrzebę administrowania infrastrukturą serwerową.
Skalowalność i elastyczność
Listę korzyści, jakie oferują nam chmury, w porównaniu do rozwiązań on-premises, otwiera niewątpliwie skalowalność i elastyczność. Kubernetes w chmurze publicznej pozwala dynamicznie skalować zasoby, w zależności od obciążenia aplikacji. Dzięki temu, dodając funkcje, takie jak Cluster Autoscaler, Horizontal Pod Autoscaler czy Vertical Pod Autoscaler, zyskujemy platformę, która w sposób płynny i dynamiczny dostosowuje się do naszych wymagań i potrzeb. Wiąże się to nierozerwalnie z możliwością dynamicznego dodawania i usuwania zasobów dosłownie w kilka minut. W dodatku bez konieczności martwienia się o zasoby infrastrukturalne. Jest to praktycznie nie do osiągnięcia, a już na pewno niezwykle trudne do wykonania w środowiskach on-premise. Zakładając, iż obciążenie naszej aplikacji rozkłada się nierównomiernie, lecz w sposób łatwy do przewidzenia i cykliczny, jesteśmy w stanie tak zaplanować skalowanie horyzontalne czy wertykalne, aby w razie potrzeby dodać do klastra kolejne węzły. Natomiast w przypadku braku ich wykorzystania – usunąć je.
Optymalizacja kosztów
Chmura publiczna, ze względu na model, w którym płacimy wyłącznie za wykorzystywane i używane zasoby, pozwala nam dosyć dobrze optymalizować koszty. Zasoby Kubernetesa są często niewykorzystane, a aplikacje zaprojektowane są w taki sposób, że pomimo możliwości korzystania z mechanizmów autoskalowania, nie robią tego. Na takie „marnotrawienie zasobów” możemy sobie oczywiście pozwolić w środowiskach lokalnych. Natomiast chmura wymaga od nas zmiany podejścia na takie, w którym powołujemy do życia tylko te zasoby, z których faktycznie korzystamy. Dodatkowo każdy praktycznie dostawca chmury publicznej daje możliwość rezerwacji zasobów, umożliwiając w ten sposób obniżenie kosztów w dłuższym okresie czasu. Oferują oni również maszyny wirtualne typu spot, których jedyną wadą, w porównaniu do klasycznych instancji, jest to, że w każdej chwili mogą zostać wyłączone. Rozwiązanie to jest idealne dla zadań niewymagających ciągłego działania lub takich, które mogą być bez żadnych strat w każdej chwili wznowione. Przykładem są procesy CI/CD.
Dostępność i odporność na awarie
Chmury publiczne oferują bardzo wysoki poziom dostępności i odporności na awarie. Mamy tutaj do dyspozycji regiony, znajdujące się w różnych strefach geograficznych i strefy dostępności w każdym z nich. Umożliwia to pełne wsparcie dla HA we wdrażanych klastrach Kubernetes. Zresztą, każda chmura zapewnia mechanizmy do globalnej dystrybucji ruchu. Oznacza to, że w bez względu na to, w jakim regionie ulokujemy nasz klaster, użytkownicy, w zależności od konfiguracji Load Balancera, i tak będą kierowani do najbliższego endpointu.
Zarządzalność oraz automatyczna naprawa
Powiedzieliśmy sobie już wcześniej, że usługi oferowane przez dostawców chmury są w pełni zarządzalne. To znaczy, że oprócz braku konieczności administrowania infrastrukturą serwerową i zmniejszonych do minimum czynności operacyjnych (instalowanie, konfigurowanie czy aktualizowanie klastrów) otrzymujemy również możliwość automatycznego instalowania poprawek w systemach operacyjnych obsługujących węzły kubernetesowe. Możliwa jest także ich automatyczna naprawa w przypadku awarii. Wbudowane narzędzia do monitorowania i logowania, takie jak Amazon CloudWatch, Google Cloud Operations Suite czy Azure Monitor, znacznie nam to ułatwiają. Dodać należy również natywne wsparcie dla podejścia IaC i możliwość wykorzystania narzędzi uniwersalnych, jak Terraform czy Pulumi. U każdego providera dostępne są także dedykowane platformy, czyli AWS CloudFormation, Google Cloud Deployment Manager i Azure Resource Manager.
Integracja z natywnymi usługami chmurowymi
Kolejną rzeczą, na jaką warto zwrócić uwagę, jest integracja z natywnymi usługami chmurowymi. Trudno znaleźć dzisiaj usługę, która nie działa w modelu SaaS, a ich paleta wciąż się zwiększa. Mamy do dyspozycji zarówno bazy danych, systemy przechowywania danych, platformy do wdrażania modeli AI czy wreszcie usługi bezpieczeństwa i mechanizmy do zarządzania sekretami. To właśnie sekrety i informacje niejawne stanowią często problem w lokalnych klastrach kubernetesowych, wymuszając instalowanie i używanie zewnętrznych rozwiązań. Dostawcy chmurowi uwalniają nas od tego obowiązku, oferując takie usługi jak AWS Secrets Manager, GCP Secret Manager czy Azure Key Vault.
Łatwe zarządzanie cyklem życia aplikacji
Ostatnią, ale nie mniej ważną korzyścią wdrażania klastrów kubernetesowych w chmurach publicznych jest łatwiejsze zarządzanie cyklem życia aplikacji z wykorzystaniem metodologii GItOps. Wykorzystuje się w tym celu takie rozwiązania jak ArgoCD czy Flux. Dodatkowo pełne wsparcie dla procesów CI/CD z wykorzystaniem chociażby GitHub Actions czy AWS CodePipeline, Azure DevOps lub Google Cloud Build, posiadających wsparcie dla helm chartów, operatorów czy zdefiniowanych zasobów użytkownika w klastrach. Wszystko to dodatkowo upraszcza wdrażanie aplikacji.
Przegląd głównych dostawców chmury: AWS, GCP, Azure
Amazon Web Services, Google Cloud Platform i Microsoft Azure to zdecydowanie najwięksi na rynku gracze, jeżeli chodzi o dostarczanie usług chmury publicznej. Każdy z nich posiada również natywną, zarządzaną usługę Kubernetes. Eliminuje to konieczność samodzielnej konfiguracji i utrzymania klastrów.
Amazon Elastic Kubernetes Service
Amazon Elastic Kubernetes Service (EKS) umożliwia pełną integrację z pozostałymi usługami AWS, jak IAM, VPC, ALB czy RDS. Jedną z ciekawszych usług kontenerowych jest AWS Fargate. To usługa serverless, która umożliwia uruchamianie podów Kubernetes w modelu serverless, eliminując konieczność zarządzania węzłami roboczymi. Warto jednak zauważyć, że Fargate dla EKS działa inaczej niż w ECS, czyli natywnej usłudze Amazona do zarządzania kontenerami.
Zwrócić uwagę należy również na to, iż w tym przypadku Fargate nie obsługuje DaemonSetów. Wymaga specyficznych konfiguracji sieciowych i nie wspiera obciążeń GPU. Ograniczenia te mogą wpłynąć na wybór rozwiązania w zależności od wymagań aplikacji. AWS umożliwia stawianie węzłów na maszynach typu spot, o czym wspominaliśmy już wcześniej. Pozwala to na znaczne obniżenie kosztów w przypadku zadań niewymagających ciągłego działania.
Ciekawą usługą jest również EKS Anywhere, pozwalająca na uruchamianie i zarządzanie klastrami Kubernetes w środowisku on-premise. Dzięki niej zyskujemy całkowitą zgodność z EKS przy jednoczesnym wykorzystaniu własnych maszyn wirtualnych w lokalnej serwerowni lub nawet innej chmury.
AWS w kontekście konteneryzacji oferuje takie usługi i funkcjonalności jak Amazon RDS, umożliwiający uruchamianie relacyjnych baz danych, APP Mesh dla komunikacji pomiędzy podami, Secret Manager do zarządzania sekretami i informacjami niejawnymi czy wreszcie Auto Scaling, pozwalający na dynamiczne skalowanie klastrów. Do wad tego rozwiązania należy przede wszystkim nieco złożona konfiguracja dostępów z wykorzystaniem usługi IAM oraz nieco trudniejsze niż w pozostałych przypadkach zarządzanie siecią.
Google Kubernetes Engine (GKE)
Google Kubernetes Engine (GKE) to zarządzana usługa konteneryzacji oferowana przez twórcę Kubernetesa. Co za tym idzie, jest najbardziej zintegrowana i zgodna ze specyfikacją K8s. Google oferuje nam możliwość uruchomienia Kubernetesa w trybie serverless, dostarczając usługę o nazwie GKE Autopilot. W tym przypadku płacimy jedynie za wykorzystanie zasobów pod działające aplikacje, a całą konfiguracją i administracją klastra zajmuje się dostawca chmury.
W klastrze mamy dostępne Istio, czyli usługę service mesh, będącą warstwą zarządzania ruchem pomiędzy usługami. Umożliwia ona zaawansowane funkcje, takie jak routing, zabezpieczenia, monitoring i automatyczne balansowanie obciążenia bez konieczności modyfikacji kodu aplikacji. Typowa implementacja podejścia serverless w tym przypadku nosi nazwę Cloud Run. Pozwala ona na uruchamianie kontenerów bez konieczności stawiania klastra kubernetesowego.
Usługi, z jakimi nasz klaster się doskonale integruje, to przede wszystkim Cloud Spanner, czyli skalowalna baza danych, Google Secret Manager do zarządzania sekretami, a także Vertex AI umożliwiająca integrację z AI/ML.
Azure Kubernetes Service
Azure Kubernetes Service (AKS) to produkt najbardziej zintegrowany z ekosystemem Microsoftu. W jego skład wchodzą między innymi Windows Server czy Active Directory. AKS wspiera kontenery oparte na systemie Windows, co znajduje się w oficjalnej specyfikacji Kubernetesa, począwszy od wersji 1.14. W odróżnieniu od pozostałych dostawców chmury jest to wsparcie praktycznie kompletne. Jednak wciąż jest ono mniej istotne i znacznie mniej stabilne niż wsparcie dla Linuxa. Wynika to prawdopodobnie z faktu, iż kontenery oparte na systemie Microsoftu stanowią znikomy procent i ich popularność jest nikła. Posiada on również wbudowane Azure Policy, służące do zarządzania regulacjami. Także i tutaj możemy skorzystać z rozwiązania serverless. W tym przypadku nosi ono nazwę Azure Container Apps.
Jeśli chodzi o integrację z innymi usługami oferowanymi przez chmurę Microsoftu, to wyróżnić można przede wszystkim Azure Key Vault, służące do przechowywania sekretów, Azure DevOps oferujące pełną integrację z procesami CI/CD czy Azure Monitor i Log Analytics. Oczywiście możliwa jest integracja z większością usług oferowanych przez chmurę, jednak działa ona najlepiej z tymi działającymi w ekosystemie Microsoftu. Drugą wadą jest nieco większa złożoność konfiguracji, zwłaszcza w porównaniu do produktu Google.
Co wybrać?
Wszystkie wspomniane rozwiązania są w gruncie rzeczy podobne do siebie. Oferują możliwość tworzenia klastrów kubernetesowych bez konieczności zarządzania infrastrukturą serwerową. Umożliwiają skorzystanie z w pełni zarządzalnej wersji serverless oraz dają możliwość integracji z innymi usługami oferowanymi przez chmurę. Pozwalają na połączenie z innym dostawcą lub nawet stworzenie chmury hybrydowej łączącej w sobie różne podejścia. Każdy dostawca stosuje jednak nieco inne podejście, co postaram się rozwinąć w niniejszym artykule.
Amazon Elastic Kubernetes Service
Architektura i sposób działania
Powołując Kubernetesa w chmurze Amazona, otrzymujemy środowisko gotowe do uruchamiania klastrów bez konieczności czy nawet bez możliwości zarządzania infrastrukturą kontrolną. Węzły typu Control Plane utrzymywane są i aktualizowane przez AWS. Otrzymujemy natomiast w pełni skonfigurowane workery działające na bazie serwerów wirtualnych EC2. Te mogę być dodawane i zarządzane przez użytkownika. Klastry instalują się wewnątrz izolowanej prywatnej bądź publicznej podsieci VPC, umożliwiając między innymi wsparcie dla CNI w celu dynamicznego przydzielania adresów IP. Oczywiście możemy swobodnie zarządzać konfiguracją sieciową z punktu widzenia bezpieczeństwa. Podobnie zresztą jak integracją z AWS IAM, dzięki czemu mamy pełną kontrolę nad dostępami do naszych klastrów i zasobów. Przechowywanie danych to przede wszystkim Amazon EBS, EFS czy FSx. Natomiast eksponowania aplikacji na zewnątrz klastra możemy z powodzeniem dokonać, wykorzystując Load Balancery i Ingress Controllery.
Integracja z usługami AWS (IAM, VPC, ALB, Route 53, CloudWatch)
Wykorzystując konta serwisowe w Kubernetesie, możemy zintegrować naszą aplikację z IAM i przy pomocy RBAC przydzielić każdemu podowi osobną rolę uruchamianą w ramach kontenera w zależności od potrzeb. Dzięki temu możemy z powodzeniem posługiwać się zasadą Principle of Least Privilege (PoLP), polegającą na przydzielaniu aplikacjom tylko tych uprawnień, które są naprawdę niezbędne do pracy. Mówimy tutaj głównie o integracji z innymi usługami oferowanymi przez AWS.
Application Load Balancer (ALB) oraz Network Load Balancer (NLB) to usługi umożliwiające wystawienie kontenerów na zewnątrz. Możemy skorzystać zarówno z protokołów HTTP i HTTPS (umożliwiających udostępnianie np. stron internetowych z wykorzystaniem warstwy 7 sieci), jak i protokołów TCP i UDP w sytuacjach, w których usługi, jakie serwujemy, udostępniają dane poprzez warstwę 4.
Route 53 to z kolei skalowalna i wysoko dostępna usługa zarządzania rekordami DNS. Umożliwia ona rejestrowanie domen, zarządzanie rekordami DNS oraz obsługę routingu na podstawie różnych strategii, jak geolokalizacja czy latency-based routing. Również tutaj mamy pełną swobodę i możemy wykorzystać cały potencjał tego serwisu.
Ostatnią usługą, o jakiej warto wspomnieć, jest Amazon CloudWatch. Pozwala na pełny monitoring, zbieranie metryk i centralne logowanie zdarzeń klastrów uruchomionych na EKS oraz praktycznie wszystkich innych usług oferowanych przez AWS. CloudWatch może być używane między innymi do monitorowania metryk (jak użycie CPU, pamięci czy liczba podów), zbierania logów z aplikacji i komponentów K8s (np. kubelet, controller-manager), jak również do obsługi alertów na podstawie metryk czy logów. CloudWatch daje nam także możliwość integracji z Grafaną i Prometheusem, co dodatkowo zwiększa jego funkcjonalność.
Zarządzanie klastrem: AWS Console, eksctl, Terraform
Zarządzać klastrem EKS możemy na kilka sposobów. Najprostszym i najbardziej intuicyjnym jest oczywiście graficzna konsola AWS. Za jej pomocą możemy zrobić praktycznie wszystko – od samego utworzenia klastra, jego konfiguracji i integracji z usługami zewnętrznymi, poprzez wdrażanie aplikacji aż do monitorowania stanu klastra, węzłów, a nawet samych aplikacji.
Narzędzie o nazwie eksctl to oficjalne CLI do zarządzania EKS. Jego możliwości nie są tak duże jak konsoli, gdyż zostało ono stworzone przede wszystkim do zarządzania samymi klastrami, podczas gdy konsola AWS oferuje możliwości znacznie wykraczające poza EKS. Umożliwia ona między innymi zaawansowane zarządzanie siecią, politykami IAM czy integracją z innymi usługami AWS. Główne możliwości eksctl to tworzenie i usuwanie klastrów EKS, zarządzanie węzłami roboczymi i grupami węzłów, zarządzanie siecią i bezpieczeństwem klastra oraz konfiguracją IAM dla Kubernetes ServiceAccount, a także obsługa aktualizacji klastra i węzłów. Jednak eksctl nie umożliwia chociażby analizy logów czy obsługi monitoringu poprzez wspomniany CloudWatch. Ogranicza to trochę jego funkcjonalność w procesie administracji.
Ostatnim sposobem zarządzania klastrem, na który warto zwrócić uwagę, jest Terraform. Jest to rozwiązanie stworzone raczej do zarządzania infrastrukturą, bazujące na modelu IaC, czyli Infrastructure as Code. Dzięki swojej wszechstronności i możliwości korzystania z całej gamy providerów (w tym wielu oficjalnych, tworzonych i utrzymywanych przez producenta – firmę HashiCorp), pozwala nie tylko na planowanie i definiowanie samej struktury klastra, ale również na wdrażanie i utrzymywanie aplikacji kontenerowych.
Obsługa sieci i storage w EKS
Do zarządzania ruchem sieciowym w EKS wykorzystywany jest Container Network Interface (CNI). Jest to natywne rozwiązanie oferowane przez AWS, które zapewnia, że każdy pod Kubernetes otrzymuje własny adres IP bezpośrednio w Amazon VPC. Dzięki temu, w odróżnieniu od klasycznych rozwiązań, nie musimy korzystać z NAT i tunelowania. Skutkuje to małymi opóźnieniami w przesyłaniu pakietów oraz wysoką przepustowością. Zarządzanie bezpieczeństwem sieci w AWS opiera się na rozwiązaniu o nazwie Security Groups. W kontekście klastrów kubernetesowych zapewnia ono ograniczenia w dostępie nie tylko do całych węzłów, ale także do pojedynczych podów. Co za tym idzie – działających na nich aplikacji. Dzięki temu już na poziomie klastra, bez potrzeby korzystania z wewnętrznych mechanizmów Kubernetesa, możemy ograniczyć dostęp tylko z lub do określonych adresów IP.
Service Mesh to technologia pozwalająca zarządzać ruchem sieciowym między mikrousługami w klastrze Kubernetes. EKS obsługuje zarówno AWS App Mesh, jak i z Istio. AWS App Mesh to natywny serwis AWS integrujący się z Cloud Map (umożliwiającym aplikacjom dynamiczne odkrywanie, znajdowanie i łączenie się z usługami, bazami danych, kolejkami i innymi zasobami w chmurze) oraz ze wspomnianym Route 53. Istio, jest natomiast popularną open source’ową implementacją service mesh, używaną w wielu środowiskach Kubernetes.
Jeżeli chodzi o storage, to mamy tu przede wszystkim możliwość skorzystania z Amazon Elastic Block Store (EBS). To usługa pozwalająca na tworzenie i przypisywanie kontenerom wolumenów blokowych. Cechuje się ona przede wszystkim wysoką wydajnością i niską latencją oraz możliwością wykonywania snapshotów, a także automatycznym backupem. Możemy też skorzystać z Amazon EFS, jeżeli potrzebujemy dostępu współdzielonego, dostępnego w różnych strefach (Multi-AZ) oraz umożliwiającego automatyczne skalowanie bez konieczności zarządzania pojemnością. W klastrach EKS mamy również dostępny Amazon FSx, będący usługą przeznaczoną dla środowisk wymagających pełnej kompatybilności z systemami Windows, jak również z Amazon S3. Jednak nie jest to natywny system plików jak EBS czy EFS. Skorzystanie z niego wymaga dodatkowej konfiguracji zarówno po stronie serwisów kubernetesowych, jak i nadania dodatkowych uprawnień w IAM.
Mechanizmy bezpieczeństwa i zarządzanie sekretami
Bezpieczeństwo i zarządzanie sekretami to kluczowe aspekty wdrażania aplikacji w EKS. AWS oferuje nam natywne rozwiązanie do zarządzania informacjami niejawnymi, czyli AWS Secrets Manager. Jest to usługa bezpiecznego przechowywania i zarządzania sekretami, takimi jak hasła do baz danych (np. RDS, Aurora, PostgreSQL, MySQL), klucze API i tokeny dostępu do zewnętrznych usług, poświadczenia IAM do uwierzytelniania aplikacji czy klucze szyfrowania. Najważniejsze funkcje tego rozwiązania to przede wszystkim automatyczna rotacja sekretów i integracja z IAM. To także łatwa integracja z Kubernetesem, dzięki czemu poprzez External Secrets Operator (umożliwiający automatyczne pobieranie sekretów i ich konwersję na natywne obiekty Kubernetesa) zwiększamy znacznie poziom bezpieczeństwa naszych aplikacji bez konieczności dokonywania znaczących zmian w kodzie czy manifestach yaml.
Koszty i modele rozliczeń
Mówiąc o chmurach publicznych, nie sposób nie wspomnieć o kosztach. Model, jakim posługuje się AWS, jest relatywnie prosty – płacimy za to, z czego korzystamy. W EKS nie płaci się za sam Kubernetes, ale za zasoby obliczeniowe, sieć, przechowywanie danych oraz dodatkowe usługi AWS, które są wykorzystywane w klastrze. Analizując temat bardziej szczegółowo, koszty korzystania z Kubernetesa dostarczonego przez Amazon możemy podzielić na koszty związane z:
- zarządzaniem warstwą kontrolną (Control Plane);
- instancjami EC2 działającymi jako workery;
- przechowywaniem danych;
- obsługą sieci (np. ruch wychodzący czy obsługa Load Banalcerów);
- wszystkimi dodatkowymi usługami AWS, które mogą być używane do monitoringu, zarządzania sekretami czy routingu ruchu sieciowego.
Pamiętajmy, że duża część usług oferowanych przez AWS jest bezpłatna lub przynajmniej występuje w różnych wariantach. Skorzystanie z podstawowego nie generuje kosztów. Przykładem może być chociażby CloudWatch, gdzie otrzymujemy 5 GB bezpłatnego miejsca na logi. Uruchamiając i używając Kubernetesa w wydaniu AWS-owym musimy się zastanowić nad mocą obliczeniową, jakiej potrzebujemy, konfiguracją sieci czy nad tym, na ile potrzebne nam są dodatkowe usługi. Nieprzemyślane wykorzystanie dostępnych usług i serwisów może być bowiem przyczyną generowania naprawdę dużych kosztów.
Google Kubernetes Engine (GKE)
Architektura i główne cechy
Planując wdrożenie Kubernetesa w chmurze oferowanej przez Google mamy do wyboru dwa tryby jego działania: autopilot i standard. Pierwszy z nich jest opcją, w której to provider zarządza całą praktycznie infrastrukturą Kubernetesa, w tym workerami, skalowaniem i optymalizacją kosztów. W trybie autopilot nie mamy zbyt wielu możliwości zarządzania i administrowania naszym klastrem. Jednak jest on doskonały do testów, stawiania szybkich środowisk deweloperskich czy testowych. Idealnie sprawdza się także w sytuacjach, w których potrzebujemy klastra niezawodnego, ale jednocześnie prostego w instalacji i obsłudze, bez konieczności jego konfigurowania. Nie zapominajmy jednak, że dostajemy do dyspozycji środowisko kompletne i zgodne ze specyfikacją – pod spodem jest taka sama infrastruktura, jak w przypadku klasycznej wersji. Wersja standard natomiast to typowy Kubernetes instalowany w chmurze, w którym to Google zarządza węzłami typu Control Plane, a całą resztą zawiaduje użytkownik. GCP daje nam co prawda możliwość automatycznej aktualizacji workerów, jednak jest to funkcjonalność opcjonalna, na którą nie musimy się zgadzać.
GCP oferuje nam takie opcje jak Horizontal Pod Autoscaler (HPA), który skaluje aplikacje na podstawie metryk (np. CPU, RAM) czy Cluster Autoscaler, dzięki któremu możliwe jest dynamiczne dodawanie i usuwanie węzłów w zależności od obciążenia klastra. GKE, podobnie jak AWS, daje nam rozbudowane możliwości zarządzania dostępem, integrując się z IAM oraz Workload Identity, które pozwala aplikacjom na dostęp do usług Google Cloud bez przechowywania kluczy API w Kubernetes. Pod względem integracji sieciowej GKE wykorzystuje Google Virtual Private Cloud (VPC) do izolacji i komunikacji między zasobami. Mamy możliwość użycia Pod CIDR (IP Alias) dla natywnych adresów IP podów w VPC oraz możliwość wykorzystania Ingress Controllerów i automatycznego równoważenia ruchu na L4 (TCP/UDP) i L7 (HTTP/HTTPS) dla aplikacji poprzez Load Balancery. GKE oferuje też pełną integrację z Istio i Anthos Service Mesh do zarządzania ruchem sieciowym, politykami bezpieczeństwa i monitoringiem mikrousług.
Integracja z ekosystemem GCP (IAM, Cloud Logging, Cloud Load Balancing, VPC)
Zarządzanie dostępem w GKE odbywa się na trzech poziomach:
- poziom projektu – na którym przydzielamy dostęp do wszystkich zasobów;
- poziom klastra – gdzie dostęp ogranicza się tylko do zasobów kontenerowych;
- poziom przestrzeni nazw i podów – umożliwiający precyzyjne nadawanie uprawnień i ról do konkretnych aplikacji czy zasobów klastra.
Osobną funkcjonalnością, jaką dostajemy do dyspozycji, jest Workload Identity, będący bezpieczną metodą integracji z innymi usługami Google Cloud. Workload Identity umożliwia podom Kubernetes uwierzytelnianie się w Google Cloud bez konieczności przechowywania kluczy API. Dodatkowo każdy pod może zostać przypisany do tożsamości IAM. Pozwala mu to korzystać z takich usług jak Cloud Storage, BigQuery czy Pub/Sub, zastępując w ten sposób wcześniejsze podejście oparte na kluczach (service account keys). Zwiększa to bezpieczeństwo i minimalizuje ryzyko wycieku tychże kluczy.
Google Cloud Logging
Google Cloud Logging (dawniej Stackdriver) pozwala na zbieranie, analizowanie i przeszukiwanie logów generowanych przez aplikacje i infrastrukturę Kubernetes. Integracja GKE z Cloud Logging polega na tym, że każdy klaster GKE może automatycznie wysyłać logi do Cloud Logging, w tym dane z węzłów worker nodes, kontenerów oraz aplikacji uruchamianych w podach. Możemy przeglądać logi w Google Cloud Console, eksportować je do bazy danych BigQuery czy też analizować w usłudze Cloud Operations. Dodatkowo możemy tworzyć alerty na podstawie logów, np. powiadomienia o błędach HTTP czy innych błędach aplikacyjnych. GKE wspiera też Google Managed Service for Prometheus, co umożliwia natywne monitorowanie metryk Kubernetes oraz ich wizualizację w Grafanie.
Google Cloud Load Balancing
Google Cloud Load Balancing to w pełni zarządzana usługa równoważenia ruchu, która obsługuje ruch przychodzący do aplikacji Kubernetes w GKE. Wśród typów LB mamy do dyspozycji:
- External i interlan HTTP(S) Load Balancer – używany z Kubernetes Ingress do obsługi ruchu HTTP/HTTPS;
- TCP/UDP Load Balancer – obsługujący warstwę czwartą;
- Network Load Balancer – dla aplikacji wymagających niskiej latencji i wysokiej wydajności.
Jak działa Cloud Load Balancer w GKE? Wystarczy utworzyć Service typu LoadBalancer lub Ingress, a GKE automatycznie skonfiguruje odpowiedni Load Balancer w Google Cloud. Dodatkowo oferuje globalny routing, co oznacza, że użytkownicy są kierowani do najbliższego regionu Google Cloud. Możemy też zintegrować go z serwisem Cloud Armor, oferującym pełną ochronę przed atakami DDoS oraz Identity-Aware Proxy (IAP), służącym jako pośrednik w procedurze uwierzytelniania użytkowników.
Google Cloud Virtual Private Cloud
Google Cloud Virtual Private Cloud (VPC) zapewnia izolowaną sieć dla klastrów GKE, umożliwiając bezpieczną komunikację między podami, usługami i innymi zasobami GCP. Podstawowa integracja odbywa się za pomocą VPC-Native Clusters, wykorzystujących IP Alias, umożliwiających każdemu podowi otrzymanie własnego adresu IP w VPC zamiast współdzielenia adresów worker nodes. Dodatkowo możliwa jest obsługa tzw. Private Clusters. Wówczas węzły klastra dostępne będą wyłącznie w ramach prywatnej sieci VPC. Kontrola dostępu odbywa się, podobnie jak w rozwiązaniu oferowanym przez AWS, na Security Groups i Firewall Rules. Dają nam one możliwość tworzenia reguł firewall kontrolujących ruch między podami i usługami Kubernetes.
Zarządzanie klastrem: gcloud CLI, Terraform
Do zarządzania klastrem postawionym na GCP możemy użyć konsoli graficznej. Jest to rozwiązanie, które oferuje każda z opisywanych chmur. Także w tym przypadku jest to najbardziej intuicyjne i kompletne podejście, dające nam, z pewnymi małymi wyjątkami, praktycznie wszystkie możliwości administracji. Konsola jest dosyć prosta w obsłudze i nie odbiega znacznie w swojej funkcjonalności od tego, co oferują inni providerzy.
Drugą możliwością jest narzędzie gcloud, wchodzące w skład pakietu Google Cloud SDK. Pozwala ono na interakcję nie tylko z GKE, ale też z pozostałymi usługami Google Cloud. Gcloud CLI to oficjalne narzędzie do zarządzania usługami Google Cloud, w tym Google Kubernetes Engine (GKE). Różni się tym od narzędzia eksctl opisywanego w poprzednim rozdziale, które zostało stworzone stricte do zarządzania klastrem kubernetesowym. Tutaj możliwości są znacznie większe. Poprzez gcloud CLI możemy bowiem zarządzać praktycznie wszystkimi usługami oferowanymi przez GCP. Poza tworzeniem i zarządzaniem klastrami GKE (obsługa dotyczy również klastrów powołanych w trybie autopilot), umożliwia integrację z IAM i Cloud Logging, konfiguracje autoskalowania, obsługę sieci czy nawet zarządzanie rekordami DNS w Route 53.
Trzecią i ostatnią metodą kontroli, jaką chciałbym opisać, jest ponownie – tak jak w przypadku poprzedniej chmury – Terraform. Umożliwia on definiowanie i zarządzanie infrastrukturą chmurową za pomocą deklaratywnych plików konfiguracyjnych. Daje nam możliwość automatyzacji tworzenia i zarządzania klastrami. Umożliwia wersjonowanie infrastruktury przy jednoczesnej łatwej integracji z pozostałymi usługami GCP. Zapewnia także spójność konfiguracji i łatwość odtwarzania środowiska. Wybór narzędzia zależy oczywiście od potrzeb. Terraform jest lepszy do długoterminowego zarządzania infrastrukturą, a konsola i gcloud CLI do szybkich działań administracyjnych.
Obsługa sieci i storage w GKE
GKE oferuje dwa tryby sieci:
- VPC-native – które jest rozwiązaniem rekomendowanym, umożliwiającym bardziej zaawansowaną kontrolę nad ruchem sieciowym;
- Routes-based – będącym implementacją klasycznego, znacznie mniej elastycznego modelu opartego na trasach.
GKE wykorzystuje Google Cloud VPC, co oznacza, że wszystkie pody i węzły mogą być częścią tej samej wirtualnej sieci. W trybie VPC-native każdy pod może otrzymać własny adres IP z puli adresowej VPC, co poprawia bezpieczeństwo i skalowalność.
Jak już powiedzieliśmy wcześniej, Service Mesh to warstwa sieciowa dla mikroserwisów, umożliwiająca zaawansowaną komunikację między usługami w klastrze Kubernetes. W Google Kubernetes Engine integracja z Service Mesh ułatwia zarządzanie ruchem, bezpieczeństwem oraz monitoringiem aplikacji. Google oferuje dwie główne opcje wdrożenia Service Mesh w GKE:
- Istio – utrzymywane jako open source, umożliwiające samodzielne zarządzanie Service Mesh;
- Anthos Service Mesh (ASM) – czyli w pełni zarządzana usługa z pełną integracją z GCP. Do podstawowych funkcji tego rozwiązania należy automatyczne równoważenie obciążenia między usługami, szyfrowanie ruchu pomiędzy podami, mechanizmy kontroli dostępu czy zaawansowana obserwowalność.
Wśród typów pamięci masowej obsługiwanej przez klastry GKE, możemy wyróżnić:
- Persistent Disk – będący domyślną opcją, czyli typowy dysk podłączony do instancji pełniących funkcję workerów;
- Filestore – który jest implementacją protokołu NFS oferowaną przez Google, używaną głównie tam, gdzie wymagany jest storage współdzielony;
- obiektowy Cloud Storage – dla przechowywania nieustrukturyzowanych danych, jak backupy czy dane statyczne.
Mechanizmy bezpieczeństwa i zarządzania sekretami (GCP Secret Manager, Sealed Secrets)
W kontekście klastrów Google Kubernetes Engine, zarządzanie sekretami i ich bezpieczeństwo są kluczowe dla zapewnienia ochrony danych uwierzytelniających, kluczy API i innych wrażliwych informacji. Istnieje kilka podejść i narzędzi, które można wykorzystać do bezpiecznego przechowywania oraz dostarczania sekretów do aplikacji uruchamianych w GKE. Wśród najważniejszych rozwiązań warto wyróżnić Google Cloud Secret Manager – będący zarządzaną przez Google usługą umożliwiającą centralne i bezpieczne przechowywanie i zarządzanie sekretami. Zapewnia takie funkcjonalności jak automatyczna rotacja, precyzyjna kontrola dostępu oparta na IAM czy audyt i logowanie. GCP Secrets Manager w pełni integruje się z klastrem, dając nam znacznie większy poziom bezpieczeństwa niż przy pomocy wbudowanego w Kubernetes mechanizmu sekretów. Dodatkowo nie musimy rezygnować z klasycznego podejścia, czyli ładowania sekretów bezpośrednio do zmiennych środowiskowych aplikacji. Jednocześnie jako natywny serwis chmurowy integruje się z pozostałymi usługami Google Cloud Platform. Dzięki temu możliwe jest wykorzystanie Workload Identity do bezpiecznego uwierzytelnienia aplikacji w GCP.
Koszty i modele rozliczeń
GKE obsługuje trzy główne modele kosztowe, w zależności od typu klastra:
- Autopilot – w którym płacimy tylko za uruchomione pody oraz wykorzystane przez nie zasoby jak CPU, pamięć RAM czy storage;
- Standard – do których dochodzi jeszcze opłata za działające węzły i pamięć dyskową;
- KE Enterprise – będący najdroższą, ale też najbardziej kompletną opcją w sytuacjach, w których potrzebujemy zaawansowanej automatyzacji i bezpieczeństwa oraz pełnego wsparcia firmy.
Koszty korzystania z GKE nie różnią się zbytnio od pozostałych klastrów. Dla modelu Standard obejmują koszty ruchu sieciowego, maszyn wirtualnych pełniących rolę węzłów, oraz pamięć dyskową. W każdej chmurze publicznej – także i tu – płacimy według modelu pay-as-you-go. Opłaty są naliczane za faktyczny czas korzystania z zasobów. Pamiętajmy, że klaster kubernetesowy postawiony jest na rzeczywistych maszynach wirtualnych.
Azure Kubernetes Service (AKS)
Architektura i sposób działania
Azure Kubernetes Service (AKS) to zarządzana usługa Kubernetes dostarczana przez Microsoft w ramach platformy Azure. Architektura AKS składa się z kilku kluczowych elementów, które współpracują w celu zarządzania klastrem Kubernetes w chmurze. Są to między innymi:
- uruchamiane w ramach klastra workery oparte na zarządzanych przez użytkownika maszynach wirtualnych;
- węzły typu Control Plane zarządzane, podobnie jak w przypadku pozostałych platform, przez dostawcę chmury – firmę Microsoft;
- usługi i zasoby zintegrowane z AKS, jak:
- Azure Virtual Network (VNet) – zapewniający izolację sieciową dla klastra AKS i umożliwiający komunikację między węzłami w ramach prywatnej sieci,
- Azure Load Balancer – używany do równoważenia obciążenia między węzłami klastra, szczególnie w przypadku serwisów typu LoadBalancer,
- Azure Active Directory – umożliwiający integrację w tożsamościami w chmurze i dający możliwość uwierzytelnienia użytkowników,
- Azure Storage – czyli przestrzeń dyskowa dla aplikacji wymagających przechowywania danych.
W przypadku AKS Microsoft automatycznie zarządza aktualizacjami i poprawkami dla Control Plane, ale użytkownicy muszą dbać o aktualizację węzłów roboczych. Aktualizacje mogą być zarządzane ręcznie lub automatycznie.
AKS udostępnia takie funkcjonalności jak zarządzanie skalowaniem węzłów (poprzez Cluster Autoscaller umożliwiający automatyczne dostosowywanie liczby węzłów w odpowiedzi na wymagania) oraz podów (z wykorzystaniem funkcji Horizontal Pod Autoscaler, który skaluje aplikacje w zależności od obciążenia). Azure Monitor i Log Analytics to z kolei narzędzia dające nam możliwość monitorowania zdrowia klastrów, wykrywania problemów z wydajnością czy zbierania statystyk i metryk (jak wykorzystanie CPU, RAM czy dysków). Mamy tutaj do dyspozycji takie usługi jak szczegółowe zarządzanie dostępem użytkowników poprzez RBAC, Network Policies, dające kontrolę komunikacji między podami w klastrze, czy Azure Key Vault, czyli usługę przechowywania informacji niejawnych.
Również AKS posiada w swojej ofercie usługę uruchamiania kontenerów w modelu serverless. W tym przypadku nosi ona nazwę Azure Container Apps i jest alternatywą zarówno dla AWS Fargate, jak i GKE Autopilot. Oferuje jednak kilka unikalnych cech, takich jak:
- obsługa KEDA (Kubernetes Event-Driven Autoscaler) – pozwalająca na autoskalowanie kontenerów na podstawie różnych źródeł eventów (np. kolejki, zapytania HTTP, Prometheus czy Kafka);
- obsługa Distributed Application Runtime – pozwalająca na budowanie mikroserwisów i rozproszonych aplikacji;
- możliwość uruchamiania zarówno długoterminowych aplikacji (backendy czy serwisy API), jak i krótkoterminowych kontenerów reagujących na eventy, tzw. event-drivern, np. webhooki czy przetwarzanie kolejek.
Integracja z usługami Azure (Azure AD, Azure Monitor, Application Gateway, VNET)
Azure Active Directory jest usługą pozwalającą na zarządzanie tożsamościami i dostępem w chmurze. Zapewnia centralne uwierzytelnianie i kontrolowanie dostępu do aplikacji oraz zasobów. W przypadku AKS integracja z Azure AD pozwala na uwierzytelnianie oraz autoryzację użytkowników i aplikacji za pomocą tożsamości w Azure AD, a także na stosowanie RBAC. Pozwala to na przypisywanie określonych ról użytkownikom lub grupom domenowym, umożliwiając precyzyjne zarządzanie dostępem, również poprzez takie narzędzia jak kubectl. Jedną z ciekawszych funkcji jest integracja z Azure AD Pod Identity, dzięki której aplikacje kubernetesowe uruchamiane w podach mają możliwość komunikowania się i uwierzytelniania w pozostałych zasobach chmury Microsoftu.
Azure Monitor to kompleksowe rozwiązanie do monitorowania aplikacji, infrastruktury i usług w chmurze Azure. Zintegrowany z AKS pozwala na śledzenie wydajności, analizowanie dzienników i zdarzeń oraz identyfikowanie problemów w klastrze kubernetesowym. Dzięki integracji z Log Analytics możliwe jest analizowanie logów, takich jak dzienniki z kube-apiserver, kube-scheduler, kubelet, jak również aplikacji działających w klastrze. Można tworzyć niestandardowe zapytania i raporty, które pomogą w diagnozowaniu problemów z wydajnością lub błędów aplikacji. Azure Monitor obsługuje monitorowanie kontenerów w AKS, umożliwiając śledzenie zasobów, takich jak wykorzystywana pamięć i CPU, a także wykrywanie nieprawidłowego zachowania aplikacji (przeciążenie CPU lub przekroczenie limitów pamięci). Funkcja Alerts and Diagnostics, będąca częścią Azure Monitora, pozwala na definiowanie alertów na podstawie zebranych metryk i logów. W przypadku wykrycia nieprawidłowości w systemie usługa wyśle powiadomienie, co pozwala na szybkie reagowanie na problemy.
Wystawienie aplikacji kontenerowych na świat oraz sterowanie ruchem możemy osiągnąć poprzez zastosowanie load balancingu dla warstwy 7 modelu OSI, czyli narzędzia o nazwie Azure Application Gateway. Poza funkcjami związanymi z równoważeniem ruchu jest ono też w pełni zarządzalnym firewallem aplikacyjnym obsługującym żądania oparte o kryteria, takie jak ścieżki URL czy nagłówki. Dzięki wbudowanemu Web Application Firewall mamy zapewnioną dodatkową warstwę ochrony przed popularnymi zagrożeniami aplikacji webowych. Mowa o atakach SQL Injection czy Cross-Site Scripting. Obsługa warstwy 4 z wykorzystaniem protokołów TCP i UDP jest natomiast dostępna w Azure Load Balancerze.
Virtual Network (VNet) to podstawowa usługa sieciowa w Azure, która pozwala na tworzenie prywatnych sieci w chmurze i kontrolowanie komunikacji między zasobami w chmurze Azure. Integracja z AKS zapewnia elastyczną konfigurację sieciową i pełną kontrolę nad dostępem do usług uruchamianych w klastrze. Podłączanie klastra AKS do VNet zapewnia pełną izolację i kontrolę nad komunikacją między podami i usługami uruchamianymi w chmurze. Możemy ustawić reguły zapory, łączyć klastry z innymi zasobami w sieci (jak bazy danych) czy magazynami plików i kontrolować dostęp do klastra. Dzięki temu zyskujemy też pełną kontrolę na routingiem wraz z tworzeniem niestandardowych reguł oraz możliwość przypisywania adresów IP z prywatnego zakresu węzłom i obiektom kubernetesowym.
Zarządzanie klastrem: Azure CLI, Terraform, Azure Portal
Podobnie jak w przypadku pozostałych omawianych chmur, także i tutaj mamy możliwość zarządzania klastrem na kilka różnych sposobów. Konsola webowa daje nam właściwie pełne możliwości i nie ogranicza się jedynie do tworzenia klastrów czy zarządzania zasobami. Możemy za jej pomocą zrobić praktycznie wszystko i to w prosty oraz dosyć intuicyjny sposób.
Azure CLI to potężne narzędzie wiersza poleceń, które oprócz zarządzania zasobami chmury, pozwala na szybkie tworzenie, konfigurację i monitorowanie AKS bez konieczności korzystania z interfejsu graficznego. Zalety tego podejścia to przede wszystkim szybkość i elastyczność działania, możliwość tworzenia skryptów i automatyzacji oraz pełna kontrola nad klastrem z każdego właściwie systemu operacyjnego.
Jeżeli jednak szukamy sposobu na bardziej deklaratywne zarządzanie klastrem, z pomocą i w tym przypadku przychodzi Terraform. Użycie go w przypadku Azure nie różni się niczym od podejścia opisanego w przypadku dwóch pozostałych chmur i cechuje się powtarzalnością oraz deklaratywnością zarządzania, możliwością wersjonowania konfiguracji przy podejściu GitOps, a także łatwą integracją z procesami CI/CD.
Obsługa sieci i storage w AKS
W AKS dwa podstawowe modele sieci to Kubenet i Azure CNI. Pierwszy z nich jest modelem standardowym, w którym każdy węzeł otrzymuje adres IP z sieci VNET, ale pody używają własnej przestrzeni adresowej. To znaczy, że nie posiadają bezpośrednich adresów IP w Azure VNET. Co za tym idzie, ruch pomiędzy podami przechodzi przez translację NAT.
Azure CNI to z kolei zaawansowany model sieci, w którym każdy pod otrzymuje własny, routowalny wewnątrz sieci adres IP. Dzięki temu pody mogą się bezpośrednio komunikować z pozostałymi usługami chmury. Jest to model posiadający integrację z usługami Azure Load Balancer czy Application Gateway.
Na przechowywanie danych składają się, podobnie jak u pozostałych providerów, Azure Managed Disks (czyli klasyczny storage możliwy do użycia wewnątrz podów poprzez Persistent Volume Claim) oraz implementacja protokołu NFS. W tym przypadku nosi ona nazwę Azure Files i pozwala na współdzielone przechowywanie plików między podami. Nie możemy oczywiście zapomnieć również o Azure Blob Storage, czyli usłudze przechowywania obiektowego. W tym przypadku konieczne jest zastosowanie Blob CSI Driver, który umożliwia podpięcie object storage jako Persistent Volume.
Mechanizmy bezpieczeństwa i zarządzania sekretami (Azure Key Vault, Secrets Store CSI Driver)
Azure Kubernetes Service (AKS) oferuje kilka mechanizmów zapewniających bezpieczne zarządzanie sekretami, uwierzytelnianie i autoryzację. W tym kontekście kluczowe rozwiązania to Azure Key Vault oraz Secrets Store CSI Driver.
Azure Key Vault to centralne repozytorium sekretów oferowane przez chmurę. Umożliwia przechowywanie haseł, kluczy API, poświadczeń do baz danych, kluczy szyfrujących oraz certyfikatów TLS. Trudno mówić o zaletach tego rozwiązania, które nie byłyby wymienione wcześniej. Są to między innymi centralne zarządzanie dostępem do informacji niejawnych oraz uniknięcie przechowywania sekretów bezpośrednio w obiekcie Kubernetes Secrets. Przypomnijmy – nie są one szyfrowane, a ich bezpieczeństwo jest w gruncie rzeczy dosyć niskie.
Koszty i modele rozliczeń
Co jest bezpłatne w podejściu AKS? Przede wszystkim samo zarządzanie klastrem. Komponent Kubernetes Control Plane jest zarządzany przez Azure i opłaty za niego nie są pobierane. Otrzymujemy przede wszystkim automatyczne aktualizacje i patche K8s, monitorowanie i zabezpieczenia oraz API serwisu. Płatne jest natomiast wykorzystanie zasobów pod węzły obliczeniowe, pamięć dyskowa oraz częściowo sieć i wykorzystanie Load Balancerów czy serwisu Azure Application Gateway. To również monitoring i przechowywanie logów, gdzie opłata uzależniona jest od ilości przechowywanych danych.
Podsumowanie
Analizując usługi Kubernetes oferowane przez trzech głównych dostawców chmury publicznej – AWS (EKS), Google Cloud (GKE) i Azure (AKS) – możemy dojść do wniosku, że pomimo pewnych różnic w implementacji i integracji z innymi serwisami, ich fundamenty pozostają bardzo podobne. Każda z tych platform bazuje na tej samej technologii, oferując zarządzane klastry Kubernetes, mechanizmy autoskalowania, integrację z natywnymi usługami chmurowymi oraz wsparcie dla podejścia IaC i DevOps. O tym powiemy w kolejnym artykule na ten temat.
Główne różnice między EKS, GKE i AKS dotyczą integracji z ekosystemem konkretnego dostawcy chmurowego, podejścia do zarządzania siecią i przechowywania danych, a także sposobu obsługi modelu serverless. W praktyce jednak każda z tych chmur pozwala na efektywne wdrażanie i skalowanie aplikacji w Kubernetesie, oferując podobne mechanizmy zarządzania zasobami.
Dzięki standaryzacji technologii Kubernetes migracja między dostawcami jest stosunkowo łatwa, a organizacje mogą elastycznie dobierać usługi w zależności od swoich potrzeb biznesowych i technicznych. Ostateczny wybór zależy głównie od priorytetów danej firmy – czy jest to lepsza integracja z istniejącymi systemami, niższe koszty, czy preferowane narzędzia DevOps.
Bez względu na wybór dostawcy, Kubernetes w chmurze publicznej pozostaje solidnym i elastycznym narzędziem do zarządzania nowoczesnymi aplikacjami kontenerowymi i stanowi niesamowicie wygodną i potężną alternatywę dla klasycznego podejścia.
Przeczytaj: Kubernetes w chmurach publicznych cz. II. Usługi serverless w AWS, GCP i Azure
