Docker 是最受歡迎和使用最廣泛的免費開源容器管理系統。 Docker 有助於在隔離環境中構建、部署和交付軟件應用程序； 稱為容器。 容器包含軟件包正常運行和工作所需的庫、依賴項和配置。
過去，Docker 是唯一一種易於使用的容器化技術。 在過去的幾年裡，許多項目已經成為 Docker 的替代品和市場上的競爭對手。 一些常見的 Docker 替代品 在市場上列出如下。
1）播客
這些天一個很好的碼頭替代品是 波德曼，這是一個免費的開源容器引擎，在 Apache-2.0 許可證。 波德曼 幫助構建、部署和管理容器鏡像和卷。 它是一個無守護進程的服務，這意味著它不需要運行任何集中的守護進程來管理容器和鏡像。
在 Podman 中，我們可以從 root 和非 root 用戶管理容器。 但默認情況下，它需要以 root 用戶身份運行。 Podman 命令行與 docker cli 命令接口兼容。 因此，熟悉 docker 的人可以輕鬆使用 Podman。
目前，它僅在 GNU/Linux 系統中可用，而遠程客戶端可用於 Windows 和 Mac OS。 Podman 的一個附加功能是我們可以根據正在運行的容器輕鬆生成與 Kubernetes 兼容的 YAML 文件，以便人們可以輕鬆地通過 Kubernetes 運行容器。
優點：
- Podman 是一個無守護進程的服務，不需要任何集中的守護進程。
- 它可以作為 root 和非 root 用戶運行。
- Docker 用戶可以輕鬆使用 Podman，因為命令是相同的。
缺點：
- Podman 後端僅在 GNU/Linux 發行版中可用。
2) LXC
Linux 容器 (LXC) 是一個眾所周知且經過實戰考驗的低級 Linux 容器運行時。 它是一種操作系統級虛擬化方法，用於使用單個 Linux 內核主機運行多個稱為容器的 Linux 系統。
和 LXC，可以得到一個孤立的環境 close 到虛擬機，但沒有執行單獨的 Linux 內核和模擬硬件所帶來的開銷。 LXC 是在 Docker 之前開發和維護的。 但由於 Docker 相當易於使用，它在社區中越來越受歡迎和感興趣。
優點：
- LXC 是經過實戰考驗的低級 Linux 容器運行時。
- 它是輕量級的，更適合運行 I/O 密集型軟件應用程序。
- 它適用於運行多個 Linux 系統，是傳統基於管理程序的虛擬化的一個很好的替代方案。
缺點：
- 由於主要為 Ubuntu 維護，LXC 在不同的 GNU/Linux 發行版之間具有不一致的功能支持。
3) 容器化
原來， 容器化 最初是作為 Docker 開源項目的一部分，但後來作為一個獨立項目開始。 容器化 是一個簡單的、可移植的守護進程，用於管理主機中容器的完整生命週期。 它用於監督網絡附件的低級存儲，甚至更多地用於 GNU/Linux 和 Windows 機器。
containerd 的 API 通過 API 調用而不是系統調用使管理環境變得非常容易。 目前，Containerd被視為業界標準的容器運行時管理器，在主流雲提供商的Docker、Kubernetes等重大項目中用於容器編排和容器管理。 它是一個強大的高級獨立容器運行時管理器，並針對低內存、低 CPU 峰值和低存儲進行了很好的優化，最大限度地減少了開銷以獲得更好的性能。
優點：
- Containerd 是行業標準的容器運行時管理器，並且符合 OCI。
- 它針對低內存、低 CPU 峰值和更好的性能進行了很好的優化，開銷最小。
- 它在 Kubernetes、Docker 和其他容器編排系統中用作主要組件。
缺點：
- Containerd 是關於管理容器，但不處理網絡和其他東西。
4）火箭（rkt）
Rocket（也稱為rkt）是CoreOS項目開發的容器運行時，後來被Red Hat收購。 在 CRI 之前，Rocket 是唯一一個與 Kubernetes 的 kubelet 集成的容器運行時。 它是一個高級容器運行時，提供低級功能，並且可以在沒有守護進程的情況下運行。 在 2020 年 2 月， rkt 項目被終止 並且不再維護。
優點：
- Rocket 可以在沒有守護進程的情況下運行。
- 它與 systemd 和 upstart 等初始化系統兼容。
缺點：
- rkt 項目已停止，不再維護。
容器運行時
容器運行時 是容器生命週期的重要組成部分，其主要職責是在主機中運行和管理容器。 從廣義上講，容器運行時可以分為兩大類，它們是低級運行時和高級運行時。
州長 是一個容器編排管理系統，它需要一個容器運行時接口的實現，以便容器運行時與 Kubelet 通信。 一些與 Kubernetes CRI 兼容的流行容器運行時如下。
創造它
創造它 是一個優化良好的輕量級容器運行時，為 Kubernetes 開發，作為 Docker 的替代品。 它是 Kubernetes 的一個實現 容器運行時接口 (CRI) 以啟用 OCI 兼容的運行時。 它能夠從任何容器註冊表中提取。
創造它 使用 Runc 和 Kata Containers 作為默認的低級容器運行時，但原則上可以使用任何符合 OCI 的運行時。
推薦閱讀： 如何在 Ubuntu 20.04 上安裝 Kubernetes
小程序
Rktlet 是 Kubernetes Container Runtime Interface with Rocket (rkt) 的另一個容器運行時實現。 它使用 rkt 作為 Kubernetes 的主要容器運行時。 所有使用 rktlet 運行的容器都使用 rkt 容器運行時運行。 Kubernetes (kubelet) 通過 gRPC 與 rktlet 通信。 CRI 是 kubelet 和 rktlet 相互通信的接口。 項目 rktlet 已停止，因此生命週期結束 (EOL)。
斷裂
Frakti 是一個輕量級、可移植的基於管理程序的 Kubernetes 容器運行時。 它使 Kubernetes 能夠使用 runV 直接在管理程序內運行和管理 Pod 和容器。 HyperContainer 是一個與管理程序無關的 docker 運行時，用作 runV 上的 API 包裝器。 與基於 Linux 命名空間的容器運行時相比，它為每個具有獨立內核的 pod 提供了更強的隔離。
Docker CRI 墊片
Dockershim 是使用 Kubernetes 進行 Docker 集成的容器運行時接口的實現。 Dockershim 由 Kubernetes 維護，但最近貶值了。 它從來沒有打算長期維護，因此“墊片”這個詞。 它實際上是為了幫助 Docker 與 Kubernetes 集成而創建的，但它總是最終成為一個額外的跳躍，這導致 Docker 開發了 Containerd 運行時，現在作為開放容器計劃 (OCI) 的一部分。
最近， dockershim 折舊了 在 Kubernetes v1.20.0 版本中，儘管有這個重大變化，但它不會影響最終開發人員和 DevOps 工程師，而負責底層 Kuberenetes 基礎設施的操作員和系統管理員可能不得不從 dockershim 切換到其他 CRI 兼容容器運行時，如 CRI -O、Containerd 等
結論
在容器化的世界中，不同的技術正在及時發展。 過去，是 docker 向社區介紹了軟件應用程序中容器的強大功能。 我們在容器管理器和編排方面沒有太多選擇，Docker 是 DevOps 和容器化技術的唯一選擇。 但是在過去的幾年裡情況發生了變化，有幾個系統和 docker 替代方案或者適用於 docker 和容器技術。 如果您有任何問題、建議、反饋，請將它們寫在下面的評論框中。
