github上有可以参考的k8s最佳实践案例么？

资源管理这块，最基本也最容易被忽略的是给每个容器设置 resources.requests 和 resources.limits，不设置的话 kube-scheduler 在做我们之前详细讲过的 Filter/Score 阶段时根本不知道这个 Pod 大概要吃多少资源，容易导致某些节点被塞爆、某些节点又很空闲，调度决策失去意义；limits 设得太紧又会导致容器频繁被 OOMKilled（这个状态会直接反映在我们刚聊的 Pod Conditions 和容器的 terminated reason 里）。比较成熟的做法是先给一个保守的初始值，然后用 VerticalPodAutoscaler 之类的工具跑一段时间观察真实用量再调整，而不是拍脑袋定数字。命名空间层面建议配合 ResourceQuota 和 LimitRange，防止某个团队或者某个应用把整个集群资源吃光，这在多租户集群里几乎是必须的。

高可用这块，跟我们之前聊的”K8s 里的单点”直接相关——业务 Pod 层面至少要跑多副本（replicas ≥ 2，一般 3 起步），并且要用 podAntiAffinity 或者 topologySpreadConstraints 把这几个副本打散到不同节点、甚至不同可用区，不然多副本形同虚设，一个节点挂了照样把所有副本一起带走。还要配 PodDisruptionBudget，限制滚动升级、节点维护这类”主动”操作时最多能同时下线几个副本，避免运维操作误伤到刚好凑不够存活数量的场景。健康探针这块也很关键，readinessProbe 和 livenessProbe 要分开设计、语义不能混——readinessProbe 决定这个 Pod 要不要被 Service 转发流量（对应我们前面聊的 Ready 这个 Condition），livenessProbe 决定这个容器是不是已经死锁/僵死需要被重启，两者混用或者探针本身写得太脆弱（比如探测逻辑本身很重、容易超时）经常是生产环境里”看起来健康实际上在抖动”的根源。

安全这块，RBAC 权限一定要按最小权限原则配置，不要图省事直接把 ServiceAccount 绑到 cluster-admin 上；容器尽量避免以 root 用户跑（securityContext 里设 runAsNonRoot），也不要开 privileged 模式除非真的有硬件访问这类刚需；Pod 如果不需要调用 Kubernetes API，记得把 automountServiceAccountToken 设成 false，减少万一容器被攻破之后拿到的攻击面（呼应我们之前聊的 mTLS/SPIFFE 那块，ServiceAccount Token 是很多身份体系的信任根，不该被滥用）；网络层面建议配上 NetworkPolicy，默认不该让集群里任意 Pod 都能随便访问任意其他 Pod,这也是很多集群”默认全通”埋下的安全隐患;敏感信息走 Secret（更进一步接外部密钥管理系统比如 Vault 或者云厂商的 KMS，而不是把明文密码直接写进 ConfigMap 或者 YAML 里提交进 Git）。

部署策略这块，镜像标签不要用 :latest，这个我们之前隐约提到过，用具体的版本号或者 digest（sha256 摘要）能保证”这个 Pod 用的镜像”是确定、可复现的，不会出现你以为部署的是 A 版本、实际上因为 :latest 被后台重新 push 过而悄悄变成了 B 版本这种诡异问题；滚动更新（RollingUpdate）要配合 maxUnavailable 和 maxSurge 仔细调，确保升级过程中始终有足够多的健康副本在线；更进一步，生产环境建议走 GitOps 模式（比如 ArgoCD、Flux），所有变更都通过 Git 提交触发，而不是本地手动 kubectl apply，这个我们聊 Crossplane 误删风险的时候也提到过，本质上是同一个思路——变更留痕、可审查、可回滚。

可观测性这块，日志尽量走标准输出（stdout/stderr）交给统一的日志采集系统（比如 Fluentd/Loki 收集后进 ELK 或者其他日志平台），不要自己在容器里往文件里写日志然后想着以后再处理；Metrics 走 Prometheus 这套生态基本是行业默认选择；分布式追踪（Tracing）在微服务规模上来之后基本是必需品，不然一个请求跨了十几个服务出问题根本没法定位是哪一环慢了。

最后回到我们这几天一直在聊的架构层面——etcd 要按 3 或 5 节点部署并且定期做 snapshot 备份（这个我们详细聊过具体命令），apiserver 要做好水平扩展加负载均衡，scheduler/controller-manager 要开多副本走 leader election，这些控制面本身的高可用配置往往是最容易被新手忽略、但一旦出问题影响面最大的部分。

以上这几块任何一个你想深入展开（比如具体怎么写好一个 readinessProbe、NetworkPolicy 具体怎么配、GitOps 工具怎么选），都可以告诉我，我们可以聚焦某一个方向细讲,不然”最佳实践”这个话题确实有点大,泛泛而谈价值有限。