閱讀提示｜本文大概2000字 閱讀需要20分鐘
CRI-O的誕生
開源界已經轉向open containers 已有一段時間了。無論是在Kubernetes還是更低層中，容器標準都在各個層面孕育了創新生態系統。
一切始於2015年6月成立「 Open Containers Initiative」。這項早期工作標準化了容器映像和運行時規範。這些保證了工具可以針對容器映像以及如何運行它們以單一格式進行標準化。後來，添加了分發規範，允許各地的用戶自由共享容器映像。
接下來，Kubernetes社區在Container Runtime Interface (CRI).的可插拔接口上進行了標準化。這使Kubernetes用戶可以插入除Docker之外的其他容器引擎。
來自Red Hat和Google的工程師認識到市場對容器引擎的需求，該容器引擎可以通過CRI協議接受來自Kubelet的請求，並啟動符合上述OCI規範的容器。CRI-O誕生了。
CRI-O和CoreOS的創新
使用OpenShift 4時，默認容器引擎已從Docker遷移到CRI-O，從而提供了精簡，穩定的容器運行時，該運行時與Kubernetes步調一致。這極大地簡化了集群的支持和配置。作為OpenShift 4的一部分，容器引擎和主機的所有配置和管理都將自動化。
使用OpenShift 4，無需登錄到各個容器主機並安裝容器引擎、配置存儲、配置註冊表伺服器以進行搜索或配置網絡。Kubernetes始終使用戶能夠通過定義所需的狀態並使用Controller來確保實際狀態與定義的狀態儘可能匹配，從而管理應用程式。這種定義的狀態，實際狀態方法對於開發人員和操作人員都是強大的。開發人員可以定義所需的狀態，然後將其作為YAML或JSON文件交給操作員，然後操作員可以使用完全相同的定義實例化生產環境中的應用程式。
通過在平臺中使用Operators，OpenShift 4為管理RHEL CoreOS和CRI-O帶來了定義的狀態，實際狀態範例。作業系統和容器引擎的配置和版本控制任務由 Machine Config Operator（MCO）自動執行。MCO通過以全自動方式處理安裝的最後一英裡以及Day2的操作，極大地簡化了集群管理員的工作。這使OpenShift 4成為真正的雲平臺。稍後再詳細介紹。
運行容器
自版本3.7起，用戶可以選擇在OpenShift中使用CRI-O（作為技術預覽版），而從版本3.9（通常）（受支持）開始使用。從3.10版開始，紅帽還一直在OpenShift Online中針對生產工作負載運行CRI-O。這為CRI-O團隊提供了在大型Kubernetes集群中大規模運行容器的豐富經驗。要了解Kubernetes如何使用CRI-O的基本概念，請看以下架構圖：
CRI-O通過在供應新節點以及發布新版本的OpenShift時保持整個頂層處於鎖定狀態，從而簡化了新容器主機的製造。一起修訂整個平臺可以進行事務更新/回滾，還可以防止容器主機內核，容器引擎，Kubelet和Kubernetes Master之間的依賴關係出現死鎖。當平臺的所有組件都一起受版本控制時，從A點到B點總會有一條清晰的路徑。這將導致更輕鬆的更新，更好的安全性，更好的性能責任制以及更少的升級和新版本成本。
如前所述，利用Machine Config Operator在OpenShift 4中管理容器主機和容器引擎可以實現Kubernetes前所未有的更高水平的自動化水平。為了演示，讓我們展示如何將更改部署到crio.conf文件。不要迷失術語，只專注於結果。
為了演示，讓我們創建一個所謂的容器運行時配置。可以將其視為代表CRI-O的配置的Kubernetes資源。實際上，它是MachineConfig的專用版本，它表示在OpenShift集群中部署到RHEL CoreOS計算機的任何配置。
已經實現了稱為ContainerRuntimeConfig的自定義資源，以使集群管理員可以輕鬆調整CRI-O。它甚至功能強大到可以僅根據所謂的MachineConfigPool將其應用於某些節點。可以將這視為一組功能相同的機器。
首先，CRIO的配置文件在OCP節點的/etc/crio/crio.conf中。OCP4的Master和Worker節點默認使用CoreOS，這是不可變基礎架構。因此，我們如果想改這個配置文件的內容，通過CRD的方式修改即可。我們查看這個配置文件中的配置內容：
[root@master-0 ~]# cat /etc/crio/crio.conf |grep -v "#" | sed '/^$/d'
[crio]
log_dir = "/var/log/crio/pods"
version_file = "/var/run/crio/version"
version_file_persist = "/var/lib/crio/version"
[crio.api]
listen = "/var/run/crio/crio.sock"
host_ip = ""
stream_address = ""
stream_port = "10010"
stream_enable_tls = false
stream_tls_cert = ""
stream_tls_key = ""
stream_tls_ca = ""
grpc_max_send_msg_size = 16777216
grpc_max_recv_msg_size = 16777216
[crio.runtime]
default_runtime = "runc"
no_pivot = false
conmon = "/usr/libexec/crio/conmon"
conmon_cgroup = "pod"
conmon_env = [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
]
default_env = [
"NSS_SDB_USE_CACHE=no",
]
selinux = true
seccomp_profile = ""
apparmor_profile = "crio-default"
cgroup_manager = "systemd"
default_capabilities = [
"CHOWN",
"DAC_OVERRIDE",
"FSETID",
"FOWNER",
"NET_RAW",
"SETGID",
"SETUID",
"SETPCAP",
"NET_BIND_SERVICE",
"SYS_CHROOT",
"KILL",
]
default_sysctls = [
]
additional_devices = [
]
hooks_dir = [
"/etc/containers/oci/hooks.d",
]
default_mounts = [
]
pids_limit = 1024
log_size_max = -1
log_to_journald = false
container_exits_dir = "/var/run/crio/exits"
container_attach_socket_dir = "/var/run/crio"
bind_mount_prefix = ""
read_only = false
log_level = "info"
uid_mappings = ""
gid_mappings = ""
ctr_stop_timeout = 0
manage_network_ns_lifecycle = false
[crio.runtime.runtimes.runc]
runtime_path = ""
runtime_type = "oci"
runtime_root = "/run/runc"
[crio.image]
default_transport = "docker://"
global_auth_file = "/var/lib/kubelet/config.json"
pause_image = "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:1428f0d9146362d35d6bced979aca00a669ef89903014b0764b5191c18da5ff0"
pause_image_auth_file = "/var/lib/kubelet/config.json"
pause_command = "/usr/bin/pod"
signature_policy = ""
image_volumes = "mkdir"
[crio.network]
network_dir = "/etc/kubernetes/cni/net.d/"
plugin_dirs = [
"/var/lib/cni/bin",
]
[crio.metrics]
enable_metrics = true
metrics_port = 9537
我們通過crd的方式，在K8S層面修改配置中的pidsLimit（初始為1024）和logLevel（初始為info）:
[root@master-0 ~]# cat /etc/crio/crio.conf |grep -v "#" | sed '/^$/d' |grep -i log
log_level = "info"
[root@master-0 ~]# cat /etc/crio/crio.conf |grep -v "#" | sed '/^$/d' |grep -i pids
pids_limit = 1024
vi ContainerRuntimeConfig.yaml
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
name: set-log-and-pid
spec:
machineConfigPoolSelector:
matchLabels:
debug-crio: config-log-and-pid
containerRuntimeConfig:
pidsLimit: 2048
logLevel: debug現在，將其提交給Kubernetes集群並驗證它是否已創建。注意，它看起來與任何其他Kubernetes資源一樣：
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfigNAME AGE
set-log-and-pid 22h創建ContainerRuntimeConfig之後，我們必須修改其中一個MachineConfigPool，以告訴Kubernetes我們希望將此配置應用於集群中的特定計算機組。在這種情況下，我們將為Master修改MachineConfigPool：oc edit MachineConfigPool/master
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""加在這個位置：此時，MCO開始為群集製造一個新的crio.conf文件。ContainerRuntimeConfig只是MachineConfig的專用版本，因此我們可以通過查看呈現的MachineConfigs來查看輸出：oc get MachineConfigs | grep rendered
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h我們可以查看一個Wroker節點最多運行容器的適量：python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pidpids_limit = 2048
現在，驗證它是否已部署到主節點。首先，獲取集群中節點的列表：oc get node | grep master
Output:
ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1檢查部署的文件。您會注意到它已使用我們在ContainerRuntimeConfig資源中指定的新pid和debug指令進行了更新。oc debug node/ip-10-0-135-153.us-east-2.compute.internal -- cat /host/etc/crio/crio.conf | egrep 'debug||pid』
...
pids_limit = 2048
...
log_level = "debug"
所有這些更改都是在不運行SSH的情況下對群集進行的。一切都是通過與Kuberentes大師溝通來完成的。僅主節點配置有這些新參數。工作節點未更改，證明了已定義狀態的值，Kubernetes應用於容器主機和具有可互換零件的容器引擎的實際狀態方法。
上面的演示重點介紹了對具有三個工作節點的小型OpenShift Container Platform 4集群或具有3000的大型生產實例進行更改的能力。這兩種方法的工作量相同-數量不多-一個ContainerRuntimeConfig文件和一個標籤更改到MachineConfigPool。而且，您可以在整個生命周期內使用任何版本的基於OpenShift Container Platform 4.X的Kubernetes。那是強大的。
通常，技術公司的步伐如此之快，以至於我們無法很好地解釋為什麼我們為基礎組件選擇技術。容器引擎一直以來都是用戶直接與之交互的組件。由於容器的流行合法地從容器引擎開始，因此用戶經常會對它們產生個人興趣。值得一提的是，為什麼紅帽選擇了CRI-O。容器已經發展，現在的重點完全放在業務流程上，我們發現CRI-O可以在OpenShift 4中提供最佳體驗。