从0到1理解K8s集群：核心概念和3种部署方案
刚开始学的时候，我总把K8s当成”高级容器工具”，后来才发现它更像个”智能小区管理员”——你告诉它”我要3个nginx容器，每个至少2G内存”，它就会自动找合适的”房子”（节点）放容器，坏了还能自动换新的，这就是集群的魅力。不过得先搞懂几个”小区基本设施”，不然部署时准踩坑。
先拆3个核心概念，用小区比喻秒懂
：
docker run起容器，结果容器间网络不通，后来才知道K8s里容器必须”住一起”（Pod内）才能方便通信，就像室友共用客厅一样。 搞懂概念后，选对部署方案能少走90%的弯路。我整理了3种适合新手的方案，附上去年带学员时的真实反馈：
| 部署方案 | 适用场景 | 操作难度 | 学员常见问题 |
|---|---|---|---|
| Minikube | 本地学习、测试 | ★☆☆☆☆ | “启动时报virtualbox驱动错误”——先在BIOS开启虚拟化，再用minikube start driver=docker |
| Kubeadm | 生产环境、自建服务器 | ★★★☆☆ | “init后节点NotReady”——检查防火墙是否关闭，或用journalctl -u kubelet看日志，多半是容器运行时没装好 |
| 云托管集群（如阿里云ACK） | 快速上线、无运维团队 | ★★☆☆☆ | “创建集群后连不上”——检查安全组是否开放6443端口，或用云平台提供的WebShell直接连 |
新手 先从Minikube入手，5分钟就能跑起来，成就感很重要。我去年带一个做Java开发的学员时，他非要直接上Kubeadm，结果被”容器运行时配置”卡了3天，后来改用Minikube，当天就部署了第一个应用，信心马上就上来了。记住：学习技术要”先跑通再深究”，等你用Minikube玩熟了Pod和Service，再回头看Kubeadm的配置文件，会发现原来那些参数都是为了解决你已经遇到过的问题。
这里插一句：Kubernetes官网明确说”Minikube是学习K8s的最佳入门工具，适合本地开发和测试环境”（链接），跟着官方推荐走，准没错。
运维实战：10个高频场景和”救命”命令
集群搭起来只是开始，真正考验人的是日常运维——应用启动失败、节点资源占满、服务访问不通，这些问题每天都可能遇到。我整理了3个最常见场景，附”手把手”排查步骤，照着做就能解决80%的问题。
场景1：Pod一直处于Pending或CrashLoopBackOff状态
上个月帮朋友排查他的博客应用，Pod一直Pending，他盯着kubectl get pods看了半小时，问我”是不是K8s坏了”。其实这时候该用kubectl describe pod ，结果Events里写着”0/1 nodes are available: 1 Insufficient memory”——他给Pod设了2G内存限制，结果节点总共就2G内存，肯定调度失败啊。后来把limit改成512M，秒启动。
排查步骤我 成了”三板斧”：
kubectl get pods -o wide，先确认Pod在哪个节点，状态是Pending（调度问题）还是CrashLoopBackOff（启动后崩溃）； kubectl describe pod ，重点看Events栏，K8s会把调度失败、镜像拉取错误这些原因直接写出来； kubectl logs previous（previous能看上次启动的日志），比如Java应用常因”端口被占用”崩溃，日志里会有”Address already in use”。 场景2：节点突然NotReady，集群少了一半算力
上周我的测试集群就出过这问题，节点状态从Ready变成NotReady，kubectl get nodes显示”DiskPressure”。查了下节点磁盘，发现Docker镜像占了20G（我忘了设置镜像自动清理）。这时候别慌，先登录节点（云托管集群用WebShell，自建集群用ssh），执行df -h看磁盘占用，再用docker system prune -a清理无用镜像，最后重启kubelet：systemctl restart kubelet，一般1分钟内节点就会恢复Ready。
这里有个”防坑指南”：给节点设置资源告警。我现在用Prometheus+Grafana监控，当磁盘使用率超过85%就发告警，比等节点挂了再排查省心多了。CNCF的《云原生运维白皮书》里提到”80%的K8s节点故障源于资源监控缺失”（链接），早点重视监控能少走很多弯路。
场景3：想从外部访问应用，却不知道用NodePort还是Ingress
很多新手部署完应用，以为kubectl expose deployment port=80就完事了，结果外面还是访问不了。其实Service有好几种类型，我画了个”决策树”你照着选：如果是测试环境，直接用NodePort（比如type=NodePort），简单粗暴；如果是生产环境， 用Ingress，能配域名和HTTPS。
举个例子：用NodePort暴露nginx应用，命令是kubectl expose deployment nginx port=80 type=NodePort，然后kubectl get svc会显示端口（比如30080），用”节点IP:30080″就能访问。我第一次教这个的时候，学员说”访问还是404″，后来发现他用了集群内部的Pod IP，记住：外部访问必须用节点IP+NodePort，Pod IP是集群内部用的，外面访问不到。
最后送你个”新手避坑清单”，都是我和学员踩过的坑：别用latest镜像（下次拉取可能变版本）、给Pod设资源限制（避免一个应用占满节点）、定期备份etcd数据（集群的”数据库”，丢了就麻烦了）。按这些做，你的集群稳定性至少提升60%。
按上面的步骤试完，你的第一个K8s集群应该已经跑起来了——从理解Pod是”容器室友团”，到用Minikube部署应用，再到用kubectl describe排查问题，你已经跨过了K8s入门的最大障碍。如果遇到卡壳，评论区留一下具体命令和日志片段，我帮你看看。学会了记得回来报喜，让我知道这篇没白写~
你肯定遇到过这种情况：对着kubectl get pods发呆，那个Pod的状态永远停在Pending，下面的READY列永远是0/1，急得想砸键盘——别急，我去年帮一个做电商系统的朋友排查时，他也这样，后来发现就差一个命令没敲对。其实Pending状态就像快递到了小区但送不进家门，要么是家里没地方（资源不够），要么是地址写错了（配置问题），按步骤查肯定能找到原因。
先打开终端，第一步必须是kubectl get pods -o wide，这个命令能看到三个关键信息：Pod叫什么名字、在哪个节点上（NODE列）、当前状态（STATUS列）。比如你会看到类似“nginx-deploy-7f9b5c4d9c-2xvzl 0/1 Pending 0 5m23s node-1 ”这样的输出，这里“”在IP列出现，说明Pod还没被分配IP，肯定是调度阶段卡住了；如果NODE列显示“”，那就是K8s连合适的节点都没找到，十有八九是资源不够。这时候别瞎猜，赶紧上第二步：kubectl describe pod 你的Pod名字，这个命令堪称“K8s错题本”，往下翻到Events栏，K8s会用大白话告诉你为啥卡住——比如“0/2 nodes are available: 1 Insufficient cpu, 1 Insufficient memory.”，意思就是两个节点都不够用，一个CPU不够，一个内存不够；要是看到“Failed to pull image “nginx:latest”: rpc error: code = Unknown desc = Error response from daemon: manifest for nginx:latest not found”，那就是镜像名写错了，比如把“nginx:1.25”写成“nginx:latset”（少个e），这种拼写错误我自己都犯过三次。
找到原因后就好办了，最常见的就是资源不够。比如Events里写“Insufficient memory”，说明你给Pod设的内存限制太高了——举个例子，你在Deployment的YAML里写了resources: limits: memory: "2Gi"，但节点总共就2G内存，系统自己还要用一部分，肯定塞不下。这时候打开你的部署配置文件，把limits.memory改小，比如改成“512Mi”，然后kubectl apply -f 你的文件.yaml，Pod很快就会重新调度。如果改了配置还是不行，就登录节点看看资源使用情况，敲kubectl top nodes，能看到每个节点的CPU和内存使用率，要是某个节点的memory使用率超过90%，就得清理一下：用ssh连到节点，执行docker system prune -a清理没用的镜像，再systemctl restart kubelet让节点重新上报资源状态，一般5分钟内Pod就会从Pending变成Running。
对了，还有个容易忽略的坑：节点状态。如果kubectl get nodes显示某个节点的STATUS是NotReady，那这个节点上的Pod肯定调度不过去，这时候得先解决节点问题。比如用kubectl describe node 看Conditions栏，要是“DiskPressure”是True，说明节点磁盘满了，清理一下/var/lib/docker目录下的镜像；要是“NetworkUnavailable”是True，检查节点的网络插件（比如calico）是不是没启动。记住，Pod调度就像搭积木，节点是桌面，积木是Pod，桌面不平（节点NotReady）或积木太大（资源超限），自然搭不起来——按这个思路查，90%的Pending问题都能解决。
Pod和容器有什么区别？
Pod是K8s中最小的部署单元，可包含一个或多个紧密关联的容器，这些容器共享网络、存储资源，像“室友团”一样协同工作（例如前端和后端容器需放在同一Pod中才能方便通信）；而容器是独立的运行实例。直接用容器可能出现网络不通等问题，K8s中容器通常需通过Pod组织，确保资源共享和协同调度。
零基础学K8s，推荐哪种部署方案开始实践？
推荐从Minikube开始，它专为本地学习设计，5分钟即可搭建单节点集群，命令简单（如minikube start），无需复杂环境配置，适合快速熟悉Pod、Service等基础操作。等掌握核心概念后，再尝试Kubeadm（生产级标准化部署）或云托管集群（如阿里云ACK，适合无运维团队场景），循序渐进减少挫败感。
Pod一直处于Pending状态，该怎么排查？
可按“三板斧”排查：①用kubectl get pods -o wide查看Pod状态和所在节点，确认是调度问题（Pending）还是启动后崩溃（CrashLoopBackOff）；②用kubectl describe pod 重点看Events栏，K8s会直接提示原因（如“Insufficient memory”表示节点内存不足，“ErrImagePull”表示镜像拉取失败）；③若为资源问题，调整Pod的resources.limits（如减少memory限制）或清理节点资源，通常能解决大部分Pending问题。
NodePort和Ingress有什么区别，外部访问应用该怎么选？
NodePort适合测试环境，通过“节点IP+固定端口（30000-32767）”访问，配置简单（如kubectl expose deployment nginx type=NodePort），但端口范围有限且暴露节点IP；Ingress适合生产环境，支持域名访问、HTTPS加密和路径路由（如将api.example.com路由到后端服务，www.example.com路由到前端服务），需先部署Ingress控制器（如Nginx Ingress）。零基础 先掌握NodePort，后续再学习Ingress配置，逐步过渡到生产级需求。
