关于数据库:Kubernetes-中的应用参数配置案例详析

5次阅读

共计 3179 个字符，预计需要花费 8 分钟才能阅读完成。

✏️ 作者简介：
宗玉芬，Zilliz 测试开发工程师，华中科技大学计算机技术工程硕士。目前专一于 Milvus 数据库的品质保障工作，包含但不限于接口测试、SDK 测试、Benchmark 测试等。一个喜爱定位问题、酷爱探索混沌工程实践与故障演练实际的测试开发小朋友。

在应用 Milvus 时，咱们可能心愿批改默认参数，以满足不同场景的需要。前不久，已有 Milvus 用户分享了如何在应用 docker-compose 部署时批改配置文件（点击浏览：技术分享|如何对 Milvus 2.0 进行参数配置），本文将简略介绍如何在应用 Kubernetes 部署 Milvus 时批改配置参数。

不同的参数配置能够抉择不同的批改计划。Milvus 所有的配置文件都位于 /milvus/configs/ 门路下。当应用 Kubernetes 装置 Milvus 利用时咱们会增加 Milvus Chart 仓库，增加后通过命令 helm show values milvus/milvus 查看 Chart 反对配置的参数项。如果这些参数项中蕴含咱们想要批改的参数，则能够通过 --values 或 --set 两种形式传递配置数据，具体应用细节请参考 Milvus Helm Chart 或 Helm；如果不蕴含咱们想批改的参数，则能够思考下文介绍的小办法：

Milvus 在 Kubernetes 中的配置文件治理是通过 ConfigMap 资源对象实现的。如果咱们须要批改 Milvus Chart 可配置选项以外的参数，则须要先更新对应 Chart Release 的 ConfigMap 对象，而后批改相应 Pod 的 Deployment 资源文件。接下来，以批改 /milvus/configs/advanced/root_coord.yaml 文件中的 rootcoord.dmlChannelNum 参数为例进行阐明，依照先批改 ConfigMap 对象属性再批改 Deployment 对象属性两个步骤进行，将其值从 256 批改为 128。

须要留神的是，该办法只针对曾经部署的 Milvus 利用进行配置批改。如果须要在部署时或部署前批改 /milvus/configs/advanced/*.yaml 中的配置，咱们须要对 Milvus Helm Chart 进行再开发。

Kubernetes 中运行的 Release 对应着名为 milvus-chaos 的 ConfigMap 对象，其 data 属性只蕴含了 milvus.yaml 文件的配置。同理，咱们须要将 rootcoord.dmlChannelNum 参数所在的 root_coord.yaml 配置到 data 属性中，同时将 rootcoord.dmlChannelNum 批改为 128 即可。

kind: ConfigMap
apiVersion: v1
metadata:
  name: milvus-chaos
  ...
data:
  milvus.yaml: >
    ......
  root_coord.yaml: |
    rootcoord:
      dmlChannelNum: 128
      maxPartitionNum: 4096
      minSegmentSizeToEnableIndex: 1024
      timeout: 3600 # time out, 5 seconds
      timeTickInterval: 200 # ms

ConfigMap 对象中存储的数据能够被 configMap 类型的卷援用，而后向 Pod 注入配置数据，从而被 Pod 中运行的容器化利用应用。如果咱们想让 Pod 拜访新的配置文件，则需批改那些会加载 root_coord.yaml 配置的 Pod 模板，具体是在 Deployment 资源清单文件中的 spec.template.spec.containers.volumeMounts 下增加一个挂载申明。以 rootcoord pod 的 Deployment 资源清单为例，从 spec.template.spec.volumes 关键字能够看到 Pod 顶层申明了一个名为 milvus-config，类型是 configMap 的 Volume，并且 Pod 中的 rootcoord 容器申明将卷 milvus-chaos 的 milvus.yaml 文件挂载到门路 /milvus/configs/milvus.yaml 下。同理，咱们只须要将 root_coord.yaml 文件挂载到 /milvus/configs/advanced/root_coord.yaml 门路下，以便容器能拜访即可。

spec:
  replicas: 1
  selector:
    ......
  template:
    metadata:
      ...
    spec:
      volumes:
        - name: milvus-config
          configMap:
            name: milvus-chaos
            defaultMode: 420
      containers:
        - name: rootcoord
          image: 'milvusdb/milvus-dev:master-20210906-86afde4'
          args:
            ...
          ports:
            ...
          resources: {}
          volumeMounts:
            - name: milvus-config
              readOnly: true
              mountPath: /milvus/configs/milvus.yaml
              subPath: milvus.yaml
            - name: milvus-config
              readOnly: true
              mountPath: /milvus/configs/advanced/root_coord.yaml
              subPath: root_coord.yaml
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          imagePullPolicy: IfNotPresent
      restartPolicy: Always
      terminationGracePeriodSeconds: 30
      dnsPolicy: ClusterFirst
      securityContext: {}
      schedulerName: default-scheduler

实现上述两步批改后，Pod 从新挂载了 ConfigMap 卷，且 ConfigMap 属性的批改被检测到后，Pod 会滚动更新。当新的 Pod 从新进入 Running 状态后，咱们能够进入 Pod 验证是否批改胜利，具体命令如下所示。能够看到 /milvus/configs/advanced/root_coord.yaml 文件中的 rootcoord.dmlChannelNum 的值曾经更新为 128 了。

$ kctl exec -ti milvus-chaos-rootcoord-6f56794f5b-xp2zs -- sh

# cd configs/advanced
# pwd
/milvus/configs/advanced
# ls
channel.yaml  common.yaml  data_coord.yaml  data_node.yaml  etcd.yaml  proxy.yaml  query_node.yaml  root_coord.yaml

# cat root_coord.yaml
rootcoord:
  dmlChannelNum: 128
  maxPartitionNum: 4096
  minSegmentSizeToEnableIndex: 1024
  timeout: 3600 # time out, 5 seconds
  timeTickInterval: 200 # ms
# exit

至此，该批改 Milvus 配置的办法曾经介绍结束。在 Milvus 之后的版本中，咱们会将用户所关怀的配置参数对立搁置到一个文件中，且反对通过 Helm Chart 配置更新。在新版本诞生前，心愿这篇文档介绍的长期批改计划能对大家有所帮忙!

正文完