• GitOps workflow steps
• Helm chart with GitOps workflow
• Helm configuration reference
• Custom values
• Automatic drift remediation
• Example repository layout
• Known issues
• Troubleshooting
  • Agent cannot find values for the chart

Using Helm charts to update a Kubernetes cluster (Experiment)

You can deploy Helm charts to your Kubernetes cluster and keep the resources in your cluster in sync with your charts and values. To do this, you use the pull-based GitOps features of the agent for Kubernetes.

This feature is an Experiment and an epic exists to track future work. Tell us about your use cases by leaving comments in the epic.

GitOps workflow steps

To update a Kubernetes cluster by using GitOps with charts, complete the following steps.

1. Ensure you have a working Kubernetes cluster, and that the chart is in a GitLab project.
2. In the same project, register and install the GitLab agent.
3. Configure the agent configuration file so that the agent monitors the project for changes to the chart. Use the GitOps configuration reference for guidance.

Helm chart with GitOps workflow

To update a Kubernetes cluster by using Helm charts:

1. Ensure you have a working Kubernetes cluster.
2. In a GitLab project:
   • Store your Helm charts.
   • Register and install the GitLab agent.
3. Update the agent configuration file so that the agent monitors the project for changes to the chart. Use the configuration reference for guidance.

Any time you commit updates to your chart repository, the agent applies the chart in the cluster.

Helm configuration reference

The following snippet shows an example of the possible keys and values for the GitOps section of an agent configuration file (config.yaml).

gitops:
  charts:
  - release_name: my-application-release
    source:
      project:
        id: my-group/my-project-with-chart
        ref:
          branch: production
        path: dir-in-project/with/charts
    namespace: my-ns
    max_history: 1
    values:
      - inline:
          someKey: example value

Custom values

To customize the values for a release, set the values key. It must be an array of objects. Each object must have exactly one top-level key that describes where the values come from. The supported top-level keys are:

• inline: Specify the values inline in YAML format, similar to a Helm values file.

When installing a chart with custom values:

• Custom values get merged on top of the chart’s default values.yaml file.
• Values from subsequent entries in the values array overwrite values from previous entries.

Example:

gitops:
  charts:
  - release_name: some-release
    values:
      - inline:
          someKey: example value
    # ...

Automatic drift remediation

Drift happens when the current configuration of an infrastructure resource differs from its desired configuration. Typically, drift is caused by manually editing resources directly, rather than by editing the code that describes the desired state. Minimizing the risk of drift helps to ensure configuration consistency and successful operations.

In GitLab, the agent for Kubernetes regularly compares the desired state from the chart source with the actual state from the Kubernetes cluster. Deviations from the desired state are fixed at every check. These checks happen automatically every 5 minutes. They are not configurable.

Example repository layout

/my-chart
 ├── templates
 |   └── ...
 ├── charts
 |   └── ...
 ├── Chart.yaml
 ├── Chart.lock
 ├── values.yaml
 ├── values.schema.json
 └── some-file-used-in-chart.txt

Known issues

The following are known issues:

• Your chart must be in a GitLab project. The project must be an agent configuration project or a public project. This known issue also exists for manifest-based GitOps and is tracked in this epic.
• Values for the chart must be in a values.yaml file. This file must be with the chart, in the same project and path.
• Because of drift detection and remediation, the release history stored in the cluster is not useful. A new release is created every five minutes and the oldest release is discarded. Eventually history consists only of the same information. View this issue for details.

Troubleshooting

Agent cannot find values for the chart

Make sure values are in values.yaml and in the same directory as the Chart.yaml file. The filename must be lowercase, with .yaml extension (not .yml).