2. Kubernetes 核心概念回顾:Pod、Service、Deployment、Namespace、ConfigMap、Secret

在深入环境编排与部署之前,必须牢固掌握 Kubernetes 的六大核心原语。这些对象构成了声明式运维的基石,也是自助门户在后台调度的基本单元。下面逐一回顾其定义、职责与典型用法。

2.1 Pod:最小的调度与运行单元

Pod 是 Kubernetes 中可创建和部署的最小计算单元,代表集群上运行的一个进程实例。一个 Pod 封装一个或多个容器(通常为一个主容器),共享存储卷(Volume)和网络 IP。

  • 共享网络栈:同一 Pod 内的容器通过 localhost 互相通信,端口不能冲突。
  • 共享存储卷:Pod 级别的 Volume 可被内部所有容器挂载,用于日志收集、Sidecar 模式等场景。
  • 生命周期短暂:Pod 本身不提供自愈能力,通常由上层控制器(如 Deployment)管理。
设计提示:自助门户在编排环境时,应避免将多个不同生命周期的进程强行塞入同一个 Pod。遵循“一个 Pod 一个主进程 + 辅助 Sidecar”的模式。
Pod 内部结构示意 Pod 边界(共享网络命名空间 & Volume) 主容器 App / Nginx / Java Sidecar 容器 日志采集 / 代理 共享存储卷(emptyDir / PVC)

2.2 Deployment:声明式应用管理

Deployment 是用于管理无状态工作负载的核心控制器。它通过 ReplicaSet 确保指定数量的 Pod 副本始终运行,并支持滚动更新、回滚、扩缩容等操作。

特性 说明 自助门户场景
滚动更新 逐步替换旧 Pod,支持 maxSurge / maxUnavailable 控制速率 发布新版本时零停机部署
回滚 保留历史版本 revision,一键回退到任意稳定版本 发布失败时快速恢复
水平扩缩 调整 replicas 字段,配合 HPA 可实现自动伸缩 环境负载变化时动态调整资源
声明式更新 只提交期望状态(YAML),控制器自行调和差异 门户后端只需更新 API 对象
# 一个典型的 Deployment YAML 片段
apiVersion: apps/v1
kind: Deployment
metadata:
  name: portal-backend
  labels:
    app: portal
spec:
  replicas: 3
  selector:
    matchLabels:
      app: portal
  template:
    metadata:
      labels:
        app: portal
    spec:
      containers:
      - name: backend
        image: registry.example.com/portal:v2.1.0
        ports:
        - containerPort: 8080

2.3 Service:稳定的网络访问抽象

Pod 的 IP 是动态变化的,Service 通过标签选择器(Selector)将一组 Pod 暴露为固定的网络端点,并提供负载均衡与服务发现能力。

  • ClusterIP(默认):集群内部虚拟 IP,仅集群内可访问。
  • NodePort:在每个节点上开放一个静态端口(30000-32767),外部可通过 NodeIP:NodePort 访问。
  • LoadBalancer:云厂商提供外部负载均衡器,自动分配公网 IP。
  • Headless Service:不分配 ClusterIP,直接返回后端 Pod IP 列表,用于 StatefulSet 或自定义发现。
关键理解:Service 解耦了“前端调用”与“后端 Pod 实例变化”。自助门户在编排环境时,应始终为每个工作负载创建对应的 Service,避免硬编码 Pod IP。

2.4 Namespace:多租户隔离边界

Namespace 将物理集群划分为多个虚拟集群,用于实现资源配额、访问控制和环境隔离。在发布工程中,通常按团队、项目或环境(dev/staging/prod)划分 Namespace。

隔离维度 默认行为 门户编排建议
资源配额 通过 ResourceQuota 限制 CPU/内存/PVC 总量 每个环境 Namespace 设置独立配额
网络策略 默认允许所有流量,需 NetworkPolicy 收紧 生产 Namespace 启用默认拒绝策略
权限控制 RBAC 绑定到 Namespace 级别 开发人员只赋予目标 Namespace 的 edit 权限

2.5 ConfigMap & Secret:配置与敏感数据管理

ConfigMap 用于存储非机密性的配置数据(如配置文件、环境变量),Secret 用于存储敏感信息(如密码、、证书)。两者都可以被 Pod 以环境变量或 Volume 挂载的方式使用。

对比项 ConfigMap Secret
数据存储 明文(Base64 编码传输) Base64 编码,etcd 中可加密
典型用途 应用配置文件、命令行参数、环境变量 数据库密码、、TLS 证书
大小限制 单个对象 ≤ 1 MiB(etcd 限制) 单个对象 ≤ 1 MiB
更新方式 更新后需重启 Pod 或触发重新挂载 同 ConfigMap,部分工具支持自动 reload
# ConfigMap 示例:挂载为配置文件
apiVersion: v1
kind: ConfigMap
metadata:
  name: portal-config
data:
  application.yml: |
    server:
      port: 8080
    database:
      host: db-service

# Secret 示例:挂载为环境变量
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
stringData:
  DB_USER: admin
  DB_PASS: s3cr3t!
安全警告:切勿将 Secret 的明文值提交到 Git 仓库。自助门户应集成外部密钥管理服务(如 Vault、AWS Secrets Manager),或使用 SealedSecret / External Secrets Operator 进行加密存储。
Kubernetes 六大核心对象关系 Namespace(隔离边界) Deployment 声明式更新 & 扩缩容 Pod 最小运行单元 Service 稳定网络端点 管理 选择 ConfigMap 非敏感配置 Secret 敏感数据 注入配置 / 环境变量 所有对象 隶属于 Namespace

2.6 核心概念速查表

对象 API 版本(稳定) 作用域 是否持久 是否包含容器
Pod v1 Namespace 否(临时) 是
Deployment apps/v1 Namespace 是 否(管理 Pod)
Service v1 Namespace 是 否
Namespace v1 集群 是 否
ConfigMap v1 Namespace 是 否
Secret v1 Namespace 是 否
课程关联:在后续章节中,自助门户的“环境编排”本质上就是组合这些对象——用 Namespace 隔离环境,用 Deployment 管理应用,用 Service 暴露访问入口,用 ConfigMap/Secret 注入配置。理解这些原语的职责边界,是编写可靠编排逻辑的前提。