10 najlepszych alternatyw dla Dockera dla zespołów DevOps w 2026 roku

Recenzje najlepszych alternatyw dla Dockera

1. 

   1

   Firecracker

   Najlepszy pod względem wydajności mikromaszyn wirtualnych

   • Niedostępne
   • Cena dostępna na żądanie

   Visit Website

   Customer Rating:4.8/5This rating combines scores from multiple user review sites to reflect overall customer sentiment about the product.

   

   Firecracker to otwarty monitor maszyn wirtualnych dla zespołów infrastruktury, które potrzebują lekkich, izolowanych środowisk na potrzeby platform opartych na kontenerach, obciążeń bezserwerowych i usług wielodostępnych.

   Dla kogo Firecracker jest najlepszym wyborem?

   Zespoły zajmujące się infrastrukturą chmurową, które muszą uruchamiać izolowane obciążenia z wysoką gęstością, mogą korzystać z lekkiej architektury mikromaszyn wirtualnych Firecracker.

   Dlaczego wybrałem Firecracker

   Wybrałem Firecracker dla architektur alternatywnych dla Dockera, które wymagają silniejszej izolacji obciążeń bez narzutu właściwego dla pełnej maszyny wirtualnej. Najlepiej sprawdza się w zakresie wydajności mikromaszyn wirtualnych — wykorzystuje KVM i minimalny model urządzeń do uruchamiania lekkich mikromaszyn wirtualnych, które mogą obsługiwać obciążenia kontenerowe. Podoba mi się jego dopasowanie do platform bezserwerowych, które uruchamiają izolowane środowiska na żądanie.

   Najważniejsze funkcje Firecracker

   • Interfejs API REST do sterowania: Konfiguruj, uruchamiaj, wstrzymuj i zatrzymuj mikromaszyny wirtualne za pośrednictwem punktów końcowych HTTP.
   • Tworzenie migawek i przywracanie: Zapisuj stan mikromaszyny wirtualnej i przywracaj go z migawki.
   • Ograniczanie przepustowości zasobów: Ustawiaj limity dla operacji sieciowych i operacji na urządzeniach blokowych.
   • Usługa metadanych: Udostępniaj obciążeniom gościa metadane właściwe dla danej instancji.

   Integracje Firecracker

   Firecracker jest wymieniany jako używany przez platformy lub zintegrowany z containerd za pośrednictwem firecracker-containerd, E2B, Fly.io, Kata Containers, Koyeb i Northflank. Jego interfejs API REST obsługuje konfigurację mikromaszyn wirtualnych oraz zarządzanie ich cyklem życia.

   Pros and Cons

   Pros:

   • Izolacja wspierana sprzętowo dla obciążeń kontenerowych
   • Lekkie mikromaszyny wirtualne zmniejszają narzut wirtualizacji
   • Interfejs API REST umożliwia sterowanie cyklem życia maszyn wirtualnych i migawkami

   Cons:

   • Wymagane są hosty z systemem Linux obsługujące KVM
   • Konfiguracja sieci hosta wymaga ręcznego ustawienia
   Learn more about Firecracker:

   • Check out Firecracker on their website
   • Read my in-depth review of Firecracker
2. 

   2

   runc

   Najlepszy pod względem zgodności z OCI

   • Niedostępne
   • Ceny ustalane na żądanie

   Visit Website

   

   Dla zespołów infrastruktury tworzących niestandardowe przepływy pracy z kontenerami Linuksa, runc to otwarte środowisko uruchomieniowe niskiego poziomu, które uruchamia kontenery bez konieczności korzystania z platformy Docker wyższego poziomu.

   Dla kogo runc jest najlepszym wyborem?

   runc dobrze sprawdza się w przypadku inżynierów platform integrujących wykonywanie kontenerów zgodnych z OCI z infrastrukturą lub systemami orkiestracji Linuksa.

   Dlaczego wybrałem runc

   Wybrałem runc, oceniany jako najlepszy pod względem zgodności z OCI, jako alternatywę dla Dockera, ponieważ implementuje specyfikację środowiska uruchomieniowego OCI. Uruchamia kontenery z pakietów OCI, zapewniając narzędziom infrastruktury Linuksa środowisko uruchomieniowe niskiego poziomu do wykonywania kontenerów bez szerszej platformy Dockera.

   Najważniejsze funkcje runc

   • Polecenia cyklu życia kontenera: Twórz, uruchamiaj, wyświetlaj i usuwaj kontenery za pomocą oddzielnych poleceń CLI.
   • Kontenery bez uprawnień administratora: Uruchamiaj kontenery bez uprawnień administratora, gdy jądro Linuksa obsługuje przestrzenie nazw użytkowników.
   • Obsługa seccomp: Stosuj filtry seccomp w celu ograniczenia wywołań systemowych, gdy program został zbudowany z obsługą libseccomp.
   • Punkt kontrolny i przywracanie: Zapisuj i przywracaj stan kontenera za pomocą CRIU przy wymaganej konfiguracji kompilacji.

   Integracje runc

   Natywne integracje nie są udokumentowane, a runc nie udostępnia osobnego interfejsu API do niestandardowych integracji. containerd może używać runc jako środowiska uruchomieniowego OCI, umożliwiając uruchamianie obciążeń Kubernetes za pośrednictwem containerd; sam runc nie implementuje interfejsu CRI Kubernetes.

   Pros and Cons

   Pros:

   • Implementuje specyfikację środowiska uruchomieniowego OCI
   • Bezpośrednia kontrola cyklu życia za pomocą wyspecjalizowanych poleceń CLI
   • Obsługa uruchamiania bez uprawnień administratora z użyciem przestrzeni nazw użytkowników

   Cons:

   • Środowisko uruchomieniowe dostępne wyłącznie w systemie Linux
   • Wymaga pakietów OCI zamiast zarządzania obrazami
   Learn more about runc:

   • Check out runc on their website
3. 

   3

   Kaniko

   Najlepsze do budowania bez demona

   • Niedostępne
   • Ceny na zapytanie

   Visit Website

   

   Kaniko zapewnia zespołom platformowym i DevOps sposób na budowanie obrazów kontenerów z plików Dockerfile w przepływach pracy CI, wspierając środowiska ukierunkowane na Kubernetes, które potrzebują alternatywy dla narzędzi do budowania opartych na Dockerze.

   Dla kogo Kaniko jest najlepszym wyborem?

   Kaniko jest odpowiednie dla zespołów infrastruktury, które muszą budować obrazy kontenerów z plików Dockerfile w CI bez polegania na demonie Dockera.

   Dlaczego wybrałem Kaniko

   Wybrałem Kaniko jako najlepsze rozwiązanie do budowania bez demona, ponieważ jego mechanizm wykonawczy buduje obrazy z plików Dockerfile bez demona Dockera. Podoba mi się, że mogę uruchomić je w zadaniu CI Kubernetes i wypchnąć gotowy obraz do rejestru bez ujawniania gniazda Dockera.

   Najważniejsze funkcje Kaniko

   • Zdalna pamięć podręczna warstw: Buforuje warstwy RUN i COPY w rejestrze.
   • Konteksty budowania: Akceptuje katalogi lokalne, archiwa, repozytoria Git i magazyny w chmurze.
   • Uwierzytelnianie w rejestrze: Obsługuje konfigurację danych uwierzytelniających dla GCR, Amazon ECR i Azure ACR.
   • Powtarzalne kompilacje: Oferuje opcję usuwania znaczników czasu z obrazu.

   Integracje Kaniko

   Kaniko obsługuje uwierzytelnianie w rejestrach i wypychanie obrazów do Google Container Registry, Amazon ECR, Azure ACR, Docker Hub oraz JFrog Artifactory lub rejestru kontenerów; można skonfigurować inne pomocnicze narzędzia do obsługi danych uwierzytelniających Dockera.

   Pros and Cons

   Pros:

   • Eliminuje potrzebę korzystania z uprzywilejowanych konfiguracji Docker-in-Docker
   • Budowanie odbywa się wewnątrz zasobników Kubernetes
   • Zdalnie buforuje warstwy `RUN` i `COPY`

   Cons:

   • Główne repozytorium Google jest zarchiwizowane
   • Migawki systemu plików mogą spowalniać duże kompilacje
   Learn more about Kaniko:

   • Check out Kaniko on their website
4. 

   4

   Podman

   Najlepszy do zarządzania środowiskiem lokalnym

   • Dostępny bezpłatny plan
   • Ceny na zapytanie

   Visit Website

   

   Podman zapewnia deweloperom i zespołom IT bezdemonowy, otwartoźródłowy sposób lokalnego budowania, uruchamiania i zarządzania kontenerami, pomagając im testować aplikacje i utrzymywać spójność środowisk programistycznych.

   Dla kogo Podman jest najlepszym wyborem?

   Podman jest odpowiedni dla deweloperów i administratorów systemów, którzy chcą zarządzać przepływami pracy związanymi z kontenerami na stacjach roboczych bez centralnego demona.

   Dlaczego wybrałem Podmana

   Wybrałem Podmana, ponieważ jego bezdemonowy i bezrootowy przepływ pracy z kontenerami sprawia, że jest praktyczną alternatywą dla Dockera podczas lokalnego tworzenia oprogramowania. Mogę uruchamiać kontenery bez centralnego demona, grupować powiązane kontenery w pody oraz generować pliki YAML Kubernetes, aby przenosić przetestowaną konfigurację do przepływów pracy z klastrami.

   Najważniejsze funkcje Podmana

   • Zarządzanie obrazami: Pobieranie, oznaczanie, kontrolowanie i usuwanie obrazów kontenerów.
   • Zarządzanie woluminami: Tworzenie i kontrolowanie nazwanych woluminów na potrzeby trwałych danych kontenerów.
   • Zarządzanie siecią: Tworzenie sieci i podłączanie do nich kontenerów.
   • Kontrole kondycji: Konfigurowanie kontroli kondycji w celu monitorowania stanu kontenera.

   Integracje Podmana

   Natywne integracje Podmana nie są jasno udokumentowane, ale zapewnia on zgodny z Dockerem interfejs API REST oraz interfejs API Libpod na potrzeby niestandardowych integracji. Podman Desktop może zarządzać Dockerem, Limą, kind, Red Hat OpenShift i Red Hat OpenShift Developer Sandbox, a także wdrażać rozwiązania do kontekstów Kubernetes.

   Pros and Cons

   Pros:

   • Kontenery bez uprawnień administratora ograniczają narażenie uprawnień hosta
   • Działanie bez demona eliminuje potrzebę stałej usługi silnika
   • Obsługa podów i YAML Kubernetes wspiera testowanie od środowiska lokalnego do klastra

   Cons:

   • Obsługa Compose pozostaje w tyle za szerszym zakresem funkcji Dockera
   • Sieci bez uprawnień administratora mogą komplikować rejestrowanie adresów IP źródła
   Learn more about Podman:

   • Check out Podman on their website
5. 

   5

   Rancher

   Najlepszy do zarządzania wieloma klastrami

   • Dostępny bezpłatny plan
   • Cennik na żądanie

   Visit Website

   

   Rancher to platforma zarządzania Kubernetes dla zespołów infrastruktury, które muszą wdrażać aplikacje skonteneryzowane w środowiskach chmurowych i lokalnych oraz zarządzać ich działaniem.

   Dla kogo Rancher jest najlepszy?

   Rancher jest odpowiedni dla zespołów platformowych i zespołów infrastruktury, które potrzebują centralnego sposobu administrowania klastrami Kubernetes w środowiskach programistycznych, testowych i produkcyjnych.

   Dlaczego wybrałem Rancher

   Wybrałem Rancher jako najlepsze rozwiązanie do zarządzania wieloma klastrami, ponieważ zapewnia centralny sposób administrowania klastrami Kubernetes w środowiskach chmurowych i lokalnych. Jego funkcje aprowizowania klastrów oraz scentralizowane mechanizmy kontroli dostępu oparte na rolach pomagają mi zarządzać obciążeniami skonteneryzowanymi i uprawnieniami w środowiskach programistycznych, testowych i produkcyjnych.

   Najważniejsze funkcje Rancher

   • Fleet GitOps: Wdrażaj zasoby Kubernetes i zarządzaj nimi z repozytoriów Git.
   • Monitorowanie i alerty: Wyświetlaj metryki klastrów i konfiguruj alerty za pomocą Prometheus i Grafana.
   • Rejestrowanie: Zbieraj dzienniki z obciążeń klastra i wyświetlaj je.
   • Zarządzanie wykresami Helm: Instaluj i konfiguruj aplikacje z wykresów Helm.

   Integracje Rancher

   Rancher obsługuje zewnętrzne uwierzytelnianie za pośrednictwem Microsoft Active Directory, Microsoft Entra ID, GitHub, Okta, Keycloak, Google OAuth, OpenLDAP i ogólnego OIDC. Jego stos monitorowania może wysyłać alerty za pośrednictwem Alertmanager do Slack i PagerDuty, a Rancher udostępnia interfejs API do niestandardowych integracji.

   Pros and Cons

   Pros:

   • Centralizuje zarządzanie klastrami Kubernetes
   • Ułatwia konfigurację klastrów i zarządzanie nimi
   • Zapewnia wizualne monitorowanie i kontrolę obciążeń

   Cons:

   • Interfejs użytkownika może działać wolno lub niestabilnie
   • Generuje wiele reguł i ról RBAC
   Learn more about Rancher:

   • Check out Rancher on their website
6. 

   6

   LXC/LXD

   Najlepsze rozwiązanie do zarządzania kontenerami Linuksa

   • Niedostępne
   • Cennik na żądanie

   Visit Website

   

   LXC/LXD pozwala zespołom IT uruchamiać systemowe kontenery Linuksa jako izolowane środowiska, oferując administratorom infrastruktury alternatywę dla Dockera do konsolidowania obciążeń i zarządzania hostami z systemem Linux.

   Dla kogo LXC/LXD jest najlepszym rozwiązaniem?

   Administratorzy systemów Linux, którzy muszą tworzyć systemowe kontenery i zarządzać nimi na hostach z systemem Linux, dobrze pasują do LXC/LXD.

   Dlaczego wybrałem LXC/LXD

   Wybrałem LXC/LXD jako alternatywę dla Dockera, ponieważ najlepiej sprawdza się w zarządzaniu kontenerami Linuksa. Podoba mi się, że LXD uruchamia pełne systemowe kontenery Linuksa, dzięki czemu mogę zarządzać izolowanymi środowiskami, które zachowują się bardziej jak lekkie serwery niż kontenery przeznaczone dla pojedynczych aplikacji. Profile pozwalają stosować spójne ustawienia w wielu kontenerach, a klient wiersza poleceń i interfejs API REST umożliwiają zarządzanie na poziomie hosta.

   Najważniejsze funkcje LXC/LXD

   • Migawki instancji: Przechwytywanie stanu instancji i przywracanie go w późniejszym czasie.
   • Zarządzanie obrazami: Tworzenie instancji na podstawie obrazów oraz zarządzanie aliasami obrazów i zdalnymi źródłami.
   • Zarządzanie siecią: Konfigurowanie zarządzanych mostów, sieci OVN i innych typów sieci.
   • Limity zasobów: Ustawianie limitów procesora, pamięci, dysku i sieci dla instancji.

   Integracje LXC/LXD

   Dokumentacja LXD opisuje sterownik CSI, który integruje jego zaplecza pamięci masowej z Kubernetesem. Udostępnia również interfejs API REST do niestandardowych integracji.

   Pros and Cons

   Pros:

   • Pełne systemy Linux działają jak lekkie serwery
   • Szybkie, lekkie instancje zużywają niewiele zasobów
   • Migawki ułatwiają odzyskiwanie danych po zmianach w projekcie

   Cons:

   • Praca z wierszem poleceń może wydawać się nieintuicyjna
   • Obsługa wyłącznie systemu Linux wyklucza hosty z systemem Windows
   Learn more about LXC/LXD:

   • Check out LXC/LXD on their website
7. 

   7

   containerd

   Najlepszy dla prostoty i przenośności

   • Niedostępna
   • Ceny na żądanie

   Visit Website

   

   Stworzony z myślą o zespołach infrastruktury poszukujących alternatywy dla Dockera, containerd to środowisko uruchomieniowe kontenerów o otwartym kodzie źródłowym, które zarządza obrazami kontenerów i ich wykonywaniem w środowiskach produkcyjnych.

   Dla kogo najlepiej nadaje się containerd?

   Dla zespołów infrastruktury, które potrzebują przenośnego środowiska uruchomieniowego kontenerów o otwartym kodzie źródłowym do zarządzania obrazami i ich wykonywaniem w środowiskach produkcyjnych.

   Dlaczego wybrałem containerd

   Wybrałem containerd jako alternatywę dla Dockera ze względu na jego prostotę i przenośność. Jego zgodne z OCI środowisko uruchomieniowe i usługi obrazów obsługują pobieranie, przechowywanie oraz wykonywanie kontenerów bez rozbudowanego zestawu narzędzi Dockera. Podoba mi się, że jego wtyczka CRI pozwala węzłom Kubernetes korzystać bezpośrednio z containerd, a standardy OCI pomagają zachować przenośność obciążeń w zgodnych środowiskach.

   Najważniejsze funkcje containerd

   • Przestrzenie nazw: Oddzielają kontenery i metadane obrazów dla wielu użytkowników korzystających z jednego demona.
   • Mechanizmy migawek: Tworzą zapisywalne migawki i widoki migawek tylko do odczytu przy użyciu obsługiwanych systemów plików.
   • Punkt kontrolny i przywracanie: Umożliwiają korzystanie z CRIU do tworzenia punktów kontrolnych i przywracania kontenerów oraz zadań.
   • Biblioteka kliencka Go: Łączy kod platformy z containerd za pośrednictwem jego gniazda i interfejsu API.

   Integracje containerd

   containerd ma wbudowaną obsługę Kubernetes za pośrednictwem wtyczki interfejsu środowiska uruchomieniowego kontenerów (CRI) i współpracuje z rejestrami zgodnymi ze standardem dystrybucji OCI. Jego biblioteka kliencka Go oraz interfejsy API gRPC obsługują niestandardowe integracje.

   Pros and Cons

   Pros:

   • Obrazy i środowiska uruchomieniowe zgodne z OCI
   • Natywna obsługa Kubernetes CRI
   • Działa w systemach Linux i Windows

   Cons:

   • Tworzenie obrazów wymaga osobnych narzędzi
   • Niskopoziomowy interfejs wiersza poleceń nie oferuje wygód Dockera
   Learn more about containerd:

   • Check out containerd on their website
8. 

   8

   OpenVZ

   Najlepszy do efektywnego wykorzystania serwerów z systemem Linux

   • Dostępny bezpłatny plan
   • Ceny na żądanie

   Visit Website

   

   Dla zespołów zajmujących się infrastrukturą i dostawców hostingu OpenVZ to platforma konteneryzacji systemu Linux, która uruchamia odizolowane środowiska we współdzielonym jądrze, oferując alternatywę dla Dockera w zakresie konsolidowania obciążeń serwera bez używania oddzielnych maszyn wirtualnych.

   Dla kogo najlepiej nadaje się OpenVZ?

   OpenVZ jest odpowiedni dla administratorów systemów, którzy chcą uruchamiać wiele odizolowanych środowisk Linuksa na współdzielonym sprzęcie serwerowym.

   Dlaczego wybrałem OpenVZ

   Wybrałem OpenVZ jako alternatywę dla Dockera, ponieważ najlepiej sprawdza się w efektywnym wykorzystaniu serwerów z systemem Linux. Jego kontenery izolują środowiska Linuksa, jednocześnie współdzieląc jądro hosta, dzięki czemu mogę konsolidować obciążenia bez uruchamiania oddzielnej maszyny wirtualnej dla każdej usługi. Kontrola procesora, pamięci i dysku dla poszczególnych kontenerów pomaga mi przydzielać zasoby na obciążonym serwerze.

   Najważniejsze funkcje OpenVZ

   • Szablony kontenerów: Twórz kontenery na podstawie gotowych obrazów dystrybucji Linuksa.
   • Migracja na żywo: Przenoś uruchomione kontenery między obsługiwanymi hostami za pomocą CRIU i P.Haul.
   • Migawki: Zapisuj stany dysków kontenerów za pomocą systemu pamięci masowej ploop.
   • Sieci wirtualne: Konfiguruj interfejsy sieciowe kontenerów, adresy IP i routing.

   Integracje OpenVZ

   OpenVZ obsługuje integrację z OpenStack za pomocą DevStack, a libvirt pełni funkcję standardowego interfejsu API do zarządzania kontenerami i maszynami wirtualnymi.

   Pros and Cons

   Pros:

   • Kontenery wymagające niewielkich zasobów zmniejszają obciążenie hosta
   • Kontrola poszczególnych kontenerów ułatwia gęstą konsolidację serwerów
   • Migracja na żywo umożliwia przenoszenie uruchomionych kontenerów

   Cons:

   • Współdzielone jądro ogranicza wybór systemów operacyjnych i jąder
   • Mniejszy ekosystem narzędzi i wsparcia niż w przypadku Dockera
   Learn more about OpenVZ:

   • Check out OpenVZ on their website
9. 

   9

   Singularity

   Najlepsze rozwiązanie do obliczeń wysokiej wydajności

   • Dostępny bezpłatny plan
   • Ceny na żądanie

   Visit Website

   

   Singularity pomaga zespołom badawczym i zespołom ds. infrastruktury pakować aplikacje wraz z ich zależnościami oraz uruchamiać je w spójny sposób w różnych systemach, w tym we współdzielonych środowiskach, w których model Dockera oparty na demonie może być trudny do obsługi.

   Dla kogo Singularity jest najlepszym rozwiązaniem?

   Zespoły zajmujące się obliczeniami badawczymi oraz administratorzy środowisk HPC, którzy muszą uruchamiać przenośne obciążenia w różnych współdzielonych klastrach.

   Dlaczego wybrałem Singularity

   Wybrałem Singularity jako alternatywę dla Dockera, najlepszą do obciążeń związanych z obliczeniami wysokiej wydajności we współdzielonych klastrach. Umożliwia uruchamianie kontenerów bez demona, co sprawdza się w środowiskach, w których użytkownicy nie mogą uruchamiać demona Dockera. Przenośne obrazy SIF pomagają zespołom przenosić obciążenia między systemami, zachowując zależności aplikacji spakowane razem.

   Najważniejsze funkcje Singularity

   • Obsługa GPU: Udostępnia konteneryzowanym aplikacjom urządzenia i biblioteki hosta NVIDIA CUDA lub AMD ROCm.
   • Obsługa MPI: Umożliwia uruchamianie aplikacji Open MPI lub MPICH za pomocą programów uruchamiających hosta, takich jak mpirun.
   • Pliki definicji: Umożliwiają określanie kroków kompilacji, ustawień uruchomieniowych, metadanych i testów dla obrazów kontenerów.
   • Obsługa rejestrów OCI: Umożliwia używanie obrazów z obsługiwanych rejestrów OCI jako źródeł kompilacji.

   Integracje Singularity

   SingularityCE może pobierać obrazy z rejestrów OCI, uruchamiać je i tworzyć na ich podstawie obrazy, w tym z Docker Hub, Quay, NVIDIA NGC, GitHub Container Registry, AWS ECR i Azure ACR. W przypadku obciążeń HPC obsługuje Open MPI i MPICH wraz z programami uruchamiającymi hosta oraz harmonogramami, takimi jak mpirun, srun i Slurm.

   Pros and Cons

   Pros:

   • Uruchamianie kontenerów bez demona
   • Uruchamianie obciążeń bez dostępu administratora
   • Obsługa obciążeń GPU i szybkich połączeń międzysieciowych

   Cons:

   • Mniejsze dopasowanie do hostowania usług ogólnego przeznaczenia
   • Tworzenie obrazów może wymagać konfiguracji przez administratora
   Learn more about Singularity:

   • Check out Singularity on their website
10. 

    10

    CRI-O

    Najlepsze do integracji z Kubernetes

    • Niedostępne
    • Ceny ustalane na życzenie

    Visit Website

    

    CRI-O to otwarte środowisko uruchomieniowe kontenerów dla węzłów Kubernetes, pomagające zespołom infrastruktury uruchamiać kontenery OCI bez wdrażania silnika Docker ogólnego przeznaczenia.

    Dla kogo CRI-O jest najlepszym wyborem?

    CRI-O jest odpowiednie dla zespołów platformowych Kubernetes, które potrzebują środowiska uruchomieniowego kontenerów OCI stworzonego specjalnie dla węzłów Kubernetes.

    Dlaczego wybrałem CRI-O

    Wybrałem CRI-O, ponieważ określenie „Najlepsze do integracji z Kubernetes” odzwierciedla jego założenia projektowe: implementuje interfejs Container Runtime Interface (CRI) platformy Kubernetes, umożliwiając kubeletowi zarządzanie kontenerami bez użycia silnika Docker ogólnego przeznaczenia. Podoba mi się, że uruchamia obrazy zgodne z OCI za pośrednictwem środowisk uruchomieniowych, takich jak runc, dzięki czemu wykonywanie kontenerów pozostaje spójne z procesami pracy węzłów Kubernetes.

    Najważniejsze funkcje CRI-O

    • Sieciowanie CNI: Łączy się z wtyczkami CNI w celu konfigurowania sieci kontenerów.
    • Monitorowanie kontenerów: Wykorzystuje conmon do obsługi dzienników, klientów podłączających się do kontenerów oraz wykrywania zdarzeń wyczerpania pamięci.
    • Elementy kontroli bezpieczeństwa systemu Linux: Obsługuje SELinux, możliwości systemu Linux oraz zasady seccomp.
    • Sterowniki pamięci masowej: Obsługuje Overlayfs, devicemapper, AUFS i btrfs.

    Integracje CRI-O

    CRI-O implementuje interfejs CRI platformy Kubernetes dla kubeleta i obsługuje środowiska uruchomieniowe OCI, takie jak runc i Kata Containers. Współpracuje z wtyczkami CNI, w tym Flannel, Weave i OpenShift-SDN, oraz udostępnia interfejs API CRI gRPC i niestabilny interfejs API stanu HTTP.

    Pros and Cons

    Pros:

    • Natywny dla Kubernetes interfejs CRI pozwala skoncentrować środowisko uruchomieniowe węzła
    • Lekka konstrukcja eliminuje potrzebę korzystania z silnika Docker ogólnego przeznaczenia
    • Obsługuje formaty obrazów OCI i Docker

    Cons:

    • Brak samodzielnego zarządzania kontenerami poza Kubernetes
    • Wymaga oddzielnych narzędzi do tworzenia obrazów
    Learn more about CRI-O:

    • Check out CRI-O on their website