kubectl apply 部署 Nginx 前需确认集群可用、镜像可拉取、YAML 语义正确，否则会卡在 Pending 或 ImagePullBackOff；手写 YAML 时易漏 spec.selector.matchLabels、containerPort、resources.limits 和 imagePullSecrets；Service 类型需按环境选对，验证须查 events、logs、endpoints 及 port-forward。
kubectl apply 是部署 Nginx 的核心命令，但直接运行它之前必须确认三件事：集群可用、镜像可拉取、YAML 语义正确。跳过任一环节都会卡在 Pending 或 ImagePullBackOff 状态，而不是“部署失败”。
用 kubectl create deployment 快速启动单实例
这是最简路径，适合验证集群连通性或临时调试：
- 执行
kubectl create deployment nginx --image=nginx:alpine，会自动生成 Deployment 和 ReplicaSet - 它默认不带
selector和template.labels的显式声明，但 kubectl 会自动补全，等价于手写一个最小 YAML - 注意：这种方式无法指定
namespace、资源限制、健康检查等生产必需字段，仅用于起步 - 后续要加 Service，必须手动
kubectl expose deployment nginx --port=80 --type=ClusterIP
Deployment YAML 中最容易漏掉的字段
手写 YAML 时，以下字段缺失会导致 Pod 启动后立即退出或无法被 Service 关联：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
-
spec.selector.matchLabels必须和template.metadata.labels完全一致，否则 ReplicaSet 不认 Pod —— 这是Available为 0 的常见原因 -
containers[].ports[].containerPort缺失不会报错，但 Service 的targetPort将找不到目标端口，导致流量不通 -
containers[].resources.limits虽非强制，但在多租户或资源紧张的集群中缺失，可能被节点驱逐（Evicted状态） - 若使用私有镜像仓库，
imagePullSecrets必须定义在spec.template.spec下，而非顶层spec
Service 类型选错会导致根本访问不到
不是所有 type 都适用于你的环境，选错等于白部署：
-
ClusterIP：仅集群内可访问，kubectl get svc显示的CLUSTER-IP无法从宿主机curl -
NodePort：需确认节点防火墙放行对应端口（如30080），且云厂商安全组也得开；minikube默认支持，但裸金属集群需确认 kube-proxy 模式（iptables/ipvs） -
LoadBalancer：只在云平台（AWS/Azure/GCP）自动创建外部负载均衡器；本地环境会一直卡在Pending，除非你装了metalLB - 别忽略
spec.selector：必须和 Deployment 的 label 完全匹配，大小写、连字符都不能错
部署后验证不能只看 Running
kubectl get pods 显示 Running 只代表容器进程起来了，不代表服务就绪。真正要查的是：
-
kubectl describe pod <pod-name>：重点看Events区域，FailedScheduling、ErrImagePull、CrashLoopBackOff都在这里暴露 -
kubectl logs <pod-name>：Nginx 启动失败时通常不报错退出，而是静默挂起——日志里没输出就说明配置加载失败（比如/etc/nginx/nginx.conf权限不对） -
kubectl get endpoints nginx-service：如果返回空，说明 Service 没关联到任何 Pod，大概率是 label 不匹配或 Pod 还没通过 readiness probe - 用
kubectl port-forward service/nginx-service 8080:80本地测试，绕过网络策略和 DNS，快速定位是服务问题还是网络问题
kubectl apply 有效得多。 
