本部分包含以下有关节点的参考主题:
- Kubelet 的 Checkpoint API
- 一系列关于 dockershim 移除和使用兼容 CRI 运行时的文章
- 节点
.status
信息
你还可以从 Kubernetes 文档的其他地方阅读节点的详细参考信息,包括:
本部分包含以下有关节点的参考主题:
.status
信息你还可以从 Kubernetes 文档的其他地方阅读节点的详细参考信息,包括:
Kubernetes v1.25 [alpha]
为容器生成检查点这个功能可以为一个正在运行的容器创建有状态的拷贝。 一旦容器有一个有状态的拷贝,你就可以将其移动到其他计算机进行调试或类似用途。
如果你将通过检查点操作生成的容器数据移动到能够恢复该容器的一台计算机, 所恢复的容器将从之前检查点操作执行的时间点继续运行。 你也可以检视所保存的数据,前提是你拥有这类操作的合适工具。
创建容器的检查点可能会产生安全隐患。
通常,一个检查点包含执行检查点操作时容器中所有进程的所有内存页。
这意味着以前存在于内存中的一切内容现在都在本地磁盘上获得。
这里的内容包括一切私密数据和可能用于加密的密钥。
底层 CRI 实现(该节点上的容器运行时)应创建只有 root
用户可以访问的检查点存档。
另外重要的是记住:如果检查点存档被转移到另一个系统,该检查点存档的所有者将可以读取所有内存页。
post
对指定的容器执行检查点操作 告知 kubelet 对指定 Pod 中的特定容器执行检查点操作。
查阅 Kubelet 身份验证/鉴权参考了解如何控制对 kubelet 检查点接口的访问。
Kubelet 将对底层 CRI 实现请求执行检查点操作。
在该检查点请求中,Kubelet 将检查点存档的名称设置为 checkpoint-<pod 全称>-<容器名称>-<时间戳>.tar
,
还会请求将该检查点存档存储到其根目录(由 --root-dir
定义)下的 checkpoints
子目录中。
这个目录默认为 /var/lib/kubelet/checkpoints
。
检查点存档的格式为 tar,可以使用 tar
的一种实现来读取。存档文件的内容取决于底层 CRI 实现(该节点的容器运行时)。
POST /checkpoint/{namespace}/{pod}/{container}
namespace (路径参数):string,必需
名字空间(Namespace)pod (路径参数):string,必需
Podcontainer (路径参数):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(参阅错误消息了解更多细节))
这是关于 Kubernetes 弃用和移除 dockershim 或使用兼容 CRI 的容器运行时相关的文章和其他页面的列表。
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)
本页详述了 Kubernetes 设备插件 API 与不同版本的 Kubernetes 本身之间的版本兼容性。
v1alpha1 |
v1beta1 |
|
---|---|---|
Kubernetes 1.21 | - | ✓ |
Kubernetes 1.22 | - | ✓ |
Kubernetes 1.23 | - | ✓ |
Kubernetes 1.24 | - | ✓ |
Kubernetes 1.25 | - | ✓ |
Kubernetes 1.26 | - | ✓ |
简要说明:
✓
设备插件 API 和 Kubernetes 版本中的特性或 API 对象完全相同。+
设备插件 API 具有 Kubernetes 集群中可能不存在的特性或 API 对象,
不是因为设备插件 API 添加了额外的新 API 调用,就是因为服务器移除了旧的 API 调用。
但它们的共同点是(大多数其他 API)都能工作。
请注意,Alpha API 可能会在次要版本的迭代过程中消失或出现重大变更。-
Kubernetes 集群具有设备插件 API 无法使用的特性,不是因为服务器添加了额外的 API 调用,
就是因为设备插件 API 移除了旧的 API 调用。但它们的共同点是(大多数 API)都能工作。在 Kubernetes 中,节点的状态是管理 Kubernetes 集群的一个关键方面。在本文中,我们将简要介绍如何监控和维护节点状态以确保集群的健康和稳定。
一个节点的状态包含以下信息:
你可以使用 kubectl
来查看节点状态和其他细节信息:
kubectl describe node <节点名称>
下面对输出的每个部分进行详细描述。
这些字段的用法取决于你的云服务商或者物理机配置。
--hostname-override
参数覆盖。conditions
字段描述了所有 Running
节点的状况。状况的示例包括:
节点状况 | 描述 |
---|---|
Ready |
如节点是健康的并已经准备好接收 Pod 则为 True ;False 表示节点不健康而且不能接收 Pod;Unknown 表示节点控制器在最近 node-monitor-grace-period 期间(默认 40 秒)没有收到节点的消息 |
DiskPressure |
True 表示节点存在磁盘空间压力,即磁盘可用量低,否则为 False |
MemoryPressure |
True 表示节点存在内存压力,即节点内存可用量低,否则为 False |
PIDPressure |
True 表示节点存在进程压力,即节点上进程过多;否则为 False |
NetworkUnavailable |
True 表示节点网络配置不正确;否则为 False |
如果使用命令行工具来打印已保护(Cordoned)节点的细节,其中的 Condition 字段可能包括
SchedulingDisabled
。SchedulingDisabled
不是 Kubernetes API 中定义的
Condition,被保护起来的节点在其规约中被标记为不可调度(Unschedulable)。
在 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 仍然能够调度到且继续运行在设置了特定污点的节点上。
进一步的细节可参阅基于污点的驱逐 和根据状况为节点设置污点。
这两个值描述节点上的可用资源:CPU、内存和可以调度到节点上的 Pod 的个数上限。
capacity
块中的字段标示节点拥有的资源总量。
allocatable
块指示节点上可供普通 Pod 使用的资源量。
你可以通过学习如何在节点上预留计算资源 来进一步了解有关容量和可分配资源的信息。
Info 指的是节点的一般信息,如内核版本、Kubernetes 版本(kubelet
和 kube-proxy
版本)、
容器运行时详细信息,以及节点使用的操作系统。
kubelet
从节点收集这些信息并将其发布到 Kubernetes API。
Kubernetes 节点发送的心跳帮助你的集群确定每个节点的可用性,并在检测到故障时采取行动。
对于节点,有两种形式的心跳:
与节点的 .status
更新相比,Lease 是一种轻量级资源。
使用 Lease 来表达心跳在大型集群中可以减少这些更新对性能的影响。
kubelet 负责创建和更新节点的 .status
,以及更新它们对应的 Lease。
.status
。
.status
更新的默认间隔为 5 分钟(比节点不可达事件的 40 秒默认超时时间长很多)。kubelet
会创建并每 10 秒(默认更新间隔时间)更新 Lease 对象。
Lease 的更新独立于节点的 .status
更新而发生。
如果 Lease 的更新操作失败,kubelet 会采用指数回退机制,从 200 毫秒开始重试,
最长重试间隔为 7 秒钟。content_type: "reference" title: 由 kubelet 填充的节点标签 weight: 40
你还可以通过 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 可能没有这些信息来设置标签)这些标签的值是特定于云提供商的,并且不保证其可靠性。
例如,kubernetes.io/hostname
的值在某些环境中可能与节点名称相同,
而在其他环境中可能与节点名称不同。