从 dockershim 迁移

• 1: 将节点上的容器运行时从 Docker Engine 改为 containerd
• 2: 将 Docker Engine 节点从 dockershim 迁移到 cri-dockerd
• 3: 查明节点上所使用的容器运行时
• 4: 排查 CNI 插件相关的错误
• 5: 检查移除 Dockershim 是否对你有影响
• 6: 从 dockershim 迁移遥测和安全代理

1 - 将节点上的容器运行时从 Docker Engine 改为 containerd

本任务给出将容器运行时从 Docker 改为 containerd 所需的步骤。 此任务适用于运行 1.23 或更早版本 Kubernetes 的集群操作人员。 同时，此任务也涉及从 dockershim 迁移到 containerd 的示例场景。 有关其他备选的容器运行时，可查阅 此页面进行拣选。

准备开始

安装 containerd。进一步的信息可参见 containerd 的安装文档。 关于一些特定的环境准备工作，请遵循 containerd 指南。

腾空节点

kubectl drain <node-to-drain> --ignore-daemonsets

将 <node-to-drain> 替换为你所要腾空的节点的名称。

停止 Docker 守护进程

systemctl stop kubelet
systemctl disable docker.service --now

安装 Containerd

遵循此指南 了解安装 containerd 的详细步骤。

• Linux
• Windows (PowerShell)

配置 kubelet 使用 containerd 作为其容器运行时

编辑文件 /var/lib/kubelet/kubeadm-flags.env，将 containerd 运行时添加到标志中； --container-runtime-endpoint=unix:///run/containerd/containerd.sock。

使用 kubeadm 的用户应该知道，kubeadm 工具将每个主机的 CRI 套接字保存在该主机对应的 Node 对象的注解中。 要更改这一注解信息，你可以在一台包含 kubeadm /etc/kubernetes/admin.conf 文件的机器上执行以下命令：

kubectl edit no <node-name>

这一命令会打开一个文本编辑器，供你在其中编辑 Node 对象。 要选择不同的文本编辑器，你可以设置 KUBE_EDITOR 环境变量。

• 更改 kubeadm.alpha.kubernetes.io/cri-socket 值，将其从 /var/run/dockershim.sock 改为你所选择的 CRI 套接字路径 （例如：unix:///run/containerd/containerd.sock）。

  注意新的 CRI 套接字路径必须带有 unix:// 前缀。

• 保存文本编辑器中所作的修改，这会更新 Node 对象。

重启 kubelet

systemctl start kubelet

验证节点处于健康状态

运行 kubectl get nodes -o wide，containerd 会显示为我们所更改的节点上的运行时。

移除 Docker Engine

如果节点显示正常，删除 Docker。

• CentOS
• Debian
• Fedora
• Ubuntu

sudo yum remove docker-ce docker-ce-cli

sudo apt-get purge docker-ce docker-ce-cli

sudo dnf remove docker-ce docker-ce-cli

sudo apt-get purge docker-ce docker-ce-cli

上面的命令不会移除你的主机上的镜像、容器、卷或者定制的配置文件。 要删除这些内容，参阅 Docker 的指令来卸载 Docker Engine。

uncordon 节点

kubectl uncordon <node-to-uncordon>

将 <node-to-uncordon> 替换为你之前腾空的节点的名称。

2 - 将 Docker Engine 节点从 dockershim 迁移到 cri-dockerd

本页面为你展示如何迁移你的 Docker Engine 节点，使之使用 cri-dockerd 而不是 dockershim。 在以下场景中，你可以遵从这里的步骤执行操作：

• 你期望不再使用 dockershim，但仍然使用 Docker Engine 来在 Kubernetes 中运行容器。
• 你希望升级到 Kubernetes v1.28 且你的现有集群依赖于 dockershim， 因此你必须放弃 dockershim，而 cri-dockerd 是你的一种选项。

要进一步了解 dockershim 的移除，请阅读 FAQ 页面。

cri-dockerd 是什么？

在 Kubernetes v1.24 及更早版本中，你可以在 Kubernetes 中使用 Docker Engine， 依赖于一个称作 dockershim 的内置 Kubernetes 组件。 dockershim 组件在 Kubernetes v1.24 发行版本中已被移除；不过，一种来自第三方的替代品， cri-dockerd 是可供使用的。cri-dockerd 适配器允许你通过 容器运行时接口（Container Runtime Interface，CRI） 来使用 Docker Engine。

如果你想要迁移到 cri-dockerd 以便继续使用 Docker Engine 作为你的容器运行时， 你需要在所有被影响的节点上执行以下操作：

1. 安装 cri-dockerd；
2. 隔离（Cordon）并腾空（Drain）该节点；
3. 配置 kubelet 使用 cri-dockerd；
4. 重新启动 kubelet；
5. 验证节点处于健康状态。

首先在非关键节点上测试这一迁移过程。

你应该针对所有希望迁移到 cri-dockerd 的节点执行以下步骤。

准备开始

• 安装了 cri-dockerd 并且该服务已经在各节点上启动；
• 一个网络插件。

隔离并腾空节点

1. 隔离节点，阻止新的 Pod 被调度到节点上：

   kubectl cordon <NODE_NAME>
   

   将 <NODE_NAME> 替换为节点名称。

2. 腾空节点以安全地逐出所有运行中的 Pod：

   kubectl drain <NODE_NAME> --ignore-daemonsets
   

配置 kubelet 使用 cri-dockerd

下面的步骤适用于用 kubeadm 工具安装的集群。如果你使用不同的工具， 你需要使用针对该工具的配置指令来修改 kubelet。

1. 在每个被影响的节点上，打开 /var/lib/kubelet/kubeadm-flags.env 文件；
2. 将 --container-runtime-endpoint 标志，将其设置为 unix:///var/run/cri-dockerd.sock。
3. 将 --container-runtime 标志修改为 remote（在 Kubernetes v1.27 及更高版本中不可用）。

kubeadm 工具将节点上的套接字存储为控制面上 Node 对象的注解。 要为每个被影响的节点更改此套接字：

1. 编辑 Node 对象的 YAML 表示：

   KUBECONFIG=/path/to/admin.conf kubectl edit no <NODE_NAME>
   

   根据下面的说明执行替换：

   • /path/to/admin.conf：指向 kubectl 配置文件 admin.conf 的路径；
   • <NODE_NAME>：你要修改的节点的名称。

2. 将 kubeadm.alpha.kubernetes.io/cri-socket 标志从 /var/run/dockershim.sock 更改为 unix:///var/run/cri-dockerd.sock；

3. 保存所作更改。保存时，Node 对象被更新。

重启 kubelet

systemctl restart kubelet

验证节点处于健康状态

要检查节点是否在使用 cri-dockerd 端点， 按照找出你所使用的运行时页面所给的指令操作。 kubelet 的 --container-runtime-endpoint 标志取值应该是 unix:///var/run/cri-dockerd.sock。

解除节点隔离

kubectl uncordon <NODE_NAME>

接下来

• 阅读 移除 Dockershim 的常见问题。
• 了解如何从基于 dockershim 的 Docker Engine 迁移到 containerd。

3 - 查明节点上所使用的容器运行时

本页面描述查明集群中节点所使用的容器运行时 的步骤。

取决于你运行集群的方式，节点所使用的容器运行时可能是事先配置好的， 也可能需要你来配置。如果你在使用托管的 Kubernetes 服务， 可能存在特定于厂商的方法来检查节点上配置的容器运行时。 本页描述的方法应该在能够执行 kubectl 的场合下都可以工作。

准备开始

安装并配置 kubectl。参见安装工具 节了解详情。

查明节点所使用的容器运行时

使用 kubectl 来读取并显示节点信息：

kubectl get nodes -o wide

输出如下面所示。CONTAINER-RUNTIME 列给出容器运行时及其版本。

对于 Docker Engine，输出类似于：

NAME         STATUS   VERSION    CONTAINER-RUNTIME
node-1       Ready    v1.16.15   docker://19.3.1
node-2       Ready    v1.16.15   docker://19.3.1
node-3       Ready    v1.16.15   docker://19.3.1

如果你的容器运行时显示为 Docker Engine，你仍然可能不会被 v1.24 中 dockershim 的移除所影响。 通过检查运行时端点，可以查看你是否在使用 dockershim。 如果你没有使用 dockershim，你就不会被影响。

对于 containerd，输出类似于这样：

# For containerd
NAME         STATUS   VERSION   CONTAINER-RUNTIME
node-1       Ready    v1.19.6   containerd://1.4.1
node-2       Ready    v1.19.6   containerd://1.4.1
node-3       Ready    v1.19.6   containerd://1.4.1

你可以在容器运行时 页面找到与容器运行时相关的更多信息。

检查当前使用的运行时端点

容器运行时使用 Unix Socket 与 kubelet 通信，这一通信使用基于 gRPC 框架的 CRI 协议。kubelet 扮演客户端，运行时扮演服务器端。 在某些情况下，你可能想知道你的节点使用的是哪个 socket。 如若集群是 Kubernetes v1.24 及以后的版本， 或许你想知道当前运行时是否是使用 dockershim 的 Docker Engine。

可以通过检查 kubelet 的参数得知当前使用的是哪个 socket。

1. 查看 kubelet 进程的启动命令

    tr \\0 ' ' < /proc/"$(pgrep kubelet)"/cmdline
   

   如有节点上没有 tr 或者 pgrep，就需要手动检查 kubelet 的启动命令

2. 在命令的输出中，查找 --container-runtime 和 --container-runtime-endpoint 标志。

   • 如果你的节点使用 Kubernetes v1.23 或更早的版本，这两个参数不存在， 或者 --container-runtime 标志值不是 remote，则你在通过 dockershim 套接字使用 Docker Engine。 在 Kubernetes v1.27 及以后的版本中，--container-runtime 命令行参数不再可用。
   • 如果设置了 --container-runtime-endpoint 参数，查看套接字名称即可得知当前使用的运行时。 如若套接字 unix:///run/containerd/containerd.sock 是 containerd 的端点。

如果你将节点上的容器运行时从 Docker Engine 改变为 containerd，可在 迁移到不同的运行时 找到更多信息。或者，如果你想在 Kubernetes v1.24 及以后的版本仍使用 Docker Engine， 可以安装 CRI 兼容的适配器实现，如 cri-dockerd。

4 - 排查 CNI 插件相关的错误

为了避免 CNI 插件相关的错误，需要验证你正在使用或升级到一个经过测试的容器运行时， 该容器运行时能够在你的 Kubernetes 版本上正常工作。

关于 "Incompatible CNI versions" 和 "Failed to destroy network for sandbox" 错误

在 containerd v1.6.0-v1.6.3 中，当配置或清除 Pod CNI 网络时，如果 CNI 插件没有升级和/或 CNI 配置文件中没有声明 CNI 配置版本时，会出现服务问题。containerd 团队报告说： “这些问题在 containerd v1.6.4 中得到了解决。”

在使用 containerd v1.6.0-v1.6.3 时，如果你不升级 CNI 插件和/或声明 CNI 配置版本， 你可能会遇到以下 "Incompatible CNI versions" 或 "Failed to destroy network for sandbox" 错误状况。

Incompatible CNI versions 错误

如果因为配置版本比插件版本新，导致你的 CNI 插件版本与配置中的插件版本无法正确匹配时， 在启动 Pod 时，containerd 日志可能会显示类似的错误信息：

incompatible CNI versions; config is \"1.0.0\", plugin supports [\"0.1.0\" \"0.2.0\" \"0.3.0\" \"0.3.1\" \"0.4.0\"]"

为了解决这个问题，需要更新你的 CNI 插件和 CNI 配置文件。

Failed to destroy network for sandbox 错误

如果 CNI 插件配置中未给出插件的版本， Pod 可能可以运行。但是，停止 Pod 时会产生类似于以下错误：

ERRO[2022-04-26T00:43:24.518165483Z] StopPodSandbox for "b" failed
error="failed to destroy network for sandbox \"bbc85f891eaf060c5a879e27bba9b6b06450210161dfdecfbb2732959fb6500a\": invalid version \"\": the version is empty"

此错误使 Pod 处于未就绪状态，且仍然挂接到某网络名字空间上。 为修复这一问题，编辑 CNI 配置文件以添加缺失的版本信息。 下一次尝试停止 Pod 应该会成功。

更新你的 CNI 插件和 CNI 配置文件

如果你使用 containerd v1.6.0-v1.6.3 并遇到 "Incompatible CNI versions" 或者 "Failed to destroy network for sandbox" 错误，考虑更新你的 CNI 插件并编辑 CNI 配置文件。

以下是针对各节点要执行的典型步骤的概述：

1. 安全地腾空并隔离节点。

2. 停止容器运行时和 kubelet 服务后，执行以下升级操作：

• 如果你正在运行 CNI 插件，请将它们升级到最新版本。
• 如果你使用的是非 CNI 插件，请将它们替换为 CNI 插件，并使用最新版本的插件。
• 更新插件配置文件以指定或匹配 CNI 规范支持的插件版本， 如后文"containerd 配置文件示例"章节所示。
• 对于 containerd，请确保你已安装 CNI loopback 插件的最新版本（v1.0.0 或更高版本）。
• 将节点组件（例如 kubelet）升级到 Kubernetes v1.24
• 升级到或安装最新版本的容器运行时。

3. 通过重新启动容器运行时和 kubelet 将节点重新加入到集群。取消节点隔离（kubectl uncordon <nodename>）。

containerd 配置文件示例

以下示例显示了 containerd 运行时 v1.6.x 的配置， 它支持最新版本的 CNI 规范（v1.0.0）。 请参阅你的插件和网络提供商的文档，以获取有关你系统配置的进一步说明。

在 Kubernetes 中，作为其默认行为，containerd 运行时为 Pod 添加一个本地回路接口，lo。 containerd 运行时通过 CNI 插件 loopback 配置本地回路接口。
loopback 插件作为 containerd 发布包的一部分，扮演 cni 角色。 containerd v1.6.0 及更高版本包括与 CNI v1.0.0 兼容的 loopback 插件以及其他默认 CNI 插件。 loopback 插件的配置由 containerd 内部完成， 并被设置为使用 CNI v1.0.0。 这也意味着当这个更新版本的 containerd 启动时，loopback 插件的版本必然是 v1.0.0 或更高版本。

以下 Bash 命令生成一个 CNI 配置示例。这里，cniVersion 字段被设置为配置版本值 1.0.0， 以供 containerd 调用 CNI 桥接插件时使用。

cat << EOF | tee /etc/cni/net.d/10-containerd-net.conflist
{
 "cniVersion": "1.0.0",
 "name": "containerd-net",
 "plugins": [
   {
     "type": "bridge",
     "bridge": "cni0",
     "isGateway": true,
     "ipMasq": true,
     "promiscMode": true,
     "ipam": {
       "type": "host-local",
       "ranges": [
         [{
           "subnet": "10.88.0.0/16"
         }],
         [{
           "subnet": "2001:db8:4860::/64"
         }]
       ],
       "routes": [
         { "dst": "0.0.0.0/0" },
         { "dst": "::/0" }
       ]
     }
   },
   {
     "type": "portmap",
     "capabilities": {"portMappings": true},
     "externalSetMarkChain": "KUBE-MARK-MASQ"
   }
 ]
}
EOF

基于你的用例和网络地址规划，将前面示例中的 IP 地址范围更新为合适的值。

5 - 检查移除 Dockershim 是否对你有影响

Kubernetes 的 dockershim 组件使得你可以把 Docker 用作 Kubernetes 的 容器运行时。 在 Kubernetes v1.24 版本中，内建组件 dockershim 被移除。

本页讲解你的集群把 Docker 用作容器运行时的运作机制， 并提供使用 dockershim 时，它所扮演角色的详细信息， 继而展示了一组操作，可用来检查移除 dockershim 对你的工作负载是否有影响。

检查你的应用是否依赖于 Docker

即使你是通过 Docker 创建的应用容器，也不妨碍你在其他任何容器运行时上运行这些容器。 这种使用 Docker 的方式并不构成对 Docker 作为一个容器运行时的依赖。

当用了别的容器运行时之后，Docker 命令可能不工作，或者产生意外的输出。 下面是判定你是否依赖于 Docker 的方法。

1. 确认没有特权 Pod 执行 Docker 命令（如 docker ps）、重新启动 Docker 服务（如 systemctl restart docker.service）或修改 Docker 配置文件 /etc/docker/daemon.json。
2. 检查 Docker 配置文件（如 /etc/docker/daemon.json）中容器镜像仓库的镜像（mirror）站点设置。 这些配置通常需要针对不同容器运行时来重新设置。
3. 检查确保在 Kubernetes 基础设施之外的节点上运行的脚本和应用程序没有执行 Docker 命令。 可能的情况有：
   • SSH 到节点排查故障；
   • 节点启动脚本；
   • 直接安装在节点上的监控和安全代理。

4. 检查执行上述特权操作的第三方工具。 详细操作请参考从 dockershim 迁移遥测和安全代理。
5. 确认没有对 dockershim 行为的间接依赖。这是一种极端情况，不太可能影响你的应用。 一些工具很可能被配置为使用了 Docker 特性，比如，基于特定指标发警报， 或者在故障排查指令的一个环节中搜索特定的日志信息。 如果你有此类配置的工具，需要在迁移之前，在测试集群上测试这类行为。

Docker 依赖详解

容器运行时是一个软件， 用来运行组成 Kubernetes Pod 的容器。 Kubernetes 负责编排和调度 Pod；在每一个节点上，kubelet 使用抽象的容器运行时接口，所以你可以任意选用兼容的容器运行时。

在早期版本中，Kubernetes 提供的兼容性支持一个容器运行时：Docker。 在 Kubernetes 后来的发展历史中，集群运营人员希望采用别的容器运行时。 于是 CRI 被设计出来满足这类灵活性需求 - 而 kubelet 亦开始支持 CRI。 然而，因为 Docker 在 CRI 规范创建之前就已经存在，Kubernetes 就创建了一个适配器组件 dockershim。 dockershim 适配器允许 kubelet 与 Docker 交互，就好像 Docker 是一个 CRI 兼容的运行时一样。

你可以阅读博文 Kubernetes 正式支持集成 Containerd。

切换到 Containerd 容器运行时可以消除掉中间环节。 所有相同的容器都可由 Containerd 这类容器运行时来运行。 但是现在，由于直接用容器运行时调度容器，它们对 Docker 是不可见的。 因此，你以前用来检查这些容器的 Docker 工具或漂亮的 UI 都不再可用。

你不能再使用 docker ps 或 docker inspect 命令来获取容器信息。 由于你不能列出容器，因此你不能获取日志、停止容器，甚至不能通过 docker exec 在容器中执行命令。

你仍然可以下载镜像，或者用 docker build 命令创建它们。 但用 Docker 创建、下载的镜像，对于容器运行时和 Kubernetes，均不可见。 为了在 Kubernetes 中使用，需要把镜像推送（push）到某镜像仓库。

已知问题

一些文件系统指标缺失并且指标格式不同

Kubelet /metrics/cadvisor 端点提供 Prometheus 指标， 如 Kubernetes 系统组件指标 中所述。 如果你安装了一个依赖该端点的指标收集器，你可能会看到以下问题：

• Docker 节点上的指标格式为 k8s_<container-name>_<pod-name>_<namespace>_<pod-uid>_<restart-count>， 但其他运行时的格式不同。例如，在 containerd 节点上它是 <container-id>。

• 一些文件系统指标缺失，如下所示：

  container_fs_inodes_free
  container_fs_inodes_total
  container_fs_io_current
  container_fs_io_time_seconds_total
  container_fs_io_time_weighted_seconds_total
  container_fs_limit_bytes
  container_fs_read_seconds_total
  container_fs_reads_merged_total
  container_fs_sector_reads_total
  container_fs_sector_writes_total
  container_fs_usage_bytes
  container_fs_write_seconds_total
  container_fs_writes_merged_total
  

解决方法

你可以通过使用 cAdvisor 作为一个独立的守护程序来缓解这个问题。

1. 找到名称格式为 vX.Y.Z-containerd-cri 的最新 cAdvisor 版本（例如 v0.42.0-containerd-cri）。
2. 按照 cAdvisor Kubernetes Daemonset 中的步骤来创建守护进程。
3. 将已安装的指标收集器指向使用 cAdvisor 的 /metrics 端点。 该端点提供了全套的 Prometheus 容器指标。

替代方案：

• 使用替代的第三方指标收集解决方案。
• 从 Kubelet 摘要 API 收集指标，该 API 在 /stats/summary 提供服务。

接下来

• 阅读从 dockershim 迁移， 以了解你的下一步工作。
• 阅读弃用 Dockershim 的常见问题，了解更多信息。

6 - 从 dockershim 迁移遥测和安全代理

Kubernetes 对与 Docker Engine 直接集成的支持已被弃用且已经被删除。 大多数应用程序不直接依赖于托管容器的运行时。但是，仍然有大量的遥测和监控代理依赖 docker 来收集容器元数据、日志和指标。 本文汇总了一些信息和链接：信息用于阐述如何探查这些依赖，链接用于解释如何迁移这些代理去使用通用的工具或其他容器运行。

遥测和安全代理

在 Kubernetes 集群中，有几种不同的方式来运行遥测或安全代理。 一些代理在以 DaemonSet 的形式运行或直接在节点上运行时，直接依赖于 Docker Engine。

为什么有些遥测代理会与 Docker Engine 通信？

从历史上看，Kubernetes 是专门为与 Docker Engine 一起工作而编写的。 Kubernetes 负责网络和调度，依靠 Docker Engine 在节点上启动并运行容器（在 Pod 内）。一些与遥测相关的信息，例如 pod 名称， 只能从 Kubernetes 组件中获得。其他数据，例如容器指标，不是容器运行时的责任。 早期遥测代理需要查询容器运行时和 Kubernetes 以报告准确的信息。 随着时间的推移，Kubernetes 获得了支持多种运行时的能力， 现在支持任何兼容容器运行时接口的运行时。

一些代理和 Docker 工具紧密绑定。比如代理会用到 docker ps 或 docker top 这类命令来列出容器和进程，用 docker logs 订阅 Docker 的日志。 如果现有集群中的节点使用 Docker Engine，在你切换到其它容器运行时的时候， 这些命令将不再起作用。

识别依赖于 Docker Engine 的 DaemonSet

如果某 Pod 想调用运行在节点上的 dockerd，该 Pod 必须满足以下两个条件之一：

• 将包含 Docker 守护进程特权套接字的文件系统挂载为一个卷；或
• 直接以卷的形式挂载 Docker 守护进程特权套接字的特定路径。

举例来说：在 COS 镜像中，Docker 通过 /var/run/docker.sock 开放其 Unix 域套接字。 这意味着 Pod 的规约中需要包含 hostPath 卷以挂载 /var/run/docker.sock。

下面是一个 shell 示例脚本，用于查找包含直接映射 Docker 套接字的挂载点的 Pod。 你也可以删掉 grep '/var/run/docker.sock' 这一代码片段以查看其它挂载信息。

kubectl get pods --all-namespaces \
-o=jsonpath='{range .items[*]}{"\n"}{.metadata.namespace}{":\t"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.hostPath.path}{", "}{end}{end}' \
| sort \
| grep '/var/run/docker.sock'

检测节点代理对 Docker 的依赖性

在你的集群节点被定制、且在各个节点上均安装了额外的安全和遥测代理的场景下， 一定要和代理的供应商确认：该代理是否依赖于 Docker。

遥测和安全代理的供应商

本节旨在汇总有关可能依赖于容器运行时的各种遥测和安全代理的信息。

我们通过 谷歌文档 提供了为各类遥测和安全代理供应商准备的持续更新的迁移指导。 请与供应商联系，获取从 dockershim 迁移的最新说明。

从 dockershim 迁移

Aqua

无需更改：在运行时变更时可以无缝切换运行。

Datadog

如何迁移： Kubernetes 中对于 Docker 的弃用 名字中包含以下字符串的 Pod 可能访问 Docker Engine：

• datadog-agent
• datadog
• dd-agent

Dynatrace

如何迁移： 在 Dynatrace 上从 Docker-only 迁移到通用容器指标

Containerd 支持公告：在基于 containerd 的 Kubernetes 环境的获取容器的自动化全栈可见性 CRI-O 支持公告：在基于 CRI-O 的 Kubernetes 环境获取容器的自动化全栈可见性（测试版）

名字中包含以下字符串的 Pod 可能访问 Docker：

• dynatrace-oneagent

Falco

如何迁移： 迁移 Falco 从 dockershim Falco 支持任何与 CRI 兼容的运行时（默认配置中使用 containerd）；该文档解释了所有细节。

名字中包含以下字符串的 Pod 可能访问 Docker：

• falco

Prisma Cloud Compute

在依赖于 CRI（非 Docker）的集群上安装 Prisma Cloud 时，查看 Prisma Cloud 提供的文档。

名字中包含以下字符串的 Pod 可能访问 Docker：

• twistlock-defender-ds

SignalFx (Splunk)

SignalFx Smart Agent（已弃用）在 Kubernetes 集群上使用了多种不同的监视器， 包括 kubernetes-cluster，kubelet-stats/kubelet-metrics，docker-container-stats。 kubelet-stats 监视器此前已被供应商所弃用，现支持 kubelet-metrics。 docker-container-stats 监视器受 dockershim 移除的影响。 不要为 docker-container-stats 监视器使用 Docker Engine 之外的运行时。

如何从依赖 dockershim 的代理迁移：

1. 从所配置的监视器中移除 docker-container-stats。 注意，若节点上已经安装了 Docker，在非 dockershim 环境中启用此监视器后会导致报告错误的指标； 如果节点未安装 Docker，则无法获得指标。
2. 启用和配置 kubelet-metrics 监视器。

名字中包含以下字符串的 Pod 可能访问 Docker：

• signalfx-agent

Yahoo Kubectl Flame

Flame 不支持 Docker 以外的容器运行时，具体可见 https://github.com/yahoo/kubectl-flame/issues/51