Use of Umbrella Chart in CI/CD Pipeline w/ Multiple Contractors

Question

I am new to this group. Glad to have connected.
I am wondering if someone has experience in using an umbrella helm chart in a CI/CD process?

In our project, we have 2 separate developer contractors. Each contractor is responsible for specific microservices.

We are using Harbor as our repository for charts and accompanying container images and GitLab for our code repo and CI/CD orchestrator...via GitLab runners.

The plan is to use an umbrella chart to deploy all approx 60 microservices as one system.

I am interested in hearing from any groups that have taken a similar approach and how they treated/handled the umbrella chart in their CI/CD process.

Thank you for any input/guidance.

VR,

Answer 1

We use similar kind of pattern where we have 30+ microservices.

We have got a Github repo for base-charts.

The base-microservice chart has all sorts of kubernetes templates (like HPA,ConfigMap,Secrets,Deployment,Service,Ingress etc) ,each having the option to be enabled or disabled.

Note- The base chart can even contain other charts too

eg. This base-chart has a dependency of nginx-ingress chart:

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

Below is an example template for secrets.yaml template:

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

Now when commit happens in this base-charts repo, as part of CI process, (along with other things) we do

1. Check if Helm index already exists in charts repository
2. If exists, then download the existing index and merge currently generated index with existing one -> helm repo index --merge oldindex/index.yaml .
3. If it does not exist, then we create new Helm index ->( helm repo index . ) Then upload the archived charts and index yaml to our charts repository.

Now in each of our microservice, we have a charts directory , inside which we have 2 files only:

1. Chart.yaml
2. values.yaml

Directory structure of a sample microservice:

The Chart.yaml for this microservice A looks like:

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"

And the values.yaml for this microservice A has those values which need to be overriden for the base-microservice values.

eg.

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

Now while doing Continuous Deployment of this microservice, we have these steps (among others):

1. Fetch helm dependencies (helm dependency update ./charts/my-service-A)
2. Deploy my release to kubernetes (helm upgrade --install my-service-a ./charts/my-service-A)