> For the complete documentation index, see [llms.txt](https://docs.groundcover.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.groundcover.com/collect-data/customize-deployment/configuring-sensor-deployment-coverage.md).

# Configuring sensor Deployment on Kubernetes

groundcover's sensors are required to be running on every node for it to be monitored. By default, the sensor will be included across all installed clusters with the exception of fargate nodes.

{% hint style="info" %}
When installing groundcover using the CLI, detected taints will be displayed and a prompt for adding appropriate tolerations will be displayed.
{% endhint %}

## Tolerations

When installing groundcover using the CLI, detected taints will be displayed and a prompt for adding appropriate tolerations will be displayed.

Otherwise, the following configuration values are used by default, which allow our sensor to run on all nodes.

```yaml
agent:
  tolerations: 
   - operator: "Exists"
```

This allows sensors to tolerate all taints, which may sometimes be problematic. For example, tolerating `node.kubernetes.io/not-ready` may cause sensors to restart until the node becomes ready. If this is a problem in your case, you may replace this configuration with a list of specific tolerations that match your environment. To do so, consult [these](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) docs.

You can control where other groundcover components are scheduled by configuring nodeSelector and tolerations in your values.yaml.

This is useful when you want to run observability workloads on dedicated nodes.

```yaml
vector:
  nodeSelector:
    <label-key>: <label-value>

  tolerations:
    - key: "<taint-key>"
      operator: "Equal"   # or "Exists"
      value: "<taint-value>"   # omit if operator is "Exists"
      effect: "NoSchedule"     # or "PreferNoSchedule", "NoExecute"
```

The relevant sections for the non-backend components of groundcover that can be configured in a similar way are: `vector`, `k8sWatcher`, `kube-state-metrics`, `custom-metrics`, `metrics-ingester`, `victoria-metrics-agent`

Example:

```yaml
k8sWatcher:
  nodeSelector:
    node-role: observability

  tolerations:
    - key: "dedicated"
      operator: "Equal"
      value: "observability"
      effect: "NoSchedule"
```

## Affinity

By default, we prevent the sensor from attempting to start on fargate nodes, with the affinity configuration:

```yaml
agent:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions: # prevent sensor from starting on fargate
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - fargate
        - matchExpressions: # prevent sensor from starting on control plane nodes
          - key: "node-role.kubernetes.io/control-plane"
            operator: "DoesNotExist"
```

## Priority Class

It's recommended for sensor to have a high priority class so that it's scheduled before other pods, providing full visibility into the startup of the entire environment.

The default priority class is relatively high (yet lower than default node and cluster critical priority class), and can be configured. The default is shown below:

```yaml
priorityClass:
  create: true
  fullname:
  value: 1000000000
  preemptionPolicy: PreemptLowerPriority
```

{% hint style="info" %}
Exceptions can be set by overriding the above values.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.groundcover.com/collect-data/customize-deployment/configuring-sensor-deployment-coverage.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.