Kubernetes a Docker – na czym polega różnica?

Wirtualizacja sprzętowa zapewnia szereg korzyści, takich jak skalowalność, bezpieczeństwo, izolacja itp., dzięki wykorzystaniu hiperwizorów do współdzielenia sprzętu fizycznego przez maszyny wirtualne (VM). Obecnie maszyny wirtualne nie są jedyną formą wirtualizacji, ponieważ dużą popularność zyskały również kontenery. Podczas gdy maszyny wirtualne współdzielą sprzęt fizyczny maszyn bazowych, kontenery współdzielą jądro bazowego systemu operacyjnego. Kontenery nie są lekkimi maszynami wirtualnymi, ale znormalizowanymi pakietami wykonywalnymi używanymi do dostarczania aplikacji, w tym aplikacji opracowanych przy użyciu architektury oprogramowania opartej na mikrousługach, i zawierają wszystkie komponenty niezbędne do uruchamiania aplikacji.

Silnik Docker jest najpopularniejszą platformą do uruchamiania kontenerów. Kubernetes to termin, o którym coraz częściej słyszy się w sferze konteneryzacji i przetwarzania w chmurze. Ale co jest lepsze – Docker czy Kubernetes? Jest to popularny temat debat, ale sformułowanie tego pytania w ten sposób nie jest technicznie poprawne. Na przykład nie można zapytać: „Co jest lepsze – gorące czy niebieskie?”.

Czym jest Docker?

Docker to samodzielna aplikacja typu open source, która działa jako silnik służący do uruchamiania aplikacji w kontenerach. Instaluje się ją w systemie operacyjnym (OS), najlepiej na Linux, ale można ją również zainstalować w systemie Windows oraz macOS, który z kolei działa na maszynie fizycznej lub wirtualnej.

Aplikacja działająca w kontenerze jest odizolowana od reszty systemu i od innych kontenerów, ale sprawia wrażenie, jakby działała we własnej instancji systemu operacyjnego. W jednym systemie operacyjnym można jednocześnie uruchamiać wiele kontenerów Docker; kontenerami tymi można zarządzać za pomocą Docker, a Docker może działać bez Kubernetes. Jeśli masz wiele hostów do uruchamiania kontenerów, ręczne zarządzanie nimi może być trudne i zazwyczaj lepiej jest wybrać scentralizowane narzędzie do zarządzania lub rozwiązanie do orkiestracji.

Docker Compose to podstawowe narzędzie do orkiestracji kontenerów, używane do uruchamiania aplikacji Docker z wieloma kontenerami. Można skonfigurować jeden plik konfiguracyjny YAML (yml) Docker Compose, aby zdefiniować aplikacje wielokontainerowe zamiast ręcznie konfigurować oddzielne pliki Dockerfile dla każdego kontenera. Po skonfigurowaniu pojedynczego pliku YAML można uruchomić wszystkie potrzebne kontenery za pomocą jednego polecenia w konsoli systemu Linux. Korzystanie z Docker Compose to jeden ze sposobów orkiestracji kontenerów Docker, ale istnieje potężna alternatywa dla Docker Compose, zwana Kubernetes.

Czym jest Kubernetes?

Kubernetes to oparte na otwartym oprogramowaniu rozwiązanie do orkiestracji kontenerów, służące do zarządzania oprogramowaniem i usługami w kontenerach z wysokim stopniem automatyzacji.

Kubernetes to projekt firmy Google, którego celem jest automatyzacja wdrażania, skalowania i zapewnienia dostępności aplikacji działających w kontenerach. Możesz zwiększyć liczbę hostów uruchamiających kontenery do 11 lub więcej. Ponadto możesz utworzyć klaster kontenerów Docker przy użyciu Kubernetes, aby zapewnić wysoką dostępność i równoważenie obciążenia.

Hosty używane w klastrze nazywane są węzłami. Architektura Kubernetes opiera się na modelu master-slave — klaster składa się z węzłów głównych i roboczych. Minimalna zalecana liczba węzłów wymagana przez Kubernetes to cztery. Chociaż można zbudować klaster z jednej maszyny, do uruchomienia wszystkich przykładów i testów potrzebne są co najmniej cztery węzły. Klaster Kubernetes obsługujący ruch produkcyjny powinien mieć co najmniej trzy węzły robocze. Użycie dwóch węzłów głównych chroni klaster przed awarią jednego z nich. W razie potrzeby można użyć więcej niż dwóch węzłów głównych.

• Master nodes służą do zarządzania stanem klastra, co obejmuje przyjmowanie żądań klientów, planowanie operacji z kontenerami, uruchamianie pętli sterowania itp. Kopia etcd bazy danych przechowującej wszystkie dane klastra musi być uruchomiona na każdym węźle głównym. Węzeł główny uruchamia zestaw trzech procesów: kube-apiserver , kube-controller-manager oraz kube-scheduler .
• Working nodes służą do wykonywania obciążeń aplikacji poprzez uruchamianie kontenerów. Dwa procesy Kubernetes działają na węźle innym niż główny: kubelet (do komunikacji z węzłami głównymi) oraz kube-proxy (do odzwierciedlania usług sieciowych Kubernetes na każdym węźle).
• Replication Controller to komponent służący do zapewnienia, że repliki podów, których liczba jest określona, zawsze działają w danym momencie. Dzięki temu można mieć pewność, że pody są zawsze dostępne, gdy są potrzebne. W przypadku korzystania z Kubernetes do komunikacji między usługami wykorzystywane są różne interfejsy CLI i API. Istnieją również specyficzne terminy używane do nazywania obiektów i zasobów RESTful API, które są komponentami klastra zbudowanego przy użyciu Kubernetes.
• Pod jest podstawową jednostką planowania w Kubernetes. Jest to grupa zasobów, w której może działać wiele kontenerów. Kontenery należące do jednego poda mogą działać na tym samym hoście oraz korzystać z tych samych zasobów i tej samej sieci lokalnej. Kontenery w podzie są odizolowane, ale mogą dość łatwo komunikować się między sobą. Dlatego pody są powszechnie stosowane w Kubernetes, ale w przypadku korzystania z samodzielnej aplikacji Docker dostępne są jedynie pule kontenerów.
• Service to zbiór kontenerów, które współpracują ze sobą, zapewniając na przykład działanie aplikacji wielowarstwowej. Kubernetes obsługuje dynamiczne nazewnictwo i równoważenie obciążenia podów poprzez wykorzystanie abstrakcji. Takie podejście zapewnia przejrzyste połączenie między usługami na podstawie nazwy i pozwala śledzić ich aktualny stan.
• Labels to pary klucz-wartość powiązane z podami oraz innymi obiektami lub usługami, które dodatkowo umożliwiają łatwe grupowanie i przypisywanie zadań.
• Namespaces to metoda pozwalająca na logiczny podział zjednoczonego klastra Kubernetes na wiele klastrów wirtualnych. Każdy wirtualny klaster może istnieć w środowisku wirtualnym ograniczonym limitami bez wpływu na inne wirtualne klastry.

Kubernetes może być używany z Dockerem, choć Docker nie jest jedyną platformą kontenerową, z którą można korzystać z Kubernetes. Kubernetes może również współpracować z kontenerami Windows, kontenerami Linux, rkt itp. K8s to nazwa Kubernetes, którą czasami można znaleźć w dokumentacji technicznej.

Kubernetes vs Docker: Porównanie sieci

Przyjrzyjmy się opcjom sieciowym dla każdego rozwiązania.

Docker udostępnia trzy tryby sieciowe do komunikacji między kontenerami.

Bridge. Ten tryb jest używany domyślnie, tworząc wirtualny most warstwy 3. Nazwa sieci na hoście to docker0 dla tej sieci. Docker automatycznie tworzy most sieciowy warstwy 3 i konfiguruje reguły maskowania dla zewnętrznego interfejsu sieciowego, wykorzystując zasadę translacji adresów sieciowych (NAT), co pozwala kontenerom komunikować się ze sobą i łączyć się z sieciami zewnętrznymi. Możesz skonfigurować przekierowanie portów dla interfejsu sieciowego komputera hosta, jeśli chcesz połączyć się z kontenerem z innych hostów i sieci zewnętrznych. W ten sposób, łącząc się z odpowiednim portem komputera hosta, zostaniesz przekierowany do odpowiedniego portu kontenera Docker. W razie potrzeby możesz utworzyć więcej niż jeden interfejs sieciowy dla kontenera Docker.

Host. W tym trybie sterownik sieci hosta zapewnia, że kontener nie jest odizolowany od hosta Docker. Kontener korzysta ze stosu sieciowego hosta, a jego nazwa jest taka sama jak nazwa systemu operacyjnego hosta. Jeśli uruchomisz kontener nasłuchujący na porcie TCP 8080, aplikacja w kontenerze będzie dostępna pod adresem IP maszyny hosta na porcie TCP 8080. Sterownik sieciowy hosta jest dostępny tylko dla maszyn z systemem Linux.

None. Dla interfejsu sieciowego danego kontenera nie są skonfigurowane żadne adresy IP, z wyjątkiem adresu 127.0.0.1 dla interfejsu pętli zwrotnej. Nie ma dostępu do sieci zewnętrznych, jeśli ustawiony jest tryb sieciowy None .

Multi-host networking for Docker containers. Jeśli kontenery działają na różnych hostach, mogą się ze sobą komunikować po skonfigurowaniu sieci nakładkowej. Aby utworzyć takie sieci, należy skonfigurować poprawną usługę magazynu kluczy-wartości ( Consul , Etcd lub ZooKeeper ).

Kubernetes. Jeśli używasz samodzielnych kontenerów Docker, każdy kontener można traktować jako podstawową jednostkę, która komunikuje się przez sieć za pomocą odpowiedniego interfejsu sieciowego. Jeśli korzystasz z Kubernetes, podstawowymi jednostkami klastra kontenerów są pody. Każdy pod ma swój własny adres IP i składa się z co najmniej jednego kontenera. Pod może składać się z wielu kontenerów, które są wykorzystywane do powiązanych zadań. Kontenery tego samego poda nie mogą otwierać tego samego portu jednocześnie. Tego typu ograniczenie jest stosowane, ponieważ pod składający się z wielu kontenerów nadal ma jeden adres IP.

Ponadto Kubernetes tworzy specjalny kontener pauzujący dla każdego poda. Ten specjalny kontener ma na celu zapewnienie interfejsu sieciowego (do komunikacji wewnętrznej i zewnętrznej) dla innych kontenerów i zazwyczaj jest w stanie pauzy (w trybie uśpienia). Te kontenery pauzujące budzą się, gdy Kubernetes wysyła sygnał „SIGTERM”.

Flannel jest zazwyczaj używany jako struktura sieciowa do łączenia kontenerów w Kubernetes przy użyciu zasad nakładania sieci. Sieć nakładkowa pozwala na uruchamianie kontenerów poprzez komunikację za pośrednictwem sieci logicznej między różnymi fizycznymi hostami klastra (określanymi jako węzły). Otwarty magazyn kluczy/wartości etcd służy do zapisywania mapowań między rzeczywistymi adresami IP przypisanymi do kontenerów przez hosty, na których kontenery są uruchomione, a adresami IP w sieci nakładkowej.

Sieć Kubernetes może zostać zintegrowana z VMware NSX-T przy użyciu wtyczki NSX Container Plugin. Ta integracja umożliwia korzystanie z topologii sieci wielodostępnej, która nie jest dostępna w standardowej konfiguracji Kubernetes.

Model sieciowy Kubernetes zapewnia następujące funkcje:

• Wszystkie kontenery mogą komunikować się z dowolnymi innymi kontenerami w klastrze bez konieczności stosowania NAT.
• Wszystkie węzły klastra mogą komunikować się ze wszystkimi kontenerami w klastrze bez konieczności stosowania NAT. I odwrotnie, wszystkie kontenery mogą komunikować się ze wszystkimi węzłami klastra.
• Kontenery widzą swoje własne adresy IP, a adresy te są widoczne dla innych komponentów Kubernetes.

Ingress to obiekt API Kubernetes, który służy do zarządzania dostępem do usług w klastrze z zewnątrz (głównie HTTP i HTTPS). Można skonfigurować Ingress do obsługi dostępu zewnętrznego do usług kontenerowych w celu równoważenia obciążenia, terminacji SSL oraz wirtualnego hostingu opartego na nazwach. Aby reguły Ingress działały, na węźle głównym musi zostać wdrożony kontroler Ingress.

Przypadki użycia

Wykorzystanie Docker jako samodzielnego oprogramowania jest przydatne przy tworzeniu aplikacji, ponieważ programiści mogą uruchamiać swoje aplikacje w izolowanych środowiskach. Co więcej, testerzy mogą również używać Docker do uruchamiania aplikacji w środowiskach sandbox. Jeśli chcesz używać Docker do uruchamiania dużej liczby kontenerów w środowisku produkcyjnym, możesz napotkać pewne komplikacje. Na przykład niektóre kontenery mogą łatwo ulec przeciążeniu lub awarii. Możesz ręcznie zrestartować kontener na odpowiedniej maszynie, ale ręczne zarządzanie może pochłonąć dużo Twojego cennego czasu i energii.

Kubernetes pozwala rozwiązać te problemy, zapewniając kluczowe funkcje, takie jak wysoka dostępność, równoważenie obciążenia, narzędzia do orkestracji kontenerów itp. W rezultacie Kubernetes najlepiej nadaje się do środowisk produkcyjnych o dużym obciążeniu, w których znajduje się duża liczba kontenerów Docker. Wdrażanie Kubernetes jest trudniejsze niż instalacja samodzielnej aplikacji Docker, dlatego Kubernetes nie zawsze może być używany do rozwoju i testowania.

Kubernetes a Docker Swarm

Docker Swarm to natywne narzędzie do klastrowania dla Docker, które może przekształcić pulę hostów Docker w jeden wirtualny host. Docker Swarm jest w pełni zintegrowany z silnikiem Docker Engine i pozwala na korzystanie ze standardowych interfejsów API oraz procesów sieciowych; jest przeznaczony do wdrażania, zarządzania i skalowania kontenerów Docker.

Swarm to klaster hostów Docker, które nazywane są węzłami. Zanim porównamy wdrażanie klastra w Docker Swarm z rozwiązaniami Kubernetes i Docker Swarm, przyjrzyjmy się następującym głównym komponentom klastra:

Manager nodes służą do orkiestracji kontroli, zarządzania klastrem oraz dystrybucji zadań.

Worker nodes służą do uruchamiania kontenerów, którym zadania przydzielają węzły menedżerskie. Każdy węzeł można skonfigurować jako węzeł menedżerski, węzeł roboczy lub jako oba typy, tak aby pełnił funkcje zarówno węzła menedżerskiego, jak i roboczego. Należy pamiętać, że węzły typu Worker uruchamiają usługi Swarm.

Services. Usługa Docker Swarm definiuje wymagany optymalny stan dla każdej usługi kontenerowej. Usługa kontroluje takie parametry, jak liczba replik, dostępne dla niej zasoby sieciowe, porty, które muszą być dostępne z sieci zewnętrznych itp. Konfigurację usługi, taką jak konfiguracja sieciowa, można modyfikować i stosować do kontenera bez konieczności ręcznego restartowania usługi wraz z kontenerem.

Tasks. Zadanie to miejsce, w którym działa pojedynczy kontener. Zadania są częściami usługi Swarm.

Tak więc Docker Swarm i Kubernetes to dwie różne platformy używane do podobnych celów. Czas porównać je w odpowiednich kategoriach.

Wdrażanie klastra

Docker Swarm. Standardowy interfejs API Docker pozwala wdrożyć klaster za pomocą Swarm, korzystając ze standardowego interfejsu CLI (interfejs wiersza poleceń) Docker, co ułatwia wdrażanie, zwłaszcza przy pierwszym użyciu. Łatwość wdrażania w Swarm w porównaniu z Kubernetes wynika również z możliwości decydowania o rozdzielaniu usług przez pojedynczy serwer główny Docker. W Docker Swarm nie są używane żadne pody.

Kubernetes wymaga użycia określonych poleceń, które różnią się od standardowych poleceń Docker. W Kubernetes używane są określone interfejsy API, co oznacza, że nawet jeśli znasz polecenia do zarządzania Dockerem, może być konieczne nauczenie się korzystania z dodatkowego zestawu narzędzi do procesu wdrażania Kubernetes. W klastrze Kubernetes węzły muszą być definiowane ręcznie – należy wybrać węzeł główny, zdefiniować kontroler, harmonogram itp.

Skalowalność

Docker Swarm. Dzięki prostemu API dostarczanemu przez Docker wdrażanie kontenerów i aktualizacja usług w dużych i małych klastrach może odbywać się szybciej. Interfejs wiersza poleceń (CLI) jest dość prosty i łatwy do zrozumienia. W rezultacie Swarm można uznać za rozwiązanie bardziej skalowalne w porównaniu z Kubernetes. Kubernetes oferuje stosunkowo ujednolicone interfejsy API oraz szereg funkcji, które często powodują spowolnienie procesu wdrażania. Istnieją trzy rodzaje komponentów, które należy skonfigurować: Pod, Deploy i Service. Jeśli chodzi o automatyczne skalowanie, Kubernetes jest preferowanym rozwiązaniem ze względu na możliwość analizowania obciążenia serwerów, a także zapewnienie automatycznego skalowania w górę i w dół zgodnie z określonymi wymaganiami. Kubernetes stanowi optymalny wybór dla dużych sieci rozproszonych i złożonych systemów.

Wysoka dostępność

Oba warianty rozwiązania posiadają podobne mechanizmy replikacji usług i nadmiarowości, a w obu przypadkach system jest samoregulujący się i nie wymaga ręcznej rekonfiguracji po ponownym włączeniu się uszkodzonego węzła do klastra.

Docker Swarm. Węzły menedżerskie zarządzają zasobami węzłów roboczych oraz całym klastrem. Węzły klastra Swarm uczestniczą w replikacji usług.

Kubernetes. Węzły w złym stanie są wykrywane przez usługi równoważenia obciążenia Kubernetes i eliminowane z klastra. Wszystkie pody są rozdzielane między węzłami, co zapewnia wysoką dostępność w przypadku awarii węzła, na którym działa aplikacja w kontenerze.

Równoważenie obciążenia

Docker Swarm. Równoważenie obciążenia jest wbudowaną funkcją i może być wykonywane automatycznie przy użyciu wewnętrznej sieci Swarm. Wszystkie żądania kierowane do klastra są rozdzielane i przekierowywane do węzłów klastra; każdy węzeł może połączyć się z dowolnym kontenerem. Docker Swarm wykorzystuje element DNS do rozdzielania przychodzących żądań do nazw usług.

Kubernetes. Zasady zdefiniowane w podach są wykorzystywane do równoważenia obciążenia w Kubernetes. W tym przypadku pody kontenerowe muszą być zdefiniowane jako usługi. Ustawienia równoważenia obciążenia należy skonfigurować ręcznie, natomiast do tego celu można wykorzystać Ingress.

Tworzenie i uruchamianie kontenerów

Docker Swarm. Dzięki znormalizowanemu API Docker Swarm podczas korzystania z Docker Swarm można używać zdecydowanej większości poleceń dostępnych dla interfejsu CLI Docker. Docker Compose definiuje pracę z woluminami i używanymi sieciami, a także określa, które kontenery muszą być zgrupowane razem. Dokładną liczbę replik można ustawić za pomocą Docker Compose dla Docker Swarm.

Kubernetes. Kubernetes ma własny interfejs API, klienta i wymaga plików YAML do konfiguracji. Jest to jedna z kluczowych różnic, ponieważ w tym przypadku nie można używać Docker Compose i Docker CLI do wdrażania kontenerów. W Kubernetes system definiowania usług działa na podobnej zasadzie jak w Docker Compose, ale jest bardziej złożony. Funkcja Docker Compose realizowana jest w Kubernetes za pomocą podów, wdrażania i usług, przy czym każda z tych warstw służy do określonego celu. Pody odpowiadają za interakcję kontenerów, podczas gdy wdrażanie odpowiada za wysoką dostępność i obsługę sieci dla pojedynczego węzła w klastrze (podobnie jak Docker Compose w przypadku samodzielnej aplikacji Docker bez Swarm), a usługi Kubernetes odpowiadają za konfigurację działania usług wewnątrz klastra, odporność na awarie itp.

Sieci

Docker Swarm. Istnieje jedna domyślna sieć wewnętrzna do komunikacji kontenerów w klastrze, do której w razie potrzeby można dodać więcej sieci. Sieci są chronione generowanymi certyfikatami TLS. Wsparcie dla ręcznego generowania certyfikatów w celu szyfrowania ruchu danych kontenerów jest dostępne.

Kubernetes. Model sieciowy Kubernetes jest zupełnie inny i jest realizowany za pomocą wtyczek, z których jedną jest Flannel, najpopularniejsza opcja. Pody współdziałają ze sobą, a to współdziałanie może być ograniczone przez zasady. Istnieje sieć wewnętrzna zarządzana przez usługę etcd. Dostępne jest również szyfrowanie TLS, ale należy je skonfigurować ręcznie. Model sieciowy Kubernetes zakłada konfigurację dwóch CIDR-ów (Classless Inter-Domain Routing), znanego również jako supernetting.

Monitorowanie

Docker Swarm. Nie ma wbudowanych narzędzi do monitorowania i logowania, choć można ręcznie skonfigurować narzędzia monitorujące innych producentów. W tym celu można użyć ELK lub Reimann.

Kubernetes. Kubernetes udostępnia wbudowane narzędzia do logowania i monitorowania. Elasticsearch i Kibana (ELK) mogą służyć do monitorowania stanu całego klastra, a dla monitorowania usług kontenerowych dostępne są Heapster, Grafana i Influx.

Graficzny interfejs użytkownika (GUI)

Docker Swarm. Interfejs GUI można włączyć za pomocą narzędzi innych firm, takich jak Portainer.io, które zapewniają przyjazny dla użytkownika interfejs internetowy. Alternatywnie można skorzystać z edycji Enterprise programu Docker, która zapewnia graficzny interfejs do zarządzania klastrem.

Kubernetes. Interfejs graficzny zapewniany przez Kubernetes to niezawodny pulpit nawigacyjny, do którego dostęp można uzyskać za pośrednictwem interfejsu internetowego, za pomocą którego można łatwo kontrolować klaster. Interfejs graficzny może być bardzo cennym narzędziem dla użytkowników posiadających minimalne doświadczenie w zarządzaniu Kubernetes za pomocą interfejsu CLI.

Wniosek

Docker Swarm to natywne rozwiązanie Docker, które wykorzystuje przede wszystkim interfejs API Docker oraz interfejs CLI. Natomiast Kubernetes to projekt firmy Google służący do wdrażania klastra, na którym działają kontenery.

Zarówno Docker Swarm, jak i Kubernetes zapewniają funkcje wysokiej dostępności, równoważenia obciążenia, sieci nakładkowej oraz skalowalności. Docker Swarm jest łatwiejsze do wdrażania, ponieważ większość konfiguracji jego funkcji jest zautomatyzowana, a rozwiązanie to zużywa niewiele zasobów sprzętowych. Jego funkcjonalność jest jednak ograniczona przez interfejs API Docker, a brakuje mu natywnych narzędzi do monitorowania.

Z kolei Kubernetes to modułowe rozwiązanie o wysokim poziomie elastyczności, które od wielu lat jest wspierane przez większość dużych przedsiębiorstw. W Kubernetes dostępne są wbudowane narzędzia do monitorowania usług i całego klastra, choć wdrażanie i konfiguracja są trudniejsze, co sprawia, że jest to rozwiązanie bardziej wymagające. Kubernetes nie jest kompatybilny z Docker CLI i Docker Compose. Korzystanie z Kubernetes jest preferowane w dużych środowiskach, w których działają aplikacje wielokontainerowe o dużym obciążeniu.

Roczny bezpłatny dostęp do usługi ochrony danych: NAKIVO Backup & Replication

Wdrażanie w 2 minuty i ochrona danych w środowiskach wirtualnych, chmurowych, fizycznych oraz SaaS. Opcje wykonywania kopii zapasowych, replikacji i natychmiastowego odzyskiwania danych.

Pobierz edycję bezpłatną