标签:前言 滚动 hub curl 帮助 date 过程 最小 不可用
当我们要进行 K8S 节点维护时往往需要执行 kubectl drain
, 等待节点上的 Pod 被驱逐后再进行维护动作。
命令行如下:
kubectl drain NODE
待节点排空后再进行维护操作, 内核升级等。
drain
命令有一个问题, 他不会考虑资源所定义的 UpdateStrategy, 而直接强制驱逐或删除 Pod, 这样就会导致 Deployment 或 StatefulSet 资源的 Pod 达不到所设置的策略数.
replicas: 2
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
副本数为 3, 采用了滚动更新, 并且先启动完成一个 Pod 后再进行旧 Pod 的删除(最大不可用为0,最小可用为2).Deployment 的 Pod 全部运行在需要维护的节点上, 这时候执行 drain
那将是一个灾难, 这个 Deployment 在新的Pod启动之前它无法在对外提供服务了, 恢复的时间取决于新 Pod 的启动速度。
GitHub: https://github.com/majian159/kubectl-safe-drain
一个 kubectl 插件, 用于更为安全的排空节点。
对于 Deployment 和 StatefulSet 资源会根据其配置的更新策略先将Pod调度到其它可用节点。
spec:
replicas: 2
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
操作前有两个可用 Pod
safe-drain
后从 Deployment watch 的信息中可见最小 Ready 数没有小于 2, 从 Pod watch 的信息中可见 kind-worker2 上承载了 2 个准备就绪的 nginx Pod, 也就是说 nginx 从 kind-worker 安全的移动到了 kind-worker2 节点上。
PDB 只会保障 Pod 不被驱逐, 而不会帮助它在其它可用节点上重建。
使用了 PDB 后能防止服务不可用的尴尬情况,但它还是需要人工手动迁移 Pod。
理想的情况是搭配 PDB 使用, 防止严苛情况下服务不可用的问题。
curl -sLo sdrain.tgz https://github.com/majian159/kubectl-safe-drain/releases/download/v0.0.1-preview1/kubectl-safe-drain_0.0.1-preview1_linux_amd64.tar.gz && tar xf sdrain.tgz && rm -f sdrain.tgz && mv kubectl-safe-drain /usr/local/bin/kubectl-safe_drain
curl -sLo sdrain.tgz https://github.com/majian159/kubectl-safe-drain/releases/download/v0.0.1-preview1/kubectl-safe-drain_0.0.1-preview1_darwin_amd64.tar.gz && tar xf sdrain.tgz && rm -f sdrain.tgz && mv kubectl-safe-drain /usr/local/bin/kubectl-safe_drain
curl -O https://raw.githubusercontent.com/majian159/kubectl-safe-drain/master/krew.yaml && kubectl krew install --manifest=krew.yaml && rm -f krew.yaml
kubectl safe-drain NODE
# safe-drain并没有调用 drain命令, 而是利用了 SchedulingDisabled 机制
# 所以如有需要可以继续使用 drain 命令来确保节点被驱逐
kubectl drain NODE
该项目部分代码源于 kubectl 项目。
标签:前言 滚动 hub curl 帮助 date 过程 最小 不可用
原文地址:https://www.cnblogs.com/ants/p/12804407.html