4 - Kubernetes Environments

Updated 2 weeks 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. 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.

Create a New Harness 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 a 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.
  4. Click Next. 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, select 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.

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 Service Infrastructure 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:

INFO   2019-02-15 11:32:44    kind: Deployment
INFO 2019-02-15 11:32:44 metadata:
INFO 2019-02-15 11:32:44 name: nginx-deployment
INFO 2019-02-15 11:32:44 labels:
INFO 2019-02-15 11:32:44 app: nginx
INFO 2019-02-15 11:32:44 spec:
INFO 2019-02-15 11:32:44 replicas: 3


How did we do?