3-11-8-API发起的驱逐
API 发起的驱逐是一个先调用 Eviction API创建 Eviction 对象 , 再由该对象体面地中止 Pod 的过程。
你可以通过直接调用 Eviction API 发起驱逐 , 也可以通过编程的方式使用 API 服务器的客户端来发起驱逐 , 比如 kubectl drain 命令。 此操作创建一个 Eviction 对象 , 该对象再驱动 API 服务器终止选定的 Pod。
API 发起的驱逐将遵从你的 PodDisruptionBudgets和 terminationGracePeriodSeconds配置。
使用 API 创建 Eviction 对象 , 就像对 Pod 执行策略控制的 DELETE操作
1. 调用 Eviction API
你可以使用 Kubernetes语言客户端来访问 Kubernetes API 并创建 Eviction 对象。 要执行此操作 , 你应该用 POST 发出要尝试的请求 , 类似于下面的示例 :
policy/v1policy/v1beta1
说明 :
policy/v1 版本的 Eviction 在 v1.22 以及更高的版本中可用 , 之前的发行版本使用 policy/v1beta1 版本。
{
"apiVersion": "policy/v1",
"kind": "Eviction",
"metadata": {
"name": "quux",
"namespace": "default"
}
}说明 :
在 v1.22 版本废弃以支持 policy/v1。
{
"apiVersion": "policy/v1beta1",
"kind": "Eviction",
"metadata": {
"name": "quux",
"namespace": "default"
}
}或者 , 你可以通过使用 curl 或者 wget 来访问 API 以尝试驱逐操作 , 类似于以下示例 :
curl -v -H 'Content-type: application/json' https://your-cluster-api-endpoint.example/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json2. API 发起驱逐的工作原理
当你使用 API 来请求驱逐时 , API 服务器将执行准入检查 , 并通过以下方式之一做出响应 :
200 OK: 允许驱逐 , 子资源Eviction被创建 , 并且Pod被删除 , 类似于发送一个DELETE请求到Pod地址。429 Too Many Requests: 当前不允许驱逐 , 因为配置了PodDisruptionBudget。 你可以稍后再尝试驱逐。你也可能因为API速率限制而看到这种响应。500 Internal Server Error: 不允许驱逐 , 因为存在配置错误 , 例如存在多个PodDisruptionBudgets引用同一个Pod。
如果你想驱逐的 Pod 不属于有 PodDisruptionBudget 的工作负载 , API 服务器总是返回 200 OK 并且允许驱逐。
如果 API 服务器允许驱逐 , Pod 按照如下方式删除 :
API服务器中的Pod资源会更新上删除时间戳 , 之后API服务器会认为此Pod资源将被终止。 此Pod资源还会标记上配置的宽限期。本地运行状态的
Pod所处的节点上的kubelet注意到Pod资源被标记为终止 , 并开始优雅停止本地Pod。当
kubelet停止Pod时 , 控制面从Endpoint和EndpointSlice对象中移除该Pod。因此 , 控制器不再将此Pod视为有用对象。Pod的宽限期到期后 ,kubelet强制终止本地Pod。kubelet告诉API服务器删除Pod资源。API服务器删除Pod资源。
3. 解决驱逐被卡住的问题
在某些情况下 , 你的应用可能进入中断状态 , 在你干预之前 , 驱逐 API 总是返回 429 或 500。 例如 , 如果 ReplicaSet 为你的应用程序创建了 Pod , 但新的 Pod 没有进入 Ready 状态 , 就会发生这种情况。 在最后一个被驱逐的 Pod 有很长的终止宽限期的情况下 , 你可能也会注意到这种行为。
如果你注意到驱逐被卡住 , 请尝试以下解决方案之一 :
终止或暂停导致问题的自动化操作 , 重新启动操作之前 , 请检查被卡住的应用程序。
等待一段时间后 , 直接从集群控制平面删除
Pod, 而不是使用Eviction API。
参考链接
调度、抢占和驱逐 - API 发起的驱逐 - 《Kubernetes v1.28 中文文档》 - 书栈网 · BookStack