平滑升级 Kubernetes Master 节点避免服务不可用的核心方案是构建高可用控制平面并结合逐节点驱逐策略。首先应确保集群具备多 Master 架构并通过负载均衡器（如 Nginx 或 HAProxy）代理 API Server 流量，避免单点故障。升级前务必备份 Etcd 数据及 Kubernetes 配置文件以防万一。具体操作时，先将待升级节点标记为不可调度（kubectl cordon），随后驱逐其上运行的 Pod（kubectl drain），确保业务负载迁移至其他健康节点。升级完成后恢复节点调度能力，依次对其他 Master 节点重复此流程，从而实现零停机平滑升级，保障业务连续性。
【k8s】单 master 到多 master 平滑升级_kubernetesv1.21.3 从单 master 升级到 3 个 master-CSDN 博客
【k8s】单 master 到多 master 平滑升级 升级原因 由于单 master 节点用于线上环境发生故障时会导致集群整个不可用，生产环境中有很大风险所以要把集群升级为多 master 且高可用，其中任何一个节点宕机都不影响集群正常运行。本机环境 mater control-plane,master v1.21.0 node1nodev1.21.0 node2nodev1.21.0 一键获取完整项目代码 bash 1 2 3 计划将 node1 和 node2 升级为 master。为了 api-server 高可用，在另两台机器上部署了 haproxy 用来代理 api-server。后文用 inspot:6443 表示新的 api-server 地址。备份 k8s 环境 以防万一备份 k8s 配置 cp-a /etc/kubernetes /etc/kubernetes.bak 一键获取完整项目代码 bash 1 申请新的 api-server 证书 将 kube-system 中的 kubeadm-config 配置导出，并修改配置 kubectl -n kube-system get configmap kubeadm-config -ojsonpath='{.data.ClusterConfiguration}'>kubeadm.yaml 一键获取完整项目代码 bash 1 旧配置 apiServer:extraArgs:authorization-mode:Node,RBACtimeoutForControlPlane:4m0sapiVersion:kubeadm.k8s.io/v1beta2certificatesDir:/etc/kubernetes/pkiclusterName:kubernetescontrolPlaneEndpoint:master:6443controllerManager:{}dns:type:CoreDNSetcd:local:dataDir:/var/lib/etcdimageRepository:k8s.gcr.iokind:ClusterConfigurationkubernetesVersion:v1.21.0networking:dnsDomain:cluster.localpodSubnet:192.168.0.0/16serviceSubnet:10.96.0.0/12scheduler:{} 一键获取完整项目代码 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 新的配置 apiServer:certSANs:-inspot-master-node1-node2-10.196.96.11-10.196.96.12-10.196.96.17extraArgs:authorization-mode:Node,RBACtimeoutForControlPlane:4m0sapiVersion:kubeadm.k8s.io/v1beta2certificatesDir:/etc/kubernetes/pkiclusterName:kubernetescontrolPlaneEndpoint:inspot:6443controllerManager:{}dns:type:CoreDNSetcd:local:dataDir:/var/lib/etcdimageRepository:k8s.gcr.iokind:ClusterConfigurationkubernetesVersion:v1.21.0networking:dnsDomain:cluster.localpodSubnet:192.168.0.0/16serviceSubnet:10.96.0.0/12scheduler:{} 一键获取完整项目代码 yaml 1 2 3
K8s 集群的平滑升级：构建高可用性云原生应用的必经之路_服务_节点_node
升级通常分为两部分：首先是 master 节点的升级，随后是 worker(node) 节点的升级。1. 确定节点状态 通过 kubectl get nodes 命令，管理员可以查看当前节点的状态和版本，以及各个节点的角色与负载情况。这有助于制定升级策略。2. 配置 Nginx 代理 由于 K8s 的 API Server 可能使用了 Nginx 作为代理，升级前需临时注释掉代理中的对应节点配置，以避免在升级过程中发生访问阻断。这是平滑升级的重要步骤之一。升级步骤详解 以下是 K8s 集群的平滑升级步骤，分别针对 master 节点与 node 节点。1. 升级 Master 节点 在升级前，首先需要将 Master 节点上的 API Server、Controller Manager 和 Scheduler 临时移除其相关工作负载。然后按照预定计划，各部分依次进行升级。可以使用如下命令标记节点为不可调度状态：bash kubectl cordon 然后可以执行 kubectl drain <master-node-name> 以完成。2. 升级 Node 节点 在升级 Node 节点时，需遵循先将节点标记为不可调度，随后挪走其中 Pod 的原则。即使 Pod 使用了 emptyDir，在这种情况下也可使用参数删除。bash kubectl drain --delete-local-data --ignore-daemonsets --force
第十四章 二进制部署 k8s 集群的平滑升级 - 沾沾自喜的混子 - 博客园
2、升级说明 升级包括 master 节点升级和 node 节点的升级，本章升级至 v1.15.12; Master 节点的服务包括:apiserver、controller-manager、kube-scheduler; Node 节点的服务包括:kubelet 和 kube-proxy; 由于 apiserver 被 nginx 代理，所以在升级的时候需要操作操作 nginx 注释升级节点，避免带来无法访问的情况; 我们的 master 节点和 node 都是在同一个集群服务器上，所以一起进行操作; 3、确定节点升级顺序 查看节点信息 [root@hdss7-21~]# kubectlgetnode NAME STATUS ROLES AGE VERSION hdss7-21.host.com Ready<none>14d v1.14.10hdss7-22.host.com Ready<none>14d v1.14.10 查看 pod 分布状态，尽量选择较少 pod 的节点先进行迁移 [root@hdss7-21~]# kubectlgetpod-o wide-n kube-systemNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES coredns-64f49f5655-smzzz1/1Running68d172.7.21.4hdss7-21.host.com<none><none>kubernetes-dashboard-99ff79fcd-khl8z1/1Running24d172.7.22.4hdss7-22.host.com<none><none>traefik-ingress-2svq61/1Running35d172.7.21.5hdss7-21.host.com<none><none>traefik-ingress-rcd281/1Running35d172.7.22.3hdss7-22.host.com<none><none> 由于分布差不多，我们选择先升级 10.4.7.21 服务器上的节点 4、修改代理 nginx 配置 在 10.4.7.21 和 22 上都操作，以 21 为例 注释 apiserver 升级节点的服务器 [root@hdss7-11 ~]# vim /etc/nginx/nginx.confupstream kube-apiserver {# server 10.4.7.21:6443 max_fails=3 fail_timeout=30s;server10.4.7.22:6443max_fails=3fail_timeout=30s; } [root@hdss7-11 ~]# nginx -tnginx: the configuration file /etc/nginx/nginx.conf syntaxisok nginx: configuration file /etc/nginx/nginx.conf testissuccessful [root@hdss7-11 ~]# nginx -s reload 5、删除第一个节点 将节点调成不可调度状态 [root@hdss7-21 ~]# kubectl cordon hdss7-21.host.comnode/hdss7-21.host.com cordoned 当节点设置成不可调度状态之后，新启动的 pod 不会调度到此节点上，但是该节点上正在运行的 Pod 将不会被影响。驱逐节点上的 pod [root@hdss7-21 ~]# kubectl drain hdss7-21.host.com --delete-local-data --ignore-daemonsets --forcenode/hdss7-21.host.com already cordoned WARNING: ignoring DaemonSet-managed Pods: default/nginx-ds-2rj9d, kube-system/traefik-ingress-2svq6 evicting pod"coredn
FAQ
问：升级 Master 节点前需要做什么备份？
答：需要备份 k8s 配置和 etcd 数据，例如使用 cp -a /etc/kubernetes /etc/kubernetes.bak 和 etcdctl snapshot save。
问：如何避免升级过程中流量中断？
答：通过 Nginx 或 HAProxy 代理，升级前注释掉待升级节点配置，升级完成后再恢复。
问：如何安全驱逐节点上的 Pod？
答：使用 kubectl drain 命令，并配合--ignore-daemonsets 和--delete-local-data 参数。