Wiele firm używa Kubernetes i Docker razem. Wiele z nich twierdzi nawet, że takie podejście przynosi znaczące korzyści dla ich biznesu. Jednak obecnie może to już nie być możliwe. Dlaczego tak się dzieje i jak można używać Kubernetes bez Docker? Dowiedz się więcej w naszym artykule.
Docker i Kubernetes to dwa komplementarne rozwiązania IT. Docker służy jako platforma containerization (umożliwia deweloperom pakowanie aplikacji w kontenery), a Kubernetes to narzędzie do container orchestration (możesz go użyć do automatyzacji i optymalizacji uruchamiania zcontainerowanych workloadów i usług). W rzeczywistości wiele firm wykorzystywało oba te rozwiązania jednocześnie. Teraz jednak wydaje się, że wkrótce będą musiały nauczyć się korzystać z Kubernetes bez Docker.
Czym jest Docker?
Docker to open source containerization platform. Deweloperzy używają go do umieszczania aplikacji w kontenerach. Kontenery to standaryzowane, wykonywalne komponenty, które łączą kod źródłowy produktów cyfrowych z systemem operacyjnym (OS), bibliotekami i zależnościami niezbędnymi do uruchomienia tego kodu w dowolnym środowisku. Dlaczego Twoja firma go używa? Dzięki containerization łatwiej jest dostarczać rozproszone aplikacje. Takie podejście jest obecnie powszechne w firmach zajmujących się cloud-native development lub działających w środowiskach hybrydowych czy multicloud. Kontenery można oczywiście tworzyć bez Docker, ale ta platforma oferuje narzędzia i rozwiązania, które czynią to łatwiejszym, szybszym i bezpieczniejszym. Zamiast godzin ręcznej pracy, deweloperzy mogą używać prostych komend i korzystać z automatyzacji.
Czym jest Kubernetes?
Przy korzystaniu z kontenerów trzeba zadbać o pewne zadania – takie jak workload scheduling, komunikacja, zarządzanie zasobami, skalowalność itd. Wszystko to można zrealizować za pomocą narzędzi takich jak Kubernetes. Ta platforma do container orchestration jest open source (każdy może jej używać za darmo) i potrafi obsłużyć najważniejsze procesy zarządzania kontenerami (deployment, scaling, healing, load balancing). Po zdefiniowaniu poda, Kubernetes zadba o to, by był on zawsze uruchomiony. Monitoruje kontenery i jeśli jeden przestanie działać, próbuje uruchomić nowy. To odciąża Twoich pracowników i pozwala im skupić się na bardziej złożonych zadaniach.
Jak Docker i Kubernetes współpracują?
Kubernetes robi wiele, ale sam nie uruchamia kontenerów na maszynie. Do tego potrzebny jest dodatkowy element oprogramowania – container runtime. Kubernetes przekazuje mu informacje, co ma być wykonane na każdym hoście, a runtime uruchamia kontenery zgodnie z tymi instrukcjami. Masz duży wybór – na rynku dostępnych jest wiele takich rozwiązań (wiele z nich to open source). Przez długi czas najczęściej wybieraną opcją był Docker.
Nie wszystkie firmy potrzebują obu tych narzędzi. Startupy i małe firmy, które mają mniej kontenerów, nie muszą używać Kubernetes do orkiestracji i (jak już wspomniano) można budować kontenery bez Docker. Przez długi czas te dwa rozwiązania były uznawane za niezawodną kombinację i wykorzystywane przez wiele organizacji. Docker służył do tworzenia kontenerów, a Kubernetes do ich zarządzania. Razem zapewniały efektywność procesu developmentu i szybkie wdrożenia.
Dlaczego Docker nie może już być container runtime dla Kubernetes?
Dla tych, którzy korzystają z tej kombinacji, mamy złą wiadomość – Kubernetes usuwa wsparcie dla Docker jako container runtime. Wsparcie dla Docker było „zaszyte” w narzędziu do orkiestracji. Ten komponent był znany jako Dockershim. Kubernetes ewoluował i obecnie wspiera dodatkowe runtimes. Kubernetes działa dobrze ze wszystkimi container runtimes, które implementują standard zwany CRI (Container Runtime Interface). W skrócie, jest to standard komunikacji między Kubernetes a wybranym container runtime. Rozwiązania, które wspierają ten standard, automatycznie działają poprawnie z Kubernetes, inne nie – a Docker nie zaimplementował Container Runtime Interface. Kubernetes zaimplementował Dockershim, by umożliwić komunikację między tymi dwoma rozwiązaniami i przez długi czas wspierał Docker. Teraz, gdy użytkownicy mają szeroki wybór runtimes, zespół Kubernetes odchodzi od utrzymywania specjalnego wsparcia dla Docker.
Możesz zapytać, dlaczego Kubernetes właśnie teraz wycofał Docker – przecież wiele dostępnych obecnie rozwiązań było już na rynku od jakiegoś czasu. Otóż Docker nie jest tak naprawdę container runtime. To zestaw narzędzi do tworzenia kontenerów, a możliwość faktycznego uruchamiania kontenerów zapewnia prawdziwy runtime o nazwie Containerd, na którym opiera się Docker. W rzeczywistości Docker nie potrafi samodzielnie uruchamiać kontenerów – zapewnia jedynie wygodniejszy interfejs nad osobnym container runtime.
Wszyscy lubimy „all in one” rozwiązania (jeśli są wydajne) i nikt nie lubi łączyć trzech (lub więcej) różnych narzędzi, jeśli nie jest to konieczne. W parze Kubernetes – Docker, Docker jest po prostu pośrednikiem między platformą orkiestracji a Containerd. Co ważniejsze – jest to niepotrzebny pośrednik. Kubernetes może współpracować z Containerd jako container runtime bezpośrednio. Docker ma oczywiście inne zastosowania, ale mając tę wiedzę, możesz rozważyć używanie Kubernetes bez Docker (albo przynajmniej bez Docker jako container runtime).
Jak używać Kubernetes bez Docker?
Docker jest starszy niż Kubernetes i nie zaimplementował CRI, co oznacza, że nie jest już dobrym kandydatem na Kubernetes runtime. Możesz zdecydować się na używanie Kubernetes bez Docker, albo nawet Docker bez Kubernetes (ale zalecamy używać go do innych celów niż uruchamianie kontenerów). Mimo że Kubernetes to dość rozbudowane narzędzie, musisz znaleźć dla niego odpowiedni container runtime – taki, który zaimplementował CRI. Runtime z implementacją CRI będzie mógł płynnie komunikować się z Kubernetes i taka kombinacja będzie działać dobrze. Praktycznie nie musisz się o nic martwić. Jeśli korzystasz z usług Kubernetes takich jak GKE, EKS czy AKS, musisz upewnić się, że Twoje worker nodes używają wspieranego runtime. Najlepiej zrobić to zanim wsparcie dla Docker zostanie usunięte. Twoje dostosowania node mogą wymagać aktualizacji w zależności od środowiska i wymagań runtime. Po wybraniu innego runtime, który używa Container Runtime Interface (CRI), Twoje obrazy stworzone w Docker będą działać bez problemu w klastrze z innymi runtimes. Wielu autorów podkreśla, że Docker nadal jest przydatnym narzędziem do budowania kontenerów. Jednak obecna transformacja Kubernetes to dobra okazja, by ocenić swój stack technologiczny i porównać używane obecnie rozwiązania z alternatywami.
Jak działać dalej bez Docker?
Po pierwsze, nie panikuj – to właściwie rada prosto od zespołu Kubernetes. Powinieneś rozważyć swoje opcje. Zawsze istnieje szansa, że znajdziesz lepszy container runtime dla swojej firmy. Dostępnych jest wiele rozwiązań – zarówno open source, jak i komercyjnych. Na pewno znajdziesz to, czego potrzebujesz po dokładnym rozważeniu. Chętnie doradzimy i pomożemy we wdrożeniu nowych rozwiązań. Opowiedz nam więcej o swoim projekcie i wymaganiach biznesowych.
Czytaj więcej
Jak zbudować wydajną Big Data Architecture dla swojej firmy
Jak połączyć się z Databricks z lokalnego IDE
Data Warehouse vs. Data Lake vs Lakehouse: Kompleksowe porównanie podejść do zarządzania danymi
