问题标签 [containerd]

正在探索如何containerd代替 dockerd 使用。这仅用于学习并作为 cli 工具，而不是用于任何管道或自动化。

到目前为止，关于在 cli (via ctr) 中使用 containerd 的文档非常有限。甚至官方文档都使用 Go langcontainerd直接使用。

我所学到的是ctr指挥起着docker指挥控制的作用containerd。到目前为止，我已经创建了一个 docker 映像并将其导出为 .tar 格式。现在使用ctr i import hello.tar我已将其作为图像导入。

现在ctr i ls给我以下输出：

尝试运行容器时要求我提供图像 ID：

我不确定从哪里获取图像 ID。是否有任何与初学者相关ctr或containerd可能对初学者有帮助的文档？

仅将图像作为容器运行对我来说就足够了。

我想从可下载的桌面应用程序（Electron 应用程序）运行 docker 命令（主要是 docker build 和 docker run），可能是通过访问 Docker API。然而，与其让用户同时下载 Docker 客户端和这个应用程序，我想知道是否有任何方法可以将两者捆绑在同一个安装中？

我正在使用 containerd 和 Calico 作为 CNI 在 CentOS 8 上设置 kubernetes 集群。使用 kubeadm 命令设置主节点，它处于就绪状态。

当我将节点加入主节点时，节点未处于就绪状态。我在下面看到日志文件的消息。

解决此错误的任何提示？

我的构建与 docker-compose 配合得很好；但是，我被要求通过仅安装了 containerd 的管道构建它，它未配置为侦听任何端口，而是使用套接字路径

甚至可以在没有 dockerd 的情况下使用 docker-compose，只使用 containerd 吗？

我已经使用 containerd 在 CentOS 8 Kubernetes 1.17 上安装了 nignx ingress helm chat，ingress pod 失败并显示以下错误消息。相同的 helm chat 在 CentOS 7 和 Docker 上工作。

如果我从部署中删除它，则入口 pod 正在启动。

我想了解为什么相同的 helm chart 在 containerd 上失败

添加部署。

错误信息

作为我大学项目的一部分，我正在尝试在 Go 中编写一个容器守护程序，并且由于某种原因，Chroot('/to/a/directory')这给了我一个错误：

我已经尝试syscall.Chroot()在 SysProcAttr 中使用和 Chroot 字段，但正如它可能已经清楚的那样，错误仍然存​​在。

我使用 Ubuntu 18.04，我的 Go 版本是1.13.5

编辑：

代码：

我在 vm 上有本地 kubernetes 集群。我使用 containerd 作为 CRI。当我安装 calico 时，calico-kube-controllers 出现下一个错误

“Warning FailedCreatePodSandBox 2m41s (x638 over 140m) kubelet, serverhostname (combined from similar events): 无法创建 pod 沙箱：rpc 错误：code = Unknown desc = 无法为沙箱设置网络“a46b6b0c52c2adec7749fff781401e481ca911a198e0406d7fa646c 获取 ClusterInformd556d7fa6466 错误//[10.96.0.1]:443/apis/crd.projectcalico.org/v1/clusterinformations/default: tls: server selected unsupported protocol version 301"

PS 与 docker 作为 CRI，工作正常

操作系统版本 Red Hat Enterprise Linux Server release 7.7 (Maipo)

Openssl 版本 OpenSSL 1.1.1 2018 年 9 月 11 日

为 kubelet 和 kube-api-server 配置 tls-min-version 没有帮助。

如何使用 containerd 而不是默认 docker 启动 minikube？

当我使用 在容器中执行任务时docker exec，新生成的进程会containerd-shim与该容器的其他进程连接，这是预期的行为。但我不详细了解新生成的进程如何附加到此进程。

编辑：经过一番研究，我了解到该进程实际上是由 runc 产生的，使用prctl(PR_SET_CHILD_SUBREAPER, 1);它可以终止 runc 并将该进程附加到 runc。然而，这并不能解释进程是如何从我的外壳“转移”到附加到这个 runc 进程的containerd-shim

例如，如果我生成一个进程，sudo strace docker exec 104f931f77ee sleep 99那么我将拥有以下 ps 树（为清楚起见进行了简化）。

根据straceof containerd-shim，这不是containerd-shim直接原因，因为当容器附加到此进程时没有进行系统调用。（因为它仅在容器死亡时唤醒，而不是在它生成时）

（见编辑）这特别奇怪，因为：

您不能将进程作为 shell 的子进程启动，然后将其“重新设置为父进程”，以便另一个进程成为它的父进程。

因此，您需要使用显式启动子进程的父进程。

此外，根据这个 strace，产卵过程和containerd-shim

那么，containerd-shim作为父级的容器是如何创建的呢？

注意：问题不在于为什么容器需要这种架构（我知道它允许产生容器的进程退出而不中断它：容器可以继续执行它与外壳分离）。但是如何在技术上做到这一点。

I have been trying to use some custom, local built image on my kind cluster by following the instructions on https://kind.sigs.k8s.io/docs/user/local-registry - i.e. applying the following containerdConfigPatches to my cluster.cfg:

192.168.83.82:5000 is the IP of the VM where the local (insecure) registry is running alongside the kind cluster and its exposed port.

Once the cluster is created, I can verify the settings where applied to all nodes:

However, pods keep failing with to ErrImagePull and these Event log:

TL;DR: "http: server gave HTTP response to HTTPS client" - which I thought would be solved with the ConfigPatch above (As it happens when you tweak docker's daemon.json).

Also, as an alternative, tried loading the image from the host to the cluster nodes:

And verified the image was loaded to all nodes by listing them:

Hoping that the image now would be read from the image cache. However, the result was exactly the same.

Any clue on how to approach this one? Is there something I might have overlooked?