> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/harness-platform/use-harness-platform/service-discovery.md).

# Service Discovery

This topic introduces you to **service discovery** for **Kubernetes infrastructure**, its significance, and its purpose.

#### What is a discovered service? <a href="#what-is-a-discovered-service" id="what-is-a-discovered-service"></a>

Discovered service is an entity on the Harness platform (also known as the control plane) that corresponds to a Kubernetes service on your (user) cluster. It includes details about the connections made from and to it.

Below is the control flow to a discovered service.

![](/files/pgC4NEaCBNClcEG6fkED)

#### Why is a discovered service required? <a href="#why-is-a-discovered-service-required" id="why-is-a-discovered-service-required"></a>

Large enterprises deal with hundreds of deployed services. Monitoring these services on these services would require building a database of these services and the relationship between these services, which is time-consuming. Service discovery comes into the picture: Instead of creating a database with the services, **automatically discover services** and the relationship between them.

#### How does Harness discover services? <a href="#how-does-harness-discover-services" id="how-does-harness-discover-services"></a>

Harness performs the following steps to discover services in your cluster:

1. Scan your Kubernetes cluster periodically (you can define the interval or ad-hoc).
2. Build a database of services that describes the relationship between the services.
3. Provide APIs to group the discovered services into a map, wherein the map represents a topological view of an application.

Service discovery leverages the standard Kubernetes API for workload identification and eBPF (extended Berkeley Packet Filter) to analyze real-time network traffic between workloads using kprobe hooks. These open-source technologies enable efficient monitoring and visualization of service-to-service communication within a Kubernetes cluster.

#### How does Harness leverage discovered services? <a href="#how-does-harness-leverage-discovered-services" id="how-does-harness-leverage-discovered-services"></a>

* Identify the various available services in the Kubernetes cluster that you can deploy using Harness or other means.
* Record the resources backing the above services (logical resources such as deployment, pods, containers, processes, FQDNs, ports, physical resources such as nodes, storage, and so on).
* Highlight the given service's position and the lineage within the topology view.

{% hint style="info" %}
You can leverage all the [permissions mentioned](/resilience-testing/chaos-engineering/security/security-templates/openshift-scc.md#run-service-account-as-a-cluster-admin) for service discovery.
{% endhint %}

#### Advantages <a href="#advantages" id="advantages"></a>

* Reduces overhead of creating a database with services
* User-friendly
* Increased adoption of Harness

When you are onboarding, one of the steps involves discovering services. Harness creates the discovery agent that automatically discovers services for your application.

### Next Steps <a href="#next-steps" id="next-steps"></a>

* [Customize Discovery Agent](/harness-platform/use-harness-platform/service-discovery/customize-agent.md)