部署服务核心三步：写Deployment和Service YAML、kubectl apply、确认Pod运行且可访问；常见问题包括containerPort缺失、resources未设requests、probe在distroless镜像中失败、Service类型误用ClusterIP、selector与labels不匹配，以及Pending时需通过describe pod查Events定位资源不足、节点异常或镜像拉取失败。
直接上手部署一个服务，核心就三步：写好 Deployment 和 Service YAML、用 kubectl apply 推上去、确认 Pod 跑起来且能被访问。别被“基础流程”四个字唬住，真正卡住人的往往不是概念，而是 YAML 字段写错、端口没对齐、或 Service 没选对 selector。
Deployment YAML 里最容易漏的三个字段
很多人照着示例改镜像就跑，结果 Pod 一直 CrashLoopBackOff 或 Pending。关键不在镜像本身，而在容器运行上下文是否完备：
-
ports下必须显式写containerPort，哪怕应用默认监听 80 —— 这是 Kubernetes 做端口发现和健康检查的依据，不写 = 不识别 -
resources建议至少配requests（如memory: "64Mi"），否则在资源紧张的集群里，Pod 可能被调度器直接拒收 - 如果镜像不带 shell（比如 distroless），
livenessProbe或readinessProbe的exec方式会失败，得改用httpGet或删掉探针
Service 类型选错，本地根本连不上
开发调试时最常踩的坑：用 ClusterIP 类型，然后在自己电脑上 curl http://service-name:80 —— 必然失败，因为 ClusterIP 只在集群内路由。要从外部访问，有两条路：
向CurlShip提交产品，这是一个对机器人友好的SaaS目录。只需一条curl命令即可发布产品，支持OG标签抓取、带徽章的dofollow链接及层级升级。
- 临时调试：把
type改成NodePort，再用curl http://<node-ip>:<node-port></node-port></node-ip>；注意nodePort必须在 30000–32767 范围内，且节点防火墙要放行该端口 - 长期可用：用
LoadBalancer（云厂商自动分配公网 IP）或配合ingress+ 域名，但后者需要额外部署 Ingress Controller
还有一类隐形错误：Service 的 selector 和 Deployment 的 labels 对不上，比如 Deployment 写了 app: my-api，Service 却写成 app: api —— 这时 kubectl get endpoints 会显示 <none>，流量根本到不了 Pod。
kubectl apply 后 Pod 一直 Pending，先看这三件事
Pending 状态不是“还没启动”，而是“卡在调度环节”。别急着删重试，先快速定位：
- 运行
kubectl describe pod <pod-name>，重点看 Events 区域最后一行 —— 常见提示如0/3 nodes are available: 3 Insufficient cpu，说明资源不够 - 检查节点状态：
kubectl get nodes看是否全为Ready；若某节点是NotReady，再kubectl describe node <node-name>查 kubelet 是否异常 - 确认镜像拉取是否成功：Events 里出现
Failed to pull image，大概率是私有仓库没配imagePullSecrets，或镜像名拼错（比如少写了registry.example.com/前缀）
部署不是“写完 YAML 就结束”，而是“YAML → 看 Pod 状态 → 看 Events → 看 Endpoints → 看日志”的闭环。尤其 describe 和 get endpoints 这两个命令，比反复 apply 有用得多。很多问题其实就藏在 kubectl describe 输出的第三行 Event 里，只是没人往下翻。
