3 - Kubernetes Services

Updated 1 week ago by Michael Cretzman

This topic describes how to create a Harness Service for Kubernetes. First, we create a Harness Application, and then the Harness Kubernetes Service.

Harness Application Setup

The following procedure creates a Harness Application for a Kubernetes deployment.

An Application in Harness represents a logical group of one or more entities, including Services, Environments, Workflows, Pipelines, Triggers, and Infrastructure Provisioners. Applications organize all of the entities and configurations in Harness CI/CD. For more information, see  Application Components.

To create the Harness Application, do the following:

  1. In Harness, click Setup.
  2. Click Add Application. The Application dialog appears.
  3. Give your Application a name that describes your microservice or app. For the purposes of this guide, we use the name ExampleApp.
  4. Click SUBMIT. The new Application is added.
  5. Click the Application name to open the Application. The Application entities are displayed.

Kubernetes Services

There are different types of Harness Services for different deployment platforms. The Kubernetes type includes Kubernetes-specific settings.

A Harness Service is different from a Kubernetes service. A Harness Service defines your microservice or application for deployment. A Kubernetes service enables applications running in a Kubernetes cluster to find and communicate with each other, and the outside world. To avoid confusion, a Harness Service is always capitalized in Harness documentation. A Kubernetes service is not.

To add the Kubernetes Service, do the following:

  1. In your new Application, click Services. The Services page appears.
  2. In the Services page, click Add Service. The Service dialog appears.
  3. In Name, enter a name for your Service, such as NGINX K8s.
  4. In Description, enter a description for your service.
  5. In Deployment Type, select Kubernetes.
  6. Click Enable Kubernetes V2 to enable it.
  7. Click SUBMIT. The new Service is displayed.

Next, we will walk through how to set up the Kubernetes manifests and use the Service features.

Add Artifact Sources

An Artifact Source in a Service is the microservice or application artifact you want to deploy. The Artifact Source uses an Artifact Server you set up for your Harness account, as described in  Connectors and Providers Setup.

In this guide, we use a publicly-available Docker image of NGINX as our Artifact Source for deployment.

To add an Artifact Source to this Service, do the following:

  1. In the new Service, click AddArtifact Source, and select Docker Registry. There are a number of artifact sources you can use to add a Docker image. For more information, see  Add a Docker Artifact Source. The Docker Registry dialog appears.
  2. In Name, let Harness generate a name for the source.
  3. In Source Server, select the Artifact Server you added earlier in this guide. We are using an Artifact Server connected to Docker Hub in this guide.
  4. In Docker Image Name, enter the image name. Official images in public repos such as Docker Hub need the label library. For example, library/nginx. For this guide, we will use Docker Hub and the publicly available NGINX at library/nginx.
  5. Click SUBMIT. The Artifact Source is added.

You can add multiple Artifact Sources to a Service and view the build history for each one by clicking Artifact History.

Now that we have our Docker image artifact, we can add the Kubernetes manifests for our Service.

Pull an Image from a Private Registry

If the Docker artifact source is in a private registry, Harness has access to that registry using the credentials set up in the Harness Artifact Server, but your Kubernetes cluster might not have the needed permissions. To solve this problem, the default values.yaml file contains dockercfg: ${artifact.source.dockerconfig} (to import the credentials from the Docker credentials file in the artifact) and the default deployment.yaml references this using the following:

apiVersion: v1
kind: Secret
metadata:
name: {{.Values.name}}-dockercfg
annotations:
harness.io/skip-versioning: true
data:
.dockercfg: {{.Values.dockercfg}}
type: kubernetes.io/dockercfg

When you are using a public repo, the dockercfg: ${artifact.source.dockerconfig} in values.yaml is ignored by Harness. You do not need to remove it.

If you want to use a private repo and no imagePullSecret, then set dockercfg to empty in values.yaml.

If you are using anonymous access to a Docker registry (public Docker, Nexus, Artifactory), then imagePullSecrets should be removed from the container specification. This is standard Kubernetes behavior and not related to Harness specifically.
Legacy imagePullSecret Method

Previously, Harness used a createImagePullSecret value in values.yaml that could be set to true or false, and dockercfg: ${artifact.source.dockerconfig} to obtain the credentials. If createImagePullSecret was set to true, the following default Secret object in deployment.yaml would be used:

{{- if .Values.createImagePullSecret}}
apiVersion: v1
kind: Secret
metadata:
name: {{.Values.name}}-dockercfg
annotations:
harness.io/skip-versioning: true
data:
.dockercfg: {{.Values.dockercfg}}
type: kubernetes.io/dockercfg
---
{{- end}}

This legacy method is still supported for existing Services that use it, but the current method of using the default values.yaml and deployment.yaml files is recommended.

Add Manifests

The Manifests section of Service contains the configuration files that describe the desired state of your application in terms of Kubernetes API object descriptions.

All files in Manifests may have the .yaml or .yml file extension except values.yaml, which must have the .yaml extension.

What Can I Add in Manifests?

You can add any Kubernetes configurations files, formatted in YAML, such as object descriptions, in one or more files. For example, the Manifests section has the following default files:

  • values.yaml - This file contains the data for templated files in Manifests, using the  Go text template package. This is described in greater detail below.
The only mandatory file and folder requirement in Manifests is that values.yaml is located at the directory root. The values.yaml file is required if you want to use Go templating. It must be named values.yaml and it must be in the directory root.
  • spec.yaml - This manifest contains two API object descriptions, ConfigMap and Deployment. These are standard descriptions that use variables in the values.yaml file. In the Canary and Rolling Update deployments in this guide, we simply deploy the NGINX artifact using these descriptions as is.
Manifest files added in Manifests are freeform. You can add your API object descriptions in any order and Harness will deploy them in the correct order at runtime.
YAML File Size Limit

Each YAML manifest file is limited in size to 16KB.

What about Secrets?

You cannot add binary or any non-Cleartext in the manifest files. For encrypted values, Harness stores them in its (or your) Secrets Manager and then sends them to Kubernetes via the Kubernetes API, as you will see later in this document.

What Kubernetes Workloads Can I Include?

In order to successfully deploy the workloads in your Manifests section, they must meet the minimum requirements of the type of deployment you are performing.

  • Canary and Blue/Green Workflow Type - Deployment workloads only.
  • Rolling Workflow Type - All workload types except Jobs. Jobs will be added soon.
  • Apply Step - All workload types, including Jobs.

Go Templating and Harness Variables

You can use Go templating and Harness built-in variables in combination in your Manifests files.

First, let's look at the values.yaml file to see the variables we will use in our configuration files, with comments showing how they can be referenced:

# This will be used as {{.Values.name}}
name: harness-example

# This will be used as {{int .Values.replicas}}
replicas: 1

# This will be used as {{.Values.image}}
image: ${artifact.metadata.image}

The variable ${artifact.metadata.image} is a Harness variable for referencing the metadata of the Artifact Source. For more information about Harness variables, see  Variables and Expressions in Harness.

Now, let's look at the default object descriptions to understand how easy it is to use Kubernetes in Harness.

apiVersion: v1 # for versions before 1.9.0 use apps/v1beta2
kind: ConfigMap # store non-confidential data in key-value pairs
metadata:
name: {{.Values.name}}-config # name is taken from values.yaml
data:
key: value # example key-value pair
---
apiVersion: apps/v1
kind: Deployment # describe the desired state of the cluster
metadata:
name: {{.Values.name}}-deployment # name is taken from values.yaml
spec:
replicas: {{int .Values.replicas}} # tells deployment to run pods matching the template
selector:
matchLabels:
app: {{.Values.name}} # name is taken from values.yaml
template:
metadata:
labels:
app: {{.Values.name}} # name is taken from values.yaml
spec:
containers:
- name: {{.Values.name}} # name is taken from values.yaml
image: {{.Values.image}} # image is taken from values.yaml
envFrom:
- configMapRef:
name: {{.Values.name}}-config # name is taken from values.yaml
ports:
- containerPort: 80

Let's look at some more examples:

Expression Builder

When you edit manifests in the Harness Service, you can enter expressions by entering {{. and Harness will fetch the values available in the values.yaml file.

This expression builder helps to ensure that you do not accidentally enter an incorrect value in your manifests.

Example 1: Using Docker Image from Harness Artifact Stream

The Docker image name is available in the Harness variable: ${artifact.metadata.image}.

In the values.yaml file, it will look like this:

image: ${artifact.metadata.image}

In a manifest file, it will be used like this:

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
selector:
matchLabels:
app: nginx
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: {{.Values.image}} # applying ${artifact.metadata.image}
ports:
- containerPort: 80

Example 2: Creating ImagePullSecret using Harness Artifact Stream

The DockerConfig for docker repository (kubectl get secret regcred --output=yaml) is available in Harness variable in values.yaml by default: ${artifact.source.dockerconfig}. For more information, see  Inspecting the Secret regcred from Kubernetes.

In the values.yaml file, it looks like this:

image: ${artifact.metadata.image}
dockercfg: ${artifact.source.dockerconfig}

In a manifest file, it is used like this:

apiVersion: v1
kind: Secret
metadata:
name: docker-regcred
annotations:
harness.io/skip-versioning: true
data:
.dockercfg: {{.Values.dockercfg}} # applying ${artifact.source.dockerconfig}
type: kubernetes.io/dockercfg
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
selector:
matchLabels:
app: nginx
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: {{.Values.image}}
ports:
- containerPort: 80
imagePullSecrets:
- name: docker-regcred

If you want to use a private repo and no imagePullSecret, then set dockercfg to empty in values.yaml.

When you are using a public repo, the dockercfg: ${artifact.source.dockerconfig} in values.yaml is ignored by Harness. You do not need to remove it.

If you are using anonymous access to a Docker registry (public Docker, Nexus, Artifactory), then imagePullSecrets should be removed from the container specification. This is standard Kubernetes behavior and not related to Harness specifically.

Example 3: Using Harness Variables in Manifests

Harness built-in variables can be used in values.yaml file, and are evaluated at runtime. For a list of Harness variables, see  Variables and Expressions in Harness.

In the values.yaml file, it will look like this:

name: ${serviceVariable.serviceName}

In a manifest file, it will be used like this:

apiVersion: apps/v1
kind: Deployment
metadata:
name: {{.Values.name}} # ${serviceVariable.serviceName}
spec:
selector:
matchLabels:
app: nginx
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80

Example 4: Creating Namespace based on Environment InfraMapping

The Harness variable ${infra.kubernetes.namespace} refers to the namespace entered in the Harness Environment Service Infrastructure/Infrastructure Definition settings Namespace field.

Here it is in a Service Infrastructure:

Here it is in an Infrastructure Definition:

You can use ${infra.kubernetes.namespace} in your Harness Service Manifests definition of a Kubernetes namespace to reference the name you entered in the Service Infrastructure/Infrastructure Definition Namespace field.

When the Harness Service is deployed to that Service Infrastructure/Infrastructure Definition, it will create a Kubernetes namespace using the value you entered in the Service Infrastructure/Infrastructure Definition Namespace field.

In the values.yaml file, it will look like this:

namespace: ${infra.kubernetes.namespace}

In a manifest file for the Kubernetes Namespace object, it will be used like this:

apiVersion: v1
kind: Namespace
metadata:
name: {{.Values.namespace}}

When this manifest is used by Harness to deploy a Kubernetes Namespace object, it will replace ${infra.kubernetes.namespace} with the value entered in the Service Infrastructure/Infrastructure Definition Namespace field, creating a Kubernetes Namespace object using the name. Next, Harness will deploy the other Kubernetes objects to that namespace.

If you omit the namespace key and value from a manifest in your Service, Harness automatically uses the namespace you entered in the Harness Environment Service Infrastructure/Infrastructure Definition settings Namespace field.

Can I Change the Default Folder Structure?

Yes. There is no significance to the default folder structure. You can use the folders and files just as you would in any Kubernetes folder or file structure.

The only mandatory file and folder requirement is that values.yaml is located at the directory root. The values.yaml file is required if you want to use Go templating.

Manifest Versioning

API objects described in the Manifests section are versioned by Harness. For example, let's say you have four object descriptions in a manifest file:

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
...
apiVersion: v1
kind: Secret
metadata:
name: image-pull-secret
annotations:
harness.io/skip-versioning: true
...
apiVersion: v1
kind: Namespace
metadata:
name: {{.Values.namespace}}
...
apiVersion: v1
kind: Secret
metadata:
name: sample
stringData:
password: {{.Values.password}}
type: Opaque
...

Each time these objects are deployed, they are versioned by Harness, as you will see in Harness Deployments:

INFO   2019-02-15 10:53:33    Kind                Name                                    Versioned 
INFO 2019-02-15 10:53:33 Namespace default false
INFO 2019-02-15 10:53:33 Secret image-pull-secret false
INFO 2019-02-15 10:53:33 Secret sample true
INFO 2019-02-15 10:53:33 Deployment nginx-deployment false
INFO 2019-02-15 10:53:33
INFO 2019-02-15 10:53:33
INFO 2019-02-15 10:53:33 Current release number is: 5
INFO 2019-02-15 10:53:33
INFO 2019-02-15 10:53:33 Previous Successful Release is 4
INFO 2019-02-15 10:53:33
INFO 2019-02-15 10:53:33 Cleaning up older and failed releases
INFO 2019-02-15 10:53:33
INFO 2019-02-15 10:53:33 Managed Workload is: Deployment/nginx-deployment
INFO 2019-02-15 10:53:33
INFO 2019-02-15 10:53:33 Versioning resources.

Ignoring a Manifest File During Deployment

To have a Workflow ignore a resource file in a Service Manifests section, you add the comment # harness.io/skip-file-for-deploy to the top of the file. For example, here is a ConfigMap file using the comment:

For information, see  Ignore a Manifest File.

Use Local or Remote Configuration Files

You can use local or remote configuration files for the Service. Local and remote configuration files have the following features and limitations:

  • Kubernetes Services come with default manifest files that you can edit to suit your deployments.
  • You can add your own files and folders.
  • You can upload your own files using a file picker.
  • By default, configuration files are stored locally in the Harness Manager.
  • You can store configuration files in a remote repo by syncing your Harness Application with a repo, as described in  Configuration as Code.
  • If you use remote configuration files for Manifests and also sync your Harness Application with a repo, nothing from the remote manifest is synced with the repo that the Application is synched with. The remote configuration files for Manifests are simply pulled at runtime.

Local Configuration Files

Kubernetes Services come with default manifest files that you can edit to suit your deployments. You can also add or upload your own files.

By default, configuration files are stored locally in the Harness Manager. You can add or edit files as needed.

Adding Manifest Files

You can add manifest files in the following ways:

  • Manually add a file using the Manifests Add File dialog.
  • Uploading local files.

To manually add a file, do the following:

  1. Click the more options button (︙) next to any existing file or folder.
    The Add File dialog appears.
  2. Enter a file name and click SUBMIT. To add a folder at the same time, enter the folder name followed by the file name, such myfolder/service.yaml.

Now you can edit the file and paste in your manifest.

To add more files to that folder, use the same folder name when you create the files.

Uploading Manifest Files

You can upload files and folders. Once you have uploaded files and folder, you can manage them in the Manifests section.

Typically, when you add your own files to Manifests, you will also want to delete the default files.

To delete the default files, do the following:

  1. Click the more options button (︙) and click Delete All Manifest Files.

To upload your own manifest files, do the following:

  1. Click the more options button (︙) and click Upload Local Manifest Files.

The Upload Local Manifest Files dialog appears.

  1. Click Choose and select folders and files or drag and drop files into the dialog. If you select a folder, all subordinate folders and files are copied.
  2. Click SUBMIT. Your files are added to the Manifests section of the Service.

The files are added to the root folder. You can create folders and add the files into them as described below. Simply select a file, click the more options button (︙) and click Rename File. Add the folder name before the file name, using a forward slash, like folderA/filename.yaml. The file is moved into the folder.

Namespace Alternatives

You might have existing manifest files from other deployments that you want to add to your Manifests section, but you do not want to use the same namespace settings. You can remove existing namespace settings in the files you upload into Manifests by selecting the Remove hard-coded namespaces from resource metadata option in the Upload Local Manifest Files dialog.

The uploaded files will have their namespace key and value removed. Harness will use the namespace you enter in the Service Infrastructure/Infrastructure Definition Namespace field as the namespace for these manifests. Here is a Service Infrastructure with its Namespace field:

Here is an Infrastructure Definition with its Namespace field:

Infrastructure Definitions are a feature-flagged replacement for Service Infrastructure.

You can also use the expression namespace: ${infra.kubernetes.namespace} in your manifest files and Harness will use the namespace you enter in the Service Infrastructure/Infrastructure Definition Namespace field as the namespace for these manifests.

Another option is to add namespace: ${infra.kubernetes.namespace} in the values.yaml file and refer it in your manifest with namespace: {{ .Values.namespace }}.

Editing Files

To edit a file, do the following:

  1. Click the Edit button.
  2. Enter your YAML, and then click Save.
Harness validates the YAML in the editor at runtime.
Manage Files and Folders

To add, rename, or delete a file or folder in the Manifests section, do the following:

  1. Click the vertical ellipsis character  next to a folder or file. The file options appear.
  2. Click Add FileRename File, or DeleteFile. In this case, let's add a file. Click Add File. The Add File dialog appears.
  3. Enter the file name for the new file. To create a folder along with the file, include the new folder in the path, such as legacy/frontend.yaml.
  4. Click SUBMIT. The new file and folder are created.

To create your own folders and move files into them, do the following:

  1. Click the more options button (︙) and click Rename File. The Rename File dialog opens.
  2. Enter a folder name before the file name, including a forward slash, such as myfolder/.
  3. Click SUBMIT. The folder is created and the file is added to it.

To add other existing files to that folder, rename them and use the same folder name.

Harness Variables in Values File

You can use Harness built-in variables in the values.yaml file by entering $. The available variables are displayed:

Click the variables name and it will be added the values.yaml file with the required syntax.

Remote Configuration Files

You can use your Git repo for the configuration files in Manifests and Harness will use them at runtime. You have two options for remote files:

  • Standard Kubernetes Resources in YAML - These files are simply the YAML manifest files stored on a remote Git repo.
  • Helm Chart Source Files - These are Helm chart files stored in standard Helm syntax in YAML on a remote Git repo or Helm repo.

For steps on using a Helm Repository, see Helm Charts.

At runtime, the Harness Delegate pulls the remote configuration files from the repo and then uses them to create resources via the Kubernetes API. It does not matter if the Delegate runs in the same Kubernetes cluster as the deployed pods. The Kubernetes API is used by the Delegate regardless of the cluster networking topology.

You can also use a Git repo for your entire Harness Application, and sync it unidirectionally or bidirectionally. For more information, see  Configuration as Code. There is no conflict between the Git repo used for remote Manifests files and the Git repo used for the entire Harness Application.

To use remote configuration files, do the following:

  1. In Manifests, click the vertical ellipsis and click Use Remote Manifests.
    The Remote Manifests dialog appears.
  1. Fill out the Remote Manifests dialog and click SUBMIT. The Remote Manifests dialog has the following fields.
  • Manifest Format - Kubernetes Resource Specs in YAML formatHelm Chart from Helm RepositoryHelm Chart from Source Repository. For Helm Charts, see Helm Charts.
  • Source Repository or Helm Repository - Select a SourceRepo Provider for the Git repo you added to your Harness account. For more information, see  Add SourceRepo Providers.
  • Commit ID - Select Latest from Branch or Specific Commit ID.
  • Branch/Commit ID - Required. Enter the branch or commit ID for the remote repo.
  • File/Folder path(s) - Enter the repo file and folder path.
If you want to use Go templating in your remote repo for your configuration files in Manifests, ensure that the values.yaml file is at the root of the folder path you select.

When the remote manifests are added, the Manifests section displays the connection details.

When you deploy a Workflow or Pipeline that uses this Service, you can see the Delegate fetch the Manifests files from the repo in the Fetch Files section of the log Harness Deployments:

Fetching files from git

Git connector Url: https://github.com/michaelcretzman/harness-example # remote manifest files

Branch: example # Git repo branch

Fetching NGINX/values.yaml # values.yaml file in repo

Successfully fetched NGINX/values.yaml

Fetching manifest files at path: NGINX/ # manifest files in repo

Successfully fetched following manifest [.yaml] files:

- templates/spec.yaml # manifest file with ConfigMap and Deployment objects

Done.

If you experience errors fetching the remote files, it is most likely because the wrong branch has been configured in the Git Connector.

To return to local configuration files, click the vertical ellipsis and select Use Local Manifests.

Your remote files are not copied locally. You are simply presented with the local configuration files you used last.

Config Variables

You can create Service-level variables to use throughout your Service configuration settings.

To use service-level variables, do the following:

  1. In Configuration, in Config Variables, click Add Variable. The Config Variable dialog appears.
  2. In Name, enter a name for your variable. This is the name you will use to reference your variable anywhere in your Service.
  3. In Type, select Text or Encrypted Text. If you selected Text, enter a string in Value.
    If you select Encrypted Text, the Value field becomes a drop-down and you can select any of the Encrypted Texts you have configured in Harness Secrets Management.
    An Encrypted Text secret is available here only if its Usage Scope includes the current Application. For more information, see  Secret Management.
    You can also click Add New Encrypted Text to create a new secret. It will be stored in Secrets Management with this Application in its Usage Scope.
    You can also use Harness variables in the Value field. To use a variable, enter $ and see the available variables.

For example, to add artifact variables, enter ${artifact and the available artifact variables are displayed. For more information about variables, see  Variables and Expressions in Harness.

  1. Click SUBMIT. The variable is added to Config Variables.
  2. To reference the variable in your Manifest values.yaml file, type ${serviceVariable and Harness will provide a drop down list of all variables. Begin typing the name of your variable to find it and select it. Or you can simply type in ${serviceVariable and the variable name, like ${serviceVariable.test}.

For example, let's say you added the variable test to Config Variables.

To reference that variable in the values.yaml file, you would do this:

myvar: ${serviceVariable.test}
Secrets in Config Variables

When you select Encrypted Text as the option in the Config Variable dialog Type field, you can select one of the encrypted text secrets you have in the Harness vault. For information about adding encrypted text secrets to the Harness vault, see  Secrets Management.

Let's look at an example where a Config Variable named password has been added.

Here is how the values.yaml references the variable:

password: ${serviceVariable.password}

Here is how the values.yaml variable is used in a manifest file:

apiVersion: v1
kind: Secret
metadata:
name: sample
stringData:
password: {{.Values.password}}
type: Opaque
For encrypted text, Harness stores it in the Harness vault (or your vault) and uses it at runtime. You do not need to manage the secret outside of Harness. For more information, and to see where encrypted text is stored in Harness, see  Secrets Management.

Helm Charts

You can use remote Helm charts in a Git Repo or a Helm Repository.

Migrating from the Harness Helm Deployment Type? If you are migrating from a Harness Helm deployment type to the Kubernetes V2 deployment type, be aware that Helm charts in Kubernetes V2 require that you set up a Harness Helm Artifact Server to connect to your remote Helm chart repo.

Helm Client Only Mode: When you use a remote Helm chart you do not need to have Tiller installed on the Harness Delegate because Harness interacts directly with the Kubernetes API server to install, upgrade, query, and remove Kubernetes resources. The Helm client is used to fetch charts from the repository and render a template. Consequently, when you install Helm on the Harness Delegate pod you can use the client-only option, as described in Common Delegate Profile Scripts.

To use a Helm chart in a remote Git repo, follow the steps in  Remote Configuration Files.

To use a Helm Repo, do the following:

  1. Add a connection to the Helm repo in Harness as a Helm Repository Artifact Server. See  Helm Repository.
  2. In your Harness Kubernetes Service, in Manifests, click Use Remote Manifests.
    The Remote Manifests dialog appears.
  3. In Manifest Format, select Helm Chart from Helm Repository.
  4. In Helm Repository, select the Helm Repository Artifact Server you added to Harness.
  5. In Chart Name, enter the name of the chart in that repo. For example, we use nginx.
  6. In Chart Version, enter the chart version to use. This is found in the Chart.yaml version label. For this guide, we will use 1.0.1. If you leave this field empty Harness gets the latest chart.

When you are finished, the dialog will look like this:

Click SUBMIT. The Helm repo is added to Manifests.

When you deploy a Workflow using a Harness Kubernetes Service set up with a Helm Repository, you will see Harness fetch the chart:

Next, you will see Harness initialize using the chart:

Harness does not support the following objects when using Helm charts in Harness Kubernetes deployments: ClusterRoleBindingList, RoleBindingList, RoleList. If you use these objects in your chart, Harness will consider the chart invalid and fail the deployment.

Config Files

Files added in the Config Files section are referenced using the configFile.getAsString("fileName") Harness expression:

  • configFile.getAsString("fileName") - Plain text file contents.
  • configFile.getAsBase64("fileName") - Base64-encoded file contents.

For example, let's add a Config Files file named config-file-example.txt.

You would reference this file in the values.yaml file like this:

configFile.getAsString("config-file-example.txt")

Another example is having two Config Files entries that reference files in the Harness vault, one for a TLS certificate and one for a TLS key.

In the values.yaml file we could reference the files like this:

tlscrt: ${configFile.getAsBase64("tlscrt")}
tlskey: ${configFile.getAsBase64("tlskey")}

In a Kubernetes Secret specification file in Manifests, it will be used like this:

apiVersion: v1
kind: Secret
metadata:
name: sample
data:
tls.crt: {{.Values.tlscrt}}
tls.key: {{.Values.tlskey}}
type: kubernetes.io/tls

At runtime, Harness takes the encrypted file from its (or your) KMS vault and sends it to Kubernetes via the Kubernetes API. For more information, see  Secrets Management in Harness docs and  Secrets from Kubernetes.

Using Config Files in ConfigMaps

You can use files added to the Config Files in your Kubernetes ConfigMap manifest. You can reference encrypted files, and they can be single or multiline.

For encrypted files, you should use a secret created in Secrets Management.

Here is an example using an un encrypted file in a ConfigMap data property.

  1. First, add the unencrypted file to Config Files. In this example, the file is a base64 encoded file named myFile.
    The base64 encoded file will be decoded when we add it to the manifest, as shown below.
  2. In the values.yaml in the Harness Service Manifests section, reference the encrypted Config File: my_file: ${configFile.getAsBase64("myFile")}.
  3. In the ConfigMap manifest, decode the base64 Config File and indent it for the YAML syntax:
data:
keyname: |
{{.Values.my_file | b64dec | indent 4}}

At runtime, the Config File is decoded and used as plaintext.

Values YAML Override

In the Values YAML Override section, you can enter the YAML for your values.yaml file that overrides a remote manifest file or remote Helm chart file.

You can override the values using the Local or Remote options.

For Remote, do the following:

  1. In Source Repository, select the Git repo you added as a  Source Repo Provider.
  2. For Commit ID, select either Latest from Branch and enter in the branch name, or Specific Commit ID and enter in the commit ID.
  3. In File path, enter the path to the values.yaml file in the repo, including the repo name, like helm/values.yaml.

Values in Services can also be overwritten in Harness Environments. For more information, see  Override Service Settings.

Next Step


How did we do?