kubectl apply 是部署容器化项目的实际入口，但需确保镜像已推送至集群可拉取的仓库、yaml语义正确、kubelet能正常拉取；否则将出现imagepullbackoff、crashloopbackoff或pending等异常状态。
kubectl apply 是部署容器化项目的实际入口，但直接运行它之前，必须确保镜像已推送到集群可拉取的仓库、YAML 文件语义正确、且 kubelet 能正常拉取镜像——否则你会看到 ImagePullBackOff、CrashLoopBackOff 或 Pending 状态卡住。
镜像必须能被节点拉取，不是“本地有就行”
Kubernetes Worker 节点不共享 Docker daemon，docker build 生成的镜像只存在于构建机本地，kubectl apply 不会自动上传。常见错误是：本地 docker images 看到镜像，但 Pod 一直 Pending 或报 ErrImagePull。
- 必须用
docker tag和docker push推送到私有仓库（如 Harbor）或公开仓库（如 Docker Hub） - 若用私有仓库，Deployment 中需配置
imagePullSecrets，且 Secret 必须在同 namespace 下 - Minikube 用户可临时用
minikube cache add <image></image>加载本地镜像，但仅限开发，不可用于类生产环境
deployment.yaml 里最关键的三个字段
一份最小可用的 Deployment 并不需要写满所有字段，但以下三项漏掉任一，大概率导致 Pod 启动失败或不可访问：
-
containerPort：只是声明端口，不影响宿主机映射，但 Service 的targetPort默认按它匹配；不写会导致 Service 流量无法转发到容器 -
livenessProbe和readinessProbe：没配探针时，Kubernetes 会认为容器“立刻就绪”，哪怕应用还在加载配置或连数据库；结果是流量打进来，502/503 一堆 -
resources.requests：尤其在资源紧张的集群中，不设 requests 会导致调度器无法判断节点是否有足够资源，Pod 卡在Pending
示例片段：
containers:
- name: python-flask-app
image: yourname/python-flask-app:v1
ports:
- containerPort: 5000
livenessProbe:
httpGet:
path: /health
port: 5000
initialDelaySeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 5000
initialDelaySeconds: 5
resources:
requests:
memory: "64Mi"
cpu: "100m"
Service 暴露方式选错，等于没部署成功
部署完 Pod，不代表服务能被访问。Service 类型决定流量如何抵达：
-
ClusterIP（默认）：只能在集群内访问，适合内部调用；误以为它能被外部访问是新手高频误区 -
NodePort：端口范围固定在30000–32767，且需确保云厂商安全组或物理防火墙放行该端口 -
LoadBalancer：公有云（AWS/GCP/Azure）会自动创建负载均衡器；裸金属或私有云需配合 MetalLB 等工具，否则永远处于Pending - Ingress 不是 Service 替代品：它依赖 Ingress Controller（如 nginx-ingress、Traefik）已部署，且需额外定义
Ingress资源
滚动更新失败时，别急着删 Deployment
执行 kubectl set image deploy/<name> ...</name> 或修改 YAML 后 apply，若新 Pod 卡在 CrashLoopBackOff，Deployment 默认会持续尝试重启，但旧 Pod 已被逐步销毁——此时服务可能已中断。
- 先用
kubectl rollout status deploy/<name></name>确认是否卡住 - 用
kubectl describe pod -l app=<label></label>查看 Events 和容器日志（kubectl logs <pod-name> --previous</pod-name>） - 回滚命令是
kubectl rollout undo deploy/<name></name>，不是delete+apply；后者会丢失历史 revision 记录 - 上线前务必在测试环境验证新镜像的探针路径、启动耗时、配置挂载是否兼容
真正容易被忽略的是：Kubernetes 不校验镜像内容是否真的适配你的 YAML 描述。一个没暴露端口、没实现健康检查接口、或启动即退出的镜像，会安静地失败——状态看似正常，实际不可用。
