Docker vs Kubernetes: co to jest i czym się różnią?
Spis treści
Docker vs Kubernetes, co to jest? Docker to narzędzie do pakowania aplikacji w kontenery i uruchamiania ich na jednej maszynie. Kubernetes to system, który zarządza wieloma kontenerami na wielu serwerach: rozkłada je, skaluje i przywraca po awarii. Te narzędzia ze sobą nie konkurują. Docker odpowiada na pytanie „jak spakować i uruchomić aplikację”, a Kubernetes na pytanie „jak utrzymać sto takich aplikacji w ruchu”. Niżej: obie definicje, pięć różnic, schemat współpracy i wskazówka, kiedy sam Docker wystarczy.
Kluczowe wnioski: Docker buduje obrazy i uruchamia kontenery, zwykle na jednym hoście. Kubernetes to orkiestrator: zarządza kontenerami w klastrze wielu maszyn. Projekt Kubernetes udostępnił Google w 2014 roku, dziś opiekuje się nim Cloud Native Computing Foundation. Od wersji 1.24 Kubernetes nie używa Docker Engine do uruchamiania kontenerów, ale obrazy zbudowane Dockerem działają w nim bez zmian. Typowy układ to oba narzędzia naraz: Docker u programisty i w CI, Kubernetes na produkcji. Dla jednej aplikacji na jednym serwerze Docker z Compose zwykle wystarcza.
Co to jest Docker?
Docker to otwarta platforma do tworzenia, dostarczania i uruchamiania aplikacji, tak opisuje go oficjalna dokumentacja. W praktyce chodzi o kontener, czyli odizolowany proces z własnym systemem plików, w którym aplikacja ma wszystko, czego potrzebuje do działania.
Trzy pojęcia, które wystarczą na start:
- Obraz (image): niezmienny szablon z aplikacją i jej zależnościami, budowany z pliku
Dockerfile. - Kontener: uruchomiona instancja obrazu.
- Rejestr (registry): magazyn obrazów, z którego pobiera je serwer lub klaster.
Do tego dochodzi Docker Compose, który jednym plikiem opisuje kilka powiązanych kontenerów, na przykład aplikację, bazę danych i kolejkę. Docker rozwiązuje problem „u mnie działa”: ten sam obraz uruchamia się tak samo na laptopie, w CI i na serwerze.
Co to jest Kubernetes?
Kubernetes (w skrócie K8s) to otwarty system orkiestracji kontenerów, który automatyzuje wdrażanie, skalowanie i zarządzanie skonteneryzowanymi aplikacjami. Tak definiuje go dokumentacja projektu. Orkiestracja oznacza tu decydowanie, na której maszynie ma działać który kontener, i pilnowanie, żeby tak zostało.
Kubernetes działa deklaratywnie. Opisujesz stan docelowy, na przykład „trzy kopie tej aplikacji, dostępne pod jednym adresem”, a klaster sam do niego dąży. Gdy kontener padnie, uruchamia nowy. Gdy rośnie ruch, może dołożyć kopie. Gdy wdrażasz nową wersję, podmienia kontenery stopniowo i pozwala wrócić do poprzedniej.
Stan na 5 listopada 2026: najnowsza gałąź to 1.37, a projekt utrzymuje trzy ostatnie wydania (lista wydań).
Docker vs Kubernetes: różnice w pigułce
- Zadanie. Docker: zbudować obraz i uruchomić kontener. Kubernetes: zarządzać wieloma kontenerami w klastrze.
- Skala. Docker: jedna maszyna. Kubernetes: wiele maszyn (węzłów) traktowanych jak jedna pula zasobów.
- Awaria. Docker: restart kontenera na tym samym hoście; gdy padnie host, aplikacja stoi. Kubernetes: przenosi kontenery na sprawne węzły.
- Konfiguracja. Docker:
Dockerfilei plik Compose. Kubernetes: manifesty YAML opisujące stan docelowy. - Próg wejścia. Docker: kilka poleceń. Kubernetes: osobny obszar wiedzy obejmujący sieć, uprawnienia, magazyn danych i aktualizacje klastra.
Docker pakuje aplikację. Kubernetes pilnuje, żeby działała, gdy maszyn i kontenerów robi się dużo.
Jak Docker i Kubernetes działają razem?
Najczęściej oba narzędzia pracują w jednym łańcuchu. Programista buduje obraz Dockerem, wysyła go do rejestru, a Kubernetes pobiera obraz i uruchamia go w podach, czyli najmniejszych jednostkach, którymi zarządza klaster.
Poglądowy przykład tego samego obrazu w obu narzędziach:
docker build -t registry.example.com/sklep-api:1.0 .
docker run -d -p 8080:8080 registry.example.com/sklep-api:1.0
docker push registry.example.com/sklep-api:1.0
kubectl create deployment sklep-api --image=registry.example.com/sklep-api:1.0 --replicas=3
kubectl expose deployment sklep-api --port=80 --target-port=8080Czy Kubernetes nadal używa Dockera?
Do uruchamiania kontenerów już nie. Warstwę pośrednią o nazwie dockershim usunięto w Kubernetes 1.24, co opisuje oficjalne FAQ. Klaster korzysta ze środowisk uruchomieniowych zgodnych ze standardem CRI, takich jak containerd. Dla programisty nic się nie zmienia: obraz z docker build jest zgodny ze standardem OCI i działa w każdym z nich.
Kiedy wystarczy Docker, a kiedy potrzebny jest Kubernetes?
Sam Docker (z Compose) zwykle wystarcza, gdy:
- aplikacja działa na jednym serwerze, a krótka przerwa przy wdrożeniu jest akceptowalna,
- ruch jest przewidywalny i nie trzeba automatycznie dokładać kopii,
- nikt w zespole nie ma czasu na utrzymanie klastra.
Kubernetes zaczyna się opłacać, gdy:
- usług jest kilkanaście lub więcej i wdrażają je różne zespoły,
- aplikacja ma przetrwać awarię pojedynczej maszyny,
- ruch mocno się waha i potrzebne jest automatyczne skalowanie,
- wdrożenia mają odbywać się bez przestoju, z możliwością szybkiego wycofania.
Jest też droga pośrednia. Docker Engine ma wbudowany tryb Swarm, czyli prostszy klaster obsługiwany tym samym poleceniem docker. Z kolei Kubernetes można kupić jako usługę zarządzaną u dostawcy chmury, co zdejmuje z zespołu utrzymanie control plane.
Kubernetes ma swoją cenę: więcej elementów do skonfigurowania, monitorowania i aktualizowania. Dla małego projektu ten koszt bywa większy niż korzyść, dlatego rozsądna kolejność to najpierw kontenery, a klaster dopiero wtedy, gdy pojawia się problem, który on rozwiązuje.
Podsumowanie
Pytanie „Docker czy Kubernetes” rzadko jest wyborem jednego z dwóch. Docker jest punktem wyjścia, bo bez obrazu kontenera Kubernetes nie ma czego uruchamiać. O klastrze decyduje skala: liczba usług, wymagana dostępność i wahania ruchu.
Zastanawiasz się, czy Twoja aplikacja potrzebuje Kubernetes, czy wystarczy jej prostsza infrastruktura? Napisz do Midapt i umów bezpłatną konsultację.
FAQ
Docker to narzędzie do budowania obrazów i uruchamiania kontenerów, a Kubernetes to system, który zarządza kontenerami na wielu serwerach. Pierwszy pakuje aplikację, drugi odpowiada za jej wdrażanie, skalowanie i odporność na awarie.
Nie. Kubernetes nie buduje obrazów, tylko uruchamia gotowe. Obrazy nadal powstają najczęściej w Dockerze, a Kubernetes przejmuje je na etapie wdrożenia.
Tak. Pojedynczą aplikację albo kilka powiązanych kontenerów można uruchomić samym Dockerem i Docker Compose. Kubernetes staje się potrzebny dopiero przy wielu usługach, wielu serwerach lub wymaganiu wysokiej dostępności.
Formalnie nie, ale w praktyce bardzo to pomaga. Pojęcia obrazu, kontenera i rejestru są wspólne, więc nauka zwykle zaczyna się od Dockera.
Kubernetes. Podstawy Dockera to kilka poleceń i jeden plik, a Kubernetes wymaga zrozumienia klastra, sieci, uprawnień i sposobu opisywania stanu w manifestach.
Tak. Obrazy budowane Dockerem są zgodne ze standardem OCI, więc uruchamiają je środowiska używane przez Kubernetes, w tym containerd. Zmiana z wersji 1.24 dotyczyła administratorów klastrów, a nie sposobu budowania obrazów.
