查看docker运行状态_docker商业版受限？请了解下crio

最新推荐文章于 2025-04-10 00:01:50 发布

最新推荐文章于 2025-04-10 00:01:50 发布 · 387 阅读

文章标签：

#查看docker运行状态

本文探讨了CRI-O与Docker的区别及其在容器运行时领域的应用。介绍了CRI-O作为Kubernetes轻量级容器运行时的发展历程，以及与Docker在架构上的不同之处。此外，还对比了两者在进程停止情况下的表现。

Talk is cheap in Open Source, show me the way to achieve！

--大魏

关于CRI-O前世今生：

最早的容器格运行时是lxc
Docker最早让容器火起来，docker最开始用lxc，觉得隔离性差，开发libcontainer，最终形成runc。所以说，runc是docker的独生子。
K8S时，发现市面上docker挺火，因此就用docker。
docker越做越重，CoreOS做了rkt容器格式。rkt与K8S协同工作比较好。
容器运行时格式有点多了，linux基金会主导的开源项目说：我们要做一个container runtime标准。叫OCI。以后容器运行时要符合这个标准。docker的独生子runc在第一时间符合了OCI标准。
K8S为了与容器运行时解耦(主要是docker)，提出了CRI(Container Runtime Interface)标准。它是一组与K8S与container runtime进行交互的接口。所以说，CRI和OCI并不冲突：K8S定义的是它调用容器运行时的标准接口，OCI定义的是容器运行时本身的标准。
OCI关于容器运行时的标准提出来以后，红帽想可以专门为K8S做一个轻量级的容器运行时。红帽自然会考虑到它自己全力投入的K8S发布的CRI标准(K8S红帽代码贡献第二)，因此决定重用了runc等基本组件来启动容器，并实现了一个最小的 CRI 接口。它叫CRI-O。所以说，CRI-O是CRI的一种标准实现。
当Red Hat正在开发其CRI-O，Docker也在研究CRI标准，这导致创建了另一个名为containerd的运行时(实际上是从docker engine剥离出来的)。所以新版本的docker会多一层containerd。kubernetes将containerd接入到cri的标准中。即cri-containerd。

由于容器的和K8S的发展史，最终暂时形成如下局面：

从概念上，从PaaS顶层到底层的调用关系是：

Orchestration API ->ContainerEngine API ->Kernel API

现有pass平台的调用架构(OpenShift3的模式，调用了docker)：

KubernetesMaster->Kubelet->DockerEngine-> containerd -> runc -> Linux Kernel

红帽的主张是(OpenShift4的模式)：

Kubernetes Master->Kubelet-> CRI-O -> runc ->Linux kernel

有一些开发者想用如下的模式：

KubernetesMaster->Kubelet->CRI-containerd->containerd -> runc ->Linux kernel

CRIO对于企业而言，最大的好处了消除了docker守护进行的单点故障。

接下来，本文验证下docker和CRIO在进程停止情况下容器的表现。

在RHEL7.8上运行docker 13.1.

[root@repo ~]# cat /etc/redhat-release

Red Hat Enterprise Linux Server release 7.8 (Maipo)

[root@repo ~]# docker version

Client:

Version: 1.13.1

API version: 1.26

Package version: docker-1.13.1-161.git64e9980.el7_8.x86_64

Go version: go1.10.3

Git commit: 64e9980/1.13.1

Built: Tue Mar 3 09:15:29 2020

OS/Arch: linux/amd64

Server:

Version: 1.13.1

API version: 1.26 (minimum version 1.12)

Package version: docker-1.13.1-161.git64e9980.el7_8.x86_64

Go version: go1.10.3

Git commit: 64e9980/1.13.1

Built: Tue Mar 3 09:15:29 2020

OS/Arch: linux/amd64

Experimental: false

docker处于运行状态：

这个版本的docker已经包含了containerd：

[root@repo ~]# systemctl status docker |grep -i containerd

├─3027 /usr/bin/docker-containerd-current -l unix:///var/run/docker/libcontainerd/docker-containerd.sock --metrics-interval=0 --start-timeout 2m --state-dir /var/run/docker/libcontainerd/containerd --shim docker-containerd-shim --runtime docker-runc --runtime-args --systemd-cgroup=true

└─3149 /usr/bin/docker-containerd-shim-current b076f2741f964d0c691f308e53b2096d98abb1aef44c134963eff6209fbb8c60 /var/run/docker/libcontainerd/b076f2741f964d0c691f308e53b2096d98abb1aef44c134963eff6209fbb8c60 /usr/libexec/docker/docker-runc-current

其架构图是：

我通过docker运行一个gogs容器：

[root@repo ~]# docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

b076f2741f96 repo.ocp4.example.com:5000/gogs/gogs "/app/gogs/docker/..." 8 days ago Up 13 minutes 0.0.0.0:10022->22/tcp, 0.0.0.0:10080->3000/tcp gogs

浏览器访问gogs，正常：

停止docker进程：

[root@repo ~]# systemctl stop docker

[root@repo ~]# systemctl status docker

查看运行的docker容器，已经无法查看：

[root@repo ~]# docker ps

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

浏览器访问失败。

接下来，我使用我安装好的一套OCP4验证CRIO。

查看在worker-0上运行的pods，26个：

[centos@lb.weixinyucluster3 ~]$ oc get pods -A -o wide |grep -i worker-0 |grep -i running |wc -l

登录worker-0，查看crio进程状态：

关闭crio进程：

[root@worker-0 ~]# systemctl stop crio

查看运行在worker-0上的pod数量，依然是26个：

[centos@lb.weixinyucluster3 ~]$ oc get pods -A -o wide |grep -i worker-0 |grep -i running |wc -l

启动worker-0节点上的crio，查看其版本：

[root@worker-0 ~]# systemctl start crio

接下来，看一下如何运维CIR-O。主要使用podman。

Podman曾经是CRI-O项目中的一部分，后来被分离出成为一个独立项目，libpod.Podman(Pod Manager)的目标是提供一个跟Docker相似体验的容器CLI，提供给使用者创立和运行容器。podman不需要守护程序，利用用户命名空间模拟容器中的 root，所以 Podman 不需要接入具有 root 权限的 socket。

除了podman外，还有buildah和skopeo两个辅助工具。

buildah实现的是dockerfile的脚本化执行。
podman对标的是docker命令的代替。

podman命令行如下：podman images - list imagespodman ps - lists running containerspodman pull - pulls (copies) container image from repository (ie: redhat and/or docker hub)podman run - run a containerpodman logs - display logs of a container (can be used with --follow)podman rm - remove one or more containerspodman rmi - remove one or more imagespodman stop - stops one or more containerspodman kill $(podman ps -q) - kill all running containerspodman rm $(podman ps -a -q) - deletes all stopped containerspodman 原生支持runc。[root@workstation ~]# podman infohost: BuildahVersion: 1.6-dev Conmon: package: podman-1.0.0-2.git921f98f.module+el8+2785+ff8a053f.x86_64 path: /usr/libexec/podman/conmon version: 'conmon version 1.14.0-dev, commit: be8255a19cda8a598d76dfa49e16e33 7769d4528-dirty' Distribution: distribution: '"rhel"' version: "8.0" MemFree: 2311213056 MemTotal: 3964555264 OCIRuntime: package: runc-1.0.0-54.rc5.dev.git2abd837.module+el8+2769+577ad176.x86_64 path: /usr/bin/runc version: 'runc version spec: 1.0.0' SwapFree: 1073737728 SwapTotal: 1073737728 arch: amd64 cpus: 2 hostname: workstation.example.com kernel: 4.18.0-67.el8.x86_64 os: linux rootless: false uptime: 1h 38m 30.4s (Approximately 0.04 days)insecure registries: registries: - core.example.com:5000registries: registries: - registry.redhat.io - quay.io - docker.io - registry.fedoraproject.org - core.example.com:5000store: ConfigFile: /etc/containers/storage.conf ContainerStore: number: 0 GraphDriverName: overlay GraphOptions: - overlay.override_kernel_check=true GraphRoot: /var/lib/containers/storage GraphStatus: Backing Filesystem: xfs Native Overlay Diff: "true" Supports d_type: "true" ImageStore: number: 0 RunRoot: /var/run/containers/storage查看镜像：

想更多关注OCP和云原生？请关注书籍：

参考：https://lwn.net/Articles/741897/https://xuxinkun.github.io/2017/12/12/docker-oci-runc-and-kubernetes/http://crunchtools.com/competition-heats-up-between-cri-o-and-containerd-actually-thats-not-a-thing/https://yq.aliyun.com/articles/66626https://blog.youkuaiyun.com/u013812710/article/details/79001463https://www.yangcs.net/posts/cri-o/