4 - Kubernetes Environments

Updated 1 day ago by Michael Cretzman

Once you've added a Kubernetes-type Service to your Application, you can define Environments where your Service can be deployed.

Create a New Harness Environment

In an Environment, you specify the following:

  • A Harness Service, such as a Service with a Docker image artifact you configured.
  • A deployment type, such as Kubernetes.
  • A Cloud Provider, such as a Kubernetes cluster or Google Cloud Platform that you added in Add Cloud Providers.

An environment can be a Dev, QA, Production, or other environment. You can deploy one or many Services to each environment.

The following procedure creates an Environment for the Service (Kubernetes type) we set up.

  1. In your Harness Application, click Environments. The Environments page appears.
  2. Click Add Environment. The Environment dialog appears.
  3. In Name, enter a name that describes the deployment environment, for example, K8s-GCP.
  4. In Environment Type, select Non-Production.
  5. Click SUBMIT. The new Environment page appears.

Add an Infrastructure Definition

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

​Infrastructure Definitions specify the target deployment infrastructure for your Harness Services, and the specific infrastructure details for the deployment, like cluster settings. 

You define the Kubernetes cluster to use for deployment as an ​Infrastructure Definition.

To add the Infrastructure Definition, do the following:

  1. In the Harness Environment, click Add Infrastructure Definition. The Infrastructure Definition dialog appears.
  2. In Name, enter the name you will use to select this Infrastructure Definition when you create a Workflow.
  3. In Cloud Provider Type, select Kubernetes Cluster, or a type that supports Kubernetes like Google Cloud Platform.
  4. In Deployment Type, select Kubernetes.
  5. Click Use Already Provisioned Infrastructure. If you were using a Harness Infrastructure Provisioner, you would select Map Dynamically Provisioned Infrastructure.
  6. In Cloud Provider, select the Cloud Provider you added earlier, such as Kubernetes Cluster or  Google Cloud Platform, etc.
  7. If you selected a non-Kubernetes Cluster type, In Cluster Name, select the Kubernetes cluster where you want to deploy. This list is populated using the Cloud Provider you selected.
  8. In Namespace, enter the name of the cluster namespace you want to use. As we noted in Values YAML Override and Example 4: Creating Namespace based on Environment InfraMapping, you can enter a ${NAMESPACE} variable in your Service and Harness will replace it with the value you enter in Namespace at runtime.
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  Infrastructure Definition settings Namespace field.
  1. In Release Name, enter a release name for tracking or simply leave the default release-${infra.kubernetes.infraId}. Harness requires a Kubernetes release name for tracking and stores all metadata in a ConfigMap named with the release name. The release name must be unique across the cluster. The Harness-generated unique identifier ${infra.kubernetes.infraId} can be used as a suffix to ensure a unique release name.
  2. In Scope to specific Services, select the Harness Service you created earlier.
    The Infrastructure Definition will look something like this:

  1. Click Submit. The new Infrastructure Definition is added to the Harness Environment.

That is all you have to do to set up the deployment Environment in Harness.

Now that you have the Service and Environment set up. Now you can create the deployment Workflow in Harness.

Add a Service Infrastructure

Harness now uses Infrastructure Definitions (which are a feature-flagged replacement for Service Infrastructure).

You define the Kubernetes cluster to use for deployment as a Service Infrastructure.

To add a service infrastructure, do the following:

  1. In the Harness Environment, click Add Service Infrastructure. The Service Infrastructure dialog appears.
  2. In Service, select the Harness service you created earlier for your Docker image.
  3. In Cloud Provider, select the Cloud Provider you added earlier. If your Cloud Provider is a Kubernetes Cluster, then you will not need to select a cluster in the Configuration section.
  4. Click Next. For platform Cloud Providers like Azure and GCP, the Configuration section is automatically populated with the clusters located using the Cloud Provider connection. If the Cluster Name drop-down is taking a long time to load, check the connectivity to the Cloud Provider of the host running the Harness Delegate.
  5. In Cluster Name, select the cluster you created for this deployment. If you are using the Delegate to authenticate the Cloud Provider, the cluster is already listed.
  6. In Namespace, enter the namespace of the Kubernetes cluster. Typically, this is default.

The namespace entered in Namespace must already exist during deployment. Harness will not create a new namespace if you enter one here. You must define the Kubernetes Namespace object in a manifest in the Service Manifests section. You can use the Harness variable ${infra.kubernetes.namespace} to reference the value you entered in the Service Infrastructure Namespace field. For example, namespace: ${infra.kubernetes.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 settings Namespace field.

This setup is described in Example 4: Creating Namespace based on Environment InfraMapping.

  1. In Release Name, enter a release name for tracking or simply leave the default release-${infra.kubernetes.infraId}. Harness requires a Kubernetes release name for tracking and stores all metadata in a ConfigMap named with the release name. The release name must be unique across the cluster. The Harness-generated unique identifier ${infra.kubernetes.infraId} can be used as a suffix to ensure a unique release name.

When you are finished with the Configuration section, the dialog will look something like this:

  1. Click SUBMIT. The new service infrastructure is added to the Harness environment.

That is all you have to do to set up the deployment Environment in Harness. You have the Service and deployment Environment set up. Now you can create the deployment Workflow in Harness.

Override Service Settings

Your Environment can overwrite Service Config VariablesConfig Files, and values.yaml settings. This enables you to have a Service keep its settings but have them changed when used with this Environment. For example, you might have a single Service but an Environment for QA and an Environment for Production, and you want to overwrite the namespace setting in the Service depending on the Environment.

You can also overwrite Service variables at the Phase-level of a multiple Phase Workflow.

To override a Service setting, do the following:

  1. In the Harness Environment, in the Service Configuration Overrides section, click Add Configuration Overrides. The Service Configuration Override dialog appears.
  2. In Service, select the Service you are using for your Kubernetes deployment. The override types appear.
  3. Click Variable Override. The Variable Override options appear.
    1. In Configuration Variable, select a variable configured in the Service's Config Variables settings.
    2. In Type, select Text or Encrypted Text.
    3. In Override Value, enter the value to overwrite the variable value in the Service. If you selected Encrypted Text in Type, you can select an Encrypted Text values defined in Secrets Management.
  4. Click File Override.
    1. In File Name, select a file configured in the Service's Config Files settings.
    2. In File, select the file to overwrite the Service's Config Files file.
  5. Click Values YAML. Click Local or Remote.
    1. Local - Enter in the values.yaml variables and values just as your would in a Service Manifests values.yaml. Ensure the name of the variable you want to overwrite is identical.
    2. Remote - Specify the Git repo branch and folder for the remote manifest files to use, as explained in Remote Configuration Files.

Here is an example of overwriting a Service values.yaml with a Service Configuration Override.

In the Service values.yaml, we have a variable for replicas:

replicas: 1

This is used in the manifest file like this:

...
spec:
replicas: {{int.Values.replicas}}
...

Now, in Service Configuration Override, you can overwrite the Service values.yaml replicas value:

At deployment runtime to this Environment, the overwritten replicas values is used:

kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3

Next Step


How did we do?