2. Kubernetes 核心概念回顾：Pod、Deployment、Service、Ingress、ConfigMap、Secret 的核心作用
在深入 IDP 自助门户的变更门禁与回滚判断之前，必须重新夯实 Kubernetes 的核心抽象层。这些原语不仅是集群的“乐高积木”，更是门禁策略的判定锚点——例如，回滚判断本质上是 Deployment 的 Revision 切换，而配置泄漏风险则直接关联 Secret 的访问审计。
2.1 六大核心对象速览
| 对象 | API 组 / 版本 | 核心作用 | 在门禁/回滚中的角色 |
|---|---|---|---|
| Pod | v1 | 最小调度单元，封装一个或多个容器、存储、网络 | 健康检查探针（liveness/readiness）是门禁准入的最终验证点 |
| Deployment | apps/v1 | 声明式更新 Pod 副本，支持滚动更新与回滚 | 回滚判断的核心对象；通过 revisionHistoryLimit 控制历史版本数 |
| Service | v1 | 提供稳定的网络端点，负载均衡到一组 Pod | 门禁需验证 Service Selector 是否匹配新 Pod 标签，防止流量断裂 |
| Ingress | networking.k8s.io/v1 | 七层 HTTP/S 路由，将外部流量分发到 Service | 变更门禁需检查 TLS 证书、路径重写规则是否合规 |
| ConfigMap | v1 | 存储非机密配置数据（键值对或文件） | 回滚时需确认 ConfigMap 版本是否与 Deployment 版本对齐 |
| Secret | v1 | 存储敏感数据（密码、、证书），Base64 编码 | 门禁必须扫描 Secret 是否被明文挂载或日志输出 |
门禁视角提示： 在 IDP 自助门户中，用户提交的 YAML 清单必须通过“对象合规性检查”——例如 Deployment 必须设置
strategy.rollingUpdate.maxSurge 和 maxUnavailable，否则拒绝变更。
2.2 核心对象关系图
下图展示了用户请求从 Ingress 到 Pod 的完整路径，以及 ConfigMap/Secret 如何挂载到 Pod 中。门禁系统需要在这个链路的每个环节插入校验点。
2.3 回滚判断的核心：Deployment 版本机制
Deployment 的 .spec.revisionHistoryLimit 决定了保留多少个旧 ReplicaSet。每次 Pod template 变更（如镜像版本、环境变量）都会生成一个新的 Revision。回滚操作本质上是将 .spec.template 重置为历史 Revision 的模板。
关键命令：
# 查看 Deployment 的变更历史
kubectl rollout history deployment/nginx-deploy
# 回滚到上一个版本
kubectl rollout undo deployment/nginx-deploy
# 回滚到指定版本
kubectl rollout undo deployment/nginx-deploy --to-revision=32.4 ConfigMap 与 Secret 的挂载方式对比
| 挂载方式 | ConfigMap | Secret | 门禁关注点 |
|---|---|---|---|
| 环境变量 | envFrom 或 valueFrom.configMapKeyRef |
valueFrom.secretKeyRef |
Secret 值可能被 env 命令或日志打印泄露 |
| 卷挂载 | volumes[].configMap → volumeMounts |
volumes[].secret → volumeMounts |
检查挂载路径是否被 Sidecar 容器意外读取 |
| 不可变配置 | Kubernetes v1.21+ 支持 immutable: true |
Kubernetes v1.21+ 支持 immutable: true |
不可变对象可提升安全性，但回滚时需要重建 |
回滚陷阱： 如果 Deployment 引用了 ConfigMap 或 Secret 的特定版本（如
configmap: app-config-v2），回滚 Deployment 时不会自动回退 ConfigMap 版本。门禁系统必须强制要求“配置版本与 Deployment Revision 绑定”，否则会出现“旧代码 + 新配置”的不一致状态。
2.5 门禁与回滚判断的映射关系
将上述核心对象映射到 IDP 自助门户的变更门禁逻辑中，形成以下校验矩阵：
- Pod 级别： 必须定义
livenessProbe和readinessProbe，且initialDelaySeconds不能为 0。 - Deployment 级别：
revisionHistoryLimit必须 ≥ 3（保留至少 3 个历史版本）；strategy.type必须为 RollingUpdate。 - Service 级别：
selector必须与 Deployment 的matchLabels完全一致。 - Ingress 级别：
spec.tls必须引用有效的 Secret（证书不能过期）。 - ConfigMap/Secret 级别： 禁止使用
stringData明文写入密码；推荐使用immutable: true。