K8s 真正上生产之前，必须搞清楚的 5 件事K8s 真正上生产之前，必须搞清楚的 5 件事在 Kubernetes

K8s 真正上生产之前，必须搞清楚的 5 件事

“Kubernetes 并不会主动摧毁你的服务，但它会在你没做好准备时悄悄设下陷阱。”

在 Kubernetes 的生产环境中，很多问题不是因为它不好用，而是因为我们对生产环境的准备工作做得不够彻底。特别是一些常见的操作和配置，直接关系到集群的稳定性和服务的高可用性。

今天，我们将深入探讨5 个必须搞清楚的问题，这些是你在生产环境上线前必须解决的，如果忽视了这些细节，后果可能是灾难性的。

1、没有 Resource Requests 和 Limits？等着被挤掉吧！

Kubernetes 中的资源请求和限制是保证服务正常运行的基础。如果没有配置 requests 和 limits，资源分配就会变得完全不可控。默认情况下，Pod 可以在集群中的任何节点上调度，但如果没有明确的资源限制，可能会遇到以下问题：

某个服务突然占用大量 CPU，导致其他服务无法获取足够资源；
即使是关键服务，也可能因为资源不足被 OOM Kill；
整个节点因为资源耗尽崩溃，一连串服务跟着挂掉。

解决方案：在部署前，务必为每个 Pod 设置合理的 requests 和 limits。

resources:
  requests:
    cpu: "500m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "512Mi"

小贴士：requests 决定了调度优先级，limits 则防止单个 Pod 狂吃资源。合理配置能让你的服务“和平共处”，避免恶性资源争抢。

2、没有就绪探针（readinessProbe），滚动升级就是“断崖式替换”

K8s 提供了滚动更新机制，但它并不是万能的。在没有配置就绪探针（readinessProbe）的情况下，服务升级可能会陷入“断崖式替换” ——即新 Pod 启动时还没有完全就绪，流量却已经被切换过去，导致服务不可用。

比如：

升级时，旧 Pod 被杀，新 Pod 启动需要 3 秒钟，但它还未准备好；
LoadBalancer 马上将流量打到新 Pod 上；
结果——用户请求全挂。

解决方案：配置 readinessProbe，确保新 Pod 完全就绪再接入流量。

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

经验分享：通过 readinessProbe，你可以确保 Pod 在健康状态下才开始接收请求，避免“假活着”的服务浪费流量。

3、你以为 ConfigMap 改了就生效了？想多了

另一个常见问题是：修改了 ConfigMap 或 Secret 后，服务并不会自动读取新的配置。如果你没有配置自动更新机制，服务会继续使用旧的配置文件，直到 Pod 被重启。

解决方法：

使用版本控制为 ConfigMap 或 Secret 打上时间戳或 Git commit hash；
在 Deployment 中指定新的 configMapKeyRef，确保每次都能引用最新的配置；
配置 CI/CD 流程，在更新 ConfigMap 后自动触发滚动重启。

示例：

envFrom:
  - configMapRef:
      name: my-config-20230625

进阶推荐：使用 Operator 或自建 Controller，实现 ConfigMap 或 Secret 的自动更新，避免手动重启 Pod。

4、不理解 Service 类型，生产暴露方式可能大错特错

Kubernetes 的 Service 是服务暴露的关键，但选择错误的 Service 类型，可能导致服务无法稳定暴露给外部。

常见类型有：

类型	是否暴露外网	典型用途
ClusterIP	❌	内部服务通信
NodePort	✅（不推荐）	快速测试，端口暴露
LoadBalancer	✅	标准对外暴露

常见误区：

NodePort 暴露生产服务，容易被随机端口撞上；
LoadBalancer 没有设置健康检查，外部流量进入时，服务直接挂掉；
错误的 Service selector 可能导致流量被转发到错误的 Pod。

最佳实践：

生产环境中，应该通过 Ingress + LoadBalancer 配合使用，确保流量管理、权限控制等功能的可用性和灵活性。

小贴士：Ingress 能帮助你灵活配置流量路由，同时加上身份验证和防火墙策略，确保服务安全。

5、监控和日志不是“上线后再装的配件”，是上线前就该配齐的战甲

没有监控和日志，一旦服务出现问题，你将无法知道发生了什么。生产环境的监控和日志系统应该在上线之前就配置好，而不是等到问题爆发时才想起加上去。

推荐配置：

Prometheus + Grafana：监控资源、QPS、错误率等；
Loki / Elasticsearch：收集多容器日志，便于排查；
Alertmanager：设置告警策略，及时发现异常（例如 CPU 超阈值、Pod 持续重启）。

👀 关键提示：确保日志中包含 Trace ID，这样你可以方便地进行跨服务链路的排查。

总结：真正的上线准备，是提前排雷

警示点	正确姿势
Pod 资源无限制	配置 requests/limits
没有探针配置	配置 readiness + liveness
ConfigMap 热更新失效	配置版本控制和滚动重启
Service 暴露不当	使用 Ingress 配置流量管理
没有监控和日志	上线前配置完整链路监控系统

📣 彩蛋互动：你上线前遇到过哪些坑？

欢迎留言分享你在 Kubernetes 上线前遇到的坑，或者解决的技术挑战。我们将精选最具代表性的问题进行深度解析，助力大家少踩坑、多成功！

扫码关注公众号

K8s 真正上生产之前，必须搞清楚的 5 件事