节点参考信息

• 1: Kubelet Checkpoint API
• 2: 关于 dockershim 移除和使用兼容 CRI 运行时的文章
• 3: Kubelet 设备管理器 API 版本
• 4: 节点状态
• 5:

1 - Kubelet Checkpoint API

为容器生成检查点这个功能可以为一个正在运行的容器创建有状态的拷贝。 一旦容器有一个有状态的拷贝，你就可以将其移动到其他计算机进行调试或类似用途。

如果你将通过检查点操作生成的容器数据移动到能够恢复该容器的一台计算机， 所恢复的容器将从之前检查点操作执行的时间点继续运行。 你也可以检视所保存的数据，前提是你拥有这类操作的合适工具。

创建容器的检查点可能会产生安全隐患。 通常，一个检查点包含执行检查点操作时容器中所有进程的所有内存页。 这意味着以前存在于内存中的一切内容现在都在本地磁盘上获得。 这里的内容包括一切私密数据和可能用于加密的密钥。 底层 CRI 实现（该节点上的容器运行时）应创建只有 root 用户可以访问的检查点存档。 另外重要的是记住：如果检查点存档被转移到另一个系统，该检查点存档的所有者将可以读取所有内存页。

操作

post 对指定的容器执行检查点操作

告知 kubelet 对指定 Pod 中的特定容器执行检查点操作。

查阅 Kubelet 身份验证/鉴权参考了解如何控制对 kubelet 检查点接口的访问。

Kubelet 将对底层 CRI 实现请求执行检查点操作。 在该检查点请求中，Kubelet 将检查点存档的名称设置为 checkpoint-<pod 全称>-<容器名称>-<时间戳>.tar， 还会请求将该检查点存档存储到其根目录（由 --root-dir 定义）下的 checkpoints 子目录中。 这个目录默认为 /var/lib/kubelet/checkpoints。

检查点存档的格式为 tar，可以使用 tar 的一种实现来读取。存档文件的内容取决于底层 CRI 实现（该节点的容器运行时）。

HTTP 请求

POST /checkpoint/{namespace}/{pod}/{container}

参数

• namespace (路径参数)：string，必需

  名字空间（Namespace）

• pod (路径参数)：string，必需

  Pod

• container (路径参数)：string，必需

  容器（Container）

• timeout (查询参数)：integer

  等待检查点创建完成的超时时间（单位为秒）。 如果超时值为零或未设定，将使用默认的 CRI 超时时间值。 生成检查点所需的时长直接取决于容器所用的内存。容器使用的内存越多，创建相应检查点所需的时间越长。

响应

200: OK

401: Unauthorized

404: Not Found（如果 ContainerCheckpoint 特性门控被禁用）

404: Not Found（如果指定的 namespace、pod 或 container 无法被找到）

500: Internal Server Error（如果执行检查点操作期间 CRI 实现遇到一个错误（参阅错误消息了解更多细节））

500: Internal Server Error（如果 CRI 实现未实现检查点 CRI API（参阅错误消息了解更多细节））

2 - 关于 dockershim 移除和使用兼容 CRI 运行时的文章

这是关于 Kubernetes 弃用和移除 dockershim 或使用兼容 CRI 的容器运行时相关的文章和其他页面的列表。

Kubernetes 项目

• Kubernetes 博客：Dockershim 移除常见问题解答（最初发表于 2020/12/02）

• Kubernetes 博客：更新：Dockershim 移除常见问题解答（更新发表于 2020/12/02）

• Kubernetes 博客：Kubernetes 即将移除 Dockershim：承诺和下一步（发表于 2022/01/07）

• Kubernetes 博客：移除 Dockershim 即将到来。你准备好了吗？（发表于 2021/11/12）

• Kubernetes 文档：从 dockershim 迁移

• Kubernetes 文档：容器运行时

• Kubernetes 增强建议：KEP-2221: 从 kubelet 中移除 dockershim

• Kubernetes 增强提问：从 kubelet 中移除 dockershim (k/enhancements#2221)

你可以通过 GitHub 问题 Dockershim 移除反馈和问题 提供反馈。 (k/kubernetes/#106917)

外部来源

• Amazon Web Services EKS 文档：Amazon EKS 将终止对 Dockershim 的支持

• CNCF 会议视频：将 Kubernetes 从 Docker 迁移到 containerd 运行时的经验教训（Ana Caylin，在 KubeCon Europe 2019）

• Docker.com 博客：开发人员需要了解的关于 Docker、Docker Engine 和 Kubernetes v1.20 的哪些知识（发表于 2020/12/04）

• YouTube 上的 “Google Open Source” 频道：与 Google 一起学习 Kubernetes - 从 Dockershim 迁移到 Containerd

• Azure 博客上的 Microsoft 应用：Dockershim 弃用和 AKS（发表于 2022/01/21）

• Mirantis 博客：Dockershim 的未来是 cri-dockerd（发表于 2021/04/21）

• Mirantis: Mirantis/cri-dockerd Git 仓库（在 GitHub 上）

• Tripwire：Dockershim 即将弃用如何影响你的 Kubernetes （发表于 2021/07/01）

3 - Kubelet 设备管理器 API 版本

本页详述了 Kubernetes 设备插件 API 与不同版本的 Kubernetes 本身之间的版本兼容性。

兼容性矩阵

简要说明：

• ✓ 设备插件 API 和 Kubernetes 版本中的特性或 API 对象完全相同。

• + 设备插件 API 具有 Kubernetes 集群中可能不存在的特性或 API 对象， 不是因为设备插件 API 添加了额外的新 API 调用，就是因为服务器移除了旧的 API 调用。 但它们的共同点是（大多数其他 API）都能工作。 请注意，Alpha API 可能会在次要版本的迭代过程中消失或出现重大变更。

• - Kubernetes 集群具有设备插件 API 无法使用的特性，不是因为服务器添加了额外的 API 调用， 就是因为设备插件 API 移除了旧的 API 调用。但它们的共同点是（大多数 API）都能工作。

4 - 节点状态

在 Kubernetes 中，节点的状态是管理 Kubernetes 集群的一个关键方面。在本文中，我们将简要介绍如何监控和维护节点状态以确保集群的健康和稳定。

节点状态字段

一个节点的状态包含以下信息:

• 地址（Addresses）
• 状况（Condition）
• 容量与可分配（Capacity）
• 信息（Info）

你可以使用 kubectl 来查看节点状态和其他细节信息：

kubectl describe node <节点名称>

下面对输出的每个部分进行详细描述。

地址

这些字段的用法取决于你的云服务商或者物理机配置。

• HostName：由节点的内核报告。可以通过 kubelet 的 --hostname-override 参数覆盖。
• ExternalIP：通常是节点的可外部路由（从集群外可访问）的 IP 地址。
• InternalIP：通常是节点的仅可在集群内部路由的 IP 地址。

状况

conditions 字段描述了所有 Running 节点的状况。状况的示例包括：

在 Kubernetes API 中，节点的状况表示节点资源中 .status 的一部分。 例如，以下 JSON 结构描述了一个健康节点：

"conditions": [
  {
    "type": "Ready",
    "status": "True",
    "reason": "KubeletReady",
    "message": "kubelet is posting ready status",
    "lastHeartbeatTime": "2019-06-05T18:38:35Z",
    "lastTransitionTime": "2019-06-05T11:41:27Z"
  }
]

当节点上出现问题时，Kubernetes 控制面会自动创建与影响节点的状况对应的 污点。 例如当 Ready 状况的 status 保持 Unknown 或 False 的时间长于 kube-controller-manager 的 NodeMonitorGracePeriod（默认为 40 秒）时， 会造成 Unknown 状态下为节点添加 node.kubernetes.io/unreachable 污点或在 False 状态下为节点添加 node.kubernetes.io/not-ready 污点。

这些污点会影响悬决的 Pod，因为调度器在将 Pod 分配到节点时会考虑节点的污点。 已调度到节点的当前 Pod 可能会由于施加的 NoExecute 污点被驱逐。 Pod 还可以设置容忍度， 使得这些 Pod 仍然能够调度到且继续运行在设置了特定污点的节点上。

进一步的细节可参阅基于污点的驱逐 和根据状况为节点设置污点。

容量（Capacity）与可分配（Allocatable）

这两个值描述节点上的可用资源：CPU、内存和可以调度到节点上的 Pod 的个数上限。

capacity 块中的字段标示节点拥有的资源总量。 allocatable 块指示节点上可供普通 Pod 使用的资源量。

你可以通过学习如何在节点上预留计算资源 来进一步了解有关容量和可分配资源的信息。

信息（Info）

Info 指的是节点的一般信息，如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、 容器运行时详细信息，以及节点使用的操作系统。 kubelet 从节点收集这些信息并将其发布到 Kubernetes API。

心跳

Kubernetes 节点发送的心跳帮助你的集群确定每个节点的可用性，并在检测到故障时采取行动。

对于节点，有两种形式的心跳：

• 更新节点的 .status
• kube-node-lease 名字空间中的 Lease（租约）对象。 每个节点都有一个关联的 Lease 对象。

与节点的 .status 更新相比，Lease 是一种轻量级资源。 使用 Lease 来表达心跳在大型集群中可以减少这些更新对性能的影响。

kubelet 负责创建和更新节点的 .status，以及更新它们对应的 Lease。

• 当节点状态发生变化时，或者在配置的时间间隔内没有更新事件时，kubelet 会更新 .status。 .status 更新的默认间隔为 5 分钟（比节点不可达事件的 40 秒默认超时时间长很多）。
• kubelet 会创建并每 10 秒（默认更新间隔时间）更新 Lease 对象。 Lease 的更新独立于节点的 .status 更新而发生。 如果 Lease 的更新操作失败，kubelet 会采用指数回退机制，从 200 毫秒开始重试， 最长重试间隔为 7 秒钟。

5 -

content_type: "reference" title: 由 kubelet 填充的节点标签 weight: 40

Kubernetes 节点预先填充了一组标准 标签。

你还可以通过 kubelet 配置或使用 Kubernetes API 在节点上设置自己的标签。

预设标签

Kubernetes 在节点上设置的预设标签有：

• kubernetes.io/arch
• kubernetes.io/hostname
• kubernetes.io/os
• node.kubernetes.io/instance-type （如果 kubelet 知道此信息 – Kubernetes 可能没有这些信息来设置标签）
• topology.kubernetes.io/region （如果 kubelet 知道此信息 – Kubernetes 可能没有这些信息来设置标签）
• topology.kubernetes.io/zone （如果 kubelet 知道此信息 – Kubernetes 可能没有这些信息来设置标签）

接下来

• 有关常见标签的列表，请参阅众所周知的标签、注释和污点。
• 了解如何向节点添加标签。