Kubernetes zarządzany czy własny? EKS, AKS i GKE w praktyce

Po co w ogóle Kubernetes i gdzie zaczyna się dylemat „zarządzany vs własny”

Decyzja „zarządzany Kubernetes czy własny klaster” pojawia się dokładnie w tym momencie, gdy proste uruchamianie kontenerów na jednym serwerze przestaje wystarczać. Pojawiają się wymagania skalowania, wysokiej dostępności, izolacji środowisk, a do tego dochodzą release’y kilka razy dziennie. Wtedy kontenery na pojedynczej maszynie zaczynają być wąskim gardłem – zarówno wydajnościowym, jak i operacyjnym.

Kubernetes rozwiązuje kilka kluczowych problemów: standaryzuje sposób deploymentu aplikacji, automatyzuje restartowanie i skalowanie podów, zarządza rozkładem obciążeń po węzłach oraz ułatwia abstrakcję nad infrastrukturą. Z punktu widzenia zespołu deweloperskiego przestaje mieć znaczenie, na którym serwerze dokładnie działa aplikacja – liczy się deklaratywna konfiguracja (YAML), a nie ręczna konfiguracja maszyn.

Problem pojawia się, gdy trzeba odpowiedzieć na pytanie: kto zarządza całą tą „maszynerią” pod spodem. Kubernetes to nie tylko kubectl apply, ale cały stos: komponenty control plane, sieć, storage, certyfikaty, backup konfiguracji, monitoring klastra, aktualizacje, łatki bezpieczeństwa. I tu zaczyna się dylemat: czy zlecić to dostawcy chmury (zarządzany cluster Kubernetes EKS, AKS, GKE), czy budować i utrzymywać własny klaster Kubernetes bare metal lub na IaaS.

Granica między „docker-compose na jednym serwerze” a „sensowny Kubernetes” pojawia się najczęściej wtedy, gdy:

• masz więcej niż 3–4 usługi zależne od siebie i wiele środowisk (dev, test, stage, prod),
• wymagasz automatycznego skalowania zależnie od obciążenia (HPA, VPA),
• potrzebujesz wysokiej dostępności i failoveru między węzłami,
• zespół deweloperski rośnie i potrzebuje jednego standardowego sposobu deploymentu,
• chcesz w perspektywie multi-cloud z Kubernetes lub migracji między dostawcami.

W tym miejscu pojawia się zasadnicze pytanie: czy samodzielnie stawiać i utrzymywać control plane (API server, scheduler, controller-manager, etcd) oraz całą infrastrukturę sieciową i storage, czy przenieść ten ciężar na dostawcę zarządzanego Kubernetes jak Amazon EKS, Azure AKS czy Google GKE. Wybór rzutuje później na koszty, bezpieczeństwo klastra Kubernetes, elastyczność konfiguracji i zależność od konkretnego vendora.

Motywacje są zwykle trzy: maksymalna szybkość startu (favor EKS/AKS/GKE), pełna kontrola i customizacja (favor własny klaster Kubernetes), oraz wymagania compliance lub on-prem (często wymuszają własną infrastrukturę). W praktyce rzadko jest to czarno-biała decyzja – część organizacji zaczyna na zarządzanym Kubernetes w chmurze, a dopiero później rozważa własne klastry np. pod szczególnie wrażliwe systemy.

Architektura Kubernetes – co faktycznie jest „zarządzane”, a co zawsze zostaje po twojej stronie

Control plane vs worker nodes – podział odpowiedzialności

Kubernetes architektonicznie dzieli się na dwie główne części: control plane i worker nodes. Control plane to mózg klastra: API server (przyjmuje i autoryzuje żądania), scheduler (decyduje, gdzie uruchomić pody), controller-manager (pilnuje, żeby stan rzeczywisty zgadzał się z deklarowanym) oraz etcd (rozproszona baza kluczy-wartości przechowująca stan klastra). Worker nodes to z kolei maszyny, na których faktycznie uruchamiane są pody.

W zarządzanych usługach Kubernetes (EKS, AKS, GKE) vendor odpowiada za:

• instalację i utrzymanie komponentów control plane,
• skalowanie i HA control plane (multi-zone, backup stanu etcd),
• aktualizacje wersji Kubernetes (zwykle z oknem wsparcia kilku wersji),
• integrację z natywnym IAM i elementami sieci w chmurze.

Własny klaster Kubernetes oznacza, że za te same obszary odpowiadasz ty lub twój zespół – niezależnie, czy działasz na bare metal, czy na ogólnych VM u dostawcy IaaS. Każdy błąd w konfiguracji etcd, braku quorum, braku backupów czy błędnego certyfikatu API servera staje się twoim bezpośrednim problemem produkcyjnym.

Co przejmuje EKS, AKS i GKE, a co i tak musisz zrobić sam

Zarządzany Kubernetes EKS, AKS czy GKE nie rozwiązuje wszystkich problemów związanych z infrastrukturą – przejmuje tylko część stosu. W największym skrócie:

• Control plane – w pełni zarządzany, z SLA od dostawcy (zwykle powyżej 99,95%),
• Worker nodes – po twojej stronie (z opcją managed node groups lub trybu Autopilot/Fargate),
• CNI (Container Network Interface) – często vendor dostarcza domyślne rozwiązanie, ale konfiguracja i zrozumienie jego ograniczeń jest po twojej stronie,
• Storage (CSI) – integrowane z dyskami/plikami w chmurze, ale to ty decydujesz o klasach storage, backupach, snapshotach.

Po twojej stronie zawsze zostają:

• aplikacje i ich manifesty (Deployment, StatefulSet, Service, Ingress, ConfigMap, Secret),
• pipeline CI/CD i sposób wgrywania zmian do klastra,
• obserwowalność: monitoring metryk (Prometheus/Grafana lub Cloud-native), logowanie, tracing,
• polityki bezpieczeństwa na poziomie namespace’ów, RBAC, NetworkPolicy, PodSecurity,
• projektowanie topologii klastrów: ile klastrów, w których regionach, jak łączone z innymi systemami,
• dr i backup danych biznesowych (bazy danych, wolumeny persistent volume, konfiguracje).

To oznacza, że nawet w najbardziej „zarządzanym” wariancie typu GKE Autopilot infrastruktura aplikacyjna wymaga takiego samego poziomu dyscypliny: kontrola konfiguracji, release management, chaos w namespace’ach – to wszystko wciąż jest twoją odpowiedzialnością.

Konsekwencje SLA, awarii control plane i odtwarzania klastra

Własny klaster Kubernetes wymaga świadomego podejścia do SLA. Jeśli API server pada, nie możesz wykonywać kubectl, rolling deployów, skalowania. Jeśli etcd traci dane, tracisz konfigurację całego klastra. To oznacza konieczność:

• projektowania HA control plane (minimum 3 węzły etcd, najlepiej w różnych AZ/serwerowniach),
• regularnych testów backupu i odtworzenia etcd,
• kontroli certyfikatów TLS i ich rotacji,
• planów DR na wypadek utraty całego DC lub części infrastruktury.

Przy EKS/AKS/GKE dostajesz SLA na control plane oraz mechanizmy odtwarzania po stronie dostawcy. Twoje SLA produkcyjne wciąż zależy jednak od poprawnej konfiguracji węzłów, autoscalingu, sieci oraz aplikacji. Zarządzany control plane nie naprawi złego HPA, źle dobranych limitów zasobów czy braku replik w StatefulSetach.

W praktyce wybierając między zarządzanym a własnym klastrem decydujesz, gdzie chcesz mieć „ostry” edge odpowiedzialności: czy na granicy API servera (zarządzany Kubernetes), czy na poziomie fizycznej infrastruktury (własny Klaster Kubernetes bare metal). To później bezpośrednio przekłada się na koszt utrzymania klastra Kubernetes oraz konieczne kompetencje zespołu.

Własny klaster Kubernetes – kiedy ma sens i z jakich klocków się składa

Scenariusze, w których własny Kubernetes wygrywa

Budowa własnego klastra ma sens tam, gdzie zarządzany Kubernetes w chmurze nie spełnia wymagań biznesowych lub technicznych. Typowe scenariusze:

• Środowiska o ostrym compliance/on-prem – banki, administracja publiczna, organizacje z wymogiem pełnej kontroli nad infrastrukturą i danymi; chmura publiczna bywa niemożliwa lub mocno ograniczona.
• Specyficzny sprzęt – niestandardowe GPU, akceleratory, dedykowane macierze storage, lokalne sieci o bardzo niskich opóźnieniach, które trudno odwzorować u cloud providera.
• Edge i rozproszone lokalizacje – klastry na urządzeniach brzegowych, w małych serwerowniach bliżej użytkownika (np. sieć sklepów, fabryki, urządzenia IoT).
• Pełna kontrola nad stosami sieci/storage – np. zaawansowane overlay network, własne rozwiązania storage, specyficzne wymagania co do routingu, multicastu itp.
• Polityka kosztowa – w niektórych przypadkach własne datacenter z dobrze wykorzystanymi serwerami może być tańsze przy bardzo dużej skali i stałym obciążeniu.

Decydując się na własny klaster Kubernetes bare metal lub na VM u dostawcy IaaS, zyskujesz pełną swobodę doboru komponentów: CNI, CSI, Ingress, mechanizmów security. Jednocześnie przejmujesz pełną odpowiedzialność za każdą warstwę stosu. Przy braku doświadczonego zespołu SRE/DevOps może się to skończyć ogromnym długiem operacyjnym.

Narzędzia do budowy własnego klastra: kubeadm, Kubespray, Rancher, OpenShift

Własny Kubernetes nie oznacza instalowania wszystkiego „ręcznie z binarek”. Istnieje kilka głównych podejść:

• kubeadm – oficjalne narzędzie z projektu Kubernetes do bootstrapu klastra. Daje sporą elastyczność, ale wymaga sporej wiedzy o certyfikatach, sieci i składaniu kontrol plane.
• Kubespray – playbooki Ansible do automatycznego stawiania klastra na różnych platformach (bare metal, OpenStack, cloud IaaS). Dobre dla zespołów, które lubią kodowalną infrastrukturę i chcą uniknąć vendor lock-in.
• Rancher – platforma do zarządzania wieloma klastrami, również własnymi. Może bootstrapować klastry i pomagać w ich aktualizacjach, monitoringu, RBAC. Przydatny, gdy chcesz mieć UI i centralne zarządzanie.
• OpenShift – rozszerzona dystrybucja od Red Hata, z wieloma dodatkami: wbudowany rejestr, CI/CD, security hardening. Cięższe rozwiązanie, ale często wybierane w dużych środowiskach enterprise/on-prem.

Na IaaS (np. czyste VM w AWS, Azure, GCP, OVH, Hetzner) dochodzi jeszcze warstwa automatyzacji infrastruktury: Terraform, Ansible, Packer. W takim modelu vendor dostarcza tylko surowe serwery, a cała logika Kubernetes jest budowana i utrzymywana samodzielnie.

Projektowanie sieci, storage, ingress, certyfikatów i backupu etcd

Własny klaster Kubernetes oznacza konieczność samodzielnego złożenia kilku krytycznych klocków:

• CNI (sieć) – wybór między Calico, Flannel, Cilium, Weave Net i innymi. Każda z opcji ma swoje wymagania co do routingu, MTU, obsługi NetworkPolicy i integracji z infrastrukturą L2/L3.
• CSI (storage) – lokalne dyski, sieciowe systemy plików (NFS, Ceph, GlusterFS), macierze SAN, komercyjne rozwiązania SDS. Trzeba zadbać o performance, HA, snapshoty i backupy.
• Ingress – NGINX Ingress Controller, Traefik, HAProxy, Envoy – plus projektowanie load balancerów na brzegu (hardware, LVS, MetalLB, Keepalived, VRRP).
• Certyfikaty – PKI dla API servera, kubeletów, komponentów między sobą oraz certyfikaty TLS dla aplikacji (np. Let’s Encrypt przez cert-managera).
• Backup etcd – regularne snapshoty, testy odtwarzania, plan awaryjny na utratę części węzłów control plane.

Dla przykładu: mała firma z własnym DC i zespołem ops decydując się na własny klaster Kubernetes musi na start odpowiedzieć na pytania:

• czy control plane będzie miał trzy węzły etcd w dwóch szafach serwerowych,
• jak będzie wyglądać routing między siecią serwerów a siecią użytkowników,
• jakie rozwiązanie storage zapewni jednocześnie wydajność i HA (np. Ceph z trzema replikami),
• jak wygląda proces aktualizacji klastra i testowania nowej wersji Kubernetes na środowisku pre-prod,
• jak monitorować cluster health i jak szybko realnie zespół jest w stanie reagować na awarie w nocy.

Bez tego projekt szybko przeradza się w serię jednorazowych „gaszeń pożarów”. Własny Kubernetes to de facto własny mini-cloud – z wszystkimi konsekwencjami operacyjnymi.

Zarządzane Kubernetes w praktyce – EKS, AKS i GKE w skrócie

Wspólne cechy zarządzanych usług Kubernetes

Zarządzane klastry Kubernetes w chmurze (EKS na AWS, AKS na Azure, GKE na Google Cloud) mają kilka wspólnych mianowników:

• Zarządzany control plane – instalacja, aktualizacje, backupy etcd, HA i dostępność API servera zapewnia vendor.
• Integracja z IAM – autoryzacja użytkowników i serwisów z wykorzystaniem istniejących tożsamości (IAM, Azure AD, Google IAM).
• Automatyczne aktualizacje – możliwość podniesienia wersji klastra z panelu/CLI, często z obsługą planowanego okna serwisowego.
• Integracje „cloud-native” – load balancery, storage classes, logowanie do usług typu CloudWatch, Azure Monitor, Cloud Logging.

Różnice w modelu operacyjnym zarządzanych klastrów

Mimo wspólnych fundamentów EKS, AKS i GKE różnią się dość istotnie na poziomie codziennej eksploatacji. Te różnice są mniej widoczne w małych środowiskach, ale przy większej skali lub wymaganiach compliance potrafią zaważyć na wyborze.

• Zakres odpowiedzialności za worker nodes – gdzie kończy się odpowiedzialność providera, a zaczyna twoja (patchowanie systemu, kernel, agentów, sterowników GPU).
• Sposób aktualizacji – jak wygląda proces upgrade’u control plane i node pooli, czy można mieć „skok” o kilka wersji, jakie są ograniczenia czasowe.
• Integracja z resztą chmury – jak naturalnie klaster „współgra” z siecią VPC/VNet, usługami security, monitoringiem, IAM.
• Obsługa multi-tenancy – czy usługa wspiera scenariusze wielu zespołów/projektów w jednym klastrze, jakie są natywne mechanizmy izolacji.

Przy jednym klastrze demo różnice te są kosmetyczne. Przy 20+ klastrach w wielu regionach wpływają na to, ilu ludzi potrzebujesz w zespole platformowym i jakie narzędzia automatyzacji trzeba dobudować.

EKS – specyfika zarządzanego Kubernetes na AWS

Model architektoniczny EKS i integracja z AWS

EKS stosunkowo konsekwentnie trzyma się „czystego” Kubernetes. Control plane jest zarządzany w całości przez AWS, uruchamiany w ukrytym VPC należącym do providera, a z twoim VPC łączy się prywatnymi linkami. Worker nodes znajdują się już w twoim koncie i twoim VPC – to ważny podział granicy odpowiedzialności.

Integracja z resztą usług AWS idzie głównie przez adnotacje i CRD (Custom Resource Definition):

• LoadBalancer – klasyczny Service typu LoadBalancer tworzy AWS Classic/Network Load Balancer zdefiniowany przez adnotacje (np. wybór NLB, cross-zone, TCP/UDP).
• Storage – EBS jako domyślny backend dla PersistentVolume (dysk blokowy per węzeł), EFS dla współdzielonych wolumenów (np. pod CMS-y lub systemy plików).
• IAM – integracja z IAM Roles for Service Accounts (IRSA), czyli mapowanie kont serwisowych na role IAM bez używania statycznych kluczy.

Tip: przy większej liczbie mikroserwisów IRSA jest praktycznie obowiązkowe – trzymanie wszystkich uprawnień na roli EC2 narusza zasadę minimalnych uprawnień i utrudnia audyt.

Zarządzanie worker nodes: managed node groups i Fargate

EKS nie wymusza jednego modelu workerów. Do wyboru są trzy główne ścieżki:

• Self-managed nodes – samodzielnie tworzysz ASG (Auto Scaling Group) z AMI przygotowanym pod EKS (np. eksctl lub własny Packer). Daje maksymalną kontrolę (kernel, agent, layout dysków), ale wymaga samodzielnego patchowania i pilnowania cyklu życia node’ów.
• Managed node groups – AWS zarządza cyklem życia node’ów w ASG, ułatwia rolling update’y AMI, integruje upgrade z wersją Kubernetes. To rozsądny kompromis dla większości teamów.
• Fargate – wariant „serverless nodes”: nie widzisz maszyn w klastrze, planujesz na poziomie podów, płacisz za CPU/RAM. Przydatne dla małych serwisów, batchy, cronów lub gdy nie chcesz w ogóle zarządzać węzłami.

W praktyce często łączy się managed node groups dla głównych workloadów i Fargate dla komponentów systemowych o zmiennym obciążeniu (np. joby, niektóre serwisy pomocnicze). Sam Fargate jako jedyny typ node’ów bywa drogi przy obciążeniach 24/7.

Bezpieczeństwo w EKS: IAM, security groups, sieć

EKS mocno opiera się na modelu security AWS. To plus, jeśli organizacja ma już poukładane IAM i polityki sieciowe, ale wymaga też zrozumienia kilku dodatkowych warstw:

• IAM + RBAC – mapowanie użytkowników/rol IAM do ról Kubernetes przez aws-auth ConfigMap. Typowy ból: chaos w aws-auth przy wielu zespołach, jeśli nie jest wersjonowany i zarządzany jako kod.
• Security Groups – EKS domyślnie izoluje ruch między node’ami przez SG; przy CNI AWS VPC CNI pods otrzymują adresy z VPC, więc SG mogą działać na poziomie podów (jeśli używa się dodatkowych mechanizmów typu security group for pods).
• NetworkPolicy – same SG nie zastępują NetworkPolicy. Do pełnego modelu segmentacji aplikacyjnej warto dodać CNI wspierające polityki (np. Calico) albo zaawansowane tryby VPC CNI.

Przy klastrach multi-tenant (kilka zespołów, jeden klaster) kluczowe staje się połączenie RBAC, namespaces, NetworkPolicy oraz osobnych ról IAM/IRSA dla krytycznych serwisów. Bez tego EKS staje się „wspólnym serwerem” z mocno dziurawą izolacją.

Specyficzne narzędzia i ekosystem dookoła EKS

Na AWS wyrosło kilka narzędzi, które w praktyce są standardem przy EKS:

• eksctl – CLI do tworzenia i modyfikacji klastrów EKS z plików YAML. Dobre na start i dla małych środowisk; przy większej skali przenosi się konfigurację do Terraform/CloudFormation.
• Cluster Autoscaler – dedykowana wersja CA z integracją z ASG, potrafi dodawać i usuwać node’y w grupach EKS Managed Node Groups.
• Karpenter – nowsze podejście do autoscalingu node’ów, nie operuje na ASG, tylko na instancjach bezpośrednio. Pomaga lepiej pakować workloady, korzystać z tańszych typów instancji i spotów.

Firmy z dużą liczbą mikroserwisów w EKS często przechodzą na Karpenter, aby zbić koszty nodów i uprościć zarządzanie flotą. Wymaga to jednak dobrego opanowania requestów/limitów w podach – chaos w zasobach powoduje słabe decyzje skalera.

AKS – specyfika zarządzanego Kubernetes na Azure

Architektura AKS i współpraca z Azure networking

AKS jest mocno „osadzony” w świecie Azure: każdy klaster składany jest z zasobów typu Resource Group, VNet, Managed Identities. Control plane jest ukryty i zarządzany w pełni przez Microsoft, natomiast worker nodes żyją w dedykowanej resource group związanej z klastrem.

Kluczowy wybór przy tworzeniu klastra to model sieci:

• Kubenet – pods mają własne adresy, NAT-owane na adresy node’ów. Prostsze adresowanie, mniejsze zużycie IP, ale trudniejsza integracja z VNet na poziomie pojedynczych podów.
• Azure CNI – pods dostają adresy IP bezpośrednio z VNet. Lepsza integracja z usługami PaaS, NSG (Network Security Group), łatwiejsze śledzenie ruchu, ale większe zużycie adresów IP i dodatkowe ograniczenia skali.

Przy projektach enterprise zwykle wygrywa Azure CNI, bo integruje się z istniejącą architekturą sieciową (firewalle, appliance’y, peering VNet). Przy środowiskach testowych i mniejszych klastrach często wystarcza Kubenet.

Tożsamość i dostęp: Azure AD, Managed Identities, RBAC

AKS mocno promuje integrację z Azure AD jako źródłem tożsamości. W praktyce oznacza to kilka poziomów:

• Użytkownicy – logują się do klastra przez kubeconfig z tokenem AAD lub Azure CLI. Daje to centralne zarządzanie dostępem i MFA po stronie AAD.
• RBAC Kubernetes – role i role bindings mapowane na grupy AAD, co pozwala nadawać uprawnienia na poziomie zespołów/projektów.
• Managed Identities – podmiana klasycznych Service Principal na zarządzane tożsamości dla node’ów i workloadów. Dzięki temu aplikacje mogą korzystać z Key Vault, Storage, baz danych bez trzymania kluczy w sekrecie Kubernetes.

Uwaga: mieszanie kilku modeli (Service Principal, Managed Identities, własne sekrety) w jednym klastrze szybko robi bałagan. Warto zdefiniować docelowy wzorzec (np. tylko Managed Identities + pod identity) i konsekwentnie go stosować.

Skalowanie i aktualizacje w AKS

AKS oferuje zarówno klasyczny Cluster Autoscaler, jak i Virtual Nodes oparte na Azure Container Instances (serverless pods). Dodatkowo można włączyć auto-upgrade dla node pooli z wybranym kanałem (np. stable, rapid).

Przy planowaniu operacji pojawiają się typowe decyzje:

• czy aktualizacje control plane będą manualne, czy