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.
Źródło: Pexels | Autor: panumas nikhomkhai
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.
Źródło: Pexels | Autor: Brett Sayles
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 włączony zostanie auto-upgrade (ze ściśle kontrolowanym „oknem”),
czy node poole produkcyjne powinny być aktualizowane w trybie blue/green (nowy pool, migracja workloadów, usunięcie starego),
jak rozbić node poole na klasy obciążeń (np. standard, memory-optimized, GPU, spot).
Tip: zamiast jednego „wspólnego” node poola lepiej mieć kilka logicznych – np. system, general, gpu, spot – i sterować przydziałem przez nodeSelector/tolerations. Ułatwia to zarówno koszty, jak i troubleshooting.
Integracje AKS z usługami Azure
Azure dookoła AKS promuje cały zestaw „przyległych” usług:
Azure Monitor + Container Insights – zbieranie metryk, logów kubelet, logów kontenerów. Świetnie integruje się z Log Analytics, ale przy złej konfiguracji potrafi generować spore koszty.
Azure Policy for AKS – enforcement polityk (np. brak privileged, ograniczenie rejestrów obrazów, wymagane etykiety) na poziomie klastra.
Ingress z Application Gateway – wariant, w którym Ingress Controller korzysta z Application Gateway jako L7 LB. Przydatne, gdy organizacja i tak standaryzuje się na App GW (WAF, certyfikaty).
Dla zespołu platformowego oznacza to, że AKS może stać się „węzłem” większego ekosystemu Azure, a nie samotnym klastrem. Jednocześnie każde takie spięcie trzeba świadomie modelować w IaC – klikana konfiguracja w portalu szybko wymyka się spod kontroli.
GKE – specyfika zarządzanego Kubernetes na Google Cloud
Architektura GKE Standard vs Autopilot
GKE ma dwa główne tryby: Standard oraz Autopilot. Ich wybór wpływa bezpośrednio na to, ile „chmury” przejmuje odpowiedzialność, a ile zostaje po twojej stronie.
GKE Standard – klasyczny model: control plane jest zarządzany przez Google, natomiast node’y (Compute Engine) są twoje: decydujesz o typach maszyn, dyskach, taintach, aktualizacjach.
GKE Autopilot – zarządzane są zarówno control plane, jak i node’y. Jako użytkownik planujesz tylko pods (requesty, limity), a płacisz za zużyte zasoby, nie za maszyny.
Autopilot ogranicza część funkcji (np. brak bezpośredniego dostępu do node’ów, wymagany pewien poziom „porządku” w konfiguracji podów), ale mocno upraszcza eksploatację dla zespołów bez kompetencji systemowych. W Standard pełną swobodę konfiguracji kupujesz dodatkową odpowiedzialnością.
Sieć w GKE i integracja z VPC
Google od początku budował Kubernetes „obok” własnej sieci VPC, więc integracja jest dość naturalna:
pods i node’y mogą korzystać z VPC-native (alias IP), co upraszcza routing i bezpieczeństwo na poziomie firewall rules,
można używać Internal Load Balancer dla usług wewnętrznych oraz External HTTP(S) Load Balancer dla ruchu z internetu,
NetworkPolicy wspierane są natywnie przez GKE (choć dla zaawansowanych scenariuszy często i tak używa się Cilium/Calico).
Przy środowiskach hybrydowych liczy się możliwość zestawienia Cloud VPN/Interconnect z VPC, gdzie działa GKE – wielu klientów wykorzystuje GKE jako „centralny” klaster i łączy do niego on-prem.
Bezpieczeństwo: Workload Identity, IAM i policy
Google mocno stawia na Workload Identity
W praktyce oznacza to:
brak konieczności wstrzykiwania kluczy JSON do podów,
precyzyjny podział uprawnień do usług GCP (Cloud Storage, Pub/Sub, BigQuery) per aplikacja,
lepszy audyt – logi IAM pokazują, która aplikacja (SA) wykonywała dane wywołania.
GKE integruje się też z Binary Authorization (polityki dopuszczania obrazów do klastra) oraz Cloud Armor (WAF na poziomie Load Balancera). Przy wymaganiach bezpieczeństwa można wymusić, że do klastra trafią wyłącznie obrazy podpisane kluczem organizacji lub pochodzące z określonego rejestru (Artifact Registry).
Skalowanie, upgrade’y i feature’y specyficzne dla GKE
GKE ma jedne z najbardziej rozbudowanych opcji skalowania i aktualizacji:
Node Auto-Provisioning – automatyczne tworzenie nowych node pooli o różnych typach maszyn, gdy istniejące pule nie mogą zaspokoić zapotrzebowania.
Optymalizacja kosztów w GKE: Standard vs Autopilot
Przy GKE wybór między Standard a Autopilot jest de facto wyborem modelu kosztowego. W Standard płacisz za node’y (maszyny w Compute Engine), w Autopilocie – za zasoby zarezerwowane przez pody (CPU/memory) plus storage i ruch sieciowy.
Przy GKE Standard typowe dźwignie kosztowe to:
dobór typów maszyn – e2/c2/e2-highmem zamiast „domyślnych” n1-standard; często da się zejść z ceny przy podobnej wydajności,
preemptible/spot nodes – osobne node poole pod zadania batchowe, CI, analitykę; aplikacje muszą tolerować nagłe ubicie,
zapas na autoscaler – lepsze wykorzystanie node’ów dzięki sensownym requestom; im mniejsza „dziura powietrzna”, tym mniej node’ów potrzeba,
Commitmenty w Compute Engine – zniżki za zobowiązanie do minimalnego zużycia (Committed Use Discounts).
W Autopilocie kluczowe jest panowanie nad requestami i limitami. Nadmiarowe requesty CPU/RAM skutkują realnym kosztem – chmura zarezerwuje tyle, ile poprosisz, niezależnie od faktycznego użycia. Z kolei zbyt agresywne cięcie requestów kończy się throttlingiem i OOMKill.
Przy prostych workloadach (HTTP API, parę jobów) Autopilot często wychodzi taniej niż własne node’y, szczególnie w środowiskach z niskim lub zmiennym obciążeniem. Dopiero przy dużych, stałych klastrach z dobrze „dopasowanym” autoscalingiem Standard może wygrać, głównie dzięki spotom i commitmentom.
GKE a inne usługi Google Cloud w kontekście kosztów
GKE rzadko działa w próżni. Na fakturze obok node’ów i podów pojawiają się:
Cloud Logging / Cloud Monitoring – logi z kubelet, podów, metric-servera; przy domyślnych ustawieniach potrafią generować znaczący koszt,
Cloud Load Balancing – każdy zewnętrzny LB to osobna pozycja na rachunku (L7 HTTP(S) lub L4 Network),
Cloud NAT / egress przez internet – ruch wychodzący poza VPC, np. do zewnętrznych API, rejestrów obrazów,
Persistent Disk – dyski pod bazy danych, kolejki, systemy plików montowane jako PersistentVolume.
Przy rozrośniętych środowiskach dobrym krokiem jest centralizacja logów i metryk (np. selektywny eksport tylko wybranych namespaces) oraz ograniczenie liczby publicznych Load Balancerów za pomocą wspólnych Ingressów.
Koszty – zarządzany vs własny Kubernetes, nie tylko faktura z chmury
Mapa kosztów: z czego naprawdę składa się „cena klastra”
Przy porównywaniu zarządzanego i własnego Kubernetes zwykle patrzy się na linię na fakturze chmurowej opisującą klaster. To tylko wierzchołek. Poniżej są jeszcze:
czas ludzi – zespół platformowy/SRE, który utrzymuje, aktualizuje i monitoruje klaster,
koszt „tarcia wewnętrznego” – ile czasu zespoły produktowe tracą na adaptację do platformy, obejścia, bugi w klastrze.
Na własnym klastrze część tych elementów jest jawna (np. zakup licencji na monitoring, etat admina), w zarządzanym – część „zaszyta” w cenie usługi lub przesunięta do kontraktu z dostawcą.
Bezpośrednie koszty infrastruktury
Przy zestawieniu „własny vs zarządzany” naturalne jest porównanie:
kosztu maszyn kontrol plane + worker nodes on-prem lub w IaaS,
z opłatą za control plane w EKS/AKS/GKE (tam, gdzie jest liczona oddzielnie) plus worker nodes.
Przykładowo na AWS przy EKS płacisz stałą kwotę za klaster (control plane) plus instancje workerów. Przy własnym klastrze na EC2 kosztuje cię każda maszyna master (wysoka dostępność) oraz elementy towarzyszące: load balancery do API, bazy etc. Na papierze zarządzany control plane prawie zawsze wychodzi taniej niż utrzymywanie równoważnej dostępności i bezpieczeństwa we własnym zakresie.
W on-prem sprawa jest mniej oczywista – jeśli i tak masz kupione serwery i storage, dopięcie na nich Kubernetes może wydawać się „za darmo”. Trzeba jednak uwzględnić:
koszt nadprowizji (overprovisioning) pod HA masternodów,
cena/utrzymanie storage (SDS, SAN),
wsparcie producenta (subskrypcje Red Hat, VMware, Canonical itp.).
Ukryte koszty operacyjne własnego klastra
Własny Kubernetes daje pełną kontrolę, ale generuje sporo kosztów „operacyjnych”, które trudno złapać w Excela:
projektowanie i utrzymanie sieci – CNI, IPAM, routing, integracje z firewallami i balancerami,
zabezpieczenia – certyfikaty, rotacja kluczy, hardening węzłów, polityki bezpieczeństwa,
rozwiązywanie problemów niskopoziomowych – kernel, sieć, kubelet, itp.
W modelu zarządzanym spora część tych problemów leży po stronie dostawcy – szczególnie awarie control plane, bugi w integracji z LB/storage, zarządzanie certyfikatami API servera, HA etc. Płacisz za to w cenie usługi, ale nie w etatach SRE.
Koszt kompetencji i „krzywa uczenia”
Droga do stabilnego, własnego klastra jest stromą krzywą uczenia. Trzeba zrozumieć nie tylko Kubernetes, ale też:
Linux na poziomie kernel / cgroups,
składnię i pułapki Calico/Cilium/Weave,
działanie kube-proxy, iptables, conntrack,
mechanikę kube-scheduler i autoscalera.
W praktyce oznacza to zatrudnienie lub rozwinięcie specjalistów o profilu systemowo-sieciowym, nie tylko devopsowym. To koszt zarówno bezpośredni (wynagrodzenia), jak i pośredni – dopóki zespół się uczy, produkcja jest polem eksperymentów.
W zarządzanym EKS/AKS/GKE ta krzywa jest łagodniejsza. Nadal trzeba rozumieć podstawy K8s i specyfikę danej chmury, jednak awarie typu „API server nie wstaje po restarcie node’a master” praktycznie znikają z twojego backlogu.
Kiedy własny klaster Kubernetes ma sens finansowy
Są scenariusze, w których własny klaster, mimo wyższej złożoności, bilansuje się ekonomicznie:
duże, stabilne obciążenia on-prem – produkcja, która i tak musi zostać w data center (compliance, opóźnienia),
silna standaryzacja infrastruktury – organizacja ma już SDS, monitoring, CMDB, duży dział sieci, który umie to wszystko spinać,
licencje / appliance’y sprzętowe – np. istniejące firewalle, load balancery, rozwiązania storage, które w chmurze byłyby powielane jako usługi PaaS.
W takim środowisku Kubernetes jest kolejną warstwą na już opłaconej infrastrukturze. Oszczędność pojawia się wtedy, gdy uda się dzięki temu skonsolidować aplikacje, zredukować footprint VM-ek i lepiej wykorzystać kupiony sprzęt.
Kiedy zarządzany Kubernetes wygrywa całkowitym kosztem
Zarządzane EKS/AKS/GKE praktycznie zawsze wygrywają w sytuacjach:
startu lub migracji do chmury – gdy jeszcze nie ma zespołu od „gołego” Kubernetesa, a projekty potrzebują środowisk szybko,
dużej zmienności obciążeń – aplikacje SaaS, kampanie marketingowe, intensywne ~spike’i ruchu; autoscaler w połączeniu z managed node groups działa lepiej niż ręcznie strojone klastry,
wielu małych środowisk – dev, test, stage, sandboksy; koszt osobnego „własnego” klastra dla każdego byłby absurdalny operacyjnie,
braku potrzeby customizacji control plane – jeśli nie musisz dotykać kube-apiserver, etcd, schedulerów, trudno uzasadnić utrzymanie ich samodzielnie.
W praktyce często wygląda to tak: organizacja zaczyna od zarządzanego Kubernetes w jednej z chmur, a dopiero przy dużej skali lub specyficznych wymaganiach dorzuca własne klastry on-prem / multi-cloud, budując warstwę abstrakcji (np. z GitOps + fleet management).
Koszt vendor lock-in vs koszt przeniesienia
Dylemat „zarządzany vs własny” jest też dylematem „lock-in vs portowalność”. Zarządzane klastry mocno zachęcają do używania usług natywnych dla danego dostawcy (IAM, LB, storage, monitoring). To ułatwia start, ale wiąże aplikacje z konkretnym ekosystemem.
Własny Kubernetes, zbudowany na open-source’owych komponentach (np. Prometheus, Loki, Jaeger, NGINX Ingress, cert-manager), ułatwia przenoszenie workloadów między środowiskami. Koszt takiej „neutralności” pojawia się w:
większym wysiłku integracyjnym – samemu trzeba zbudować i utrzymać „chmuropodobne” doświadczenie,
utrzymaniu bardziej skomplikowanego stosu narzędzi, często złożonego z wielu operatorów i CRD,
wolniejszym wdrażaniu nowych funkcji – dostawcy chmur szybciej dostarczają nowe featury w swoich managed usługach niż społeczność w genericych komponentach.
Często korzystniejszy jest kompromis: managed Kubernetes jako fundament, ale z zachowaniem pewnego poziomu przenoszalności na poziomie manifestów (Helm/Kustomize), standardowych operatorów i minimalizacji użycia chmurowych „smaczków” tam, gdzie nie są krytyczne.
Optymalizacja kosztów niezależnie od modelu klastra
Niezależnie od tego, czy klaster jest własny, czy zarządzany, kilka prostych nawyków ma największy wpływ na rachunki:
porządek w requestach/limitach – audyt namespace’ów, które rezerwują ogromne ilości CPU/RAM przy niskim użyciu,
separacja workloadów – spot/preemptible node poole dla zadań batchowych, dedykowane pule dla gęsto pakowanych mikroserwisów,
lifecycle środowisk – automatyczne wyłączanie/skalowanie środowisk testowych poza godzinami pracy,
obserwowalność jako narzędzie odchudzania – dashboardy pokazujące wykorzystanie zasobów per namespace/aplikacja, a nie tylko CPU/Memory klastra,
limity logów i metryk – filtrowanie „śmieci” (health checks, nadmiarowe debug logi) zanim trafią do systemów typu Loki/Elastic/Cloud Logging.
Jedna z organizacji, z którą pracowałem, po wprowadzeniu prostego przeglądu requestów CPU/RAM raz na kwartał, zbiła koszty klastrów w chmurze o kilkadziesiąt procent – bez zmiany dostawcy i bez przebudowy aplikacji. Źródłem oszczędności nie była więc magia pricingu, tylko konsekwencja w zarządzaniu zasobami.
Najczęściej zadawane pytania (FAQ)
Kiedy ma sens przejście z docker-compose na Kubernetes?
Próg zwykle pojawia się, gdy aplikacja przestaje być „kilkoma kontenerami na jednym serwerze”, a zaczyna być systemem z wieloma usługami, środowiskami i wymaganiami SLA. Typowy moment to więcej niż 3–4 serwisy zależne od siebie, osobne środowiska (dev/test/stage/prod) oraz potrzeba kilku wdrożeń dziennie bez ręcznej orkiestracji.
Kubernetes zaczyna mieć sens, gdy potrzebujesz: automatycznego skalowania (HPA/VPA), wysokiej dostępności między węzłami, standardowego sposobu deploymentu dla rosnącego zespołu i perspektywy migracji między dostawcami (multi‑cloud). Jeśli nadal jesteś w stanie komfortowo ogarnąć całość jednym serwerem i prostymi skryptami, koszt wejścia w Kubernetes może być na tym etapie niepotrzebny.
Co tak naprawdę oznacza „zarządzany Kubernetes” (EKS, AKS, GKE)?
Zarządzany Kubernetes oznacza, że dostawca chmury bierze na siebie cały control plane: utrzymanie API servera, schedulera, controller-managera i etcd. To on dba o HA, backup stanu, aktualizacje wersji Kubernetes oraz integrację z usługami chmurowymi (IAM, sieć, load balancery). Dostajesz SLA na dostępność control plane, zwykle na poziomie ok. 99,95%.
Po twojej stronie nadal zostają worker nodes (zwykłe VM lub tryb managed node groups / Autopilot / Fargate), konfiguracja sieci na poziomie CNI, storage (klasy storage, snapshoty, backupy) oraz cała „warstwa aplikacyjna”: manifesty, CI/CD, monitoring, logowanie i polityki bezpieczeństwa. Uwaga: „zarządzany” nie znaczy „bezobsługowy”, tylko „nie zarządzasz jądrem klastra”.
Kiedy lepiej wybrać własny klaster Kubernetes zamiast EKS/AKS/GKE?
Własny klaster ma sens, gdy publiczna chmura lub usługa zarządzana nie spełnia twardych wymogów. Chodzi głównie o środowiska on‑prem z silnym compliance (banki, administracja, sektor medyczny), brak zgody na trzymanie danych u zewnętrznego vendora albo konieczność użycia specyficznego sprzętu: niestandardowe GPU, dedykowane macierze, sieci o bardzo niskich opóźnieniach.
Drugi typowy scenariusz to edge computing i rozproszone lokalizacje (sklepy, fabryki, IoT), gdzie nie chcesz, by każdy request szedł do chmury. Trzeci powód to pełna kontrola nad siecią i storage: własne CNI, specyficzny routing, multicast, niestandardowe klasy storage. W takich przypadkach koszt i złożoność utrzymania własnego control plane jest uzasadniona biznesowo.
Jakie są główne różnice kosztowe: zarządzany Kubernetes vs własny klaster?
W zarządzanym Kubernetes płacisz bezpośrednio za usługę control plane (czasem liniowo za klaster, czasem wliczone w cenę workerów) oraz za zasoby worker nodes, storage i ruch sieciowy. Kosztem ukrytym jest zależność od konkretnego vendora i jego rozwiązań (load balancery, IAM, specyficzne CNI/CSI), co utrudnia migrację 1:1 do innej chmury.
Własny klaster wymaga inwestycji w kompetencje i czas zespołu: projektowanie HA etcd, automatyzacja instalacji, aktualizacje, monitoring, backup i DR. Często mniej płacisz vendorowi (sprzęt lub IaaS vs PaaS), ale więcej w roboczogodzinach i ryzyku operacyjnym. Tip: przy małych i średnich zespołach zwykle taniej wychodzi EKS/AKS/GKE; własny klaster zaczyna się zwracać przy dużej skali lub twardych wymaganiach on‑prem.
Jak SLA i awarie control plane wpływają na działanie klastra Kubernetes?
Przy zarządzanym Kubernetes awarie control plane są po stronie dostawcy – masz SLA na jego dostępność. Jeśli API server padnie, twoje pody dalej działają na workerach, ale nie możesz wykonywać operacji zarządzających (kubectl apply, skalowanie, rollout). Vendor odpowiada za odtworzenie klastra, spójność etcd i HA między strefami dostępności.
We własnym klastrze pełna odpowiedzialność jest po twojej stronie. Błąd w konfiguracji etcd, utrata quorum, brak backupów albo wygasły certyfikat API servera mogą oznaczać utratę całej konfiguracji klastra lub długi downtime. Dlatego własny klaster wymaga: min. 3 węzłów etcd w różnych AZ/DC, regularnych testów odtworzeniowych, planu DR na utratę całej lokalizacji oraz procedur rotacji certyfikatów TLS.
Co w EKS/AKS/GKE jest zarządzane przez dostawcę, a co zawsze pozostaje po stronie zespołu?
Dostawca zarządza: instalacją, HA i aktualizacją control plane, integracją z natywnym IAM, podstawową siecią i integracją ze storage w chmurze. W trybach typu GKE Autopilot lub EKS Fargate część zarządzania workerami również jest uproszczona (brak bezpośredniego zarządzania VM‑kami, tylko deklarujesz zasoby dla podów).
Po twojej stronie zawsze zostają: definicje aplikacji (Deployment, StatefulSet, Service, Ingress, ConfigMap, Secret), pipeline’y CI/CD, monitoring/logowanie/tracing, polityki bezpieczeństwa (RBAC, NetworkPolicy, PodSecurity) oraz projektowanie topologii klastrów (ile, gdzie, jak spięte z innymi systemami). Do tego dochodzi backup danych biznesowych (bazy danych, wolumeny PV) – vendor nie zna twojej logiki aplikacyjnej, więc nie zrobi tego za ciebie.
Czy zarządzany Kubernetes utrudnia migrację między chmurami (vendor lock-in)?
Sam „goły” Kubernetes jest przenośny – te same manifesty zadziałają na różnych klastrach przy zachowaniu tych samych wersji API. Problem vendor lock‑in pojawia się, gdy intensywnie korzystasz z natywnych dodatków chmurowych: specyficznych load balancerów, storage classów, kontrolerów Ingress, integracji z IAM czy niestandardowych CRD dostawcy.
Aby ograniczyć lock‑in, część zespołów świadomie trzyma się bardziej „vanilla” K8s: używa abstrakcji (np. ExternalDNS, cert-manager, ingress-nginx) i standardowych API, zamiast głęboko integrować się z jednym vendorem. To kompromis: trochę mniej „cukru” od chmury w zamian za łatwiejszą migrację między EKS/AKS/GKE lub do własnego klastra on‑prem.
Źródła informacji
Kubernetes Documentation. Cloud Native Computing Foundation – Oficjalna dokumentacja architektury control plane, node’ów, obiektów API
Kubernetes in Action. Manning Publications (2018) – Książka opisująca architekturę, HA, etcd, praktyki operacyjne klastra
Production Kubernetes. O’Reilly Media (2021) – Praktyki produkcyjne: SLA, HA control plane, backupy, DR, bezpieczeństwo
