问题标签 [containerd]

我看到主机中的 docker 容器显示为 Running/Up ，但是当我尝试 exec 时，我看到了 .

rpc error: code = 2 desc = containerd: container not found

我没有看到任何相关进程在ps -aef输出上运行。

翻阅dockerd我看到的日志-

level=error msg="containerd: get exit status" error="containerd: process has not exited" id=e4e5d58359 pid=bba1944c4 systemPid=5132

码头工人版本：

客户端：版本：1.13.1 API 版本：1.26 Go 版本：go1.7.5 Git 提交：092cba3 内置：2017 年 2 月 8 日星期三 06:50:14 OS/Arch：linux/amd64

服务器：版本：1.13.1 API 版本：1.26（最低版本 1.12） Go 版本：go1.7.5 Git 提交：092cba3 构建：2017 年 2 月 8 日星期三 06:50:14 OS/Arch：linux/amd64 实验性：false

什么可能导致这种行为？指针？

我正在尝试从 docker 容器创建一个 runc 容器。

我关注了这篇博文，并成功地从正在运行的 docker 容器中提取了 config.json。

问题是

1. 我找到 config.json 的路径与我在网上找到的参考不同
2. 据我所知，相同的路径在具有相同 docker 版本的不同主机上不起作用。在该主机上，我无法找到生成 config.json 的位置。

我在哪里可以找到 config.json 的信息相互矛盾，并且无法在我的主机上找到它。

我还可以查看哪些其他位置，以及如何判断它会是哪一个？这是在某处配置的吗，这是否取决于 docker、containerd、runc 或其他的版本？

我想将 docker-compose.yml 转换为（一组）runc config.json。

到目前为止我发现：

• 从正在运行的 docker 容器中复制 config.json（不可靠）
• 以某种方式使用dockerd API从 Docker Image 创建 config.json

这些都没有将 docker-compose.yml 解析为可用的 runc 规范。有没有这样的东西？

从使用相同图表的 k8s 1.10 升级到 v1.12.x 时，zookeeper 运行，但 kafka 在 liveness 探测上失败。它只是运行：

执行 [ sh -ec /usr/bin/jps | /bin/grep -q 支持的Kafka]

ret: 出口 1

我们一直在使用 confluentinc cp-kafka docker 镜像（4.1.0 等）。

由于 containerd 的新使用，是否需要进行一些更改？

谢谢！

Docker 提供了这种机制来暂停容器。

是否有等效的方法，containerd或者我是否必须找到另一种方法来“冻结”容器？

目标是获得一致的备份 - 我正在寻找另一种解决方案，而不是使用fsfreeze.

我有多个 Docker 映像和容器在 VM 上运行。但是像“runc list”这样的命令没有列出任何这些。

如何让 runc/containerd 知道我现有的 docker 镜像？

我试图了解何时有人应该真正关心可用的不同 containerRuntime，例如docker, containerd, rkt。我知道会有不同的原因，如安全问题、性能等。任何人都可以详细说明所有问题。同样考虑和不考虑使用 k8 编排容器。

我有我的服务特定图像的焦油。我将它导入到 containerd 中，以便 k3s 使用它来部署 POD。用于导入图像 tar 的命令是 -
k3s ctr images import XXX.tar

默认情况下，它将图像加载到/var/lib/rancher/data目录中。但是，我想在不同的目录中加载图像。任何人都知道，如何在加载图像时指定自定义目录？

我们在 swarm 环境中使用 docker。一切都很好......但是几天前出现了一个名为“exe”的奇怪进程：

它确实占用了 100% 的 CPU。
我们试图了解它的来源，但它非常不稳定，它的 pid 每 3-4 秒就会改变一次。你可以猜到这样的行为触发了一些警报。
最终，我们设置了一些监控工具（使用 auditd）对其进行快照，并看到：

“主” runc 的父进程是：

我读了一些关于 containerd-shim 和 runc 的东西（包括这一篇和那一篇，还有更多）...我想我理解 runc 用于启动无恶魔容器，然后 containerd-shim 接管了容器进程'父母。
因此，我理解为什么每次启动容器时我都会将 runc 视为 containerd-shim 的子进程。

但是仍然有一些事情仍然让我无法理解：

• 为什么有几个级别的 runc（一个 runc 调用另一个）？
• 为什么它不被称为“runc”而是“exe”，因此看起来非常可疑（当它听起来像是合法的时候）？它是容器（或另一个）的主进程吗？
• 这个名为“4”且可执行路径为“/”的奇怪进程是什么？它是容器中进程的一部分（还是主要进程）？
• 我猜 curl 是在容器中执行的运行状况检查（它是一个带有针对 localhost 的运行状况检查的 apache 容器）。我对吗？
• 如果容器的主进程不是“4”进程，我应该看到它吗？我怎么能以类似的方式看到它？

与此同时，该进程刚刚停止使用整个 cpu。每次启动容器时，它看起来很简短（但听起来很合理），但不会超过几个百分点。所以我认为它的 CPU 使用率过高与我们容器中的一些问题有关。无论如何，解决cpu的问题不是我的重点。

编辑 1：

关于 dockerfiles

虚拟机上运行着很多容器，我无法提供所有的 Dockerfile。我怀疑通过 healthcheck 触发 curl 的是一个 apache httpd（基于 centOs）图像。它与CentOS非常接近，主要有一些标签、清洁（未使用的模块）和额外的健康检查：

关于监控

我们将rsyslog与针对远程服务器的基本 conf 一起使用，然后启动 auditctl 以监视进程触发：

下面是在 AWS EC2 实例（Linux）上配置 ECS 任务容器的 CloudFormation 模板：

其中三个容器的内存属性平均分配（450+300+250 MB），假设这 3 个容器在t2.micro分配了 1 GB RAM（物理）的 EC2 实例类型上运行

随机更改这些值（of "Memory"）会使容器 运行或失败，而不知道失败的正确原因。

失败时，我们会在 AWS 云中调试时收到此类错误：

容器不在 docker 上运行。容器是进程——它们在 linux 内核上运行。容器是 Linux 进程（或 Windows）

runtime·clone()Docker 容器命名空间是使用系统调用在内部创建的。

内存管理将每个进程的虚拟地址空间映射到物理地址空间。进程管理是指虚拟地址，而不是物理地址。

对于Memory: 300上述代码中的 MB 语法，AWS文档说：“要呈现给容器的内存量（以 MiB 为单位）。”

在 docker world 中，containerd为每个新容器创建 shim 进程。 runc实际上创建了一个容器进程。

1）将RAM Memory: 300MB大小分配给容器进程是什么意思？在上面的代码中......它是进程的物理地址空间（或进程的虚拟地址空间）的大小吗？

2）runc用户空间程序是否使用runtime·clone()系统调用Memory: 300为每个容器进程设置物理内存空间（MB）？

https://github.com/golang/go/blob/1650f1ba0b964a06a242c3318e85b3b46f010614/src/runtime/sys_linux_amd64.s#L540