2024-08-21

揭秘 Zadig 多环境配置最佳实践 - K8s YAML 篇

Zadig K8s YAML 项目一键配置，实现数据库隔离、域名定制、配置灵活变更，简化多环境管理。

Zadig 提供了面向开发者的云原生环境，支持分钟级创建或复制一套完整的隔离环境以应对频繁的业务变更和产品迭代。在实际使用中，多套环境的数据库、域名、业务配置的差异如何管理呢？本文主要介绍如何使用 Zadig K8s YAML 项目服务管理的变量配置能力，通过一套配置，实现多环境的隔离以及全局配置管理：

数据库隔离：每个环境的业务数据独立存放在不同的数据库中，互不影响
差异化域名访问：使用不同的域名地址访问不同的环境
差异化业务配置：业务配置管理在 Nacos、Apollo 等配置中心，不同的环境使用不同的配置
全局管理共享配置：对多个服务共享的同一组配置进行全局管理

# 数据库隔离

适用：不同环境的业务数据互相隔离，一个数据库对应多个连接地址，或连接不同的数据库均适用。

# 配置服务变量

如图中 vote 服务，该服务数据库相关配置被管理在 ConfigMap 中的，并通过 volume 挂载到应用中。在 Zadig 中，将数据库配置项抽取为自定义变量 mgo_addr 和 mgo_db，并为其配置默认值。

mgo_addr 默认值设置：220.16.0.43，可根据实际情况进行配置。
mgo_db 默认值设置：$Product$_$EnvName$_vote ，这里我们用到了系统内置全局变量 $Product$、$EnvName$，分别表示项目名称和环境名称。

配置服务变量

# 使用服务变量

新建环境时，配置中的变量可以使用默认值，也可以重新指定。

新建环境定义变量值

环境创建时，变量会被自动渲染，效果如下图。在 dev 环境中被渲染为：vote-dev-vote，qa 环境中被渲染为：vote-qa-vote。

dev 环境配置渲染结果

qa 环境配置渲染结果

图例中服务 K8s YAML 配置如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: vote
  name: vote-rc-origin
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vote
      version: rc-origin
  template:
    metadata:
      labels:
        app: vote
        version: rc-origin
    spec:
      containers:
      - image: dockersamples/examplevotingapp_vote:before
        name: vote-e2e
        ports:
        - containerPort: 80
          name: vote
        volumeMounts:
        - name: config-volume
          mountPath: /app/config
      volumes:
      - name: config-volume
        configMap:
          name: vote-config
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: vote-config
data:
  SERVICE_MGO_ADDR: {{.mgo_addr}}
  SERVICE_MGO_DB: {{.mgo_db}}
  SERVICE_MGO_MODE: strong

# 差异化域名访问

适用：在 Zadig 中创建多套环境，使用不同的域名访问不同的环境

# 配置泛域名

给集群入口配置一个泛域名，比如：*.koderover.com，确保域名 DNS 正确解析到集群 Ingress 控制器 (opens new window) LoadBalancer 的外网 IP 上。

# 配置及使用服务变量

此例中为业务入口配置外网访问地址，Zadig 中配置自定义变量： {{.domain}}，变量值设为：vote-$EnvName$.koderover.com

配置服务变量

新建环境时，系统会自动渲染变量，效果图示如下。

dev 环境域名渲染结果

qa 环境域名渲染结果

图例中服务的 K8s YAML 配置如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vote-rc-origin
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/instance: vote
      app.kubernetes.io/name: vote
  template:
    metadata:
      labels:
        app.kubernetes.io/instance: vote
        app.kubernetes.io/name: vote
    spec:
      containers:
      - image: dockersamples/examplevotingapp_vote:before
        name: vote-e2e
        ports:
        - containerPort: 80
          name: vote

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: vote
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: 100m
spec:
  ingressClassName: {{.ingressClass}}
  rules:
  - host: {{.domain}}
    http:
      paths:
      - backend:
          service:
            name: vote
            port:
              number: 5000
        path: /
        pathType: ImplementationSpecific
---
apiVersion: v1
kind: Service
metadata:
  name: vote
spec:
  type: NodePort
  ports:
    - protocol: TCP
      port: 5000
      targetPort: 80
  selector:
    app.kubernetes.io/instance: vote
    app.kubernetes.io/name: vote

# 差异化业务配置

适用：服务的业务配置在第三方配置中心管理（比如 Nacos、Apollo 等），不同环境使用不同的配置项。下面以一套 Apollo 配置中心举例，通过 Zadig 管理和使用不同环境的业务配置。

# 配置服务变量

以 myapp 服务为例，我们需要在 Zadig 中设置 Apollo 配置参数与 Zadig 环境变量的对应关系。

在 Zadig 中定义的配置项（可以根据情况进行设置）：

APOLLO_APP_NAMESPACE：Apollo 配置中心的命名空间（Namespace），使用 Zadig 自定义变量 apollo_app_namespace 为其赋值，默认值设为 zadig.dev
APOLLO_APP_ID：Apollo 配置中心的应用（Application），使用 Zadig 系统内置变量 $Service$ 为其赋值。
APOLLO_APP_ENV：Apollo 配置中心的环境（Enviroment），使用 Zadig 系统内置变量 $EnvName$ 为其赋值。
APOLLO_APP_CLUSTER：Apollo 配置中心中的集群（Cluster），用 Zadig 自定义变量 apollo_app_cluster 为其赋值，默认值设为 local 。

配置服务变量

# 使用服务变量

当环境拉起或myapp 服务启动时，会去相应的配置中心获取服务配置。

dev 和 qa 环境效果：

dev 环境效果

qa 环境效果

图例中服务的 K8s YAML 配置如下：

apiVersion: v1
kind: Service
metadata:
  name: a
  labels:
    app: a
spec:
  ports:
  - name: http
    port: 80
    targetPort: 8080
  selector:
    app: a

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: a
  labels:
    app: a
spec:
  selector:
    matchLabels:
      app: a
  replicas: 1
  template:
    metadata:
      labels:
        app: a
    spec:
      containers:
      - name: myapp-1
        image: koderover.tencentcloudcr.com/koderover-demo/myapp-1:v0.1__linux_amd64
        imagePullPolicy: Always
        command: ["/myapp-1"]
        args: ["--downstream-addr", "$(DOWNSTREAM_ADDR)", "--headers", "$(HEADERS)"]
        env:
          - name: DOWNSTREAM_ADDR
            value: "b"
          - name: HEADERS
            value: "x-request-id"
          - name: APOLLO_APP_NAMESPACE
            value: {{.apollo_app_namespace}}
          - name: APOLLO_APP_ID
            value: $Service$
          - name: APOLLO_APP_ENV
            value: $EnvName$
          - name: APOLLO_APP_CLUSTER
            value: {{.apollo_app_cluster}}
        ports:
        - containerPort: 8080
        resources:
          limits:
            cpu: 100m
            memory: 100Mi

# 全局管理共享配置

在实际应用场景中，经常会遇到多个服务共享相同的数据库地址、配置管理系统地址等信息。为了有效管理这些共用的配置信息并简化后续的维护工作，我们可以采用「全局变量」来统一存储和管理这些变量。这样，一旦需要进行配置更新或变更，只需在全局变量中进行一次修改，即可实现对所有相关服务的同步更新，从而提高了管理效率并减少了出错的可能。