W poprzednim artykule z tej serii omówiliśmy usługi Kubernetes oferowane przez trzech głównych dostawców chmury publicznej – Amazon Web Services (AWS), Google Cloud Platform (GCP) i Microsoft Azure – analizując ich architekturę, kluczowe funkcje, integrację z natywnymi usługami chmurowymi, mechanizmy bezpieczeństwa, modele rozliczeń oraz scenariusze zastosowania. Zupełnie innym tematem są kontenery działające w modelu serverless, czyli takim, w którym to dostawca chmury zarządza infrastrukturą, skalowaniem i zasobami, a użytkownik dostarcza jedynie kod aplikacji lub kontener.
Każdy ze wspomnianych dostawców chmury publicznej oferuje swoje rozwiązanie w ramach modelu serverless. Amazon dostarcza AWS Fargate, w przypadku GCP możemy wykorzystać Google Cloud Run, natomiast Microsoft zapewnia Azure Container Apps.
Zalety usług serverless
Do głównych zalet takiego rozwiązania należy przede wszystkim automatyczne skalowanie w górę i w dół, w tym tzw. zero-cost scaling, mechanizm. Pozwala on całkowicie wyłączyć zasoby aplikacji, gdy nie są używane. Dzięki temu nie generują one żadnych kosztów, co sprawia, że faktyczne koszty naliczane są wyłącznie za rzeczywiste zużycie zasobów. W odróżnieniu od Kubernetesa działającego w klasycznym podejściu nie mamy tutaj działających serwerów, za które płacimy bez względu na to, w jakim stopniu są wykorzystywane. Kolejną zaletą jest brak konieczności zarządzania serwerami, systemami operacyjnymi i konfiguracją sieci. Tym wszystkim zajmuje się bowiem provider. Termin serverless jest nieco mylący, gdyż sugeruje całkowity brak maszyn czy infrastruktury dyskowej i sieciowej. Tak oczywiście nie jest. Serwery jak najbardziej są, ale my, jako użytkownicy, jesteśmy całkowicie lub prawie całkowicie zwolnieni z zarządzania nimi. Nie musimy dbać o aktualizację, instalowanie poprawek, wykonywanie backupów czy dostępność wolnych zasobów. To wszystko robi za nas dostawca.
Wady usług serverless
Usługi typu serverless nie są pozbawione wad. Do najważniejszych paradoksalnie należy ograniczona kontrola nad infrastrukturą. Zdarzają się sytuacje, w których jest to dla nas duża przeszkoda. Niestety decydując się na to rozwiązanie, akceptujemy oferowane przez dostawcę chmury warunki. Rozwiązaniem może być połączenie ze sobą rozwiązań, w których z jednej strony mamy w pełni zarządzalnego Kubernetesa, a z drugiej podejście serverless, na którym będziemy uruchamiać określone aplikacje.
Problemem w rozwiązaniach serverless może być też czas rozruchu, czyli opóźnienie, które występuje, gdy usługa serverless musi uruchomić aplikację od zera, ponieważ nie ma aktywnej instancji. W przeciwieństwie do tradycyjnych systemów, gdzie aplikacja działa cały czas, w modelu serverless instancje mogą być „uśpione” w celu oszczędności zasobów i kosztów. Jeżeli instancja aplikacji nie jest aktywna, chmura musi ją uruchomić. Może to trwać od kilku milisekund do kilku sekund, co w niektórych przypadkach jest ograniczeniem wręcz dyskwalifikującym to podejście. Należy wspomnieć też o potrzebie dostosowania aplikacji do specyfiki środowiska serverless. W większości są one stworzone do uruchamiania aplikacji na żądanie, gdzie po zakończeniu przetwarzania jest ona usypiana bądź zatrzymywana. Nie każda aplikacja nadaje się do takiego działania, stąd głównym przeznaczeniem serwisów typu serverless są aplikacje działające w modelu event-driven.
Serverless a Kubernetes – jak się uzupełniają?
Kubernetes daje nam pełną kontrolę nad infrastrukturą. Umożliwia uruchamianie aplikacji w izolowanych środowiskach i działa świetnie zarówno w modelu on-premise, hybrydowym jak i multi-cloud. Dostawcy chmury publicznej dostarczają nam środowiska kompletne i z niewielkimi wyjątkami, takimi jak brak możliwości zarządzania węzłami typu Control Plane, w pełni konfigurowane. Podejście serverless, o czym już powiedzieliśmy, sprawdza się najlepiej w przypadku aplikacji uruchamianych na żądanie. Ponadto takich, które nie wymagają stałych zasobów lub mają bardzo zmienne obciążenie. Istnieją jednak pewne scenariusze, gdy obydwa rozwiązania mogą działać razem. Pamiętajmy, że w przypadku standardowego podejścia płacimy za zasoby. W związku z tym każda operacja skalowania (horyzontalnego bądź wertykalnego) wiąże się z ryzykiem braku zasobów. Może to prowadzić do spadku wydajności aplikacji lub wzrostu kosztów związanych z dodaniem nowych węzłów do klastra.
Często takie sytuacje są krótkotrwałe, gdyż polegają na uruchomieniu na przykład funkcji obsługujących logikę biznesową czy generowanie raportów. Stoimy wówczas w sytuacji, w której musimy zdecydować, czy zapewnić środowisku wystarczającą ilość zasobów, aby wszystkie żądania mogły być bez problemu wykonane – narażając się na dodatkowe koszty – czy też zaakceptować ewentualne braki wydajności i wydłużenie czasu wykonywania pewnych operacji. Z opresji może nas uratować właśnie podejście serverless, w którym pewne aplikacje uruchomimy właśnie tam bez potrzeby rezygnowania z Kubernetesa w podejściu standardowym. Sprawdza się ono również w obsłudze procesów przetwarzania danych wejściowych dla klasycznych aplikacji kontenerowych. Usługa serverless może być pomocna również w sytuacji, gdy klaster Kubernetes osiąga swoje limity, a dodatkowe obciążenie jest przekierowane tutaj. Wymaga to oczywiście dobrego zaplanowania i dostosowania aplikacji do takiego właśnie działania.
Modele uruchamiania kontenerów bez zarządzania infrastrukturą
Pojęcie serverless jest bardzo szerokie i dostawcy chmury publicznej prześcigają się w uruchamianiu kolejnych serwisów działających w tym modelu. Jest to zwyczajnie wygodne dla użytkownika, szybkie i bezpieczne. W przypadku kontenerów możemy wyróżnić trzy podstawowe, różniące się znacznie od siebie, modele ich uruchamiania.
Function-as-a-Service (FaaS)
Pierwszym z nich jest Function-as-a-Service (FaaS). Jest to model oparty na uruchamianiu funkcji w odpowiedzi na zdarzenia. W przypadku omawianych chmur są to AWS Lambda, Google Cloud Functions oraz Azure Functions. Model ten stanowi chyba najbardziej kompletne zobrazowanie podejścia pay-as-you-go, czyli takiego, w którym płacimy tylko za czas, w którym funkcja jest aktywna. Zwykle używa się go do krótkotrwałych zadań, które muszą zostać uruchomione w odpowiedzi na zdarzenie, takie jak HTTP request, zmiana w bazie danych czy pojawienie się komunikatu w kolejce. Należy się tu jednak krótkie wyjaśnienie, gdyż usługi w modelu FaaS uznawane są co prawda za usługi kontenerowe, jednak w nieco szerszym zakresie. Nie do końca odpowiada on klasycznemu modelowi i choć zasadniczo koncentrują się one na uruchamianiu funkcji w odpowiedzi na zdarzenia, są często implementowane na infrastrukturze kontenerowej.
Container-as-a-Service (CaaS)
Usługa CaaS, czyli Container-as-a-Service to model chmurowy, który umożliwia uruchamianie, zarządzanie i skalowanie aplikacji w kontenerach bez konieczności zarządzania infrastrukturą serwerową, wirtualnymi maszynami czy systemami operacyjnymi. Jest to usługa, która udostępnia środowisko do łatwego uruchamiania kontenerów, w tym zarządzanie ich cyklem życia, orkiestrację oraz zapewnienie odpowiednich zasobów. CaaS może działać na różnych poziomach zaawansowania. Od prostych usług, które oferują hosting kontenerów, po bardziej zaawansowane platformy umożliwiające orkiestrację kontenerów, takie jak Kubernetes. Dzięki CaaS użytkownicy mogą skupić się na tworzeniu i uruchamianiu aplikacji, a nie na zarządzaniu infrastrukturą.
O tym właśnie modelu wspominaliśmy w poprzednim artykule pisząc o takich usługach jak AWS Fargate, Google Cloud Run czy Azure Container Apps. Niewątpliwą zaletą takiego podejścia, poza oczywiście brakiem konieczności zarządzania infrastrukturą, jest szerokie wsparcie i kompatybilność z Kubernetesem. Dzięki temu mamy możliwość uruchamiania aplikacji kontenerowych bez konieczności ich dostosowywania do takiego modelu działania. Wszystkie platformy obsługują autoskalowanie oraz szeroką integrację z pozostałymi usługami chmurowymi. W rezultacie czyniąc z niego narzędzie potężne oraz odejmując nam od obowiązków większość czynności operacyjnych polegających na konfiguracji i utrzymaniu klastra.
Podejście to ma jednak także wady. Pierwszą z nich jest mniejsza kontrola nad infrastrukturą. W pewnych okolicznościach może to być problemem, zwłaszcza w przypadku specyficznych wymagań infrastrukturalnych. Musimy polegać na tym, co otrzymamy od dostawcy. Drugą wadą są niestety koszty, które zwłaszcza w przypadku aplikacji o stałym i dużym obciążeniu mogą być znaczne. Na pewno o wiele większe niż w przypadku tradycyjnego podejścia, które wykorzystuje własne serwery.
Serverless Kubernetes
Ostatnim modelem uruchamiania kontenerów w chmurze jest Serverless Kubernetes. Jest to model, którego przedstawicielami są GKE Autopilot (oparty na GKE), AWS EKS Fargate (dla którego podstawą jest EKS) oraz Azure AKS (który jest zarządzaną wersją Kubernetes w chmurze Microsoftu). W tym modelu nie musimy martwić się o zarządzanie węzłami czy zasobami obliczeniowymi. Pozwala to skupić się na aplikacjach i usługach, które są uruchamiane na klastrach Kubernetes. W praktyce oznacza to, że Kubernetes jest uruchamiany i zarządzany przez dostawcę chmurowego, a użytkownicy mogą korzystać z jego możliwości orkiestracji kontenerów, nie martwiąc się o infrastrukturę. Zasoby są dynamicznie przydzielane, skalowane, a cały cykl życia klastra Kubernetes – od uruchomienia węzłów po zarządzanie nimi – jest automatycznie obsługiwany przez dostawcę.
Do zalet możemy zaliczyć nieco większą optymalizację kosztów, gdyż płacimy tylko za faktycznie wykorzystywane zasoby. To sprawia, że model ten jest bardziej efektywny kosztowo, zwłaszcza w przypadku aplikacji o zmiennym obciążeniu. Natomiast główną zaletą jest prostota i łatwość wdrożenia, gdyż otrzymujemy środowisko praktycznie gotowe do pracy i prawie całkowicie skonfigurowane. Ułatwia to szybsze wdrażanie aplikacji i zwiększa produktywność. Również szybkie i dynamiczne skalowanie jest cechą, obok której nie sposób przejść obojętnie. Odchodzi nam w tym przypadku cała procedura planowania zasobów, co ma znaczenie na przykład w środowiskach deweloperskich czy testowych, gdzie obciążenie bardzo często jest zmienne i trudne do przewidzenia.
Wśród wad znajdziemy, podobnie jak w dwóch poprzednich modelach, mniejszą kontrolę nad infrastrukturą, ale także potencjalne problemy z wydajnością, które, w zależności od dostawcy chmurowego i sposobu zarządzania zasobami, mogą się pojawić. W niektórych przypadkach może wystąpić opóźnienie przy uruchamianiu nowych zasobów, co wpłynie na wydajność. Również i tutaj koszty mogą się zwiększyć. Choć Serverless Kubernetes jest atrakcyjny pod względem kosztów w przypadku zmiennego obciążenia, dla aplikacji o stałym obciążeniu może okazać się droższy niż tradycyjne rozwiązania oparte na dedykowanych węzłach.
Rancher w chmurach publicznych
Rancher to platforma open source rozwijana przez firmę SUSE, posiadająca także w pełni supportowaną wersję Rancher Prime. Umożliwia one nie tylko tworzenie, ale także zarządzanie wieloma klastrami Kubernetes, niezależnie od tego, czy są one uruchomione lokalnie, w chmurze prywatnej czy u publicznych dostawców chmurowych, takich jak AWS, GCP czy Azure. Poprzez Ranchera możemy łatwo zarządzać i monitorować swoje klastry, centralizując kontrolę nad infrastrukturą i aplikacjami.
Integracja z AWS, GCP i Azure
Rancher zapewnia pełną integrację z opisywanymi dostawcami chmurowymi, co pozwala na łatwe uruchamianie, zarządzanie i monitorowanie klastrów kubernetesowych w każdej z tych chmur.
W przypadku AWS Rancher automatycznie integruje się z EKS i pozwala na łatwe tworzenie, skalowanie i monitorowanie klastrów w tejże chmurze. Dzięki tej integracji mamy możliwość korzystania z zaawansowanych usług i funkcji oferowanych przez providera, takich jak IAM, w celu kontroli dostępu, tworzenia i zarządzania obiektową przestrzenią dyskową czy monitorowania klastrów z wykorzystaniem CloudWatch.
Rancher obsługuje również GKE, umożliwiając tworzenie i zarządzanie klastrami Kubernetes na platformie Google Cloud. Integracja z GKE pozwala na pełne wykorzystanie usług Google Cloud, takich jak BigQuery czy Google Cloud Storage, a także ułatwia zarządzanie zautomatyzowanym skalowaniem i wsparcie w zakresie zarządzania tożsamościami przez Google Identity.
Jeżeli chodzi o Azure, to integracja również jest bezproblemowa i pozwala nam na szybkie wdrażanie klastrów na platformie Microsoftu. Rancher współpracuje z takimi narzędziami jak Azure Active Directory do zarządzania dostępem czy Azure Monitor do monitorowania aplikacji i zasobów w AKS.
Dzięki możliwości integracji z dostawcami chmury publicznej Rancher staje się platformą uniwersalną, umożliwiając zarządzanie klastrami na wielu platformach z jednej, centralnej lokalizacji. Jest to szczególnie przydatne w środowiskach, które korzystają z podejścia wielochmurowego lub hybrydowego, eliminując potrzebę zarządzania klastrami za pomocą osobnych paneli w każdej z chmur.
Zarządzanie wieloma klastrami
Jak już powiedzieliśmy, jedną z kluczowych funkcji Ranchera jest możliwość zarządzania wieloma klastrami Kubernetes. Jest to szczególnie istotne w dużych organizacjach, które korzystają z różnych dostawców chmurowych lub które muszą zarządzać klastrami w różnych regionach. Rancher umożliwia zarządzanie klastrami Kubernetes na różnych chmurach z jednej konsoli, co pozwala zaoszczędzić czas i zasoby. Administracja odbywa się za pomocą jednego interfejsu użytkownika, a wszystkie one traktowane są tak, jakby były integralną częścią infrastruktury, dzięki czemu można łatwo monitorować stan klastrów czy aplikacji oraz wykrywać i rozwiązywać problemy na każdej z nich. Do podstawowych funkcji należą między innymi tworzenie, modyfikowanie i usuwanie klastrów w chmurze publicznej, skalowanie zasobów klastrów w zależności od potrzeb (np. zmniejszanie lub zwiększanie liczby węzłów w klastrze), automatyczne aktualizacje i zarządzanie wersjami Kubernetesa oraz monitorowanie wydajności zasobów jak CPU, pamięć czy pojemność dysków.
Bezpieczeństwo i zarządzanie dostępem
Rancher zapewnia też zaawansowane funkcje bezpieczeństwa, które są niezbędne w wielochmurowych środowiskach kubernetesowych, w których zarządzanie dostępem i kontrola tożsamości mają kluczowe znaczenie. To między innymi:
- integracja z systemami tożsamości (jak IAM czy Azure AD);
- wsparcie dla RBAC umożliwiającego przypisywanie ról i uprawnień użytkownikom i grupom w zależności od potrzeb;
- zarządzanie politykami bezpieczeństwa (w tym wsparcie dla systemów zarządzania sekretami);
- audyt i monitorowanie działań na klastrach dzięki integracji z takimi narzędziami jak Prometheus czy Grafana, a także Elasticsearch i Kibana. Pozwala to na dokładne śledzenie działań użytkowników i administratorów w środowisku Kubernetes.
OpenShift w chmurach publicznych
OpenShift oferuje nieco inne podejście niż Rancher. Będąc platformą klasy enterprise, rozwijaną przez firmę Red Hat, zapewnia rozszerzone funkcjonalności w porównaniu do standardowego Kubernetesa. To m.in.: wbudowane mechanizmy CI/CD, operatory czy lepsza integracja z systemami autoryzacji i zarządzania użytkownikami. OpenShift może działać zarówno w środowiskach on-premises, jak i w chmurach publicznych, gdzie jest dostępny w formie usług zarządzanych przez Red Hat oraz dostawców chmurowych.
OpenShift – kilka wariantów w środowisku chmurowym
OpenShift Dedicated to w pełni zarządzana usługa OpenShift hostowana przez Red Hat w chmurach publicznych AWS i Google Cloud. Oferuje pełne środowisko OpenShift jako dedykowany klaster, który jest odizolowany od innych klientów i utrzymywany przez Red Hat. Eliminuje to konieczność ręcznego zarządzania infrastrukturą Kubernetes.
ROSA, czyli Red Hat OpenShift Service on AWS, to z kolei zarządzana usługa OpenShift, która działa natywnie na platformie AWS i jest współzarządzana zarówno przez Red Hat (zapewniający wsparcie dla platformy OpenShift), jak i AWS (odpowiedzialny za infrastrukturę). Oznacza to, że mamy możliwość korzystania z pełnej mocy OpenShift, nie martwiąc się o utrzymanie klastra i infrastrukturę, ponieważ AWS i Red Hat wspólnie dbają o jego aktualizacje, bezpieczeństwo oraz dostępność. ROSA zapewnia pełną integrację z natywnymi usługami AWS, takimi jak IAM, S3, RDS, Route 53, CloudWatch czy ELB, co czyni go idealnym rozwiązaniem dla firm, które chcą korzystać z OpenShift bez konieczności ręcznej konfiguracji chmury.
Odpowiednikiem ROSA w chmurze Microsoftu jest z kolei ARO, czyli Azure Red Hat OpenShift. Także i tutaj mamy do dyspozycji produkt zarządzany zarówno przez providera, jak i przez firmę Red Hat. Podobnie jak ROSA, ARO zapewnia wszystkie funkcje OpenShift, ale działa natywnie na infrastrukturze Azure. Klient nie musi zarządzać klastrem ani aktualizacjami.
Zarządzanie OpenShift w chmurze
OpenShift dostarcza własny interfejs webowy (OpenShift Web Console), który pozwala administratorom na zarządzanie klastrami, aplikacjami i użytkownikami w sposób bardziej przystępny niż standardowy Kubernetes. Oprócz tego dostępne są narzędzia CLI, takie jak oc (OpenShift Client), które umożliwiają interakcję z klastrami OpenShift w sposób skryptowy i zautomatyzowany. OpenShift w chmurze pozwala na dynamiczne skalowanie klastrów i zasobów, w tym autoskalowanie workerów, podów oraz na automatyzację zarządzania aplikacjami poprzez obsługę operatorów. Dodatkowo, dzięki narzędziom takim jak Red Hat Advanced Cluster Management for Kubernetes (RHACM), OpenShift umożliwia centralne zarządzanie klastrami rozmieszczonymi w różnych środowiskach, np. w AWS, Azure i GCP jednocześnie. Pozwala także na skalowanie i wdrażanie nowych klastrów w wielu chmurach, monitorowanie i egzekwowanie polityk bezpieczeństwa we wszystkich klastrach czy optymalizację wykorzystania zasobów na różnych platformach.
Mechanizmy zarządzania sekretami w Kubernetesie w chmurze
W Kubernetesie sekrety służą do przechowywania poufnych danych, takich jak klucze API, hasła, certyfikaty TLS, tokeny dostępu czy dane konfiguracyjne aplikacji. Choć natywne Kubernetes Secrets są prostym sposobem na przechowywanie takich danych, nie zapewniają one domyślnie silnego szyfrowania ani zaawansowanych mechanizmów dostępu. W środowiskach chmurowych istnieją bardziej zaawansowane mechanizmy zarządzania sekretami, które integrują się z Kubernetesem, poprawiają bezpieczeństwo i umożliwiają dynamiczne odświeżanie tajnych danych.
Wady i ograniczenia natywnych Kubernetes Secrets
Choć sekrety są często używane w klastrach kubernetesowych, mają kilka istotnych ograniczeń. Należą do nich między innymi:
- brak domyślnego szyfrowania – sekrety są przechowywane jako base64, co nie jest formą szyfrowania, a jedynie prostym kodowaniem;
- brak zaawansowanego zarządzania dostępem – Kubernetes używa RBAC, jednak nie pozwala na pełną kontrolę nad sekretami na poziomie aplikacji czy użytkowników;
- brak funkcji dynamicznego odnawiania sekretów, przez co zmuszeni jesteśmy do ręcznej aktualizacji podów lub użycia mechanizmów obserwacji zmian;
- brak centralnego systemu audytu, przez co nie można łatwo śledzić, kto odczytał lub zmodyfikował sekret.
Wszystko to sprawia, że często poszukujemy zewnętrznych systemów umożliwiających zarządzanie sekretami. Dostawcy chmurowi dają nam do dyspozycji takie narzędzia jak AWS Secrets Manager, Google Secret Manager czy Azure Key Vault, zapewniające znacznie większy poziom bezpieczeństwa oraz oferujące funkcjonalności, których na próżno szukać w sekretach kubernetesowych.
AWS Secrets Manager
AWS Secrets Manager to usługa do zarządzania tajnymi danymi, oferująca funkcje automatycznej rotacji, audytu dostępu oraz integracji z innymi usługami AWS. Oferuje kilka różnych sposobów integracji z Amazon EKS. Pierwszym z nich jest External Secrets Operator, który pozwala na synchronizację sekretów z AWS Secrets Manager do Kubernetes Secrets. Config Provider to driver CSI, umożliwiający pobieranie sekretów bezpośrednio do kontenerów i montowanie ich jako pliki. Ostatnią metodą jest IRSA, czyli IAM Roles for Service Accounts, który daje aplikacjom dostęp do sekretów bez potrzeby używania statycznych kluczy API.
AWS Secrets Manager to oczywiście również bezpieczeństwo i kontrola dostępu – sekrety są szyfrowane przy użyciu AWS Key Management Service (KMS), a dostęp do nich jest ściśle kontrolowany przez AWS IAM. Narzędzie pozwala również na automatyczną rotację sekretów, czy też możliwość definiowania własnych skryptów do rotacji.
Do zalet tego rozwiązania należą przede wszystkim głęboka integracja z innymi usługami AWS oraz rozbudowane mechanizmy audytu, dzięki czemu mamy pełną kontrolę nad przechowywanymi informacjami. Natomiast do wad zaliczyć można fakt, że narzędzie skupia się głównie na ekosystemie AWS, co może utrudnić migrację danych do innych środowisk.
Google Secret Manager
Google Secret Manager to usługa GCP do zarządzania sekretami z wbudowanym mechanizmem szyfrowania i wersjonowania. Integracja z Google Kubernetes Engine możliwa jest poprzez wykorzystanie:
- Workload Identity, czyli mechanizmu pozwalającego aplikacjom GKE uzyskać dostęp do sekretów bez konieczności używania statycznych kluczy API;
- External Secrets Operator, dzięki któremu możliwa jest synchronizacja z Kubernetes Secrets oraz Config Connector, który pozwala na zarządzanie sekretami w GCP za pomocą Kubernetes Custom Resource Definitions.
Jeżeli chodzi o bezpieczeństwo i kontrolę dostępu, to mamy tu bardzo podobną sytuację jak w przypadku chmury AWS. Także i tu sekrety są szyfrowane, tym razem za pomocą Cloud Key Management Service, a dostęp do nich możemy ściśle kontrolować poprzez Google IAM. Jednak narzędzie to posiada jedną ciekawą funkcję, którą jest wersjonowanie sekretów. Dzięki temu dostajemy możliwość łatwej kontroli dokonywanych zmian. Google Secret Manager obsługuje automatyczną rotację sekretów, ale wymaga to konfiguracji z użyciem Cloud Functions lub Cloud Scheduler. W przeciwieństwie do AWS Secrets Manager, gdzie rotacja może działać natywnie dla niektórych usług, tutaj użytkownik musi określić sposób odświeżania sekretów.
Do zalet Google Secret Manager możemy zaliczyć przede wszystkim wspomnianą możliwość wersjonowania sekretów. Natomiast wady to przede wszystkim brak natywnej automatycznej rotacji oraz fakt, że aby móc go używać poza ekosystemem Google Cloud, wymagana jest dodatkowa konfiguracja i uwierzytelnienie w chmurze, a także dostęp przez API.
Azure Key Vault
Ostatnią omawianą usługą jest Azure Key Vault. Jest to usługa Microsoftu do bezpiecznego przechowywania sekretów, certyfikatów i kluczy kryptograficznych. Integracja z Azure Kubernetes Service odbywa się poprzez Azure Key Vault Provider for Secrets Store CSI Driver. Dzięki niemu możliwe jest montowanie sekretów bezpośrednio do podów w Kubernetesie. Managed Identity for AKS, który umożliwia dostęp do przechowywanych sekretów bez statycznych poświadczeń oraz przy pomocy External Secrets Operator, z pomocą którego możliwa jest synchronizacja sekretów między Key Vault a Kubernetes Secrets.
W kwestii bezpieczeństwa Azure Key Vault używa Azure Active Directory do kontroli dostępu. Natomiast same sekrety szyfrowane są przy użyciu Azure Key Management Service (Azure KMS). Standardowo daje też możliwość monitorowania dostępu do sekretów poprzez Azure Monitor i Azure Security Center, zapewniając pełną kontrolę.
Do zalet tego rozwiązania możemy zaliczyć wysoki poziom integracji z Azure AKS i Azure AD, wbudowaną obsługę certyfikatów i kluczy kryptograficznych oraz możliwość automatycznej rotacji sekretów. Wadami natomiast są – nieco bardziej niż u pozostałych providerów – konfiguracja, zwłaszcza dla początkujących użytkowników oraz to, że do skutecznego działania wymaga użycia Azure Active Directory.
Praktyczne aspekty wdrażania Kubernetes w chmurze
Natywne mechanizmy automatyzacji infrastruktury
Wdrażając Kubernetes — zarówno w środowisku chmurowym, korzystając z gotowych rozwiązań dostarczanych przez providerów, jak i w podejściu on-premises — nie możemy zapominać o automatyzacji procesów. Automatyzacja obejmuje szeroki zakres działań: od definiowania infrastruktury, poprzez podejście Infrastructure as Code (IaC), konfigurację i aktualizację klastra, aż po wdrażanie i utrzymanie aplikacji. Każdy dostawca chmury oferuje zestaw narzędzi, które można wykorzystać, decydując się na jego usługi. Wadą takiego podejścia jest jednak zazwyczaj ścisła integracja z konkretną platformą, co utrudnia przenośność konfiguracji na inne środowiska.
Istnieje wiele uniwersalnych narzędzi, które pozwalają uniezależnić się od konkretnego dostawcy, jednak nie są one tak głęboko zintegrowane z daną chmurą, jak rozwiązania natywne. Jeżeli przenośność konfiguracji nie jest kluczowym wymogiem, korzystanie z narzędzi dostawców chmurowych może znacząco uprościć zarządzanie infrastrukturą.
Infrastructure as Code to podejście polegające na automatyzacji zarządzania infrastrukturą jako kod, które pozwala na tworzenie, zarządzanie i aktualizację zasobów w sposób deklaratywny.
AWS
AWS oferuje CloudFormation – narzędzie do zarządzania zasobami, takimi jak maszyny wirtualne, bazy danych, sieci, EKS i inne. CloudFormation opiera się na szablonach YAML lub JSON, które umożliwiają deklaratywne definiowanie infrastruktury. Zasoby są organizowane w stosy, co pozwala na ich jednoczesne tworzenie, modyfikowanie i usuwanie. CloudFormation obsługuje zależności między zasobami, ułatwiając zarządzanie ich cyklem życia. Jednak w bardziej skomplikowanych przypadkach wymagane może być ich jawne definiowanie przy użyciu DependsOn lub warunków logicznych.
Jednym z wyróżników tego narzędzia jest CloudFormation Designer, czyli graficzny interfejs umożliwiający wizualizację i edycję szablonów. Do głównych zalet można zaliczyć pełną integrację z ekosystemem AWS oraz obsługę najnowszych usług tej chmury. Wadą natomiast jest ograniczenie wyłącznie do AWS oraz stosunkowo wysoka złożoność szablonów – zwłaszcza dla skomplikowanych środowisk.
Google Cloud
Google Cloud oferuje Deployment Manager, czyli narzędzie do zarządzania infrastrukturą w GCP. Pozwala ono na definiowanie zasobów za pomocą deklaratywnych plików YAML oraz szablonów Jinja, które zwiększają elastyczność konfiguracji. Deployment Manager grupuje zasoby w Deploymenty, co pozwala na ich wspólne zarządzanie i aktualizację.
Do zalet tego rozwiązania należy jego prostsza konfiguracja w porównaniu do AWS CloudFormation oraz wsparcie dla szablonów Jinja, które umożliwiają dynamiczne generowanie konfiguracji. Wadą jest natomiast mniejsza elastyczność w porównaniu do narzędzi uniwersalnych, takich jak Terraform, co może stanowić wyzwanie w środowiskach multi-cloud.
Microsoft
Microsoft oferuje Azure Resource Manager (ARM), który umożliwia zarządzanie zasobami w Microsoft Azure. Konfiguracje można definiować przy użyciu szablonów JSON lub bardziej czytelnego języka Bicep, który upraszcza składnię ARM Templates.
Podobnie jak CloudFormation i Deployment Manager, ARM pozwala na zarządzanie grupami zasobów, umożliwiając traktowanie powiązanych komponentów jako jedną całość. Zaletą jest pełna integracja z ekosystemem Azure oraz uproszczona składnia Bicep. Wadą natomiast jest stosunkowo sztywna struktura ARM Templates, co może utrudniać ich stosowanie w bardziej złożonych środowiskach. Ponadto, choć Bicep jest prostszy, nie jest jeszcze tak szeroko wspierany, jak tradycyjne szablony JSON.
Procesy CI/CD w chmurach publicznych
Podobnie jak w przypadku zarządzania infrastrukturą, każdy dostawca chmury publicznej dostarcza natywne narzędzia, które w mniej lub bardziej przyjazny sposób pozwalają na automatyzację zadań związanych z wdrażaniem i aktualizacją aplikacji kontenerowych poprzez zastosowanie metodologii CI/CD.
CodePipeline
AWS dostarcza nam narzędzie o nazwie CodePipeline, które pozwala na stworzenie procesu automatyzacji, począwszy od zarządzania kodem, aż do planowania i realizacji wdrożeń na produkcji, a także na integrację z takimi usługami jak CodeCommit, CodeBuild, Elastic Beanstalk czy ECS. Pomimo tego, iż nie jest w pełni autonomicznym narzędziem i w niektórych przypadkach nie zastąpi całkowicie narzędzi zewnętrznych, integruje się również z usługą AWS CodeBuild. Umożliwia ona kompilowanie kodu, testowanie go i przygotowanie go do wdrożenia bez konieczności posiadania własnego narzędzia służącego do budowania i kompilacji. Jest to podejściem mającym zarówno wady, jak i zalety, gdyż podobnie jak w przypadku omawianego wcześniej procesu IaC, jest przeznaczone stricte dla ekosystemu AWS. Może to powodować problemy w przypadku konieczności migracji do innych chmur czy środowisk. CodePipeline pomaga automatyzować procesy CI/CD, wspierając różne jego etapy, takie jak kompilacja, testowanie, wdrażanie, integracja z repozytoriami Git (np. GitHub, Bitbucket) czy AWS CodeCommit.
Kluczowe cechy tego narzędzia to przede wszystkim ścisła integracja z innymi usługami oferowanymi przez AWS oraz pełna automatyzacja procesów CI/CD na każdym praktycznie etapie. To również wydajność i skalowalność, gdyż mamy tutaj możliwość chociażby zrównoleglenia działań. Zalety AWS są dosyć oczywiste i pokrywają się z omawianymi cechami. Jedną z wad, poza tym, iż jest to narzędzie skierowane głównie do działania w chmurze AWS, jest nieco większy poziom skomplikowania w porównaniu z zewnętrznymi narzędziami – zwłaszcza w dużych wdrożeniach.
Google Cloud Build i Google Cloud Deploy
Google Cloud Build i Google Cloud Deploy to narzędzia oferowane przez operatora chmury GCP. Umożliwiają zarówno automatyczne kompilowanie, testowanie i wdrażanie aplikacji w tej chmurze, jak i automatyzację procesów wdrożeniowych dla różnych środowisk. Do kluczowych cech tych rozwiązań zaliczyć możemy zwłaszcza elastyczność w użyciu języków, takich jak Java, Node.js, Python, Go oraz pełne wsparcie środowiska Docker, jak również natywne wsparcie dla Kubernetesa. Jedną z cech wyróżniających to narzędzie są też predefiniowane skrypty w języku YAML, służące do definiowania procesów CI/CD. Pozwala to na znaczne przyspieszenie prac związanych z automatyzacją bez potrzeby tworzenia specjalnych konfiguracji. Zalety to zdecydowanie głęboka integracja z ekosystemem GCP oraz pełne wsparcie dla konteneryzacji. Natomiast do wad tego podejścia możemy zaliczyć to, iż narzędzie jest jednak nieco trudniejsze niż narzędzia zewnętrzne, takie jak Jenkins.
Azure DevOps i GitHub Actions
Microsoft dostarcza narzędzia o nazwach Azure DevOps i GitHub Actions, które poza pełnym zestawem funkcji związanych z procesami CI/CD, umożliwiają także pełną integrację z repozytoriami GIT. Azure Pipelines obsługuje wiele języków i platform, zapewniając CI/CD zarówno dla aplikacji kontenerowych, jak i aplikacji opartych na maszynach wirtualnych. GitHub Actions jest naturalnie zintegrowany z repozytoriami GitHub, ale można go także używać do zarządzania procesami CI/CD dla innych repozytoriów. Wymaga to jednak dodatkowej konfiguracji. Zaletą tego rozwiązania jest to, iż są to de facto dwa różne narzędzia, które oferują elastyczność w zależności od wymagań projektu. Wady to przede wszystkim to, iż GItHub Actions ukierunkowane jest na projekty oparte na GitHubie. Nie jest więc idealne w przypadku innych repozytoriów. Ponadto Azure DevOps może wymagać nieco nauki i dostosowania zwłaszcza w skomplikowanych projektach.
Podsumowanie i przyszłość Kubernetes w chmurach publicznych
Trendy i prognozy na przyszłość
Kubernetes w chmurach publicznych to obecnie standard w zarządzaniu kontenerami, a jego rozwój wskazuje na kilka kluczowych trendów, które będą kształtować przyszłość tej technologii.
Serverless Kubernetes
Rosnąca popularność usług, takich jak AWS Fargate, GKE Autopilot czy Azure Container Apps, wskazuje na dążenie do uproszczenia zarządzania infrastrukturą. Organizacje coraz częściej wybierają model, w którym nie muszą zarządzać węzłami roboczymi, a klaster automatycznie skaluje się w zależności od potrzeb aplikacji.
AI-driven scaling
Wykorzystanie algorytmów sztucznej inteligencji do optymalizacji zasobów Kubernetesa staje się coraz bardziej popularne. Technologie oparte na AI pozwalają przewidywać obciążenie klastra i automatycznie dostosowywać liczbę węzłów oraz rozmieszczenie aplikacji, minimalizując koszty i poprawiając wydajność.
Lepsza integracja z AI/ML
Chmury publiczne coraz ściślej integrują Kubernetes z narzędziami do uczenia maszynowego, takimi jak Google Vertex AI, AWS SageMaker czy Azure Machine Learning. Wdrożenia AI/ML w kontenerach Kubernetesa pozwalają na dynamiczne skalowanie zasobów w zależności od zapotrzebowania na moc obliczeniową.
Rozwój podejścia GitOps
Zarządzanie klastrami Kubernetes poprzez GitOps (np. ArgoCD, Flux) staje się standardem. Organizacje wdrażają ten model, aby poprawić powtarzalność, automatyzację oraz audyt zmian w konfiguracjach.
Większy nacisk na bezpieczeństwo
Rosnące zagrożenia cybernetyczne powodują, że dostawcy chmur publicznych coraz bardziej inwestują w narzędzia zapewniające bezpieczeństwo klastrów Kubernetes, takie jak skanowanie obrazów kontenerów (np. AWS Inspector, Google Binary Authorization) czy mechanizmy zarządzania sekretami (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager).
Podsumowanie kluczowych wniosków
Elastyczność i skalowalność
Kubernetes w chmurach publicznych oferuje nieograniczone możliwości skalowania, pozwalając firmom szybko dostosowywać zasoby do zmieniającego się obciążenia aplikacji.
Integracja z ekosystemem chmurowym
Każdy z dostawców (AWS, GCP, Azure) zapewnia ścisłą integrację z natywnymi usługami chmurowymi, co upraszcza zarządzanie i zabezpieczanie aplikacji.
Optymalizacja kosztów
Chociaż chmury publiczne umożliwiają lepsze zarządzanie zasobami, to niewłaściwa konfiguracja może prowadzić do niepotrzebnych wydatków. Wykorzystanie funkcji autoskalowania oraz instancji typu spot pozwala optymalizować koszty.
Podejście wielochmurowe i hybrydowe
Narzędzia, takie jak Rancher czy Anthos, pozwalają organizacjom zarządzać klastrami Kubernetes w różnych chmurach. Daje to większą elastyczność i uniezależnia od pojedynczego dostawcy.
Automatyzacja i DevOps
Kubernetes naturalnie wspiera metodyki DevOps i GitOps, umożliwiając pełną automatyzację zarządzania infrastrukturą oraz wdrożeń aplikacji.
Podsumowując, Kubernetes w chmurach publicznych nieustannie ewoluuje, oferując nowe możliwości w zakresie automatyzacji, elastyczności oraz integracji z nowoczesnymi technologiami. Wybór konkretnej platformy zależy od indywidualnych potrzeb organizacji. Jednak niezależnie od dostawcy Kubernetes pozostaje fundamentem współczesnych aplikacji chmurowych.
