How Harness tracks service instances in the Services dashboard

Harness Experts
1

16d12d54b3b4ae7aabc8a93417570bce0984e3c9
This article explains how service instances in Service dashboard works. Intended only for NextGen.

imageimage

Introduction

Services represent your microservices and other workloads. It contains definitions that list your deployment artifacts, manifests or specifications, configuration files, and Service-specific variables. This topic will detail how Harness considers a workload as an instance and the conditions for that.

Service instances

Harness licensing is determined by the service instances you deploy. A service instance is when you use Harness to deploy the underlying infrastructure for the instance. For example, an instance of a Kubernetes workload where Harness creates the pods.

How Harness tracks service instances

This may depend on the deployment type. Where the overall logic would be similar, how we detect active instances will depend on the deployment type.

Kubernetes

  1. During a deployment for any managed workload (ex: Deployment, DeploymentConfig, StatefulSet), we’re adding to the pod templates label harness.io/release-name: <release name from infra definition> (For native helm, the label will be release: <release name> and is not automatically handled and should be manually added, but is a common pattern for helm users).
  2. After deployment is done, we fetch all the pods that match a specific label (harness.io/release-name for Kubernetes and release for native helm) and detect namespaces used for managed workloads.
  3. Pods from the deployment will be mapped as 1:1 as the active instances, which would be the initial active instances.
  4. If this is the first time deployment, a scheduled task will be created (internally called Perpetual Task) that will run every 10 minutes on one of the eligible delegates (Only in case there are any active instances after deployment).
  5. Perpetual task every 10 minutes will fetch active pods from the Kubernetes cluster matching release label and previously found namespace and send back to our manager service
  6. Once the response from the perpetual task is received by our manager service, we will check if the service or environment still exists; otherwise, we will stop tracking instances by deleting Perpetual Task and any other related metadata.
  7. If the service or environment still exists, then we will find the current active instance (in our database) and compare it with the instances we’ve received from Perpetual Task (actual state of pods in the Kubernetes cluster). Instances will be compared based on: pod name, namespace, and container image.
  8. Any instances that do exist in current active instances but don’t exist in the instances received from Perpetual Task will be deleted.
  9. Any instances that do exist in instances received from Perpetual Task but don’t exist in the current active instances will be added as a new instance.
  10. Intersection between these two sets (instances that exist in both current active instances and instances from Perpetual Task) will be updated with actual data.

Conclusion

If you have any suggestions on how to improve this article, or helpful and specific examples of permissions related issues that may be of use to others, please leave a comment with the information as this document is intended to evolve over time.
If this article cannot resolve your issue, don’t hesitate to contact us here: support@harness.io – or through the Zendesk portal in Harness SaaS.

Credits to Alexandru Bosii for the detailed explanation of how Harness considers service instances.

2 Likes