企业官网建设流程全解析

1. 为什么线上集群的master节点需要扩容

线上Kubernetes集群跑了一段时间之后，很多团队都会遇到一个很现实的问题：原本三个master节点的控制平面，突然在某次业务高峰期出现了API Server响应变慢、etcd写入延迟飙升、调度器排队的情况。你去看监控，发现三个master的CPU长期在70%以上，etcd的fsync延迟偶尔飙到几百毫秒，kube-scheduler的调度吞吐量明显跟不上Pod创建的速度。这时候，扩容master节点就不再是一个“可选项”，而是一个必须尽快推进的运维动作。

我先把话说在前面：master扩容和worker扩容完全是两码事。worker节点扩容，你直接加机器、join进去就完事了，业务Pod该跑跑，几乎无感。但master节点涉及etcd集群成员变更、证书重新签发、控制平面组件重新配置、负载均衡后端调整等一系列操作，任何一个环节出问题，都可能让整个集群的控制平面进入不可用状态。所以这件事必须谨慎，必须有计划，必须知道每一步在干什么。

这篇文章面向的是已经有一定Kubernetes运维基础的读者，比如你已经在管理一个生产级别的集群，熟悉kubeadm的基本用法，了解etcd的工作原理，知道静态Pod是什么。如果你刚接触K8s没多久，我建议你先别急着在生产环境操作，可以先用测试集群把整个流程走一遍。文章会从整体设计思路讲起，然后逐步拆解每一个核心环节，包括证书处理、etcd成员管理、负载均衡配置、组件验证等，最后分享一些我在实际操作中踩过的坑和总结出来的排查技巧。

整个扩容的核心目标很明确：把新的master节点安全地加入现有控制平面，让etcd集群从3节点扩展到5节点（或者从1节点扩展到3节点），同时保证API Server、Controller Manager、Scheduler等高可用组件在新节点上正常运行，并且所有节点通过负载均衡统一对外提供服务。

为什么是3扩5而不是3扩4？这是一个很经典的分布式系统设计问题。etcd使用Raft共识算法，Raft要求集群成员数为奇数，这样才能在发生网络分区时通过多数派投票选出Leader。3节点的容错能力是1台，5节点的容错能力是2台。如果你扩到4节点，容错能力还是1台，因为4的多数派是3，挂2台就失去多数派了。所以扩容master节点，数量上一定要保持奇数。这是第一个必须记住的原则。

另外一个常见场景是从单master扩展到3master。很多中小团队早期为了节省资源，只部署了一个master节点，所有控制平面组件都跑在这一台上。这种架构在测试环境没问题，但生产环境就是定时炸弹——这台机器一挂，整个集群就失去控制能力。所以从1扩到3，是很多团队在业务稳定后要补的课。这个场景和3扩5在操作上有一些差异，后面会专门讲到。

2. 扩容前的整体设计与关键决策

2.1 扩容方案选型：kubeadm还是手动

市面上扩容master节点主要有两种方式：一种是用kubeadm join --control-plane，另一种是手动配置所有组件。我强烈建议用kubeadm，原因很简单：

• kubeadm会自动帮你处理证书签发、kubeconfig生成、静态Pod清单创建、etcd成员添加等一系列繁琐的操作。
• kubeadm的join流程是幂等的，如果中途失败了，你可以reset之后重新join，不会留下太多脏状态。
• 手动配置的话，你需要自己生成证书、自己写etcd的启动参数、自己配置负载均衡，出错概率极高，而且排查起来非常痛苦。

但kubeadm也不是万能的。有一个关键限制：kubeadm join --control-plane默认会把新节点加入etcd集群，但它不会自动帮你更新负载均衡器的后端列表。也就是说，如果你前面有一个HAProxy或者LVS在做API Server的负载均衡，新master加入之后，你需要手动把新节点的IP加到后端池里。这一点后面会详细讲。

还有一个决策点是：新master节点的etcd数据怎么同步。kubeadm的做法是新节点作为一个全新的etcd成员加入集群，然后通过Raft协议从Leader节点同步数据。这意味着如果你的etcd数据量很大（比如几十GB），新节点加入后需要一段时间才能追上Leader的数据。在这个过程中，etcd集群的性能可能会受到一定影响。所以建议在业务低峰期操作，并且提前确认etcd的数据量大小。

2.2 扩容前的环境检查清单

在动手之前，你必须确认以下几件事。我把它们整理成一个清单，你可以逐项核对：

这个清单里的每一项都不是走形式。我见过太多因为时间不同步导致etcd成员加入失败的案例，也见过证书过期导致join卡住的场景。尤其是etcd快照备份，这是你的最后一道防线。如果扩容过程中etcd集群出了问题，你可以通过快照恢复。没有快照就动手，等于裸奔。

2.3 负载均衡层的前置考虑

在生产环境中，API Server前面通常会有一个负载均衡器，可能是HAProxy、Nginx、LVS，也可能是云厂商的CLB。这个负载均衡器的作用是：所有worker节点和外部客户端都通过一个统一的VIP或者域名来访问API Server，而不是直接连某一个master节点。

扩容master节点时，负载均衡层需要做两件事：

1. 把新master节点的IP加入到后端池。这样新节点才能分担API Server的请求流量。
2. 健康检查配置要正确。负载均衡器需要能够检测到新节点的6443端口是否可用，只有健康检查通过后才把流量转发过去。

如果你用的是HAProxy，配置大概长这样：

frontend k8s-api bind *:6443 mode tcp default_backend k8s-masters backend k8s-masters mode tcp balance roundrobin option tcp-check server master-1 192.168.1.10:6443 check server master-2 192.168.1.11:6443 check server master-3 192.168.1.12:6443 check server master-4 192.168.1.13:6443 check

新节点加入后，你需要在backend里加上server master-4那一行，然后reload HAProxy。注意，reload之前一定要先确认新节点的API Server已经正常启动，否则健康检查失败会导致HAProxy反复重试，影响其他节点的流量分发。

提示：如果你的负载均衡器不支持动态添加后端，比如某些云厂商的CLB需要通过控制台或API操作，那就要提前确认操作权限和流程，避免扩容到一半发现加不进去。

3. 核心细节解析与实操要点

3.1 证书体系：新master节点需要哪些证书

kubeadm部署的Kubernetes集群，证书体系是比较复杂的。新master节点加入时，需要以下几类证书：

• etcd相关证书：etcd peer证书、etcd server证书、etcd健康检查客户端证书。这些证书用于新etcd成员与集群内其他成员通信。
• API Server相关证书：apiserver证书、apiserver-kubelet-client证书、front-proxy-client证书。
• Controller Manager和Scheduler的kubeconfig：这两个组件通过kubeconfig与API Server通信，需要对应的客户端证书。
• Service Account密钥对：sa.key和sa.pub，用于签发Service Account Token。

kubeadm join --control-plane会自动处理这些证书。具体来说，它会从已有的master节点下载证书，或者通过kubeadm-certs Secret来分发证书。这里有一个关键点：kubeadm join --control-plane需要提供一个--certificate-key，这个key用于解密kubeadm-certs Secret中的证书。

获取certificate-key的命令是：

kubeadm init phase upload-certs --upload-certs

这个命令会输出一个key，你需要在join命令中使用它。注意，这个key默认有效期是2小时，如果超时了需要重新生成。

注意：如果你的集群证书是自签名的，并且你使用了自定义的CA，那么新节点加入时需要确保CA证书能够正确分发。否则新节点上的组件会因为证书验证失败而无法启动。

3.2 etcd成员管理：加入与移除的时机

etcd集群的成员变更是整个扩容过程中最敏感的部分。Raft协议要求任何成员变更都必须经过多数派同意，而且一次只能变更一个成员。所以你不能同时加入两个新节点，必须一个一个来。

kubeadm join --control-plane在执行时，会调用etcdctl member add命令把新节点加入集群。这个操作会返回一个新的成员ID和集群配置。然后新节点上的etcd会以这个成员ID启动，开始从Leader同步数据。

这里有几个关键注意事项：

1. 加入新成员后，etcd集群的Quorum会暂时变得脆弱。比如3节点集群，加入第4个节点时，Quorum仍然是2（因为4的多数派是3），但此时如果有一个节点挂了，集群就只剩3个节点，刚好满足Quorum。如果再加第5个节点，Quorum变成3，容错能力恢复到2。所以在加入第4个节点的过程中，集群的容错能力是最低的。这就是为什么建议在业务低峰期操作。

2. 新节点加入后，要确认etcd数据同步完成。你可以通过以下命令查看：

etcdctl --endpoints=https://127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ endpoint status --write-out=table

输出中会显示每个节点的DB Size和Leader信息。如果新节点的DB Size明显小于其他节点，说明数据还在同步中，需要等待。

3. 如果join失败，需要先移除失败的成员。etcd不允许存在两个相同ID的成员，也不允许一个成员同时以不同ID存在。如果join过程中断，你需要用etcdctl member remove把失败的成员移除，然后重新join。

etcdctl member list etcdctl member remove <member-id>

提示：移除成员时，一定要确认移除的是正确的成员ID。误删正常成员会导致集群失去Quorum，那就只能从快照恢复了。

3.3 静态Pod与kubelet配置

kubeadm部署的控制平面组件都是以静态Pod的形式运行的，Pod清单文件放在/etc/kubernetes/manifests/目录下。新master节点加入后，kubelet会自动加载这些清单文件，启动对应的静态Pod。

这里有一个容易忽略的点：kubelet的配置。新节点的kubelet需要配置正确的--pod-infra-container-image、--cluster-dns、--cluster-domain等参数。这些参数在kubeadm join时会通过kubelet-config ConfigMap自动下发。但如果你的集群有自定义的kubelet配置，比如特定的cgroup driver、特定的运行时配置，那么新节点也需要保持一致。

另外，kubelet的证书也是通过kubeadm join自动生成的。新节点的kubelet会使用bootstrap token向API Server申请证书，然后通过TLS Bootstrap机制自动续期。这个过程需要确保bootstrap token有效，并且RBAC配置正确。

3.4 网络插件与控制平面流量的关系

虽然网络插件（CNI）主要影响Pod之间的通信，但控制平面组件之间的通信也依赖于网络。比如API Server需要访问etcd的2379端口，Controller Manager和Scheduler需要访问API Server的6443端口。这些通信走的是主机网络，不经过CNI。

但是，如果你使用的是Overlay网络，比如Calico的IPIP模式或者Flannel的VXLAN模式，新master节点加入后，CNI插件需要能够在新节点上正常运行。否则，如果新节点上调度了Pod（虽然master节点默认有污点，但如果你去掉了污点），Pod之间的通信可能会出问题。

所以，扩容master节点时，也要确认CNI插件在新节点上能够正常启动。你可以通过以下命令检查：

kubectl get pods -n kube-system -o wide | grep <new-node-name>

如果CNI Pod没有正常运行，需要查看日志排查原因。

4. 完整实操流程与核心环节实现

4.1 第一步：备份etcd与集群配置

这是所有操作的前提。没有备份，不要动手。

# 在任意一个健康的master节点上执行 ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot-$(date +%Y%m%d%H%M%S).db \ --endpoints=https://127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key # 验证快照 ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-snapshot-xxx.db --write-out=table

同时，备份/etc/kubernetes/目录下的所有配置文件和证书：

tar -czvf /backup/kubernetes-config-$(date +%Y%m%d).tar.gz /etc/kubernetes/

4.2 第二步：准备新master节点

新节点的操作系统、Docker或containerd版本、kubelet版本、kubeadm版本必须与现有master一致。具体准备步骤包括：

# 关闭swap swapoff -a sed -i '/swap/s/^/#/' /etc/fstab # 加载内核模块 modprobe br_netfilter modprobe overlay # 配置sysctl cat <<EOF > /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 EOF sysctl --system # 安装containerd（版本与现有节点一致） # 安装kubeadm、kubelet、kubectl（版本与现有节点一致）

注意：新节点的主机名必须唯一，不能与现有节点重复。同时，/etc/hosts文件要配置好所有master节点的域名解析。

4.3 第三步：获取join命令与certificate-key

在现有master节点上执行：

# 生成certificate-key kubeadm init phase upload-certs --upload-certs # 输出示例： # [upload-certs] Storing the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace # [upload-certs] Using certificate key: # 1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5y6z # 生成join命令 kubeadm token create --print-join-command # 输出示例： # kubeadm join 192.168.1.100:6443 --token abcdef.1234567890abcdef \ # --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

把certificate-key和join命令组合起来，完整的join命令是：

kubeadm join 192.168.1.100:6443 --token abcdef.1234567890abcdef \ --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \ --control-plane --certificate-key 1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5y6z

4.4 第四步：在新节点上执行join

在新节点上执行上面的join命令。执行过程中，你会看到类似以下的输出：

[preflight] Running pre-flight checks [preflight] Reading configuration from the cluster... [preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml' [preflight] Running pre-flight checks before initializing the new control plane instance [preflight] Pulling images required for setting up a Kubernetes cluster [preflight] This might take a minute or two, depending on the speed of your internet connection [preflight] You can also perform this action in beforehand using 'kubeadm config images pull' [certs] Using certificateDir folder "/etc/kubernetes/pki" [certs] Generating "etcd/server" certificate and key [certs] etcd/server serving cert is signed for DNS names [new-master localhost] and IPs [192.168.1.13 127.0.0.1 ::1] [certs] Generating "etcd/peer" certificate and key [certs] etcd/peer serving cert is signed for DNS names [new-master localhost] and IPs [192.168.1.13 127.0.0.1 ::1] [certs] Generating "etcd/healthcheck-client" certificate and key [certs] Generating "apiserver-etcd-client" certificate and key [certs] Generating "etcd/ca" certificate and key ... [etcd] Announced new etcd member joining to the existing etcd cluster [etcd] Creating static Pod manifest for "etcd" [etcd] Waiting for the new etcd member to join the cluster. This can take up to 40s [mark-control-plane] Marking the node new-master as control-plane by adding the labels: [node-role.kubernetes.io/master(deprecated) node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers] [mark-control-plane] Marking the node new-master as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]

看到最后几行，说明join成功了。此时新节点已经作为control-plane节点加入集群。

4.5 第五步：验证新节点状态

在任意master节点上执行：

kubectl get nodes

你应该能看到新节点状态为Ready，角色为control-plane,master。

然后检查控制平面Pod：

kubectl get pods -n kube-system -o wide | grep new-master

你应该能看到kube-apiserver-new-master、kube-controller-manager-new-master、kube-scheduler-new-master、etcd-new-master这四个Pod处于Running状态。

再检查etcd集群健康：

etcdctl --endpoints=https://192.168.1.10:2379,https://192.168.1.11:2379,https://192.168.1.12:2379,https://192.168.1.13:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ endpoint health --write-out=table

所有节点都应该返回healthy。

4.6 第六步：更新负载均衡配置

把新master节点的IP加入到负载均衡器的后端池。以HAProxy为例：

backend k8s-masters mode tcp balance roundrobin option tcp-check server master-1 192.168.1.10:6443 check server master-2 192.168.1.11:6443 check server master-3 192.168.1.12:6443 check server master-4 192.168.1.13:6443 check

然后reload HAProxy：

haproxy -f /etc/haproxy/haproxy.cfg -c systemctl reload haproxy

验证负载均衡是否正常工作：

curl -k https://192.168.1.100:6443/healthz

应该返回ok。

4.7 第七步：重复操作加入更多节点

如果你需要从3节点扩展到5节点，重复第4.2到4.6步，加入第5个节点。记住，一次只能加入一个节点，等前一个节点完全加入并稳定后，再加入下一个。

全部加入完成后，再次检查etcd集群健康状态和节点状态，确保一切正常。

5. 常见问题与排查技巧实录

5.1 join过程中卡在etcd等待阶段

这是最常见的问题之一。join命令执行到[etcd] Waiting for the new etcd member to join the cluster时卡住，超过40秒后报错。

排查思路：

1. 检查新节点与现有master的2379和2380端口是否互通。etcd peer通信使用2380端口，如果这个端口被防火墙拦截，新成员无法加入。
2. 检查etcd的证书是否正确。新节点的etcd证书必须由同一个CA签发，否则无法通过TLS验证。
3. 检查现有etcd集群的健康状态。如果现有集群本身就不健康，新成员无法加入。
4. 查看新节点上etcd容器的日志：

crictl logs $(crictl ps -a | grep etcd | awk '{print $1}')

常见错误包括：etcdserver: assign member ID failed、rafthttp: failed to find member等。

解决方法：如果确认是网络问题，开放端口后重新join。如果是证书问题，需要清理新节点的/etc/kubernetes/pki/etcd/目录，重新join。如果是现有集群不健康，先修复现有集群。

5.2 新节点加入后API Server无法启动

新节点join成功后，kube-apiserver-new-master Pod一直处于CrashLoopBackOff状态。

排查思路：

1. 查看API Server容器日志：

crictl logs $(crictl ps -a | grep kube-apiserver | awk '{print $1}')

2. 常见错误包括：

   • Unable to register node with API server：通常是kubelet证书问题。
   • etcdserver: request timed out：etcd连接问题。
   • x509: certificate signed by unknown authority：证书CA不匹配。

3. 检查/etc/kubernetes/pki/目录下的证书是否完整。

解决方法：如果是证书问题，可以从其他master节点复制对应的证书文件过来，然后重启kubelet。如果是etcd连接问题，检查etcd Pod是否正常运行。

5.3 负载均衡后端健康检查失败

新节点加入负载均衡后，健康检查一直失败，HAProxy把新节点标记为DOWN。

排查思路：

1. 在新节点上直接测试API Server：

curl -k https://192.168.1.13:6443/healthz

如果返回ok，说明API Server本身没问题，问题出在负载均衡器到新节点的网络。

2. 检查负载均衡器到新节点的网络连通性。
3. 检查新节点的防火墙规则，确保6443端口对负载均衡器开放。

解决方法：开放防火墙端口，或者调整负载均衡器的健康检查参数。

5.4 etcd数据同步缓慢

新节点加入后，etcd数据同步很慢，DB Size长时间远小于其他节点。

排查思路：

1. 检查网络带宽和延迟。etcd数据同步对网络质量要求较高。
2. 检查新节点的磁盘IO性能。etcd对磁盘fsync延迟非常敏感。
3. 检查etcd的--snapshot-count参数。如果这个值太大，同步会变慢。

解决方法：如果数据量确实很大，可以考虑通过etcd快照恢复的方式初始化新节点，而不是通过Raft同步。具体做法是：先在新节点上恢复快照，然后以已有成员的身份加入集群。不过这个操作比较复杂，建议参考etcd官方文档。

5.5 常见问题速查表

6. 实操心得与避坑经验

6.1 关于证书有效期的坑

我遇到过好几次这样的情况：集群跑了一年多，证书快过期了，正好要扩容master节点。结果join的时候一切正常，但过几天证书过期，整个集群挂了。所以扩容之前一定要检查证书有效期，如果剩余有效期不足30天，先续期再扩容。

kubeadm certs check-expiration kubeadm certs renew all

续期之后需要重启控制平面Pod才能生效。

6.2 关于etcd快照的坑

etcd快照备份不是随便save一下就完事了。你需要验证快照的完整性，并且定期做恢复演练。我见过有人备份了快照，但恢复的时候发现快照损坏，根本用不了。验证快照的命令是：

etcdctl snapshot status /backup/etcd-snapshot-xxx.db --write-out=table

如果输出中DB Size、Revision等信息正常，说明快照可用。

6.3 关于负载均衡的坑

如果你的负载均衡器是云厂商的CLB，添加后端服务器时需要注意：CLB的健康检查路径要配置为/healthz，而不是/。因为API Server的/路径返回的是403，健康检查会失败。另外，CLB的会话保持要关闭，否则所有请求都打到同一个master节点，失去了负载均衡的意义。

6.4 关于版本一致性的坑

新节点的kubeadm版本必须与现有集群一致，否则join时会报版本不兼容的错误。如果你用的是apt或yum安装，可以通过以下命令查看可用版本：

apt-cache madison kubeadm yum list kubeadm --showduplicates

然后安装指定版本：

apt-get install kubeadm=1.24.3-00 kubelet=1.24.3-00 kubectl=1.24.3-00

6.5 关于操作时机的坑

扩容master节点最好在业务低峰期进行，比如凌晨。因为etcd成员变更期间，集群的写入性能会有所下降，如果此时业务高峰期有大量Pod创建或更新，可能会导致API Server响应变慢。另外，如果扩容过程中出现问题，低峰期也有更多时间排查和恢复。

6.6 一个容易被忽略的细节：kube-proxy

虽然kube-proxy主要运行在worker节点上，但master节点上通常也会运行kube-proxy（以DaemonSet形式）。新master节点加入后，kube-proxy Pod会自动调度到新节点上。你需要确认kube-proxy在新节点上正常运行，否则新节点上的Service访问可能会出问题。

kubectl get pods -n kube-system -o wide | grep kube-proxy | grep new-master

如果kube-proxy没有正常运行，检查其日志，常见原因是iptables规则冲突或者IPVS模式配置问题。

6.7 扩容完成后的收尾工作

扩容完成后，建议做以下几件事：

1. 更新kubeadm-config ConfigMap。kubeadm join时会自动更新这个ConfigMap，但你可以手动确认一下：

kubectl -n kube-system get cm kubeadm-config -o yaml

2. 更新集群的API Server端点列表。如果你使用了kubeadm的ClusterConfiguration，里面的controlPlaneEndpoint应该指向负载均衡器的VIP，而不是某一个具体的master节点。

3. 监控新节点的资源使用情况。观察新节点的CPU、内存、磁盘IO、网络流量，确保其能够正常分担控制平面的负载。

4. 更新文档和CMDB。把新节点的信息记录到运维文档和配置管理数据库中，方便后续维护。

6.8 关于从1扩到3的特殊说明

从单master扩展到3master，操作流程和3扩5基本一致，但有一个关键差异：单master集群的etcd是单节点模式，没有集群Quorum的概念。当你加入第2个master节点时，etcd会从单节点变成2节点集群。但2节点集群的Quorum是2，意味着任何一台挂了都会失去Quorum。所以从1扩到3的过程中，加入第2个节点后，集群的容错能力反而下降了（从单节点无容错但可用，变成2节点无容错且可能失去Quorum）。

因此，从1扩到3时，建议一次性把两个新节点都准备好，然后连续执行join，尽量缩短2节点状态的持续时间。当然，etcd成员变更一次只能加一个，所以你还是得一个一个join，但可以把两个join操作安排得很紧凑，减少风险窗口。

另外，单master集群的证书可能只有一套，join第2个节点时，certificate-key的生成和分发要确保正确。如果原master节点的证书配置有自定义修改，新节点也要同步这些修改。

6.9 关于资源规划的建议

master节点的资源规划，我个人的经验是：

• CPU：至少4核，建议8核。API Server和etcd都是CPU敏感型组件。
• 内存：至少16GB，建议32GB。etcd对内存要求较高，数据量大的集群需要更多内存。
• 磁盘：必须使用SSD，建议NVMe。etcd的fsync延迟直接受磁盘IO性能影响。磁盘容量至少100GB，建议200GB以上。
• 网络：至少千兆，建议万兆。etcd成员之间的数据同步对网络带宽和延迟有要求。

如果你用的是云服务器，建议选择计算优化型或通用型实例，不要选择突发性能型实例，因为突发性能型的CPU积分机制会导致性能不稳定。

6.10 最后一点个人体会

扩容master节点这件事，技术上的难点其实不算特别高，但心理压力大。因为一旦操作失误，影响的是整个集群的控制平面，所有业务都会受影响。所以我的建议是：在测试环境反复演练，把每一个步骤都走通，把每一个可能出错的地方都提前想到。正式操作时，严格按照预案执行，每一步都验证后再进行下一步。不要赶时间，不要跳过验证步骤。

另外，保持冷静。即使join失败了，只要etcd快照还在，集群就不会彻底挂掉。最坏的情况也就是回滚到扩容前的状态。所以备份做好，心态放平，按部就班操作，一般都不会出大问题。