Wyszukiwanie Docker vs Kubernetes sugeruje, że musisz wybrać jedno, ale to kadrowanie powoduje wiele zamieszania. To trochę tak, jakby porównywać kontener transportowy z portem, który organizuje ich tysiące. Działają na różnych poziomach i często są używane obok siebie.

Ten przewodnik wyjaśnia, co robi każdy z nich, pokazuje tę samą małą aplikację w obu i kończy się praktycznym sposobem podjęcia decyzji. Polecenia i pliki tutaj są standardowymi przykładami, których nie wykonaliśmy w tym artykule, więc porównaj je z wersjami, które instalujesz.

Krótka odpowiedź

Docker to platforma służąca do pakowania aplikacji i jej zależności w obraz, a następnie uruchamiania tego obrazu jako kontenera. Odpowiada na pytanie „jak sprawić, by ta aplikacja działała wszędzie tak samo?”

Kubernetes, często pisany jako K8, to orkiestrator kontenerów. Decyduje, gdzie kontenery działają na wielu maszynach, uruchamia je ponownie w przypadku awarii i skaluje je w zależności od zapotrzebowania. Odpowiada na pytanie: „Jak zapewnić niezawodne działanie setek kontenerów?”

Docker kontra Kubernetes obok siebie

Co robi Docker

Przed kontenerami „działa na moim komputerze” było codziennym problemem, ponieważ każdy serwer miał różne wersje wszystkiego. Docker łączy Twój kod, środowisko wykonawcze i biblioteki w jeden obraz. Działająca kopia tego obrazu to kontener, który współdzieli jądro hosta, dzięki czemu uruchamia się szybciej i zużywa mniej pamięci niż pełna maszyna wirtualna.

Przepływ pracy składa się z trzech etapów:

1. Kompilacja: a Dockerfile opisuje, jak utworzyć obraz.
2. Wysyłka: wypchnij obraz do rejestru, takiego jak Docker Hub.
3. Uruchom: uruchom kontenery z tego obrazu na dowolnej kompatybilnej maszynie.

Aby zdobyć praktyczną wiedzę, zacznij od naszego samouczka dotyczącego Dockera dla początkujących, a następnie przeczytaj nasze sprawdzone metody dotyczące pliku Dockerfile.

Co robi Kubernetes

Docker na jednym serwerze działa dobrze, dopóki ten serwer nie ulegnie awarii, ruch go nie przewyższy lub nie będziesz musiał koordynować dziesiątek usług. Kubernetes zajmuje się następującymi zadaniami operacyjnymi:

• Planowanie: umieszczanie kontenerów na maszynach z wystarczającą ilością wolnego miejsca.
• Samonaprawa: wymiana uszkodzonych kontenerów i przenoszenie pracy z uszkodzonych węzłów.
• Skalowanie: dodawanie lub usuwanie kopii ręcznie lub na podstawie wskaźników.
• Wykrywanie usług: nadawanie zmieniającej się grupie kontenerów jednej stabilnej nazwy.
• Aktualizacje ciągłe: stopniowe wydawanie nowych wersji z prostym wycofywaniem.
• Konfiguracja: zarządzanie ustawieniami i sekretami niezależnie od obrazów.

Podstawową ideą jest stan pożądany. Deklarujesz, że powinny istnieć trzy kopie, a kontrolerzy na bieżąco porównują to z rzeczywistością i korygują wszelkie różnice. Nasz samouczek Kubernetes dla początkujących omawia tę kwestię w klastrze lokalnym.

Jak Docker i Kubernetes współpracują ze sobą

Typowa droga od laptopa programisty do produkcji wygląda następująco:

1. Programista zapisuje Dockerfile i testuje kontener lokalnie.
2. Potok CI/CD buduje obraz i uruchamia testy.
3. Potok wypycha wersjonowany obraz do rejestru.
4. Manifest Kubernetes został zaktualizowany w celu użycia tej wersji obrazu.
5. Kubernetes pobiera obraz i wdraża go w klastrze.

Zatem praca Dockera jest w dużej mierze zakończona przed uruchomieniem Kubernetesa. Obraz jest punktem przekazania pomiędzy nimi.

Jedna aplikacja, w obie strony

Oto mały serwis internetowy. Obraz jest zbudowany w ten sam sposób, niezależnie od tego, które narzędzie go uruchamia:

# Dockerfile
FROM python:3.13-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

Uruchamianie go za pomocą Dockera

docker build -t shop-api:1.0 .
docker run -d --name shop -p 8080:8000 --restart unless-stopped shop-api:1.0

Dwie komendy i działa. Jest to proste i odpowiednie dla wielu małych projektów. Ale na jednej maszynie znajduje się jedna kopia, a jeśli maszyna umrze, usługa idzie z nią.

Uruchamianie go za pomocą Kubernetesa

# shop.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop
spec:
  replicas: 3
  selector:
    matchLabels:
      app: shop
  template:
    metadata:
      labels:
        app: shop
    spec:
      containers:
        - name: api
          image: registry.example.com/shop-api:1.0
          ports:
            - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
  ports:
    - port: 80
      targetPort: 8000

kubectl apply -f shop.yaml
kubectl get pods -l app=shop

Jest o wiele więcej do napisania i potrzebujesz klastra, aby to uruchomić. W zamian otrzymujesz trzy kopie, stabilny adres wewnętrzny i automatyczną wymianę. Ten kompromis to cała decyzja w miniaturze: większa złożoność w zamian za większą odporność.

Co się stanie, jeśli kontener ulegnie awarii?

Zamieszanie z dockershimem

Być może czytałeś, że „Kubernetes porzucił Dockera”. Jest to prawdą w wąskim znaczeniu i niepotrzebnie przestraszyło wiele osób. Kubernetes obsługuje kontenery za pośrednictwem standardu zwanego interfejsem wykonawczym kontenera. Docker Engine nie zaimplementował tego bezpośrednio, więc Kubernetes dołączył adapter o nazwie dockershim. Adapter ten został usunięty w wersji 1.24.

Klastry obecnie zazwyczaj korzystają ze środowisk wykonawczych, takich jak Containerd lub CRI-O. Obrazy tworzone za pomocą Dockera nadal działają, ponieważ są zgodne ze standardem obrazu Open Container Initiative (OCI). Możesz więc dalej budować za pomocą platformy Docker, a klaster uruchomi wynik w innym środowisku wykonawczym.

Docker Compose, Swarm i Kubernetes

Bardziej znaczące porównanie dotyczy narzędzi koordynujących kontenery:

Docker Compose uruchamia kilka powiązanych kontenerów z jednego pliku i doskonale sprawdza się w przypadku aplikacji internetowej i bazy danych na laptopie. Swarm jest wbudowany w Dockera i jest znacznie łatwiejszy do nauczenia niż Kubernetes, ale ma znacznie mniejszy ekosystem. Kubernetes ma największą społeczność i narzędzia, co w dużej mierze wyjaśnia, dlaczego stał się rozwiązaniem domyślnym w przypadku dużych wdrożeń.

Które potrzebujesz?

Sam Docker zwykle wystarcza, gdy:

• Tworzysz lokalnie lub uruchamiasz małą aplikację na jednym serwerze.
• Masz mały zespół i brak dedykowanego personelu operacyjnego.
• Dopuszczalne są sporadyczne krótkie przestoje.

Kubernetes zaczyna mieć sens, gdy:

• Prowadzisz wiele usług, które różne zespoły wdrażają samodzielnie.
• Potrzebujesz wysokiej dostępności na kilku maszynach lub strefach.
• Ruch jest na tyle zróżnicowany, że automatyczne skalowanie pozwala zaoszczędzić realne pieniądze.
• Masz umiejętności lub budżet, aby go obsługiwać.

Istnieje również złoty środek. Zarządzane platformy kontenerowe, takie jak AWS Fargate, Google Cloud Run lub PaaS, uruchamiają obraz Dockera bez konieczności utrzymywania klastra. Dla wielu rozwijających się firm jest to właściwy następny krok, zamiast od razu przejść do Kubernetes.

Jeśli chcesz nauczyć się obu ze względów zawodowych, kolejność jest jasna: najpierw Docker, potem Kubernetes. Nie można wygodnie debugować Poda bez uprzedniego zrozumienia obrazów, portów i dzienników kontenerów.

Typowe błędy

• Zbyt wczesne przyjęcie Kubernetesa. Kopiowanie architektury gigantycznej firmy może pogrzebać mały zespół w pracy operacyjnej.
• Używanie tagu latest w środowisku produkcyjnym. Nie można stwierdzić, co działa, ani niezawodnie wycofać. Użyj określonych tagów wersji.
• Przechowywanie danych w kontenerach. Kontenery są jednorazowe, dlatego używaj woluminów lub zarządzanej bazy danych.
• Pomijanie kontroli stanu. Bez sond gotowości i żywotności Kubernetes nie może podejmować dobrych decyzji dotyczących Twojej aplikacji.
• Zapominanie o limitach zasobów. Jeden zachłanny kontener może zagłuszyć wszystko inne w węźle.

Podsumowanie

Docker pakuje Twoje oprogramowanie, a Kubernetes obsługuje je na dużą skalę. Zamiast pytać, co jest lepsze, zapytaj, jaki masz dzisiaj problem. Jeśli jest to „trudno zainstalować moją aplikację”, użyj Dockera. Jeśli jest to „moich 40 usług potrzebnych do przetrwania awarii serwera”, spójrz na Kubernetes. Zacznij od najprostszego narzędzia, które rozwiąże Twój rzeczywisty problem i przejdź dalej, gdy zobaczysz potrzebę.

Najczęstsze pytania

Ucz się dalej