Namespace: 逻辑隔离

Namespace 是集群内的逻辑隔离边界。最常见的用法是区分 dev、staging、prod。

常用操作

kubectl create ns dev
kubectl get ns
kubectl config set-context --current --namespace=dev

配额与权限

ResourceQuota 控制资源上限
LimitRange 限制默认 requests/limits
RBAC 控制谁能访问哪些资源

小贴士

删除 Namespace 会删除其中所有资源
给每个环境配置独立的 kubeconfig 或 context

实操要点

先做快速盘点：kubectl get nodes、kubectl get pods -A、kubectl get events -A。
对比“期望状态”和“实际状态”，kubectl describe 往往能解释漂移或失败原因。
名称、Label、Selector 要一致，避免 Service 或控制器找不到 Pod。

快速检查清单

资源定义与业务意图一致。
Namespace、权限、镜像与环境匹配。
上线前具备健康探针与可观测日志。

Namespace 的工作负载视角

无论是 Pod、探针还是 Namespace，它们都在帮助工作负载变得可预测。Namespace 负责把业务意图映射成可运行的单元，并保障生命周期、调度与隔离的稳定性。理解这一层后，后续排障会更有方向。

标签、选择器与归属关系

标签是资源的索引，选择器是控制器和 Service 发现目标的方式。建议统一使用 app、component、env 等标签键。归属关系决定资源的重建逻辑，没有清晰标签和 ownerReferences，排障和清理都会变得困难。

调度与资源请求

调度器依赖 requests 来分配资源。缺少 requests 会导致调度不公平，容易过载。小服务可以先给保守请求，再基于监控调整。Namespace 层面的 ResourceQuota 和 LimitRange 则是约束规则的载体。

启动、就绪与终止

探针应该反映“可用性”，而不是仅仅“进程活着”。readiness 控制流量入口，liveness 需要更宽松避免重启风暴。终止阶段也很关键，设置合理的 terminationGracePeriodSeconds，并处理 SIGTERM，让服务能优雅退出。

隔离与安全基础

Namespace 只负责组织资源，真正的隔离需要配合 RBAC、NetworkPolicy 和安全上下文。像 runAsNonRoot、readOnlyRootFilesystem、capabilities 限制都能显著降低风险。需要提升权限时要说明理由并最小化范围。

资源隔离与噪声邻居

CPU 限额过低会导致节流，内存限额过低会触发 OOM。延迟敏感服务建议设置合理 requests 并留出余量，批处理作业则通过 limits 保护核心业务。

配置与密钥管理

ConfigMap 和 Secret 应作为工作负载契约的一部分。要明确配置变更是触发滚动更新还是热加载，并用 RBAC 控制访问范围。跨环境推广时要保持配置版本一致。

排障流程

推荐固定排障路径：先 describe 看事件，再看日志，必要时进入容器确认探针或依赖是否可用。Namespace 或配额问题时，检查 ResourceQuota 与 LimitRange 能快速定位原因。

kubectl get pods -n demo
kubectl describe pod demo-app -n demo
kubectl logs demo-app -n demo --tail=200
kubectl exec -it demo-app -n demo -- sh

可观测信号

事件说明调度失败或拉取失败，日志解释业务行为，指标显示趋势与瓶颈。三者结合能减少盲目猜测，提高排障效率。

稳定性检查清单

确认每个工作负载有标签、requests 和探针；Service 能找到 Pod；Namespace 的 RBAC 与配额配置合理；启动与终止行为符合真实流量模式。

收个尾：Namespace 最常见的坑就是“你以为你在那个 ns”

Namespace 本身不难，难的是团队协作时特别容易出现这种情况：

资源其实跑在 default，你一直在别的 namespace 里找
RBAC/Quota 把你卡住了，但你只盯着 Pod 状态看不出来
跨 namespace 调用时，DNS 需要写全（svc.ns 或完整域名）

所以我自己的习惯是：遇到奇怪问题先确认 context + namespace，再看 events。很多时间就是这么省下来的。