3. 基础层(Base)设计：如何定义通用资源、Deployment/Service/ConfigMap基础模板

在 Kustomize 的分层管理模型中，基础层（Base）是整个配置体系的基石。它定义了应用在任意环境中都保持不变的通用资源模板，包括 Deployment、Service、ConfigMap 等核心对象。本章将深入讲解如何设计高复用性的 Base 层，确保团队能够通过最小的改动实现多环境适配。

3.1 基础层设计原则

Base 层应遵循以下三条核心原则：

• 单一职责：每个 Base 目录只描述一个应用或一组紧密耦合的组件，不混入环境差异。
• 参数化入口：通过 Kustomize 的 vars 或 configMapGenerator 暴露可变字段，避免硬编码。
• 最小化覆盖：Base 层只包含所有环境共用的配置，环境专属内容通过 Overlay 层注入。

3.2 通用资源模板结构

一个标准的基础层目录结构如下：

base/
├── kustomization.yaml
├── deployment.yaml
├── service.yaml
├── configmap.yaml
└── hpa.yaml          # 可选：通用 HPA 模板

以下逐一解析各模板的设计要点。

3.3 Deployment 基础模板

Deployment 模板应预留关键的可覆盖字段，包括副本数、镜像、资源限制、环境变量和探针。示例模板：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 1  # 默认值，由 Overlay 覆盖
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-registry/my-app:latest  # 占位标签
        ports:
        - containerPort: 8080
        env:
        - name: LOG_LEVEL
          value: "info"
        - name: DB_HOST
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: db_host
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 15
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

3.4 Service 基础模板

Service 模板通常使用 ClusterIP 类型，暴露端口与 Deployment 的 containerPort 对齐：

apiVersion: v1
kind: Service
metadata:
  name: my-app-svc
  labels:
    app: my-app
spec:
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: my-app

3.5 ConfigMap 基础模板

ConfigMap 使用 configMapGenerator 在 kustomization.yaml 中声明，而非直接编写 YAML 文件。这种方式支持自动哈希追加和行为一致性：

# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- deployment.yaml
- service.yaml

configMapGenerator:
- name: app-config
  literals:
  - db_host=localhost
  - db_port=5432
  - log_level=info
  - cache_ttl=300

生成的 ConfigMap 名称会自动追加哈希后缀（如 app-config-7g4h2k9m），当内容变更时，Deployment 中的引用会自动更新，触发滚动更新。

3.6 基础层资源关系图

下图展示了 Base 层中 Deployment、Service、ConfigMap 之间的引用关系，以及它们如何通过标签选择器形成逻辑单元：

3.7 kustomization.yaml 编排

Base 层的 kustomization.yaml 负责将上述资源聚合为一个逻辑单元，并声明通用生成器和转换器：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

# 资源列表
resources:
- deployment.yaml
- service.yaml

# ConfigMap 生成器
configMapGenerator:
- name: app-config
  literals:
  - db_host=localhost
  - db_port=5432
  - log_level=info

# 通用标签
commonLabels:
  app: my-app
  managed-by: kustomize

# 通用注解
commonAnnotations:
  version: "1.0.0"
  environment: base

# 名称前缀（可选，用于多实例部署）
namePrefix: base-

3.8 多环境复用验证

设计完成后，可通过以下命令验证 Base 层的正确性：

# 渲染 Base 层输出
kustomize build base/

# 验证 YAML 合法性
kustomize build base/ | kubectl apply --dry-run=client -f -

# 查看最终生成的资源名称
kustomize build base/ | grep -E "^kind:|^  name:"

输出示例：

kind: ConfigMap
  name: base-app-config-7g4h2k9m
kind: Deployment
  name: base-my-app
kind: Service
  name: base-my-app-svc

可以看到，namePrefix 和 configMapGenerator 已正确生效，所有资源名称统一添加了 base- 前缀，ConfigMap 名称包含哈希后缀。

3.9 常见设计误区