这篇主要覆盖配置管理（ConfigMap/Secret）、权限与身份（ServiceAccount/Role）、资源配额、网络策略、日常维护、etcd 备份、Kustomize 配置以及 CRD 自定义资源扩展。适合准备 小伙伴参考，慢慢看，边看边在本地集群试试效果最好。

---

目录

1. 配置管理：ConfigMap 与 Secret 的作用与区别

2. 资源配额控制：ResourceQuota

3. Pod 身份认证：ServiceAccount

4. RBAC 权限划分：Role 与 ClusterRole

5. 网络安全隔离：NetworkPolicy 与跨 Namespace 访问控制

6. 集群日常维护与升级注意事项

7. etcd 备份与恢复流程

8. 配置定制化工具：Kustomize

9. 自定义资源扩展：CRD 的作用与创建过程

10. 总结与常见坑点

---

1. 配置管理：ConfigMap 与 Secret 的作用与区别

Kubernetes 中配置和敏感数据是分开管理的，ConfigMap 负责非敏感配置，Secret 负责敏感数据。

ConfigMap 的核心作用：
把配置从镜像中解耦，避免硬编码。常见注入方式：

• 环境变量：env 或 envFrom 直接注入

• 卷挂载：把每个 key 变成文件，或者整体生成配置文件

实际运用：
部署应用时，数据库连接字符串、特征开关这些非敏感配置全扔 ConfigMap。修改配置只需更新 ConfigMap，Pod 重启后自动生效（或者用 Reloader Operator 实现热更新）。

Secret vs ConfigMap：

• 语义更清晰：密码、token、证书这些明显该放 Secret

• 权限控制更严格：RBAC 通常对 Secret 限制更细

• 工具链处理更谨慎：日志、CI/CD 默认不会直接打印 Secret（虽然只是 base64 编码）

• 镜像拉取专用：private registry 的凭据必须用 Secret

小经验：一律敏感数据走 Secret，非敏感走 ConfigMap。Secret 挂载时建议用卷方式，避免环境变量泄露到容器日志。

---

2. 资源配额控制：ResourceQuota

ResourceQuota 是 Namespace 级别的资源总量限制，防止某个命名空间无限制消耗 CPU、内存、Pod 数量、PVC 等。

实际运用：
多租户集群必备。比如开发环境给一个 Namespace 限制 10 个 Pod、20Gi 存储、总 CPU 8 核。超过配额时创建资源直接失败，提示明确。

配置要点：
可以限制 requests/limits 总量、对象数量（pods、services）、存储。

坑点：Quota 只管总量，不限制单个 Pod 的 LimitRange（那个是 LimitRange 干的）。两者经常一起用。

---

3. Pod 身份认证：ServiceAccount

ServiceAccount 是 Pod 在集群内部访问 Kubernetes API 的身份凭证。

核心用途：

• 默认每个 Namespace 有个 default SA，Pod 不指定就用它

• 通过 RBAC 绑定权限，控制 Pod 能访问哪些资源

• token 用于应用内部调用 API（比如 Operator、控制器）

实际运用：
写 自定义控制器时，必须创建专用 SA 并绑定最小权限 RBAC。普通应用如果不需要调用 API，直接用 default 就行。

---

4. RBAC 权限划分：Role 与 ClusterRole

RBAC 的权限规则分两种：

类型	作用域	典型场景
Role	单 Namespace	普通应用权限、开发环境隔离
ClusterRole	集群级别	集群范围资源（如节点、PV）、跨 Namespace 授权

实际运用：
普通业务用 Role + RoleBinding，集群管理员或 Operator 用 ClusterRole + ClusterRoleBinding。

小技巧：ClusterRole 也可以通过 RoleBinding 绑定到单个 Namespace，实现复用。

---

5. 网络安全隔离：NetworkPolicy 与跨 Namespace 访问控制

NetworkPolicy 是 Kubernetes 的网络访问控制策略，只有支持的 CNI 插件（Calico、Cilium 等）才会生效。

核心策略：
默认拒绝所有流量，然后按需放行特定 label、Namespace、端口。

跨 Namespace 访问控制：
典型做法：在目标 Namespace 创建默认拒绝入站策略，然后用 labelSelector 放行来源 Namespace 的特定 Pod。

实际运用：
生产环境默认全 Namespace 开启默认拒绝，只允许业务必要的流量。数据库 Namespace 只允许应用 Namespace 的特定服务访问。

坑点：不装支持的 CNI，NetworkPolicy 创建了也没效果。

---

6. 集群日常维护与升级注意事项

常规维护操作：

• 节点维护：kubectl cordon/drain/uncordon（停止调度、驱逐 Pod）

• 应用滚动：kubectl rollout status/undo/restart

• 证书检查：kubeadm certs check-expiration

• 资源清理：删除 Evicted Pod、调整 Quota

• etcd 快照备份

升级注意事项：

• 先备份 etcd

• 逐个节点升级控制平面 → 工作节点

• 检查版本 skew 政策（控制平面不能比节点高 2 个小版本）

• 升级后验证 API、CNI、CoreDNS

---

7. etcd 备份与恢复流程

etcd 保存了整个集群状态，备份恢复是灾难恢复的关键。

备份命令（v3 API）：

export ETCDCTL_API=3
etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-snapshot.db

etcdctl snapshot status /backup/etcd-snapshot.db

恢复流程：

1. 停止控制平面组件

2. 用 etcdctl snapshot restore 生成新数据目录

3. 替换原数据目录

4. 重启 etcd 和控制平面

5. 验证集群对象恢复

生产建议：定期自动化备份到远程存储，结合 Velero 做全集群备份。

---

8. 配置定制化工具：Kustomize

Kustomize 是原生支持的配置定制工具，通过 base + overlay/patch 方式生成不同环境配置，无需模板语言。

实际运用：
dev/staging/prod 三个环境共用 base，各自 overlay 改镜像 tag、replicas、配置。

优势：kubectl 原生支持（kubectl apply -k），干净、无外部依赖。

---

9. 自定义资源扩展：CRD 的作用与创建过程

CRD（Custom Resource Definition）允许在不修改 Kubernetes 源码的情况下扩展 API，创建自定义资源类型。

重要意义：

• 扩展功能边界

• 实现领域特定抽象（数据库即服务、ML 流水线）

• 统一声明式管理

典型应用场景：

• 数据库服务（如 MySQL Operator）

• ML 工作流（Kubeflow）

• CI/CD 流水线自定义资源

完整创建过程：

1. 定义并应用 CRD yaml（spec.names、spec.versions、spec.scope）

2. 创建 Custom Resource 实例

3. 编写控制器（通常用 operator-sdk 或 kubebuilder）监听并调谐

4. 配置 RBAC 给控制器

5. 部署控制器

---

10. 总结与常见坑点

这些知识点基本覆盖了 Kubernetes 运维的核心：从配置权限到网络安全，再到维护扩展。实际用的时候最深的体会是“最小权限原则”和“声明式优先”——RBAC 越细越好，NetworkPolicy 默认拒绝，配置用 ConfigMap/Secret 分开，扩展用 CRD + 控制器。

坑：

• Secret 当 ConfigMap 用，导致敏感数据泄露

• NetworkPolicy 忘了装支持 CNI，完全无效

• etcd 备份忘了测试恢复流程

• CRD 版本升级没规划好，导致旧实例不兼容

有问题欢迎评论区交流，一起讨论！

（完）