Kubernetes集群搭建零基础到运维_千锋教育

01 从“单机部署”到“集群管理”的认知跃迁

多数人的Kubernetes学习之路，往往卡在靠前个“为什么”——在虚拟机里跑个单节点K8s环境，觉得“也不过如此”；可一上生产集群，面对多节点网络、持久化存储、证书过期、节点NotReady，瞬间懵了。这种落差不是知识问题，而是视角问题：把K8s当成了“更高级的Docker”，忽略了它本质上是一套分布式操作系统。

零基础搭建集群的真正起点，不是敲命令，而是理解K8s的“主从博弈”。Master节点的etcd存储状态、API Server处理请求、Scheduler分配Pod、Controller Manager维护预期——这四个组件就像公司的董事会、总经理、HR和法务，缺一不可。而Node节点上的kubelet、kube-proxy、容器运行时（如containerd）则是执行层。整个集群的可用性，取决于组件之间的心跳与选举。

金句截图： 单机环境是玩玩具，集群环境才是跑业务；前者靠命令，后者靠设计。

在实际搭建前，你需要做出3个关键决策：部署工具（kubeadm/k3s/RKE）、容器运行时（containerd/cri-o）、网络插件（Calico/Flannel/Weave）。别追求“极具实力组合”，而是看业务场景——内网测试选Flannel（配置简单），生产环境选Calico（支持网络策略）。版本选择也需谨慎：K8s每3个月发布一个版本，但CRI工具链和插件往往滞后一个次版本。一个常见翻车案例：使用kubeadm v1.28却搭配containerd 1.6（不兼容），导致节点注册失败。因此，零基础搭建的靠前个原则：版本组合决定50%的首次成功率。

02 核心组件选型：避开90%新手会踩的坑

有了方向，就该落地。K8s集群的选型本质是Trade-off：易用性 vs. 稳定性 vs. 可扩展性。我们拆解三个最易出错的环节：

证书体系。 多新手因担心证书有效期而手动签发，反而破坏了信任链。kubeadm默认生成的证书有效期1年，运维时只需执行kubeadm certs renew all并重启控制平面组件即可。但注意：证书更新后，kubeconfig文件不会自动更新，需手动替换。另一个隐蔽陷阱：etcd的证书与API Server证书如果不匹配，整个集群将无法通信。建议在初始化阶段就启用自动证书轮换（--certificate-renewal=true）。

网络平面。 节点间的Pod网段与Service网段不能重叠，这是铁律。推荐将Pod CIDR设为10.244.0.0/16（Flannel默认），Service CIDR设为10.96.0.0/12（kubeadm默认）。如果使用Calico，还需规划IPIP隧道或BGP模式：BGP模式在物理网络中广播Pod IP，适合数据中心；IPIP模式通过隧道封装，更简单但会损耗约5%性能。一个生产教训：某团队将Pod CIDR设为192.168.0.0/16，与公司局域网冲突，导致节点之间路由紊乱，排查了3天。

存储与持久化。 集群搭建后快会面临“Pod挂了数据还在吗”的提问。如果不用云厂商的PV，就用Local PV + 节点亲和性：创建存储类时设置volumeBindingMode: WaitForFirstConsumer，让Pod先调度、再确定存储位置。但别把所有鸡蛋放一个节点——合理做法是使用Rook/Ceph搭建分布式存储，或安装NFS Subdir External Provisioner模拟动态存储。对于零基础，最简单的方式是部署一个NFS服务器作为测试环境，但务必清楚：NFS无高可用，重启即丢失所有PV挂载。

金句截图： 选型不是选最好的，而是选你最能驾驭的。

03 零基础实战：三步完成集群初始化

理论讲完，动手是检验理解的唯一标准。我们以三台CentOS 7.9虚拟机为例（2C4G，Master；2C2G * 2, Node），演示最小化集群搭建。

靠前步：环境准备（30分钟）。 所有节点执行：关闭防火墙、禁用SELinux、关闭swap（swapoff -a && sed -i '/ swap / s/^/#/' /etc/fstab）。然后配置内核参数（net.bridge.bridge-nf-call-iptables=1，net.ipv4.ip_forward=1）。接着安装containerd：从官方仓库下载1.6.22版本，生成默认配置containerd config default > /etc/containerd/config.toml，并将SystemdCgroup设为true。重启containerd并验证ctr version。最后安装kubelet、kubeadm、kubectl（使用阿里云镜像源，避免网络问题）。注意：三个组件版本必须一致，否则kubeadm init会报版本不匹配。

第二步：初始化Master（10分钟）。 在Master节点执行kubeadm init --pod-network-cidr=10.244.0.0/16 --image-repository registry.aliyuncs.com/google_containers --upload-certs。参数解释：--pod-network-cidr指定Pod网段；--image-repository使用国内镜像仓库；--upload-certs用于高可用集群，单节点可省略。执行成功后，会输出kubeadm join命令。然后配置kubectl：mkdir -p $HOME/.kube && cp /etc/kubernetes/admin.conf $HOME/.kube/config。此时用kubectl get nodes应该看到Master处于NotReady状态——因为网络插件未部署。

第三步：安装网络插件并加入Node（5分钟）。 选择Flannel：kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml。等待约1分钟，watch节点状态变为Ready。接着在Node节点上执行从Master获得的join命令（带token和discovery-token-ca-cert-hash）。加入后，kubectl get nodes应看到三个节点Ready。此时集群搭建完成！验证：创建一个Deployment，kubectl create deployment nginx --image=nginx，再暴露Service，看能否通过Pod IP或Service IP访问。

金句截图： 搭建集群不是终点，验证网络和调度才是真正的“Hello World”。

04 从搭建到运维：监控、日志与故障排查

集群跑起来后，新手运维容易陷入“两眼一抹黑”——Pod OOM了？节点磁盘满了？证书过期了？这些不提前预警，就是在跪着还技术债。

监控先行。 推荐kube-prometheus-stack（包含Prometheus、Grafana、AlertManager）。安装方式：用Helm Chart快速部署，配置NodeExporter采集节点指标，KubeStateMetrics采集集群对象状态。关键告警规则：节点CPU使用率>80%、Pod重启次数>5次/小时、etcd领导者变更频繁。监控数据留存建议7天，不差钱可以用Thanos做长期存储。但别过度监控——每个Pod拉取几百个metric，反而会消耗集群资源。经验法则：只监控会烧钱或炸业务的核心指标。

日志收集。 使用Loki（轻量）或Elasticsearch（全文检索）。对新玩家，Loki + Promtail + Grafana更易上手：Promtail在每个节点以DaemonSet形式运行，将Docker/containerd日志推送到Loki。配置时注意：日志路径要与容器运行时一致（containerd默认在/var/log/pods）。若使用标准输出而非文件日志，需启用--log-opt max-size=10m限制单日志文件大小。一个常见故障：某Pod持续打印错误日志，几分钟内占满节点磁盘，导致kubelet无法正常工作——此时应设置日志轮转和Pod数量限制（如每个节点最多30个Pod）。

故障排查三板斧。 1）kubectl describe pod xxx看Events；2）journalctl -u kubelet -f实时看kubelet日志；3）ssh到问题节点，systemctl status kubelet看服务状态。更棘手的情况：节点一直NotReady。原因通常是kubelet与API Server失联，检查网络连通性（telnet Master 6443端口）、证书是否过期（openssl x509 -in /etc/kubernetes/pki/ --dates）。还有一个冷门杀手：时间不同步。所有节点必须使用NTP服务同步时间（chrony），时间漂移超过5秒会导致证书验证失败。

金句截图： 运维的本质是“提前为故障写墓志铭”，而非等它发生后再懊悔。

05 持续演进：集群扩缩容与版本升级

集群上了生产，它不会一成不变。业务增长要加节点，新功能要升级版本，安全漏洞要打补丁——这些操作如果无脑执行，轻则业务中断，重则集群崩溃。

节点扩缩容。 加入节点简单：在Master执行kubeadm token create --print-join-command生成新token，然后在新增节点上执行。但注意：token默认24小时过期，需及时使用。删除节点则分两步：先在Master执行kubectl drain node-name --delete-emptydir-data --ignore-daemonsets驱逐Pod，再kubectl delete node node-name。最后在节点上kubeadm reset清理残留。一个扩容铁律：不要在集群负载超过80%时同时加3个以上节点，会引起大量Pod重调度，导致“雪崩式”异常。

版本升级。 K8s官方只支持逐版本升级（如v1.27→v1.28，不能v1.27→v1.29）。升级前先备份etcd：etcdctl snapshot save backup.db。升级步骤：先升Master节点的kubeadm、kubelet、kubectl版本（kubeadm upgrade plan查看目标版本，kubeadm upgrade apply v1.28.x执行），然后systemctl restart kubelet。接着逐个升级Node节点：先drain节点，再升级kubelet和kubeadm版本，最后uncordon节点。整个过程耗时较长，建议在维护窗口进行，并搭配Rolling Update策略——每次只升级一个Node，观察Pod恢复后再动下一个。若升级后出现旧Pod无法调度，检查kubelet是否与API Server版本差超过2个次版本。

金句截图： 升级不是技术动作，而是风险管理流程——每一步都要有回退预案。

结尾一句狠话： 从搭建到运维，Kubernetes不欢迎“一步登天”的幻想，只奖励那些愿意把每个坑都踩实的人。

声明：本站部分稿件版权来源于网络，如有侵犯版权，请及时联系我们。