在服务器搭建k8s集群的最佳实践中，核心结论在于：必须采用“高可用架构设计+容器化运行时优化+自动化部署工具”的组合策略，才能构建出生产级稳定的Kubernetes环境，这不仅是技术实现的路径，更是保障业务连续性的基石，单纯追求安装步骤的完成而忽视底层架构的健壮性,是导致生产环境故障频发的主要原因。
生产环境架构规划与前期准备
搭建稳定集群的前提是严谨的架构规划，切忌在生产环境中使用单Master节点架构,这会带来极大的单点故障风险。
- 节点角色规划：建议采用至少3个Master节点配合3个Worker节点的标准架构，Master节点负责集群调度、元数据存储,Worker节点负责业务负载运行。
- 硬件资源配置：Master节点建议配置4核CPU、8GB内存以上，Worker节点根据业务密度动态调整，但建议预留30%的资源冗余以应对突发流量。
- 操作系统选型：推荐使用CentOS 7.9或Ubuntu 20.04 LTS版本，内核版本需升级至4.19以上,以确保容器运行时的底层支持稳定性。
- 网络与存储规划：节点间网络延迟需控制在1ms以内，且必须规划独立的Pod网段和Service网段,避免与企业内网IP冲突。
核心依赖环境配置
系统层面的优化是保障Kubernetes高性能运行的关键，这部分工作往往被初学者忽视,却直接决定了集群的上限。
- 关闭Swap分区：Kubernetes设计理念假定服务器内存充足，Swap的使用会导致性能急剧下降甚至服务不可用，必须执行
swapoff -a并注释/etc/fstab中的相关配置。 - 内核参数调优：需开启IP转发功能，修改
/etc/sysctl.conf文件，设置net.ipv4.ip_forward=1,这对于Service网络代理至关重要。 - 时间同步：集群内所有节点的时间误差不得超过1秒，建议部署Chrony服务，确保时间一致性，否则会导致证书验证失败、集群日志混乱等严重问题。
- 防火墙与SELinux：生产环境建议配置iptables规则放行特定端口，而非直接关闭防火墙，若对安全策略不熟悉，可临时关闭SELinux,但建议后期通过策略配置实现安全隔离。
容器运行时与集群部署实战
在服务器搭建k8s的过程中，选择合适的容器运行时和部署工具是核心环节，目前Docker已不再是首选,Containerd凭借其轻量级和稳定性成为主流。
- 安装Containerd：配置YUM源或APT源安装Containerd，并生成默认配置文件，关键在于配置
SystemdCgroup = true，这是Kubernetes 1.24+版本强制要求的Cgroup驱动模式。 - 部署工具选择：推荐使用Kubeadm工具，它提供了“Kubernetes官方维护、最佳实践导向”的部署体验,能够快速初始化控制平面。
- 集群初始化：执行
kubeadm init命令时，必须指定--pod-network-cidr参数，该参数需与后续安装的网络插件（如Calico或Flannel）配置保持一致。 - 工作节点加入：Master初始化完成后，会生成加入命令，Worker节点执行该命令即可加入集群,注意Token的有效期管理。
网络插件与高可用实现
集群部署完成后，CoreDNS处于Pending状态是常见问题,这是因为网络插件尚未安装。
- 网络插件选型：Calico性能强大，支持网络策略，适合大规模生产环境；Flannel配置简单，适合中小型集群,下载对应的YAML文件并应用即可。
- 高可用负载均衡：为实现Master节点高可用，需在集群前端部署负载均衡器，推荐使用Nginx + Keepalived方案，或者HAProxy + Keepalived，VIP（虚拟IP）应配置在Keepalived中，确保某个Master宕机时，API Server入口自动漂移。
集群验证与安全加固
部署的最后一步是验证与安全配置,这直接关系到集群的抗风险能力。
- 功能验证：部署Nginx测试应用，通过ClusterIP和NodePort方式访问，验证集群网络、DNS解析及服务发现功能是否正常。
- RBAC权限控制：切勿直接使用管理员权限运行Pod，应遵循最小权限原则，创建ServiceAccount并绑定Role,限制应用对集群资源的访问能力。
- 资源配额管理：为每个Namespace配置ResourceQuota，限制Pod的CPU和内存使用上限,防止个别应用资源耗尽导致整台节点瘫痪。
通过上述步骤，我们不仅完成了基础设施的搭建，更构建了一套具备高可用性、可扩展性的容器编排平台，在服务器搭建k8s的实践中，细节决定成败,每一步的参数优化都是对生产环境稳定性的投资。
相关问答
Kubernetes集群中Master节点可以运行业务Pod吗？
不建议在生产环境中让Master节点运行业务Pod，Master节点承载着etcd、kube-apiserver等核心控制组件，资源消耗较高且稳定性要求极高，如果运行业务Pod，可能因资源争抢导致控制平面响应缓慢甚至崩溃，可以通过给Master节点打污点的方式,阻止普通业务Pod调度至Master节点。
如何选择CNI网络插件，Calico和Flannel有什么本质区别？
本质区别在于网络模式和策略支持，Flannel通常采用Overlay网络（如VXLAN），配置简单但存在一定的性能损耗，且不支持Kubernetes原生的NetworkPolicy网络策略，Calico支持纯路由模式，性能接近物理网络，且支持精细化的网络策略控制，可以实现Pod间的访问控制，对于有安全隔离需求或追求高性能的场景,Calico是更优选择。
如果您在搭建过程中遇到任何问题或有独特的优化技巧,欢迎在评论区留言交流。
首发原创文章，作者：世雄 - 原生数据库架构专家，如若转载，请注明出处：https://idctop.com/article/65619.html
