服务器集群命令并不是一套统一指令，而是围绕节点管理、调度编排、监控排障、存储网络、安全权限五类场景，由操作系统、集群软件和编排平台共同提供的一组操作入口，掌握这五类命令，才能把集群从“能跑”管到“跑得稳”。
服务器集群常用命令有哪些？先分清这三层
很多新手一上来就背命令,结果发现同一个“查看状态”，在不同集群里敲法完全不一样，原因在于服务器集群命令天然分成三层，每层的命令来源不同。
节点层：管的是机器本身
这一层贴近操作系统,命令由Linux发行版和集群基础软件提供，负责把一台台服务器“串”成集群。
- 节点加入与移除：
pcs cluster node add、pcs cluster node remove、kubeadm join、kubeadm reset - 集群服务启停：
systemctl start corosync、systemctl status pacemaker、systemctl restart keepalived - 节点状态查看：
pcs status nodes、crm_mon -1、kubectl get nodes -o wide - 时间同步检查：
chronyc sources -v、timedatectl status，集群节点时间漂移超过阈值，心跳就会误判
调度层：管的是任务往哪放
这一层是集群的“大脑”，命令负责把服务、容器、任务分配到合适节点，业内专家指出，调度层命令用错，比节点宕机更难排查。
- 资源查看与调度：
kubectl describe node、kubectl get pods -o wide、pcs resource show - 手动迁移与重调度：
pcs resource move、kubectl cordon、kubectl drain - 副本与扩缩容：
kubectl scale deployment、kubectl rollout status
集群层：管的是整体健康
集群层命令不针对某一台机器,而是看全局。
- 集群整体状态：
kubectl cluster-info、pcs status、ceph -s - 配置与证书：
kubeadm certs check-expiration、pcs config show - 事件流查看：
kubectl get events --sort-by=.lastTimestamp、journalctl -u pacemaker -f
Linux服务器集群命令和单机命令有什么区别？
这是搜索量很稳定的一个对比问题,区别不在语法，而在“作用域”和“后果”。
作用域从一台变成一片
单机上的 systemctl restart nginx 只影响本机；集群里的 pcs resource restart nginx 可能触发资源迁移、VIP漂移和健康检查连锁反应。同一类操作，集群命令默认带有全局含义，执行前要先确认影响范围。
命令往往带分布式后缀或参数
单机命令通常简洁,集群命令会多出节点选择、命名空间、资源组等参数。kubectl delete pod 后面不加 --grace-period 和 --force 的取舍，可能卡在终止状态；pcs resource move 不加 --lifetime，资源可能被永久钉在某一节点。
并发与权限更敏感
集群命令常涉及多个节点同时执行,用 for 循环批量 SSH 敲命令，在十几台机器上还能应付，到上百台就容易出现“部分成功、部分失败”的中间态，行业共识认为，集群规模超过一定节点数后，应改用配置管理工具或编排平台统一下发，而不是手写批量脚本。
常用对照表
| 操作目的 | 单机命令 | 集群对应命令 |
|---|---|---|
| 查看服务状态 | systemctl status |
pcs status、kubectl get pods |
| 重启服务 | systemctl restart |
pcs resource restart、kubectl rollout restart |
| 下线一台机器 | shutdown -h now |
kubectl drain、pcs cluster standby |
| 查看日志 | journalctl -u |
kubectl logs、journalctl -u pacemaker |
高可用集群命令有哪些？Keepalived与Pacemaker实操
高可用集群命令是运维面试和日常故障处理的高频考点,主流方案分两类。
Keepalived：轻量级VIP漂移
适合双机热备、入口负载场景，命令集中在服务控制和状态查看。
systemctl status keepalived查看守护进程ip addr show确认VIP落在哪台机器journalctl -u keepalived -n 50查看漂移记录tcpdump -i eth0 vrrp抓VRRP心跳包，判断是否脑裂
Pacemaker与Corosync：资源级高可用
适合数据库、中间件等需要精细控制的场景。
pcs status看全局，重点看资源是否落在预期节点pcs resource move <资源名> <节点名>手动迁移pcs resource clear <资源名>清除迁移约束pcs cluster standby <节点名>让节点进入待机，验证切换crm_verify -LV检查配置合法性
故障切换验证的正确姿势
别等真故障才验证,标准做法是：先 pcs cluster standby 模拟节点下线，观察VIP和资源是否在设定时间内完成迁移，再用 pcs cluster unstandby 恢复，整个过程用 crm_mon -1 记录时间点，切换时间超过业务容忍窗口就是隐患。
Kubernetes集群管理命令清单与排障顺序
容器化集群的命令更密集,但日常高频的就那几条。
kubectl高频命令
kubectl get nodes、kubectl get pods -A -o wide看分布kubectl describe pod <名称>看事件和调度失败原因kubectl logs <Pod> --previous看崩溃前的日志kubectl exec -it <Pod> -- sh进容器排查kubectl top nodes、kubectl top pods看资源水位
节点维护标准流程
kubectl cordon <节点>标记不可调度kubectl drain <节点> --ignore-daemonsets --delete-emptydir-data驱逐工作负载- 完成硬件或系统维护
kubectl uncordon <节点>恢复调度
顺序反了,新Pod可能被调度到正在维护的节点上。
服务器集群命令怎么排查故障？按这个顺序走
故障现场最忌乱敲命令,推荐固定顺序：节点、服务、网络、日志。
- 第一步看节点：
kubectl get nodes或pcs status nodes，确认是否有节点 NotReady 或离线 - 第二步看服务：
kubectl get pods -A | grep -v Running，或pcs status resources，找出异常资源 - 第三步看网络：
ping、traceroute、ss -tlnp确认端口和路由，集群内还要看iptables -L或nft list ruleset - 第四步看日志：
journalctl -u kubelet -f、kubectl describe的 Events 段，往往直接给出根因
据工信部相关公开资料,运维故障中相当一部分源于配置变更而非硬件损坏，排查时优先回看最近一次变更记录，效率更高。
服务器集群命令怎么选？按规模与场景对号入座
小规模双机热备用Keepalived加脚本就够；几十台物理机做资源高可用，Pacemaker更稳；容器化业务直接上Kubernetes，命令生态最完整。选型不是越新越好，而是命令维护成本能否被团队消化，团队只有两三个人，却维护一套需要专职排障的编排集群，故障恢复时间反而会拉长。
Q&A：服务器集群命令常见问题
Q1：服务器集群常用命令需要全部背下来吗？
不需要,节点层和排障类命令要熟，调度层命令记住“查看、迁移、恢复”三个动作对应的入口即可，真正高频的通常不超过二十条，其余查手册更快。
Q2：Linux服务器集群命令和单机命令混用会有什么后果？
最典型的是在集群节点上直接 systemctl stop 业务服务，集群健康检查发现资源异常后触发迁移，造成短暂双活或VIP冲突，正确做法是先让集群接管，用集群命令下线资源，再处理节点。
Q3：高可用集群命令里，判断切换是否成功的依据是什么？
看三件事：VIP是否在新节点生效、资源状态是否全部为 Started、业务端口是否可连通，三者缺一，切换就不算完成，需要继续查 pcs status 的失败原因和 journalctl 中的资源代理日志。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/784861.html
