Tolerations

TELEMETRY PIPELINE

Tolerations

Tolerations and taints (opens in a new tab) are Kubernetes features that lets you control which nodes your pipelines run on. You can use tolerations to schedule your pipelines on Kubernetes nodes with matching taints.

In Chronosphere Telemetry Pipeline, you can set tolerations for Core Instances and for individual pipelines. Any tolerations set for a Core Instance apply to all pipelines within that Core Instance, but tolerations set for an individual pipeline override any tolerations set for its parent Core Instance.

To set corresponding taints on nodes, use the kubectl taint (opens in a new tab) command.

Toleration parameters

Tolerations in Chronosphere Telemetry Pipeline use the following parameters:

Parameter	Description
`key`	Required for tolerations with the `Equal` operator. The key to evaluate against matching taints. If a toleration with the `Equal` operator omits this parameter, that toleration will match all keys and values.
`operator`	Required. The operator that determines whether a toleration matches a taint. Possible values are `Equal` and `Exists`. `Equal`: The toleration matches a taint if the taint has a key/value pair identical to the toleration’s `key` and `value` parameters. `Exists`: The toleration matches a taint if the taint has a key with the same name as the toleration’s `key` parameter.
`value`	Required for tolerations with the `Exists` operator, but must be omitted for tolerations with the `Equal` operator. The value to evaluate against matching taints.
`effect`	Required. The effect to evaluate against matching taints. Possible values are `NoSchedule`, `PreferNoSchedule`, and `NoExecute`. `NoSchedule`: Except for pods with a matching toleration, no new pods will be scheduled onto nodes with this taint. `PreferNoSchedule`: The scheduler will try to avoid placing new non-matching pods on nodes with this taint. `NoExecute`: Pods that are already running on a node will be evicted if they don’t have a matching toleration, and pods with a matching toleration will be evicted after the duration of `tolerationSeconds`, if set.
`tolerationSeconds`	For tolerations with the `NoExecute` effect, defines how long (in seconds) pods with a matching toleration will remain bound before being evicted. If this parameter is omitted, pods with a matching toleration will remain bound indefinitely.

Pipeline tolerations

Use the following information to modify tolerations for individual pipelines.

Set tolerations for a pipeline

To set tolerations for a new pipeline:

Create a JSON file with your toleration specifications.
Use Pipeline CLI to either create a pipeline or modify a pipeline, and add the following flag to the associated command:
```
 --tolerations-spec FILE
```
Replace FILE with the path to your tolerations JSON file.

Remove tolerations from a pipeline

To remove tolerations from a pipeline:

Create a JSON file with an empty array ([]).
Use Pipeline CLI to modify a pipeline, and add the following flag to that command:
```
 --tolerations-spec EMPTY-ARRAY
```
Replace EMPTY-ARRAY with the path to your JSON file with an empty array.

Core Instance tolerations

Use one of these methods to set tolerations for a Core Instance.

Pipeline CLI lets you specify tolerations for new Core Instances. However, you can’t use Pipeline CLI to add or modify tolerations for an existing Core Instance.

To specify tolerations for a new Core Instance, use the --tolerations flag:

calyptia create core_instance operator --name INSTANCE --tolerations STRING

Replace the following values:

INSTANCE: The name for your new Core Instance.
STRING: The string that specifies your tolerations.

Toleration string syntax

The string that specifies your tolerations must follow this syntax:

key1=operator:value1:effect:tolerationSeconds,key2=operator:value2:effect:tolerationSeconds

You can also leave certain sections of this string blank to omit certain toleration parameters as permitted. For example, foo=Exists::PreferNoSchedule is a valid toleration string.

Because tolerationSeconds isn’t a required parameter and only applies to the NoExecute effect, you can omit the :tolerationSeconds portion of this syntax as necessary. [info about tolerations with an empty key? or with an empty effect?] Additionally, tolerations with the Exists operator must omit the value portion of this syntax but retain its preceding colon.

For example, this is a valid toleration string:

foo=Equal:bar:NoExecute:3600,baz=Exists::PreferNoSchedule

Toleration JSON syntax

Per-pipeline tolerations require Chronosphere Telemetry Pipeline v2.34.0 or later.

The JSON file that specifies your tolerations must follow this syntax:

[
  {
    "key": "abc",
    "operator": "abc",
    "value": "abc",
    "effect": "abc",
    "tolerationSeconds": 123
  },
  {
    "key": "xyz",
    "operator": "xyz",
    "value": "xyz",
    "effect": "xyz",
    "tolerationSeconds": 456
  }
]

Each toleration must be a structured object, and multiple tolerations must be stored as items within an array of structured objects. If a specific toleration doesn’t need a particular parameter, omit that parameter entirely.

For example, this is a valid toleration JSON file:

tolerations.json

[
  {
    "key": "foo",
    "operator": "Equal",
    "value": "bar",
    "effect": "NoExecute",
    "tolerationSeconds": 3600,
  },
  {
    "key": "baz",
    "operator": "Exists",
    "effect": "PreferNoSchedule"
  }
]

Sidecars Metadata