将Kubernetes的容器运行时替换为CRI-O
首先
树莓派的“Home Kubernetes”项目，我打算考虑将容器运行时从cri-o换成crio。之前我们已经在文章中提到过，使用crio来新增节点是可行的。但是在删除和加入节点时，无法继承之前的运行时间。为了保留运行时间，我希望尝试将其切换到crio。
前提和前期准备
考虑到使用ceph，因此我们要从其他来源构建内核。但是，我认为使用发行版提供的内核也不会有太大的差别。
接下来，作为准备工作，我们将对其进行隔离再进行排水处理。(我们已经删除了指定节点的Pod。)
$ kubectl get nodes -o wide | grep chiya
chiya Ready worker 449d v1.22.0 10.0.0.5 <none> Debian GNU/Linux 10 (buster) 5.10.52-v8+ docker://20.10.8
$ kubectl cordon chiya
$ kubectl drain chiya --ignore-daemonsets
$ kubectl get nodes | grep chiya
chiya Ready,SchedulingDisabled worker 449d v1.22.0
将docker更改为crio
我会登录到目标节点(chiya)并成为root。
接下来将在root权限下进行操作。
删除Docker
再见，Docker。
# systemctl stop docker.socket
# systemctl stop docker
# apt remove docker-ce docker-ce-cli
# apt autoremove
安装Crio和Podman。
这是某种官方步骤加上额外的α。
# OS=Debian_10
# VERSION=1.22:1.22.1
# curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
# curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
# cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
> deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
> EOF
deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/1.22:1.22.1/Debian_10/ /
# cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
> deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
> EOF
deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /
# perl -pi -e 's/22:/22:\//' /etc/apt/sources.list.d/devel\:kubic\:libcontainers\:stable\:cri-o\:1.22\:1.22.1.list
# echo 'deb http://deb.debian.org/debian buster-backports main' >> /etc/apt/sources.list
# apt update
# apt -t buster-backports install libseccomp2
# apt install cri-o cri-o-runc podman-rootless
Crio相关配置和启动
我們將進行操作系統和kubelet的設定。
# systemctl enable crio
# cat <<EOF > /etc/sysctl.d/k8s.conf
> net.bridge.bridge-nf-call-ip6tables = 1
> net.bridge.bridge-nf-call-iptables = 1
> net.ipv4.ip_forward = 1
> vm.max_map_count = 262144
> EOF
# echo "br_netfilter" >> /etc/modules
# echo "KUBELET_EXTRA_ARGS=--cgroup-driver=systemd" >> /etc/default/kubelet
# echo 'KUBELET_KUBEADM_ARGS="--container-runtime=remote --container-runtime-endpoint=/var/run/crio/crio.sock"' > /var/lib/kubelet/kubeadm-flags.env
操作系统重新启动。
# reboot
一旦启动，我们可以使用kubectl命令行工具从可用的客户端进行uncordon操作。
$ kubectl uncordon chiya
$ kubectl get nodes -o wide | grep chiya
chiya Ready worker 449d v1.22.0 10.0.0.5 <none> Debian GNU/Linux 10 (buster) 5.10.52-v8+ cri-o://1.22.1
一切没事，工作时间顺利切换到了crio！
补充（2022年8月15日）
在进行从kubeadm升级到1.24时，我确认需要将节点资源的annotations中的kubeadm.alpha.kubernetes.io/cri-socket更改为crio的路径。
$ kubectl get nodes/chino -o yaml
apiVersion: v1
kind: Node
metadata:
annotations:
:
kubeadm.alpha.kubernetes.io/cri-socket: unix:///var/run/crio/crio.sock
:
赠品
我不确定是否与环境有关，但是由于crio节点经常出现问题，我将把以前遇到的情况记录下来供参考。
重新启动操作系统后，可能会出现启动的 Pod 之间无法通信的情况。因此，最好是先删除节点上的 Pod。特别是删除 flannel 和 node-exporter 的 Pod，以便通过自我修复机制重新生成。RESTARTS 为 0 的话也更美观一些。
$ kubectl get pods -o wide -A | grep chiya
kube-system kube-flannel-ds-cqv5m 1/1 Running 0 9m25s 10.0.0.5 chiya <none> <none>
kube-system kube-proxy-cbl45 1/1 Running 0 8m34s 10.0.0.5 chiya <none> <none>
monitoring node-exporter-qhdwf 2/2 Running 0 9m1s 10.0.0.5 chiya <none> <none>
如果存在没有进行SSL化的本地注册表服务器，则可能需要在crio.conf中进行设置。
# cat /etc/crio/crio.conf
[crio.image]
registries = ['docker.io', 'quay.io', 'localhost:30500']
insecure_registries = ['localhost:30500']
据说在一些Pod中使用了Elasticsearch之类的容器，在crio节点中需要在securityContext中添加SYS_CHROOT来进行chroot操作。
securityContext:
capabilities:
add: ["SYS_CHROOT"]
可以在 Podman 中检查容器的镜像，但无法检查 ps。基本上请使用 crictl。
如果想要进行容器的构建，可以使用 Podman 进行 Docker 兼容操作。
# podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
quay.io/prometheus/node-exporter latest bb203ba967a8 25 hours ago 22 MB
k8s.gcr.io/kube-proxy v1.22.0 fef37187b238 4 months ago 99.4 MB
quay.io/coreos/flannel v0.14.0 85fc911ceba5 6 months ago 68.1 MB
k8s.gcr.io/pause 3.5 f7ff3c404263 8 months ago 491 kB
docker.io/ccrisan/motioneye master-armhf 611591554283 18 months ago 331 MB
docker.io/carlosedp/kube-rbac-proxy v0.5.0 f5fb70afc410 20 months ago 44.8 MB
# crictl images
IMAGE TAG IMAGE ID SIZE
docker.io/carlosedp/kube-rbac-proxy v0.5.0 f5fb70afc410c 44.8MB
docker.io/ccrisan/motioneye master-armhf 6115915542836 331MB
k8s.gcr.io/kube-proxy v1.22.0 fef37187b2389 99.4MB
k8s.gcr.io/pause 3.5 f7ff3c4042631 491kB
quay.io/coreos/flannel v0.14.0 85fc911ceba5a 68.1MB
quay.io/prometheus/node-exporter latest bb203ba967a80 22MB
# crictl ps -a
CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT POD ID
63458a82e4d7d docker.io/ccrisan/motioneye@sha256:1d7abea3e92e8cc3de1072a0c102a9d91ef2aea2a285d7863b1a5dadd61a81e1 23 minutes ago Running motioneye 0 2dc18fe53add2
4803f8ed3f145 fef37187b2389b314196fc3dfaabd8e9a4d2124cc497ac672743ecb7c27d51e1 38 minutes ago Running kube-proxy 0 9b79e03fb2a97
0bd68f60ee8ba f5fb70afc410c0dd73f2fa76e6f16b7e7c4b0d0d088d2be44ed7e90951b0da2b 39 minutes ago Running kube-rbac-proxy 0 14ba959338c72
b582af7dfe542 quay.io/prometheus/node-exporter@sha256:c4376d28a346a403dd6227b8d9d61b866b77c76e42fe8d54ed68632eb8cced6b 39 minutes ago Running node-exporter 0 14ba959338c72
560d0648a74c3 85fc911ceba5a5a5e43a7c613738b2d6c0a14dad541b1577cdc6f921c16f5b75 39 minutes ago Running kube-flannel 0 be1b6c28aad4b
71901ef126d17 85fc911ceba5a5a5e43a7c613738b2d6c0a14dad541b1577cdc6f921c16f5b75 39 minutes ago Exited install-cni 0 be1b6c28aad4b
我认为Crio节点与Docker相比会出现各种问题，因此偶尔监控日志和事件会更好。
