CRI-O vs Podman vs Docker vs CRI-containerd

Docker

對Docker來說，負責響應這個請求的就是一個叫作 dockershim 的組件泽裳，它把 CRI 請求里的內(nèi)容拿出來笋额，然后組裝成 Docker API 請求發(fā)給 Docker Daemon冯袍。對于別的容器項目來說犬钢，扮演shim角色的組件統(tǒng)稱為CRI-shim苍鲜，可見，CRI-shim就是實現(xiàn)CRI中定義的每一個接口玷犹，然后把具體的 CRI 請求“翻譯”成對后端容器項目的請求或者操作混滔。
注意一點的是，我們在部署docker時并沒有部署這個docker-shim組件歹颓，docker-shim代碼是包含在kubelet中的坯屿，但是其它的容器項目，就需要在hosts中部署自己的CRI-shim了巍扛。

image.png

Docker項目是C/S架構领跛，Docker client端發(fā)送請求給docker daemon采用root用戶運行在host上，通過socket進行通信电湘，docker daemon接收創(chuàng)建容器的請求再發(fā)送給containerd,容器進程是docker daemon的子進程隔节，而不是dockerCLI的子進程。

image.png

可以通過查看進程樹

# pstree -p
systemd(1)-+-agetty(3596)
           |-crond(25481)
           |-dbus-daemon(3498)
           |-dhclient(3744)
           |-dockerd(8050)-+-containerd(8062)-+-containerd-shim(7104)-+-pause(7123)
           |               |                  |                       |-{containerd-shim}(7105)
           |               |                  |                       |-{containerd-shim}(7106)
           |               |                  |                       |-{containerd-shim}(7107)
           |               |                  |                       |-{containerd-shim}(7108)
           |               |                  |                       |-{containerd-shim}(7109)
           |               |                  |                       |-{containerd-shim}(7110)
           |               |                  |                       |-{containerd-shim}(7111)
           |               |                  |                       |-{containerd-shim}(7112)
           |               |                  |                       |-{containerd-shim}(7152)
           |               |                  |                       `-{containerd-shim}(8816)
           |               |                  |-containerd-shim(7327)-+-containerd(17056)-+-{containerd}(17061)
           |               |                  |                       |                   |-{containerd}(17062)
           |               |                  |                       |                   |-{containerd}(17063)
           |               |                  |                       |                   |-{containerd}(17064)
           |               |                  |                       |                   |-{containerd}(17067)
           |               |                  |                       |                   `-{containerd}(17068)

CRI-containerd

CNCF的containerd就是充當了CRI-shim的角色寂呛，kubelet調(diào)用CRI怎诫，containerd響應CRI請求，進而調(diào)用runc創(chuàng)建容器贷痪，runc才是真正通過設置namesapce幻妓，cgroup，chroot的創(chuàng)建容易的幕后英雄劫拢。

image.png

CRI-O的范圍

CRI-O的目的是提供一種在OCI一致的運行時和kubelet之間的集成方式肉津，它實現(xiàn)了kubelet容器運行時的接口，CRI-O的范圍與CRI的范圍相關舱沧。
從更高的角度來看妹沙，CRI-O能夠在一下功能發(fā)展的更加嚴格規(guī)范：

支持更多image的格式包括目前使用的docker image的格式；
支持更多的方式來下載image包括對image的可信和驗證熟吏；
容器鏡像管理（管理image的層距糖，文件系統(tǒng)）；
容器進程的生命周期管理牵寺；
CRI所需求的monitoring和logging悍引；
CRI需求的資源隔離

CRI-O不關心的事情

building和singing和pushing容器鏡像到不同的鏡像庫中；
一個通用的用戶可使用的CLI來與CRI-O進行交互帽氓，任何CLI工具的開發(fā)都是用來測試使用的趣斤，在此項目中不進行維護。

實戰(zhàn)篇

如何安裝CRI-O

root@cri-o-1:~# sudo apt-add-repository ppa:projectatomic/ppa

 More info: https://launchpad.net/~projectatomic/+archive/ubuntu/ppa
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keyring `/tmp/tmp2p9fajjs/secring.gpg' created
gpg: keyring `/tmp/tmp2p9fajjs/pubring.gpg' created
gpg: requesting key 7AD8C79D from hkp server keyserver.ubuntu.com
gpg: /tmp/tmp2p9fajjs/trustdb.gpg: trustdb created
gpg: key 7AD8C79D: public key "Launchpad PPA for Project Atomic" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
OK

root@cri-o-1:~# sudo apt-get update -qq

root@cri-o-1:~# sudo apt-get install cri-o-1.15

CRI-O 目前支持的功能

Pod和container的lifecycle
Image lifecycle
CNI網(wǎng)絡集成
Logging
Exec（sync/streaming）
Attach/Detach
Port forwarding
OOM 檢測和匯報
daemon 重啟
支持多種存儲插件（overlay,devicemapper,aufs,btrfs）
Selinux
Seccomp
13.清除容器
支持runc
Gpg check on image pull
Mixed runtimes (runc and Clear Containers)

如何調(diào)試container

使用runc list可以列出當前環(huán)境中所有的container黎休，ID表示containerID PID表示容器的進程ID浓领，其中stopped的容器進程ID為0玉凯。

[root@master0 ~]# runc list
ID                                                                 PID         STATUS      BUNDLE                                                                                                                 CREATED                          OWNER
000d9eb1fd510da73ce8c5cd12223c9bfcc343f465b8b9a04028c59b85b2f8a9   0           stopped     /run/containers/storage/overlay-containers/000d9eb1fd510da73ce8c5cd12223c9bfcc343f465b8b9a04028c59b85b2f8a9/userdata   2019-11-11T08:53:39.787606019Z   root
016e7b606545ed6479b45cc111b58a20f54f6c0064cdb34ba0e56da6715ae6be   0           stopped     /run/containers/storage/overlay-containers/016e7b606545ed6479b45cc111b58a20f54f6c0064cdb34ba0e56da6715ae6be/userdata   2019-11-12T06:14:14.549141586Z   root
03ff0c15e16ae3a23ab657e60ff567041e58d3430c24d679378b850e6a94ba27   31456       running     /run/containers/storage/overlay-containers/03ff0c15e16ae3a23ab657e60ff567041e58d3430c24d679378b850e6a94ba27/userdata   2019-11-11T08:59:08.850697068Z   root
042ed31210e8d51c514e93d08f353c5165064d78367e099998b2e5d3bd59b986   0           stopped     /run/containers/storage/overlay-containers/042ed31210e8d51c514e93d08f353c5165064d78367e099998b2e5d3bd59b986/userdata   2019-11-11T08:52:59.286627769Z   root
05303f0aa04026cad3d216389278ce12d4e5cbb44141703e8e2cb54c7850e628   39237       running     /run/containers/storage/overlay-containers/05303f0aa04026cad3d216389278ce12d4e5cbb44141703e8e2cb54c7850e628/userdata   2019-11-12T06:13:43.119771581Z   root
058a9282710ed7cd2aac5647648530b42fa084496e850f0ba1e1dab15432d7bc   0           stopped     /run/containers/storage/overlay-containers/058a9282710ed7cd2aac5647648530b42fa084496e850f0ba1e1dab15432d7bc/userdata   2019-11-11T08:55:57.856985896Z   root
072fc279b2a9bc7f5b3f62412b32b96860f49e9641f308a2da4d3303a2607ba7   26299       running     /run/containers/storage/overlay-containers/072fc279b2a9bc7f5b3f62412b32b96860f49e9641f308a2da4d3303a2607ba7/userdata   2019-11-12T03:55:27.859988398Z   root
07542e2fd225ce3faa757a22edf8a62bc90befe521fa93ac2d7a4b65121e946d   1868        running     /run/containers/storage/overlay-containers/07542e2fd225ce3faa757a22edf8a62bc90befe521fa93ac2d7a4b65121e946d/userdata   2019-11-11T08:51:47.300206259Z   root

通過containerID我們可以查看container的監(jiān)控進程：

[root@master0 ~]# ps -ef | grep f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381
root      27881      1  0 Nov11 ?        00:00:00 /usr/libexec/crio/conmon -s -c f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381 -n k8s_node-exporter_node-exporter-cbkqp_openshift-monitoring_5b772849-0461-11ea-9404-00000a100c0b_0 -u f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381 -r /usr/bin/runc -b /var/run/containers/storage/overlay-containers/f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381/userdata -p /var/run/containers/storage/overlay-containers/f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381/userdata/pidfile -l /var/log/pods/openshift-monitoring_node-exporter-cbkqp_5b772849-0461-11ea-9404-00000a100c0b/node-exporter/0.log --exit-dir /var/run/crio/exits --socket-dir-path /var/run/crio --log-level error
root      94094  49040  0 02:52 pts/0    00:00:00 grep --color=auto f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381

conmon會負責為每一個container起一個進程來監(jiān)控容器額定運行，從它的啟動參數(shù)我們可以看出镊逝，它會監(jiān)控容器的log壮啊，socket信息嫉鲸，退出信息撑蒜，還可以通過pidfile查看監(jiān)控進程所監(jiān)控的容器的服務進程ID：

#cat /var/run/containers/storage/overlay-containers/f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381/userdata/pidfile
27913

查看容器的服務進程：

[root@master0 ~]# ps -ef | grep 27913
nobody    27913  27881  0 Nov11 ?        00:22:00 /bin/node_exporter --web.listen-address=127.0.0.1:9100 --path.procfs=/host/proc --path.sysfs=/host/sys --path.rootfs=/host/root --collector.filesystem.ignored-mount-points=^/(dev|proc|sys|var/lib/docker/.+)($|/) --collector.filesystem.ignored-fs-types=^(autofs|binfmt_misc|cgroup|configfs|debugfs|devpts|devtmpfs|fusectl|hugetlbfs|mqueue|overlay|proc|procfs|pstore|rpc_pipefs|securityfs|sysfs|tracefs)$ --no-collector.wifi
root     116492  49040  0 03:03 pts/0    00:00:00 grep --color=auto 27913

查看cri-o 的狀態(tài)，cri-o是一個daemon進程

[root@master0 ~]# systemctl status crio
● crio.service - Open Container Initiative Daemon
   Loaded: loaded (/usr/lib/systemd/system/crio.service; disabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/crio.service.d
           └─10-default-env.conf
   Active: active (running) since Mon 2019-11-11 08:47:57 UTC; 2 days ago
     Docs: https://github.com/cri-o/cri-o
 Main PID: 1083 (crio)
    Tasks: 38
   Memory: 540.2M
      CPU: 3h 42min 56.238s
   CGroup: /system.slice/crio.service
           ├─  1083 /usr/bin/crio --enable-metrics=true --metrics-port=9537
           ├─121183 /usr/libexec/crio/conmon -c 6b02031122564f9410db50e61f4694b4c429a89cb16c5bf0f1c136ba4177a14a -n k8s_guard_etcd-quorum-guard-845d699494-sqvn9_openshift-machine-config-operator_c8ba4b6d-0460-11ea-a0f4-00000a1006c9_0 -r /usr/bin/runc -p /tmp/pidfil>
           └─121184 /usr/bin/runc exec -d --pid-file /tmp/pidfile770198600 --process /tmp/exec-process-355304634 6b02031122564f9410db50e61f4694b4c429a89cb16c5bf0f1c136ba4177a14a

Nov 12 04:12:40 master0.gzhifangha.os.fyre.ibm.com crio[1083]: 2019-11-12T04:12:40Z [verbose] Del: openshift-kube-apiserver:installer-9-master0.gzhifangha.os.fyre.ibm.com:openshift-sdn:eth0 {"cniVersion":"0.3.1","name":"openshift-sdn","type":"openshift-sdn"}
Nov 12 04:13:06 master0.gzhifangha.os.fyre.ibm.com crio[1083]: 2019-11-12T04:13:06Z [verbose] Add: openshift-kube-apiserver:revision-pruner-9-master0.gzhifangha.os.fyre.ibm.com:openshift-sdn:eth0 {"cniVersion":"0.3.1","interfaces":[{"name":"eth0","sandbox":"/proc/6>
Nov 12 04:13:07 master0.gzhifangha.os.fyre.ibm.com crio[1083]: 2019-11-12T04:13:07Z [verbose] Del: openshift-kube-apiserver:revision-pruner-9-master0.gzhifangha.os.fyre.ibm.com:openshift-sdn:eth0 {"cniVersion":"0.3.1","name":"openshift-sdn","type":"openshift-sdn"}
Nov 12 06:13:50 master0.gzhifangha.os.fyre.ibm.com crio[1083]: 2019-11-12T06:13:50Z [verbose] Add: kube-system:metering-reader-7rg8z:openshift-sdn:eth0 {"cniVersion":"0.3.1","interfaces":[{"name":"eth0","sandbox":"/proc/39237/ns/net"}],"ips":[{"version":"4","interf>
Nov 12 08:39:28 master0.gzhifangha.os.fyre.ibm.com crio[1083]: 2019-11-12T08:39:28Z [verbose] Add: openshift-kube-apiserver:installer-10-master0.gzhifangha.os.fyre.ibm.com:openshift-sdn:eth0 {"cniVersion":"0.3.1","interfaces":[{"name":"eth0","sandbox":"/proc/65636/>
Nov 12 08:39:39 master0.gzhifangha.os.fyre.ibm.com crio[1083]: 2019-11-12T08:39:39Z [verbose] Del: openshift-controller-manager:controller-manager-rd987:openshift-sdn:eth0 {"cniVersion":"0.3.1","name":"openshift-sdn","type":"openshift-sdn"}
Nov 12 08:40:46 master0.gzhifangha.os.fyre.ibm.com crio[1083]: 2019-11-12T08:40:46Z [verbose] Del: openshift-kube-apiserver:installer-10-master0.gzhifangha.os.fyre.ibm.com:openshift-sdn:eth0 {"cniVersion":"0.3.1","name":"openshift-sdn","type":"openshift-sdn"}
Nov 12 08:41:17 master0.gzhifangha.os.fyre.ibm.com crio[1083]: 2019-11-12T08:41:17Z [verbose] Add: openshift-kube-apiserver:revision-pruner-10-master0.gzhifangha.os.fyre.ibm.com:openshift-sdn:eth0 {"cniVersion":"0.3.1","interfaces":[{"name":"eth0","sandbox":"/proc/>
Nov 12 08:41:18 master0.gzhifangha.os.fyre.ibm.com crio[1083]: 2019-11-12T08:41:18Z [verbose] Del: openshift-kube-apiserver:revision-pruner-10-master0.gzhifangha.os.fyre.ibm.com:openshift-sdn:eth0 {"cniVersion":"0.3.1","name":"openshift-sdn","type":"openshift-sdn"}
Nov 12 08:41:27 master0.gzhifangha.os.fyre.ibm.com crio[1083]: 2019-11-12T08:41:27Z [verbose] Add: openshift-controller-manager:controller-manager-8dnc7:openshift-sdn:eth0 {"cniVersion":"0.3.1","interfaces":[{"name":"eth0","sandbox":"/proc/70871/ns/net"}],"ips":[{">

[root@master0 ~]# runc state f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381
{
  "ociVersion": "1.0.1-dev",
  "id": "f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381",
  "pid": 27913,
  "status": "running",
  "bundle": "/run/containers/storage/overlay-containers/f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381/userdata",
  "rootfs": "/var/lib/containers/storage/overlay/d814fa5be7bbf3b659162caa399fc52ec9bacf3b0e02997c99592d0d3c6922dc/merged",
  "created": "2019-11-11T08:58:15.914588316Z",
  "annotations": {
    "io.kubernetes.container.hash": "a08e7c7d",
    "io.kubernetes.container.name": "node-exporter",
    "io.kubernetes.container.restartCount": "0",
    "io.kubernetes.container.terminationMessagePath": "/dev/termination-log",
    "io.kubernetes.container.terminationMessagePolicy": "File",
    "io.kubernetes.cri-o.Annotations": "{\"io.kubernetes.container.hash\":\"a08e7c7d\",\"io.kubernetes.container.restartCount\":\"0\",\"io.kubernetes.container.terminationMessagePath\":\"/dev/termination-log\",\"io.kubernetes.container.terminationMessagePolicy\":\"File\",\"io.kubernetes.pod.terminationGracePeriod\":\"30\"}",
    "io.kubernetes.cri-o.ContainerID": "f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381",
    "io.kubernetes.cri-o.ContainerType": "container",
    "io.kubernetes.cri-o.Created": "2019-11-11T08:58:15.422124413Z",
    "io.kubernetes.cri-o.IP": "10.16.12.11",
    "io.kubernetes.cri-o.Image": "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:fb559dae37782e6cccb56ffbec74104989979ad6e8b34b1803bb630b4431b3b6",
    "io.kubernetes.cri-o.ImageName": "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:fb559dae37782e6cccb56ffbec74104989979ad6e8b34b1803bb630b4431b3b6",
    "io.kubernetes.cri-o.ImageRef": "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:fb559dae37782e6cccb56ffbec74104989979ad6e8b34b1803bb630b4431b3b6",
    "io.kubernetes.cri-o.Labels": "{\"io.kubernetes.container.name\":\"node-exporter\",\"io.kubernetes.pod.name\":\"node-exporter-cbkqp\",\"io.kubernetes.pod.namespace\":\"openshift-monitoring\",\"io.kubernetes.pod.uid\":\"5b772849-0461-11ea-9404-00000a100c0b\"}",
    "io.kubernetes.cri-o.LogPath": "/var/log/pods/openshift-monitoring_node-exporter-cbkqp_5b772849-0461-11ea-9404-00000a100c0b/node-exporter/0.log",
    "io.kubernetes.cri-o.Metadata": "{\"name\":\"node-exporter\"}",
    "io.kubernetes.cri-o.MountPoint": "/var/lib/containers/storage/overlay/d814fa5be7bbf3b659162caa399fc52ec9bacf3b0e02997c99592d0d3c6922dc/merged",
    "io.kubernetes.cri-o.Name": "k8s_node-exporter_node-exporter-cbkqp_openshift-monitoring_5b772849-0461-11ea-9404-00000a100c0b_0",
    "io.kubernetes.cri-o.ResolvPath": "/var/run/containers/storage/overlay-containers/99d5ee6dd67aed5d4d5cbc476cff80f079a8dd18a8c78baafe3ba4625276a6ac/userdata/resolv.conf",
    "io.kubernetes.cri-o.SandboxID": "99d5ee6dd67aed5d4d5cbc476cff80f079a8dd18a8c78baafe3ba4625276a6ac",
    "io.kubernetes.cri-o.SandboxName": "k8s_POD_node-exporter-cbkqp_openshift-monitoring_5b772849-0461-11ea-9404-00000a100c0b_0",
    "io.kubernetes.cri-o.SeccompProfilePath": "",
    "io.kubernetes.cri-o.Stdin": "false",
    "io.kubernetes.cri-o.StdinOnce": "false",
    "io.kubernetes.cri-o.TTY": "false",
    "io.kubernetes.cri-o.Volumes": "[{\"container_path\":\"/host/proc\",\"host_path\":\"/proc\",\"readonly\":false},{\"container_path\":\"/host/sys\",\"host_path\":\"/sys\",\"readonly\":false},{\"container_path\":\"/host/root\",\"host_path\":\"/\",\"readonly\":true},{\"container_path\":\"/etc/hosts\",\"host_path\":\"/var/lib/kubelet/pods/5b772849-0461-11ea-9404-00000a100c0b/etc-hosts\",\"readonly\":false},{\"container_path\":\"/dev/termination-log\",\"host_path\":\"/var/lib/kubelet/pods/5b772849-0461-11ea-9404-00000a100c0b/containers/node-exporter/d61b4508\",\"readonly\":false},{\"container_path\":\"/var/run/secrets/kubernetes.io/serviceaccount\",\"host_path\":\"/var/lib/kubelet/pods/5b772849-0461-11ea-9404-00000a100c0b/volumes/kubernetes.io~secret/node-exporter-token-7lbm8\",\"readonly\":true}]",
    "io.kubernetes.pod.name": "node-exporter-cbkqp",
    "io.kubernetes.pod.namespace": "openshift-monitoring",
    "io.kubernetes.pod.terminationGracePeriod": "30",
    "io.kubernetes.pod.uid": "5b772849-0461-11ea-9404-00000a100c0b"
  },
  "owner": ""

[root@master0 ~]# runc exec f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381 ps
   PID TTY          TIME CMD
 27913 ?        00:22:02 node_exporter
 28674 ?        00:00:27 kube-rbac-proxy
 43479 ?        00:00:00 startup.sh
 43535 ?        00:00:00 npm
 43571 ?        00:01:08 nginx
 43572 ?        00:00:00 nginx
 43588 ?        00:04:15 node
126089 ?        00:00:00 ps

[root@master0 ~]# systemctl status crio-f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381.scope
● crio-f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381.scope - libcontainer container f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381
   Loaded: loaded (/run/systemd/transient/crio-f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381.scope; transient)
Transient: yes
   Active: active (running) since Mon 2019-11-11 08:58:15 UTC; 2 days ago
    Tasks: 18 (limit: 1024)
   Memory: 19.7M
      CPU: 22min 2.475s
   CGroup: /kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod5b772849_0461_11ea_9404_00000a100c0b.slice/crio-f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381.scope
           └─27913 /bin/node_exporter --web.listen-address=127.0.0.1:9100 --path.procfs=/host/proc --path.sysfs=/host/sys --path.rootfs=/host/root --collector.filesystem.ignored-mount-points=^/(dev|proc|sys|var/lib/docker/.+)($|/) --collector.filesystem.ignored-fs->

Nov 11 08:58:15 master0.gzhifangha.os.fyre.ibm.com systemd[1]: Started libcontainer container f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381.

[root@master0 ~]# systemctl status crio-conmon-f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381.scope
● crio-conmon-f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381.scope
   Loaded: loaded (/run/systemd/transient/crio-conmon-f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381.scope; transient)
Transient: yes
   Active: active (running) since Mon 2019-11-11 08:58:15 UTC; 2 days ago
    Tasks: 2 (limit: 26213)
   Memory: 1.0M
      CPU: 61ms
   CGroup: /kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod5b772849_0461_11ea_9404_00000a100c0b.slice/crio-conmon-f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381.scope
           └─27881 /usr/libexec/crio/conmon -s -c f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381 -n k8s_node-exporter_node-exporter-cbkqp_openshift-monitoring_5b772849-0461-11ea-9404-00000a100c0b_0 -u f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16>

Nov 11 08:58:15 master0.gzhifangha.os.fyre.ibm.com systemd[1]: Started crio-conmon-f784bca78cbfc88ac0a1aa11ac87e70d5bee8cdecc5b16845658fd04afa0b381.scope.

Podman

Podman是Redhat公司推出的容器管理工具玄渗，Podman起初是CRI-O的一部分座菠，后來單獨分離出來叫做libpod，使用Podman的命令幾乎和docker類似(我想這是Redhat公司大力推舉Podman替換Docker的同時又不是用戶體驗的詭計)藤树，你可以通過alias docker=podman來替換Docker浴滴。
Podman在結構上與Docker不同，Podman沒有使用daemon的方式去創(chuàng)建容器岁钓，而是直接調(diào)用OCI runtime升略，比如runc，Podman由兩部分組成屡限，Podman CLI 和conmon品嚣，Podman CLI方便用戶交互，conmon負責container runtime钧大，主要包括監(jiān)控翰撑，日志，TTY分配等啊央，簡而言之眶诈，conmon是所有容器進程的父進程。

[root@cephrook-cephMater ~]# pstree -p
systemd(1)-+-agetty(1299)
           |-conmon(1954)-+-nginx(1975)---nginx(1988)
           |              `-{conmon}(1956)

基本常用命令：

podman info
podman version
podman images
podman rmi
podman ps

# podman info
host:
  BuildahVersion: 1.9.0
  Conmon:
    package: podman-1.4.4-4.el7.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 0.3.0, commit: unknown'
  Distribution:
    distribution: '"rhel"'
    version: "7.7"
  MemFree: 15117926400
  MemTotal: 16656146432
  OCIRuntime:
    package: runc-1.0.0-65.rc8.el7.x86_64
    path: /usr/bin/runc          //創(chuàng)建容器的后端runc
    version: 'runc version spec: 1.0.1-dev'
  SwapFree: 8455712768
  SwapTotal: 8455712768
  arch: amd64
  cpus: 8
  hostname: cephrook-cephMater.fyre.ibm.com
  kernel: 3.10.0-1062.el7.x86_64
  os: linux
  rootless: false
  uptime: 23h 8m 52.84s (Approximately 0.96 days)
registries:
  blocked: null
  insecure: null
  search:
  - registry.access.redhat.com     //拉取鏡像的倉庫順序
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.centos.org
store:
  ConfigFile: /etc/containers/storage.conf
  ContainerStore:
    number: 6
  GraphDriverName: overlay
  GraphOptions: null
  GraphRoot: /var/lib/containers/storage   //存儲容器的metadata
  GraphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 5
  RunRoot: /var/run/containers/storage
  VolumePath: /var/lib/containers/storage/volumes

查看某個鏡像的詳細信息：

cat /var/lib/containers/storage/overlay-images/images.json | python -m json.tool

啟動一個容器：

# podman run -p 80:80 --name=web -d nginx
416c3f3964a0ac6731a7864090131c44baead4f251ab914b718cb66ce1089bfa

# podman ps
CONTAINER ID  IMAGE                           COMMAND               CREATED        STATUS            PORTS               NAMES
416c3f3964a0  docker.io/library/nginx:latest  nginx -g daemon o...  5 seconds ago  Up 5 seconds ago  0.0.0.0:80->80/tcp  web

# ps -ef | grep nginx
root     23477 23465  0 00:51 ?        00:00:00 nginx: master process nginx -g daemon off;
101      23491 23477  0 00:51 ?        00:00:00 nginx: worker process
root     23541  8898  0 00:52 pts/2    00:00:00 grep --color=auto nginx

# pstree -H 23477
systemd-+-agetty
        |-conmon-+-nginx---nginx
        |        `-{conmon}

可見nginx進程ID是23477瓜饥，它的父進程是23465逝撬，也就是conmon進程，conmon進程的父進程是systemd乓土，

ps -ef | grep 23465
root     23465     1  0 00:51 ?        00:00:00 /usr/libexec/podman/conmon -s -c 416c3f3964a0ac6731a7864090131c44baead4f251ab914b718cb66ce1089bfa -u 416c3f3964a0ac6731a7864090131c44baead4f251ab914b718cb66ce1089bfa -n web -r /usr/bin/runc -b /var/lib/containers/storage/overlay-containers/416c3f3964a0ac6731a7864090131c44baead4f251ab914b718cb66ce1089bfa/userdata -p /var/run/containers/storage/overlay-containers/416c3f3964a0ac6731a7864090131c44baead4f251ab914b718cb66ce1089bfa/userdata/pidfile --exit-dir /var/run/libpod/exits --exit-command /usr/bin/podman --exit-command-arg --root --exit-command-arg /var/lib/containers/storage --exit-command-arg --runroot --exit-command-arg /var/run/containers/storage --exit-command-arg --log-level --exit-command-arg error --exit-command-arg --cgroup-manager --exit-command-arg systemd --exit-command-arg --tmpdir --exit-command-arg /var/run/libpod --exit-command-arg --runtime --exit-command-arg runc --exit-command-arg --storage-driver --exit-command-arg overlay --exit-command-arg container --exit-command-arg cleanup --exit-command-arg 416c3f3964a0ac6731a7864090131c44baead4f251ab914b718cb66ce1089bfa --socket-dir-path /var/run/libpod/socket -l k8s-file:/var/lib/containers/storage/overlay-containers/416c3f3964a0ac6731a7864090131c44baead4f251ab914b718cb66ce1089bfa/userdata/ctr.log --log-level error
root     23477 23465  0 00:51 ?        00:00:00 nginx: master process nginx -g daemon off;
root     23642  8898  0 00:54 pts/2    00:00:00 grep --color=auto 23465

Podman不使用CRL直接通信宪潮，Podman使用runc創(chuàng)建容器，使用storage管理鏡像的存儲帐我。實際上Podman使用conmon創(chuàng)建容器坎炼，conmon使用runc創(chuàng)建容器，并且監(jiān)控runc拦键。Podman能夠退出然后再重新連接上conmon與容器進行通信谣光，當容器啟動之后，runc就停止運行芬为。

Podman does not communicate with using the CRI protocol. Instead, Podman creates containers using runc, and manages storage using containers/storage. Technically, Podman launches conmon which launches and monitors the OCI Runtime (runc). Podman can exit and later reconnect to conmon to talk to the container. Runc stops running once the container starts.
https://blog.openshift.com/crictl-vs-podman/

和Docker不同萄金，Podman不依賴容器運行引擎（Docker,CRI-O）,Podman在磁盤上直接創(chuàng)建容器進程并做必要的修改蟀悦。Podman依賴containers/images庫來從鏡像倉庫拉取鏡像，使用containers/storage來在磁盤上管理鏡像氧敢。CRI-O也是如此日戈，所以通過Podman拉取的鏡像也可以通過CRI-O讀取到。

最重要的是孙乖，Podman完全獨立于CRI-O浙炼，但可以管理CRI-O的存儲后端。最終唯袄，它將能夠完全處理CRI-O數(shù)據(jù)弯屈，并能夠管理后臺的內(nèi)容。關于使用Podman診斷CRI-O問題的一件好事是恋拷，即使kubelet或CRI-O出現(xiàn)問題资厉，它也可以工作。只要CRI-O正在運行蔬顾，Crictl實用程序就可以幫助您診斷和理解CRI協(xié)議宴偿。

兩種工具都是管理員在容器工具庫中的絕佳補充。
Podman 創(chuàng)建Pod

# podman pod create -n podtest
3a4525137b6a114d1bfd94513bbdff4a0875615e515cebcca01b2ef3d70760d2

容器相關的概念

要理解容器相關的術語诀豁，首先要從技術的角度正確的理解什么是容器窄刘。一個容器實際上
是兩個不同的東西。像普通的Linux進程且叁，容器實際上有兩個狀態(tài)-rest ,running都哭。當一
個容器處于rest狀態(tài)，它呈現(xiàn)的形式是一個保存在磁盤上的文件逞带，這涉及到我們所說容器
Image和容器Repository欺矫。當你啟動一個容器之后，容器引擎解壓所需要的文件和metadata
把這些數(shù)據(jù)交給Linux kernel展氓。啟動一個容器非常像啟動一個普通的Linux進程穆趴，并且這個過程
也需要制定一系列API,通過API來調(diào)用Linux kernel。這些API調(diào)用通常會啟動額外的隔離遇汞，并
掛載容器鏡像中文件的副本未妹。一旦容器運行起來，容器的表現(xiàn)就是一個Linux 進程空入。
啟動容器的過程以及磁盤上的映像格式是有一系列的標準定義和控制的络它。

image.png

有一系列的容器鏡像格式（Docker,Appc,LXD）,但是工業(yè)上制定了一些列的標準來規(guī)范鏡像
的格式，這個規(guī)范就叫做Open Container Initiative（OCI）歪赢，OCI包含了什么呢化戳？它包含了
容器鏡像的格式的詳細定義，包括存儲在磁盤上的容器鏡像的格式和原數(shù)據(jù)（類似定義硬件的架構
和操作系統(tǒng)類型）埋凯。

也有一系列的容器引擎例如Docker,CRI-O,LXC点楼。容器引擎把容器鏡像變成容器扫尖，這是一個什么
過程呢？這是由OCI中容器運行時規(guī)范定義的掠廓，是由RunC這個項目實現(xiàn)的

Container runtime(容器運行時)

在OCI標準下實現(xiàn)的Container Runtime是runc,也有其它的container runtime比如：crun,katacontainers
Docker CRI-O 容器引擎都依賴runc來創(chuàng)建容器换怖。
容器運行時的作用：

使用容器引擎提供的掛載點(可以是一個空目錄)
使用容器引擎提供的原數(shù)據(jù)（config.json）
與kernel進行通信來啟動容器進程（clone 系統(tǒng)調(diào)用）
設置cgroups
設置SELinux Policy
設置啊App Armor 規(guī)則
以下講一些歷史信息，起初創(chuàng)建Docker引擎時蟀瞧，它依賴LXC作為容器運行時沉颂。后來，Docker團隊開發(fā)
了自己的名為libcontainer的庫來啟動容器黄橘。該庫是用Golang編寫的兆览，并已編譯為原始Docker引擎屈溉。
最終塞关，在創(chuàng)建OCI時，Docker捐贈了libcontainer代碼并將其轉(zhuǎn)變?yōu)橐粋€名為runc的獨立實用程序子巾。
現(xiàn)在帆赢，runc是參考實現(xiàn)，并被其他容器引擎（例如CRI-O）使用线梗。在最低級別上椰于，無論容器引擎如何，
這都可以始終啟動容器仪搔。 Runc是一個非常簡潔實用的程序瘾婿，希望為其提供掛載點（目錄）
和元數(shù)據(jù)（config.json）。

Container engine（容器引擎）

容器引擎是一種軟件烤咧，它接受用戶請求偏陪，包括命令行選項，提取圖像煮嫌，并從終端用戶的角度運行容器笛谦。
有很多容器引擎，包括docker昌阿，RKT饥脑，CRI-O和LXD。此外懦冰，許多云提供商灶轰，平臺即服務（PaaS）和
容器平臺都有自己的內(nèi)置容器引擎，這些引擎使用Docker或OCI兼容的容器鏡像刷钢。
具有行業(yè)標準的容器鏡像格式可以在所有這些不同平臺之間實現(xiàn)互操作性笋颤。

更深入地講，大多數(shù)容器引擎實際上并不運行容器闯捎，它們依賴于與OCI兼容的容器運行時椰弊，例如runc许溅。
通常，容器運行時負責：

處理用戶輸入
通過容器編排API處理輸入
使用圖形驅(qū)動程序（塊或文件秉版，取決于驅(qū)動程序）擴展解壓縮并擴展磁盤上的容器映像
準備容器掛載點贤重，通常在寫時復制存儲上（再次取決于驅(qū)動程序還是塊或文件）
準備將傳遞到容器Container Runtime的元數(shù)據(jù)以正確啟動Container
調(diào)用容器運行時

以下講一些歷史信息，起初創(chuàng)建Docker引擎時清焕，它依賴LXC作為容器運行時并蝗。后來，Docker團隊開發(fā)
了自己的名為libcontainer的庫來啟動容器秸妥。該庫是用Golang編寫的滚停，并已編譯為原始Docker引擎。
最終粥惧，在創(chuàng)建OCI時键畴，Docker捐贈了libcontainer代碼并將其轉(zhuǎn)變?yōu)橐粋€名為runc的獨立實用程序。
現(xiàn)在突雪，runc是參考實現(xiàn)起惕，并被其他容器引擎（例如CRI-O）使用。在最低級別上咏删，無論容器引擎如何惹想，
這都可以始終啟動容器。 Runc是一個非常簡潔實用的程序督函，希望為其提供掛載點（目錄）
和元數(shù)據(jù)（config.json）嘀粱。

Conmon

conmon(container monitorring)是一個監(jiān)控程序,用來作為每個容器的容器引擎（podman ,cri-o）和OCI運行時（runc）之間通信的工具。
當conmon啟動時辰狡，它會進行兩次fork以使其與啟動它的父進程進行守護和分離锋叨。然后，它將運行時作為其子進程運行搓译。這允許管理進程在前臺消失悲柱，但仍然能夠監(jiān)視并連接到子進程（容器）。
當容器運行時些己，conmon做兩件事情：

提供一個用于連接到容器的socket豌鸡，保持容器的標準流打開并通過套接字轉(zhuǎn)發(fā)它們；
將容器流的內(nèi)容寫入日志文件（或系統(tǒng)日志）段标，以便在容器死亡后可以讀取它們涯冠。
最后，一旦容器死亡逼庞，conmon將記錄其退出時間和推出碼蛇更，以供管理程序讀取。
conmon用C語言編寫，旨在減少內(nèi)存占用派任，旨在由容器管理庫運行砸逊。本質(zhì)上，conmon是容器可以擁有的最小守護程序掌逛。

最后編輯于：2019.11.20 17:21:57

?著作權歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者

人面猴
序言：七十年代末师逸，一起剝皮案震驚了整個濱河市，隨后出現(xiàn)的幾起案子豆混，更是在濱河造成了極大的恐慌篓像，老刑警劉巖，帶你破解...
沈念sama閱讀 211,194評論 6贊 490
死咒
序言：濱河連續(xù)發(fā)生了三起死亡事件皿伺，死亡現(xiàn)場離奇詭異员辩，居然都是意外死亡，警方通過查閱死者的電腦和手機鸵鸥，發(fā)現(xiàn)死者居然都...
沈念sama閱讀 90,058評論 2贊 385
救了他兩次的神仙讓他今天三更去死
文/潘曉璐我一進店門奠滑，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人脂男，你說我怎么就攤上這事养叛。” “怎么了宰翅？”我有些...
開封第一講書人閱讀 156,780評論 0贊 346
道士緝兇錄：失蹤的賣姜人
文/不壞的土叔我叫張陵，是天一觀的道長爽室。經(jīng)常有香客問我汁讼，道長，這世上最難降的妖魔是什么阔墩？我笑而不...
開封第一講書人閱讀 56,388評論 1贊 283
?港島之戀（遺憾婚禮）
正文為了忘掉前任嘿架，我火速辦了婚禮，結果婚禮上啸箫，老公的妹妹穿的比我還像新娘耸彪。我一直安慰自己，他們只是感情好忘苛，可當我...
茶點故事閱讀 65,430評論 5贊 384
惡毒庶女頂嫁案：這布局不是一般人想出來的
文/花漫我一把揭開白布蝉娜。她就那樣靜靜地躺著，像睡著了一般扎唾。火紅的嫁衣襯著肌膚如雪召川。梳的紋絲不亂的頭發(fā)上，一...
開封第一講書人閱讀 49,764評論 1贊 290
城市分裂傳說
那天胸遇，我揣著相機與錄音荧呐，去河邊找鬼。笑死，一個胖子當著我的面吹牛倍阐，可吹牛的內(nèi)容都是我干的概疆。我是一名探鬼主播，決...
沈念sama閱讀 38,907評論 3贊 406
雙鴛鴦連環(huán)套：你想象不到人心有多黑
文/蒼蘭香墨我猛地睜開眼峰搪，長吁一口氣：“原來是場噩夢啊……” “哼届案！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起罢艾，我...
開封第一講書人閱讀 37,679評論 0贊 266
萬榮殺人案實錄
序言：老撾萬榮一對情侶失蹤楣颠，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后咐蚯，有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體童漩，經(jīng)...
沈念sama閱讀 44,122評論 1贊 303
?護林員之死
正文獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛以下內(nèi)容為張勛視角年9月15日...
茶點故事閱讀 36,459評論 2贊 325
?白月光啟示錄
正文我和宋清朗相戀三年春锋，在試婚紗的時候發(fā)現(xiàn)自己被綠了矫膨。大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
茶點故事閱讀 38,605評論 1贊 340
活死人
序言：一個原本活蹦亂跳的男人離奇死亡期奔，死狀恐怖侧馅，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情呐萌，我是刑警寧澤馁痴，帶...
沈念sama閱讀 34,270評論 4贊 329
?日本核電站爆炸內(nèi)幕
正文年R本政府宣布，位于F島的核電站肺孤，受9級特大地震影響罗晕，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜赠堵，卻給世界環(huán)境...
茶點故事閱讀 39,867評論 3贊 312
男人毒藥：我在死后第九天來索命
文/蒙蒙一小渊、第九天我趴在偏房一處隱蔽的房頂上張望。院中可真熱鬧茫叭，春花似錦酬屉、人聲如沸。這莊子的主人今日做“春日...
開封第一講書人閱讀 30,734評論 0贊 21
一樁弒父案呐萨，背后竟有這般陰謀
文/蒼蘭香墨我抬頭看了看天上的太陽。三九已至吗垮，卻和暖如春垛吗，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背烁登。一陣腳步聲響...
開封第一講書人閱讀 31,961評論 1贊 265
情欲美人皮
我被黑心中介騙來泰國打工怯屉，沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留蔚舀，地道東北人。一個月前我還...
沈念sama閱讀 46,297評論 2贊 360
代替公主和親
正文我出身青樓锨络，卻偏偏與公主長得像赌躺，于是被迫代替她去往敵國和親。傳聞我的和親對象是個殘疾皇子羡儿，可洞房花燭夜當晚...
茶點故事閱讀 43,472評論 2贊 348

CRI-O vs Podman vs Docker vs CRI-containerd

Docker

CRI-containerd

CRI-O的范圍

CRI-O不關心的事情

實戰(zhàn)篇

如何安裝CRI-O

CRI-O 目前支持的功能

如何調(diào)試container

Podman

容器相關的概念

Container runtime(容器運行時)

Container engine（容器引擎）

Conmon

推薦閱讀更多精彩內(nèi)容