我们使用类似的模式，拥有30多个微服务。

我们有一个用于基础图表的Github存储库。

基本微服务图表具有各种kubernetes模板（例如HPA，ConfigMap，Secrets，Deployment，Service，Ingress等），每个都有启用或禁用的选项。

注意-基本图表甚至可以包含其他图表

例如此基本图具有nginx-ingress图表的依赖性：

apiVersion: v2
name: base-microservice
description: A base helm chart for deploying a microservice in Kubernetes
type: application
version: 0.1.6
appVersion: 1
dependencies:
- name: nginx-ingress
  version: "~1.39.1"
  repository: "alias:stable"
  condition: nginx-ingress.enabled

以下是secrets.yaml模板的示例模板：

{{- if .Values.secrets.enabled -}}
apiVersion: v1
kind: Secret
metadata:
  name: {{ include "base-microservice.fullname" . }}
type: Opaque
data:
  {{- toYaml .Values.secrets.data | nindent 2}}
{{- end}}

现在，在此基本图表回购中发生提交时，作为CI流程的一部分（连同其他事项），我们会做

1. 检查图表存储库中是否已存在Helm索引
2. 如果存在，则下载现有索引并将当前生成的索引与现有的索引合并-> helm回购索引--merge oldindex / index.yaml。
3. 如果它不存在，则我们创建新的Helm索引->（ helm回购索引。），然后将已归档的图表和索引yaml上载到我们的图表存储库。

现在在我们的每个微服务中，我们都有一个图表目录，其中只有2个文件：

1. Chart.yaml
2. values.yaml

示例微服务的目录结构：

此微服务A的Chart.yaml如下：

apiVersion: v2
name: my-service-A
description: A Helm chart for Kubernetes
type: application
version: 0.1.0
appVersion: 1

dependencies:
- name: base-microservice
  version: "0.1.6"
  repository: "alias:azure"

此微服务A的values.yaml具有那些需要被基础微服务值覆盖的值。

例如

base-microservice:
  nameOverride: my-service-A
  image:
    repository: myDockerRepo/my-service-A
  resources:
    limits:
      cpu: 1000m
      memory: 1024Mi
    requests:
      cpu: 300m
      memory: 500Mi
  probe:
    initialDelaySeconds: 120
  nginx-ingress:
    enabled: true
  ingress:
    enabled: true

现在，在持续部署此微服务时，我们具有以下步骤（以及其他步骤）：

1. 获取头盔依赖关系（头盔依赖关系更新./charts/my-service-A）
2. 将我的发行版部署到kubernetes（ helm upgrade --install my-service-a ./charts/my-service-A）