Kubernetes i Docker to dwa piętra tej samej instalacji, a nie dwie konkurencyjne opcje: Docker pakuje aplikację w obraz i uruchamia pojedynczy kontener, Kubernetes pilnuje kopii tego kontenera na wielu maszynach. Pytanie “Kubernetes vs Docker” pada więc zwykle wtedy, gdy ktoś stoi przed zupełnie innym wyborem. Prawdziwa decyzja brzmi tak: czy aplikacja ma chodzić na jednej maszynie z plikiem Compose, czy na klastrze z całym kosztem jego utrzymania. Poniżej rozkładamy oba piętra na części. Pokazujemy też moment, w którym klaster przestaje być przerostem formy.
Skąd bierze się pytanie Kubernetes czy Docker
Zamieszanie ma konkretne źródła i żadne z nich nie jest głupie. Docker Desktop ma wbudowaną opcję utworzenia lokalnego klastra Kubernetes. Oba napisy widać więc w jednym oknie ustawień, jeden pod drugim. Docker ma też swój własny mechanizm rozkładania kontenerów na wiele maszyn, czyli Swarm. Do tego dochodzi język obu ekosystemów. Jeden i drugi mówi o “uruchamianiu aplikacji” i brzmi bliźniaczo.
W praktyce te narzędzia odpowiadają na inne pytania. Docker odpowiada na pytanie, jak spakować aplikację razem z jej zależnościami. Efektem ma być obraz, który startuje identycznie na twoim laptopie i na serwerze. Kubernetes odpowiada na pytanie, jak trzymać dwadzieścia takich paczek na sześciu maszynach. Chodzi o to, żeby awaria jednej maszyny nie oznaczała awarii usługi.
Dlatego zestawianie tych nazw jak dwóch produktów prowadzi donikąd. Można używać samego Dockera przez lata i nigdy nie dotknąć klastra. Odwrotnie się nie da. Kubernetes uruchamia obrazy kontenerów, ale ich nie buduje, więc bez Dockera albo innego narzędzia budującego nie ma czego uruchamiać.
Nikt tego zwykle nie prostuje, bo obie społeczności mówią do swoich. Materiały o Kubernetesie zakładają, że kontenery masz opanowane. Materiały o Dockerze kończą się na jednej maszynie i nie mówią, co dalej. Osoba wchodząca w temat ląduje dokładnie w luce między jednymi a drugimi.
Co robi Docker, a czego nie zrobi za ciebie
Docker daje trzy rzeczy. Format obrazu, narzędzie do jego zbudowania i program uruchamiający kontenery na jednej maszynie. Do tego dochodzi Compose, czyli plik opisujący kilka kontenerów, które mają chodzić razem. Aplikacja, baza i serwer pośredniczący startują wtedy jednym poleceniem docker compose up.
To pokrywa zaskakująco dużo przypadków. Aplikacja wewnętrzna dla trzydziestu osób. Sklep o ruchu, przy którym jeden serwer się nie poci. Środowisko testowe zespołu, panel administracyjny klienta, wewnętrzne narzędzie księgowości. Wszystko to mieści się na jednej maszynie i działa latami.
Teraz druga strona. Sam silnik Dockera z plikiem Compose nie przeniesie kontenera na inną maszynę, gdy ta pierwsza przestanie odpowiadać. Nie wymieni wersji aplikacji po jednej kopii naraz, pilnując, żeby zawsze działała co najmniej jedna sprawna. Sam z siebie nie rozłoży też ruchu między maszynami ani nie dołoży kopii, gdy obciążenie skoczy. Każdą z tych rzeczy da się oskryptować ręcznie i w małej skali tak się właśnie robi. Problem pojawia się wtedy, gdy tych skryptów jest na tyle dużo, że kolejność ich uruchamiania zna wyłącznie autor.
Osobna sprawa to pieniądze, bo tu bywa niemiła niespodzianka. Sam silnik Dockera na Linuksie jest darmowy. Docker Desktop już nie zawsze. Producent pozwala używać go bez subskrypcji w firmach, które mają mniej niż 250 pracowników i poniżej 10 milionów dolarów rocznego przychodu. Powyżej tego progu każdy użytkownik potrzebuje płatnej licencji. To jeden z powodów, dla których zespoły zaczynają patrzeć na zamienniki, o czym piszemy przy porównaniu Podmana z Dockerem.
Co dokłada Kubernetes i ile kosztuje jego utrzymanie
Kubernetes wprowadza jedno pojęcie, które zmienia sposób myślenia: stan pożądany. Opisujesz, jak ma wyglądać świat. Trzy kopie tej aplikacji, taki adres, tyle pamięci. Klaster sam dąży do tego opisu i sam koryguje odchylenia. Gdy maszyna padnie, kopie wstają gdzie indziej. Gdy zmienisz wersję obrazu, podmiana idzie po kolei i zatrzymuje się, jeśli nowa wersja nie wstaje.
Tu jest realna wartość i nie ma sensu jej umniejszać. Jest też rachunek, którego nikt nie wystawia z góry. Projekt utrzymuje trzy ostatnie wydania naraz, a każde dostaje poprawki mniej więcej przez rok. Wersja 1.37 wyszła 26 sierpnia 2026, a jej wsparcie kończy się w październiku 2027. W praktyce oznacza to stały cykl aktualizacji klastra, którego częstotliwość zależy od dystrybucji i dostawcy. Ten cykl nie kończy się, dopóki klaster istnieje.
Do tego dochodzą rzeczy, o których nie mówi się na szkoleniach wprowadzających. Sieć w klastrze to osobny komponent z własnymi awariami. Dyski trwałe to kolejny osobny komponent. Uprawnienia, certyfikaty, zbieranie logów i mierzenie zużycia zasobów dokładają się do tej samej listy. Ktoś musi to rozumieć w środku nocy, a nie tylko na warsztatach. Usługa zarządzana u dostawcy chmury zawsze zdejmuje z ciebie obsługę warstwy sterującej klastra. Zakres reszty zależy od konkretnego produktu, bo część wariantów zarządza też węzłami, skalowaniem i fragmentem sieci. Sprawdź to w cenniku, zanim uznasz, że kupujesz spokój.
Docker Compose kontra Kubernetes, czyli realny wybór
Jeśli szukasz w sieci porównania Kubernetes vs Docker, to prawie na pewno stoisz przed tym pytaniem. Po jednej stronie jest plik Compose. Jeden dokument, kilkadziesiąt linii, jedna maszyna, jedno polecenie startowe. Po drugiej stronie jest zestaw obiektów opisywanych osobno: wdrożenie, usługa, wejście z zewnątrz, konfiguracja, sekrety. Potem trzeba to jeszcze utrzymywać w jakiejś formie szablonów.
Różnica nie sprowadza się do liczby linii. Plik Compose czyta i poprawia w zespole praktycznie każdy, po krótkim wprowadzeniu. Zestaw manifestów Kubernetesa potrzebuje kogoś innego. Kogoś, kto rozumie, dlaczego usługa nie widzi kontenera, choć oba obiekty wyglądają poprawnie. To jest stanowisko, a nie zadanie na jedno popołudnie.
Wybór Compose niczego nie przekreśla. Nic nie stoi na przeszkodzie, żeby zacząć od jednej maszyny i przenieść się na klaster za rok. Obraz kontenera zwykle zostaje ten sam. Zmiany obejmują opis uruchomienia, a czasem także konfigurację aplikacji, sieć, przechowywanie danych i integracje. Odwrotny ruch bywa znacznie droższy. Schodzenie z klastra po latach dokładania do niego narzędzi to już osobny projekt z własnym terminem.
Czy do codziennej pracy na laptopie potrzebujesz klastra
Jest jeszcze trzeci wybór, o którym rzadko się mówi, a dotyczy każdego dnia pracy. Chodzi o środowisko na własnej maszynie. Można trzymać je na pliku Compose albo postawić lokalnie mały klaster i pracować na nim.
Odpowiedź zależy od tego, co za chwilę i tak cię czeka. Jeżeli aplikacja jedzie na produkcji na klastrze, praca lokalnie na Compose kupuje ci wygodę teraz i płacisz za nią później. Różnice wyjdą przy pierwszym wdrożeniu, zwykle w najgorszym momencie. Jeżeli natomiast produkcja stoi na jednej maszynie, lokalny klaster jest wyłącznie kosztem. Zjada pamięć laptopa i dokłada warstwę, której nikt w zespole nie potrzebuje do poprawienia błędu.
Jest też droga pośrednia i w wielu zespołach sprawdza się najlepiej. Codzienna praca idzie na Compose, a przed wydaniem wersja ląduje na małym klastrze testowym. Wtedy niespodzianki wychodzą przed wdrożeniem, a nie po nim. Warunkiem jest jednak to, żeby ten klaster testowy ktoś utrzymywał. Zapomniane środowisko testowe potrafi mylić bardziej, niż jego brak.
Czy Kubernetes wyrzucił Dockera z klastra
W 2022 roku przez branżę przeszła panika, że Kubernetes porzuca Dockera. Chodziło o dockershim, czyli wewnętrzny element klastra tłumaczący polecenia na język Dockera. Ten element zniknął w wydaniu 1.24 i faktycznie było to zerwanie.
Dla osoby budującej obrazy zmieniło się jednak dokładnie nic. Obrazy zbudowane Dockerem działają w klastrze dalej. Są zapisane w otwartym formacie, którego Docker jest jednym z wielu użytkowników, a nie właścicielem. Zmieniło się to, co uruchamia kontener wewnątrz węzła. Dziś jest to zwykle containerd, czyli ten sam element, który siedzi pod spodem samego Dockera.
Z tej historii płynie szerszy wniosek o czytaniu takich nagłówków. Kubernetes wymienił wtedy własny element wewnętrzny i nie dotknął formatu obrazów. Nagłówki mówiły jednak o rozstaniu dwóch narzędzi, bo tak brzmi ciekawiej. Dokładnie ten sam mechanizm produkuje dziś pytanie o wybór między nimi.
Praktyczny wniosek brzmi więc odwrotnie, niż sugerowała tamta panika. Nauka Dockera nie jest pracą straconą przy wejściu w Kubernetesa. To jest warstwa, którą trzeba mieć opanowaną najpierw. Klaster do ćwiczeń możesz przy tym utworzyć bezpośrednio w Docker Desktopie, w jego ustawieniach. Do wyboru jest wariant jednowęzłowy i wielowęzłowy.
Frontend Master 2026 · Kodożercy
Pisz kod, nie tylko prompty
Frontend Master 2026 to pakiet sześciu kursów Kodożerców (HTML, CSS, JavaScript, Git) w polskim wideo z 12-miesięcznym dostępem. Fundamenty frontu od pierwszej linijki kodu do deploy.
Wchodzę w to →
Od kiedy klaster zaczyna się opłacać
Zamiast progu ruchu proponujemy cztery pytania, bo to one rozstrzygają w praktyce. Pierwsze: czy usługa musi przeżyć awarię pojedynczej maszyny bez twojego udziału. Drugie: czy wdrożenia mają iść bez przerwy w działaniu, kilka razy dziennie. Trzecie: czy ruch skacze tak, że stała liczba maszyn albo dusi aplikację, albo pali pieniądze. Czwarte i najważniejsze: czy w zespole jest ktoś, kto weźmie klaster na własność i będzie go pilnował po odejściu autora wdrożenia.
Odpowiedź odmowna na pierwsze trzy pytania oznacza, że jedna maszyna z Compose i przyzwoitą kopią zapasową obsłuży sprawę lepiej. Odpowiedź twierdząca na choć jedno z nich otwiera rozmowę o klastrze, ale dopiero czwarte pytanie ją rozstrzyga. W polskich realiach dochodzi jeszcze wielkość zespołu. Weźmy firmę sześcioosobową, gdzie administracją zajmuje się jedna osoba przy okazji innych obowiązków. Klaster nie jest tam inwestycją w niezawodność. Jest przeniesieniem ryzyka z awarii sprzętu na awarię wiedzy, której nikt poza tą jedną osobą nie ma.
Czwarte pytanie bywa drażliwe i dlatego zwykle się je pomija. Decyzję o klastrze podejmuje zespół, a utrzymanie spada na jedną osobę i nikt tego nie zapisuje. Po roku ta osoba zmienia pracę, a zostaje po niej katalog manifestów i wersja klastra sprzed trzech wydań. Aktualizacja takiego klastra jest znacznie droższa niż jego postawienie. Tak właśnie dobry wybór technologiczny zamienia się w dług.
Osobno wygląda sytuacja, gdy Kubernetes jest wymaganiem klienta albo standardem w firmie, do której właśnie dołączasz. Wtedy nie wybierasz, tylko się uczysz. Warto to sobie jasno nazwać, bo to zupełnie inna decyzja niż projektowanie własnej infrastruktury od zera. Podobna różnica dzieli wybór platformy do kodu od wyboru narzędzia do wdrożeń, co rozkładamy w tekście o tym, którą platformę wybrać: GitLab czy GitHub. Jeśli natomiast szukasz jeszcze niższego piętra i zastanawiasz się, czym kontener różni się od zwykłej maszyny wirtualnej, zaczęlibyśmy od porównania Dockera z maszyną wirtualną.
{ aplikacje webowe }Masz pomysł na aplikację? Najpierw go zobacz
Zanim zainwestujesz w pełny system, przygotujemy klikalny prototyp, który pokażesz zespołowi albo klientom. Potem budujemy aplikację webową, która rośnie razem z firmą.
Najczęstsze pytania
Czy trzeba znać Dockera, żeby nauczyć się Kubernetesa?
Nie musisz znać konkretnie Dockera, bo obrazy buduje się też innymi narzędziami. Musisz natomiast rozumieć obrazy kontenerów, rejestry, zmienne środowiskowe i wolumeny. Docker jest po prostu najpopularniejszą drogą do opanowania tych podstaw. Bez nich praca z klastrem sprowadza się do kopiowania cudzych plików i zgadywania, czemu nie działają.
Czy Docker Swarm to sensowna alternatywa dla Kubernetesa?
Swarm rozwiązuje ten sam problem prostszym językiem i nadal działa. Zanim jednak postawisz na niego na kilka lat, sprawdź trzy rzeczy. Czy twój dostawca infrastruktury go wspiera. Czy narzędzia, których używacie, mają dla niego gotowe rozwiązania. I czy znajdziesz na rynku ludzi, którzy pracowali z nim w firmie.
Czy Kubernetes ma sens na jednym serwerze?
Ma, ale tylko w dwóch sytuacjach: do nauki albo wtedy, gdy przygotowujesz się do pracy w środowisku, które i tak stoi na klastrze. Jako rozwiązanie docelowe na jednej maszynie dokłada wszystkie koszty utrzymania klastra i nie daje najważniejszej korzyści, czyli przetrwania awarii sprzętu.
Czy da się używać Dockera całkowicie za darmo?
Na Linuksie tak, bo sam silnik jest wolnym oprogramowaniem. Ograniczenia zaczynają się przy Docker Desktopie w dużych firmach i przy pobieraniu obrazów z rejestru producenta, gdzie konto bezpłatne ma limit liczony w oknie sześciogodzinnym. Dla środowiska produkcyjnego rozwiązaniem bywa własne lustro rejestru albo inny silnik kontenerów.
Podsumowanie
Kubernetes nie jest lepszą wersją Dockera, tylko warstwą, która zaczyna się tam, gdzie jedna maszyna przestaje wystarczać. Dopóki aplikacja mieści się na jednym serwerze i przerwa na wdrożenie nikogo nie boli, plik Compose wygrywa każdym możliwym kryterium: czasem wdrożenia, liczbą osób zdolnych go poprawić i kosztem utrzymania. Na produkcji klaster zaczyna mieć sens, gdy usługa musi przeżyć awarię maszyny bez twojego udziału, a w zespole jest konkretna osoba, która weźmie go na siebie. Do nauki i do pracy w środowisku, które i tak stoi na klastrze, powody są inne i opisujemy je wyżej. Jeśli tej osoby nie ma, decyzja jest już podjęta, tylko jeszcze nikt tego nie powiedział na głos. Zacznij od pliku Compose, a przeprowadzkę na klaster potraktuj jak osobny projekt z własnym terminem i własnym właścicielem. Jeśli klaster ma stanąć w chmurze, dochodzi wybór dostawcy — rozkładamy go w tekście o AWS kontra Azure dla polskiej firmy.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
