Kubernetes中部署服务并对外访问必须同时使用Deployment和Service（或Ingress）；仅Deployment无法被发现，因selector与template.labels不匹配是常见错误，须严格一致。
直接说结论：Kubernetes 里部署一个服务并让外部能访问，必须走 Deployment + Service（或 Ingress）这两步，缺一不可；只跑 Deployment，服务在集群内都不可发现。
Deployment 必须定义 selector 和 template labels 一致
这是最常踩的坑：Pod 起来了，但 Service 找不到它们。根本原因是 selector 匹配不上 template.metadata.labels。
-
selector.matchLabels的键值必须和template.metadata.labels完全相同（包括大小写） - 不要在
template.metadata.labels里多加无关 label，比如version: v1，除非selector也包含它 - 验证方式：
kubectl get pods -l app=nginx能列出 Pod，才说明 label 生效；再用kubectl describe service nginx-service看Endpoints字段是否非空
Service 类型选 NodePort 还是 ClusterIP？看访问场景
ClusterIP 是默认类型，只在集群内部可访问；对外暴露必须显式指定 type: NodePort 或 type: LoadBalancer。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
-
NodePort：每个 Node 节点都监听一个固定端口（默认 30000–32767），适合开发/测试或私有云环境；注意防火墙要放行该端口 -
LoadBalancer：云厂商自动创建 LB 并绑定后端节点，但费用高、响应慢；本地 Minikube 或裸金属集群不支持 - 别用
port-forward上生产——它只是临时端口映射，进程退出就断，且不支持多副本负载均衡
Ingress 不是 Service 的替代品，而是补充
当你有多个 HTTP/HTTPS 服务（比如 api.example.com 和 web.example.com），用多个 NodePort 会快速耗尽端口、难管理。这时才需要 Ingress。
-
Ingress本身不处理流量，必须搭配Ingress Controller（如 Nginx Ingress、Traefik）才能生效 - 没装控制器时，
kubectl apply -f ingress.yaml不报错，但ENDPOINTS始终为空——这是最典型的“以为配好了其实没动”现象 - 检查是否就绪：
kubectl get ingress看ADDRESS列是否非空；kubectl get pods -n ingress-nginx（或对应命名空间）确认控制器 Pod Running
滚动更新失败时，replicas 和 maxUnavailable 要对得上
更新镜像后 Pod 卡在 Terminating 或新 Pod 一直 CrashLoopBackOff，往往不是应用问题，而是更新策略太激进。
-
maxUnavailable: 0意味着“一个旧 Pod 都不能下线”，适合强一致性场景，但要求新 Pod 必须能立即就绪 -
maxSurge: 1表示最多额外起 1 个 Pod；如果replicas: 3，更新时最多有 4 个 Pod 同时运行 - 健康探针（
livenessProbe/readinessProbe）超时时间设太短（比如initialDelaySeconds: 5）会导致新 Pod 被反复杀掉重试
真正容易被忽略的是：所有 YAML 中的 label、port、name 都是字符串匹配，大小写、空格、冒号后空格全算数；复制粘贴时 Ctrl+V 很可能带入不可见字符，建议用 kubectl create -f 后立刻 kubectl get -f 对比输出，比肉眼检查快得多。
