The Kubernetes Checklist for Teams Without a Platform Team

没有平台团队的团队：Kubernetes 检查清单

Most Kubernetes advice assumes you have a platform team: specialists who own upgrades, ingress, security policies, and the 2 a.m. pages. The teams I am writing for usually have three to ten engineers, one of whom “knows Kubernetes,” and no dedicated platform team. They depend on a cluster that nobody fully owns. I work in enterprise environments where platform teams are large and everything is process. This article is the opposite exercise: what is the minimum discipline a small team needs to run Kubernetes in production—and what enterprise baggage should it refuse to copy?

大多数关于 Kubernetes 的建议都假设你拥有一个平台团队：由专门负责升级、入口（Ingress）、安全策略以及凌晨两点值班的专家组成。我所针对的团队通常只有三到十名工程师，其中只有一人“懂 Kubernetes”，且没有专门的平台团队。他们依赖于一个无人完全负责的集群。我曾在大型企业环境中工作，那里有庞大的平台团队，一切都流程化。本文则反其道而行之：一个小团队在生产环境中运行 Kubernetes 所需的最低限度准则是什么？以及哪些企业级的“包袱”应该拒绝照搬？

The question that matters more than any tool: Before any checklist: who owns the platform after the migration is finished? Not “who set it up.” Who owns upgrades next year, certificate renewals, the CNI version, and deprecated APIs? If the answer is one person’s name, you do not have a platform. You have key-person risk with YAML on top. If the answer is “nobody, really,” Kubernetes is invisible operational debt accumulating interest. The rest of this checklist exists to make that ownership small enough for a small team to carry. For each item, score 0 if it does not exist, 1 if it exists but is informal or untested, and 2 if it is documented and tested. The purpose is not to produce a flattering number. It is to expose the next few conversations the team needs to have.

比任何工具都重要的问题是：在任何检查清单之前，请问迁移完成后谁来负责这个平台？不是“谁搭建了它”，而是谁负责明年的升级、证书续期、CNI 版本更新以及处理废弃的 API？如果答案是一个人的名字，那你并没有一个平台，你只是拥有一个带有 YAML 配置的“关键人员风险”。如果答案是“其实没人负责”，那么 Kubernetes 就是在不断累积利息的隐性运营债务。这份清单的其余部分旨在将这种所有权简化到小团队能够承担的程度。对于每一项，如果不存在则计 0 分，如果存在但非正式或未经测试则计 1 分，如果已记录并经过测试则计 2 分。其目的不是为了得出一个好看的分数，而是为了引出团队接下来需要进行的讨论。

1. Deployments: Git is the source of truth

1. 部署：Git 是唯一事实来源

Treat Git as the source of truth for workloads and cluster configuration, including temporary fixes. Use one reconciliation path—for example, Argo CD or Flux—so production changes are reviewed and reproducible. Keep emergency access, but reconcile every emergency change back into Git. Define and test a rollback path for every service. A Git revert is useful only if your delivery process can deploy it safely. This converts your cluster from a mystery into a diff. Every other practice gets easier once “what is running?” has an answer.

将 Git 视为工作负载和集群配置（包括临时修复）的唯一事实来源。使用单一的协调路径（例如 Argo CD 或 Flux），以确保生产环境的变更经过审查且可复现。保留紧急访问权限，但必须将所有紧急变更同步回 Git。为每个服务定义并测试回滚路径。只有当你的交付流程能够安全地部署它时，Git 回滚才有用。这会将你的集群从一个“谜团”变成一个清晰的差异（diff）。一旦“当前运行的是什么？”有了答案，其他所有实践都会变得更容易。

2. The rollout basics that prevent late-night incidents

2. 防止深夜事故的发布基础

Readiness probes that answer one question: can this pod serve traffic now? Include a dependency only when the application genuinely cannot serve a useful response without it. Graceful termination: handle SIGTERM and allow in-flight requests to drain. Add a short preStop delay only when your routing path needs time to stop sending new traffic, then test the behavior under load. Resource requests based on measured usage so scheduling and capacity planning reflect reality. Add limits deliberately; the right choice differs for CPU, memory, and workload behavior. PodDisruptionBudgets for replicated workloads that must remain available during voluntary disruptions such as node drains. Size them from the replica count and failure tolerance.

就绪探针（Readiness probes）只需回答一个问题：这个 Pod 现在能处理流量吗？仅在应用程序确实无法在没有依赖项的情况下提供有效响应时，才将其包含在内。优雅终止：处理 SIGTERM 信号并允许正在进行的请求处理完毕。仅在路由路径需要时间停止发送新流量时，才添加短暂的 preStop 延迟，并在负载下测试该行为。基于实际测量值设置资源请求（Requests），以便调度和容量规划反映真实情况。谨慎添加限制（Limits）；CPU、内存和工作负载行为的最佳选择各不相同。为在节点排空等主动中断期间必须保持可用的副本工作负载设置 PodDisruptionBudgets。根据副本数量和故障容忍度来设定它们的大小。

3. Security: the boring baseline, not the service mesh

3. 安全：枯燥的基准，而非服务网格

Small teams can over-index on advanced security machinery while skipping basics that matter in a customer security review: RBAC scoped per human and per workload. Nobody uses cluster-admin for daily work. Secrets via External Secrets Operator, Vault, or SOPS. Never store plaintext secrets in Git, and check who can run kubectl get secret in shared namespaces. Admission policy: block :latest, block privileged workloads, and require resource requests. Kyverno is one approachable option. NetworkPolicies around sensitive namespaces and workloads, starting with the traffic paths you actually understand. Restrict control-plane access to the networks and identities that need it; use the private-endpoint options of your managed provider where they fit your operating model. That is a stronger starting point than adding advanced machinery while basic access and secret handling remain unclear.

小团队往往过度关注高级安全机制，却忽略了客户安全审查中至关重要的基础工作：针对个人和工作负载的 RBAC 权限范围。日常工作中严禁使用 cluster-admin。通过 External Secrets Operator、Vault 或 SOPS 管理密钥。永远不要在 Git 中存储明文密钥，并检查谁可以在共享命名空间中运行 kubectl get secret。准入策略：禁止使用 :latest 标签，禁止特权工作负载，并强制要求资源请求。Kyverno 是一个易于上手的选择。在敏感命名空间和工作负载周围设置 NetworkPolicies，从你真正理解的流量路径开始。限制对控制平面的访问，仅允许必要的网络和身份访问；在符合运营模式的情况下，使用托管服务商提供的私有端点选项。相比在基础访问和密钥处理尚不明确时就引入高级机制，这才是更稳健的起点。

4. Observability: answers, not data

4. 可观测性：要答案，不要数据

You do not need every log, metric, and trace. You need to answer three questions quickly: is it broken, where, and since when? Prometheus—or a managed equivalent—plus golden-signal dashboards for your most important services. Alerts on symptoms users feel: error rate, latency, and saturation. Regularly review alerts that never produce action. Centralized logs with an explicit retention policy. Tracing when you have real multi-service debugging pain and the budget. “Not yet” can be a valid architecture decision.

你不需要所有的日志、指标和追踪数据。你需要快速回答三个问题：坏了吗？哪里坏了？从什么时候开始坏的？使用 Prometheus（或托管的同类产品）以及针对最重要服务的“黄金信号”仪表板。针对用户能感知到的症状设置警报：错误率、延迟和饱和度。定期审查那些从未触发实际行动的警报。使用具有明确保留策略的集中式日志。仅在遇到真正的多服务调试痛点且预算充足时才引入追踪。在架构决策中，“暂不引入”也是一个合理的选择。

5. Backup: a backup you have not restored is a rumor

5. 备份：未经恢复测试的备份只是传言

Velero—or a cloud-native equivalent—for Kubernetes resources and supported persistent volumes; database-native backups for databases. Backups stored outside the cluster and account they protect. Test a restore. Restore tests regularly expose missing permissions, credentials, data, or instructions. Find that out on a Tuesday afternoon, not during an incident. Write one page titled “the cluster is gone”: how long rebuilding from Git and backups should take, and who does what.

使用 Velero（或云原生同类产品）备份 Kubernetes 资源和受支持的持久卷；数据库则使用数据库原生的备份方式。备份必须存储在受保护的集群和账户之外。一定要测试恢复。定期的恢复测试会暴露出缺失的权限、凭据、数据或说明文档。在周二下午发现这些问题，总好过在事故发生时才发现。写一份名为“集群崩溃了”的文档：说明从 Git 和备份中重建需要多长时间，以及谁负责做什么。

6. Upgrades: a schedule, not an emergency

6. 升级：按计划进行，而非紧急应对

Kubernetes releases regularly and managed providers enforce their own support windows. Teams that wait until an upgrade is forced take on more changes at once and have less recent practice. Set a cadence that stays comfortably inside your provider’s support window, and put it on the calendar. Run pluto or kubent for deprecated APIs before every upgrade. Treat add-ons—ingress controller, cert-manager, CSI, and CNI—as part of the upgrade. Their compatibility can be as consequential as the control-plane version. Rehearse on a throwaway or staging cluster first.

Kubernetes 定期发布新版本，托管服务商也会强制执行各自的支持窗口。那些等到被迫升级时才行动的团队，往往需要一次性处理更多变更，且缺乏近期实践。设定一个节奏，确保在服务商的支持窗口内，并将其加入日程表。每次升级前，运行 pluto 或 kubent 检查废弃的 API。将插件（如 Ingress Controller、cert-manager、CSI 和 CNI）视为升级的一部分。它们的兼容性与控制平面版本同样重要。务必先在一次性集群或测试集群中进行演练。

What not to copy from enterprises

不要从企业那里照搬什么

• Multi-cluster, multi-region setups before you have multi-customer problems.

• A service mesh “because security.” Start with NetworkPolicies.

• An internal developer portal for five engineers.

• Change advisory boards. For many small teams, Git history and pull-request review are the change process.

• Every logo in the CNCF landscape. The landscape is a map, not a shopping list.

• 在遇到多客户问题之前，不要搞多集群、多区域部署。

• 不要因为“为了安全”就上服务网格。从 NetworkPolicies 开始。

• 不要为五个人搞一个内部开发者门户。

• 不要搞变更咨询委员会。对于许多小团队来说，Git 历史记录和 Pull Request 审查就是变更流程。

• 不要照搬 CNCF 全景图上的每一个图标。那是一张地图，而不是购物清单。

Copy the discipline: ownership, rollback, tested restores, and an upgrade cadence. Refuse the complexity: architecture shaped by headcount you do not have. 学习这种纪律：所有权、回滚、经过测试的恢复以及升级节奏。拒绝这种复杂性：不要构建那种需要你根本没有的人力才能维护的架构。