11 - Versioning and Annotations

Updated 2 weeks ago by Michael Cretzman

This topic covers how Harness tracks Kubernetes deployment releases and the labels Harness applies during deployments.

Releases and Versioning

Every Harness deployment creates a new release with an incrementally increasing number. Release history is stored in the Kubernetes cluster in a ConfigMap. This ConfigMap is essential for release tracking, versioning and rollback.

By default, all the ConfigMap and Secrets resources are versioned by Harness. Corresponding references in PodSpec are also updated with versions.

You can see the use of release numbers and versioning in the Deployments page details:

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
Versioning does not change how you use Secrets. You do not need to reference versions when using Secrets.

For cases where versioning is not required, the manifest entered in the Harness Service Manifests section should be annotated with harness.io/skip-versioning: true.

For example. you might want to skip versioning is for an ImagePullSecret because it never changes, or for TLS certs if they are referred in a Kubernetes container cmd args.

Harness also uses a release name for tracking releases. You can supply a release name in an Environment's Service Infrastructure Release Namefield. By default, the value Harness uses is release-${infra.kubernetes.infraId}.

Harness Annotations and Labels

Harness applies labels during Kubernetes deployment that you can use to select objects you defined in your Harness Service Manifests section. Annotations are a way to pass additional metadata for resources to Harness. For a description of Annotations, see Annotations from Kubernetes.

Annotations

The following Annotations can be put on resource specifications in the Harness Service Manifests section.

Annotation

Value

Usage

harness.io/skip-versioning

true|false

To exclude versioning of a resource (ConfigMap or Secret).

harness.io/direct-apply

true|false

If more than one workload is present in the Service Manifests files, use this annotation to exclude all but one.

harness.io/primary-service

true|false

Identifies the primary Kubernetes service in a Blue/Green deployment.

harness.io/stage-service

true|false

Identifies the Kubernetes stage service in a Blue/Green deployment.

Labels

The following labels are applied by Harness during deployment.

Label

Value

Usage

harness.io/release-name

release name

Applied on pods. Harness uses a release name for tracking releases, rollback, etc. You can supply a release name in an Environment's Service Infrastructure Release Name field.

By default, the value Harness uses is release-${infra.kubernetes.infraId}.

harness.io/track

canary|stable

Applied on pods in a Canary deployment.

harness.io/color

blue|green

Applied on pods in a Blue/Green deployment.


How did we do?