Kubernetes vs Docker – różnice, odpowiedniki poleceń i co kiedy wybrać

„Kubernetes vs Docker” to jedno z najczęściej mylących zestawień w świecie kontenerów, bo te narzędzia nie są konkurentami. Docker służy do budowania obrazów i uruchamiania kontenerów, zwykle na jednym serwerze. Kubernetes to orkiestrator — zarządza wieloma kontenerami na wielu serwerach: rozmieszcza je, skaluje, restartuje po awarii i kieruje do nich ruch. Działają na różnych warstwach i najczęściej współpracują.

Sensowne porównanie wygląda inaczej: Docker z Compose kontra Kubernetes pod kątem tego, kiedy który jest potrzebny, albo Docker Swarm kontra Kubernetes jako dwa orkiestratory. Poniżej wyjaśniam te różnice, pokazuję odpowiedniki pojęć i poleceń, rozwiewam mit, że Kubernetes „porzucił Dockera”, i podpowiadam, co wybrać. Jeśli chcesz najpierw utrwalić podstawy kontenerów, zajrzyj do 15 pytań rekrutacyjnych o Dockera.

Czym naprawdę jest Docker

Docker to platforma do pracy z kontenerami. W praktyce obejmuje kilka elementów:

• budowanie obrazów na podstawie pliku Dockerfile,
• uruchamianie kontenerów z tych obrazów,
• rejestr obrazów (Docker Hub lub własny), do którego wypychasz obrazy i z którego je pobierasz,
• sieci i woluminy na poziomie jednego hosta.

Kontener to wyizolowany proces, który korzysta z jądra systemu gospodarza, ale ma własny system plików, sieć i zależności. W odróżnieniu od maszyny wirtualnej nie emuluje całego systemu, dlatego startuje w sekundy i zajmuje mniej zasobów. Typowe polecenia:

docker build -t moja-aplikacja:1.0 .
docker run -d -p 8080:80 moja-aplikacja:1.0
docker ps

Docker świetnie sprawdza się przy budowaniu obrazów, pracy lokalnej i uruchamianiu aplikacji na pojedynczym serwerze. Jego ograniczenie zaczyna się tam, gdzie kontenerów i serwerów jest wiele — sam Docker nie rozłoży obciążenia na pięć maszyn ani nie przeniesie kontenerów z węzła, który uległ awarii.

Docker Compose: wiele kontenerów na jednym hoście

Gdy aplikacja składa się z kilku kontenerów (np. aplikacja, baza danych, cache), opisujesz je w jednym pliku compose.yaml i uruchamiasz razem:

services:
  web:
    build: .
    ports:
      - "8080:80"
    depends_on:
      - db
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: tajne
    volumes:
      - dane:/var/lib/postgresql/data
volumes:
  dane:

docker compose up -d
docker compose up -d --scale web=3   # trzy kopie usługi web na tym samym hoście

Compose to wciąż jeden host. To właśnie jego, a nie „gołego” Dockera, warto porównywać z Kubernetesem w kontekście wielu kontenerów.

Ważne: Docker Engine na Linuksie jest darmowy, ale Docker Desktop (Windows, macOS) w firmach wymaga płatnej subskrypcji, chyba że organizacja ma mniej niż 250 pracowników i mniej niż 10 mln USD rocznego przychodu. Darmowy pozostaje dla osób prywatnych, edukacji i niekomercyjnych projektów open source.

Czym jest Kubernetes

Kubernetes (K8s) to system orkiestracji kontenerów rozwijany pod egidą Cloud Native Computing Foundation. Zarządza klastrem serwerów (węzłów) i dba o to, żeby zadeklarowany stan aplikacji był zawsze utrzymany.

Kluczowa różnica filozoficzna: Kubernetes jest deklaratywny. Nie mówisz „uruchom kontener”, tylko opisujesz pożądany stan („chcę 3 kopie tej aplikacji”), a Kubernetes sam go osiąga i utrzymuje. Jeśli jedna kopia padnie, uruchomi nową; jeśli węzeł ulegnie awarii, przeniesie obciążenie na pozostałe.

Podstawowe pojęcia:

• Pod — najmniejsza jednostka, jeden lub kilka ściśle powiązanych kontenerów,
• Deployment — deklaracja, ile kopii (replik) poda ma działać i jak je aktualizować,
• Service — stały adres i równoważenie ruchu do podów,
• Ingress lub Gateway — wystawienie usług HTTP na zewnątrz klastra,
• węzeł (node) — serwer w klastrze, na którym działają pody.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: moja-aplikacja
spec:
  replicas: 3
  selector:
    matchLabels:
      app: moja-aplikacja
  template:
    metadata:
      labels:
        app: moja-aplikacja
    spec:
      containers:
        - name: web
          image: rejestr.example.com/moja-aplikacja:1.0
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet:
              path: /health
              port: 80

kubectl apply -f deployment.yaml
kubectl get pods

Za tę moc płaci się złożonością: sieć, pamięć masowa, certyfikaty, uprawnienia (RBAC), monitoring i aktualizacje samego klastra wymagają wiedzy i czasu. Dlatego wiele firm korzysta z zarządzanego Kubernetesa u dostawców chmury lub z platform zbudowanych na nim, jak OpenShift.

Jak Docker i Kubernetes współpracują w praktyce

W typowym projekcie oba narzędzia działają w jednym łańcuchu. Docker odpowiada za to, co dzieje się przed wdrożeniem, Kubernetes — za to, co po nim:

1. Programista opisuje środowisko w Dockerfile i testuje aplikację lokalnie przez Docker Compose.
2. Pipeline CI buduje obraz i wypycha go do rejestru: docker build i docker push.
3. Manifest Kubernetesa (lub chart Helm) wskazuje nowy tag obrazu.
4. Kubernetes stopniowo wymienia pody na nową wersję (rolling update), sprawdzając sondy gotowości.
5. Gdy coś pójdzie nie tak, wracasz do poprzedniej wersji jednym poleceniem.

docker build -t rejestr.example.com/moja-aplikacja:1.1 .
docker push rejestr.example.com/moja-aplikacja:1.1

kubectl set image deployment/moja-aplikacja web=rejestr.example.com/moja-aplikacja:1.1
kubectl rollout status deployment/moja-aplikacja
kubectl rollout undo deployment/moja-aplikacja   # powrót do poprzedniej wersji

Różnicę między samym wdrożeniem a udostępnieniem nowej wersji użytkownikom dobrze wyjaśnia tekst Deploy a release — różnice.

Mit: „Kubernetes porzucił Dockera”

W 2020 roku ogłoszono, że Kubernetes usuwa dockershim — warstwę pośredniczącą, dzięki której używał demona Dockera jako silnika uruchomieniowego. Stało się to w wersji 1.24 (2022). Co to oznacza:

• Kubernetes uruchamia kontenery przez interfejs CRI (Container Runtime Interface), najczęściej z silnikiem containerd (który jest zresztą częścią samego Dockera) lub CRI-O.
• Obrazy zbudowane Dockerem działają w Kubernetesie bez zmian, bo są zgodne ze standardem OCI (Open Container Initiative).
• Dla większości zespołów zmiana była niewidoczna — nadal buduje się obrazy Dockerem i wdraża je w Kubernetesie.

Kubernetes nie porzucił więc formatu obrazów ani kontenerów, zrezygnował tylko ze zbędnej warstwy integracji z demonem Dockera na węzłach. Z tego samego powodu Docker nie jest jedyną opcją do budowania obrazów — alternatywą jest np. Podman, który obsługuje te same obrazy OCI.

Kubernetes vs Docker (Compose) – porównanie

Odpowiedniki: Compose i polecenia Dockera w Kubernetesie

Jeśli znasz Compose, najszybciej zrozumiesz Kubernetesa, mapując znane pojęcia na nowe obiekty:

Brak depends_on to częste zaskoczenie: Kubernetes zakłada, że usługi startują niezależnie i aplikacja ma umieć poczekać na bazę danych. Do automatycznego skalowania służy np. kubectl autoscale deployment web --cpu-percent=70 --min=2 --max=10, przy czym wymaga to działającego w klastrze metrics-server.

Gotowy plik Compose przekonwertujesz na manifesty narzędziem kompose (kompose convert), które utworzy pliki Deployment i Service dla każdej usługi. Traktuj wynik jako szkic — sondy zdrowia, limity zasobów, sekrety i trwałe woluminy trzeba zwykle dopracować ręcznie.

Docker Swarm vs Kubernetes – gdy naprawdę porównujemy orkiestratory

Jeśli chcesz zestawić Dockera z Kubernetesem jako orkiestratory, właściwym kandydatem jest Docker Swarm — tryb klastra wbudowany w Dockera.

• Docker Swarm jest prosty: ten sam format Compose, polecenie docker swarm init, potem docker stack deploy i masz klaster. Ma jednak mniej funkcji i mniejszy ekosystem. Mirantis, który przejął biznes Docker Enterprise, zapowiedział wsparcie Swarma w swojej platformie co najmniej do 2030 roku.
• Kubernetes jest znacznie bardziej rozbudowany i stał się branżowym standardem, z ogromnym ekosystemem narzędzi (Helm, operatory, service mesh) i usługami zarządzanymi u wszystkich dużych dostawców chmury.

W nowych projektach, które mają rosnąć, wybiera się zwykle Kubernetesa. Swarm bywa sensowny tam, gdzie zespół jest mały, a potrzeby proste. Jeśli automatyzujesz konfigurację samych serwerów pod klaster, przyda się też Ansible.

Uwaga: Kontroler Ingress NGINX (projekt ingress-nginx) zakończył życie w marcu 2026 r. — nie dostaje już poprawek, także bezpieczeństwa. Sam obiekt Ingress w Kubernetesie zostaje, ale w nowych klastrach wybierz inny kontroler albo od razu Gateway API, rekomendowane przez projekt Kubernetes jako następca.

Jak zacząć z Kubernetesem lokalnie

Nie stawiaj od razu klastra produkcyjnego. Do nauki wystarczy jeden komputer:

• Docker Desktop — w panelu wybierasz widok Kubernetes i Create cluster. Do wyboru jest starszy provisioner kubeadm (jeden węzeł) albo kind, który pozwala utworzyć klaster wielowęzłowy i wybrać wersję Kubernetesa.
• kind — klaster w kontenerach Dockera, tworzony poleceniem kind create cluster. Popularny w testach CI.
• minikube — minikube start tworzy lokalny klaster z dodatkami, np. dashboardem.
• k3s — lekka, certyfikowana dystrybucja Kubernetesa, dobra do homelabu, małych serwerów i urządzeń brzegowych.

Na produkcji rozważ zarządzanego Kubernetesa u dostawcy chmury — przejmie on utrzymanie warstwy sterującej (control plane). Jeśli klaster ma stanąć na własnym sprzęcie, najpierw wybierz platformę wirtualizacji; pomoże porównanie Proxmox vs VMware ESXi.

Co wybrać do swojego projektu

Nie zaczynaj od pytania „Docker czy Kubernetes”, bo Dockera (lub innego narzędzia do budowania obrazów) i tak będziesz używać. Pytanie brzmi: czy potrzebujesz orkiestracji.

Wystarczy Docker z Compose, gdy:

• uczysz się kontenerów lub budujesz środowisko programistyczne,
• aplikacja działa na jednym serwerze i krótki przestój przy restarcie jest akceptowalny,
• masz kilka usług bez wymogu automatycznego skalowania,
• zespół jest mały i nie ma nikogo do utrzymywania klastra.

Rozważ Kubernetesa, gdy:

• aplikacja składa się z wielu usług (mikrousług) i rośnie,
• potrzebujesz wysokiej dostępności na kilku serwerach i automatycznej samonaprawy,
• ruch jest zmienny i chcesz automatycznego skalowania,
• wdrażasz często i zależy Ci na aktualizacjach bez przestoju oraz łatwym rollbacku.

Rozsądna ścieżka dla większości zespołów: Docker i Compose od pierwszego dnia, a Kubernetes (najlepiej zarządzany) dopiero wtedy, gdy liczba usług, wymóg dostępności i skala naprawdę tego potrzebują. Jeśli obrazy są dobrze zbudowane, a konfiguracja trzymana w zmiennych środowiskowych, migracja z Compose do Kubernetesa nie wymaga przepisywania aplikacji.