> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chronosphere.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Networking

Use the information on this page to configure different networking settings in
Chronosphere Telemetry Pipeline.

## Ports

Pipelines use various ports (also referred to as *endpoints*) to send and
receive data. These ports correspond to different components of each pipeline.

### View pipeline ports

To view a list of open ports for a pipeline, use the following command:

```shell theme={null}
calyptia get endpoints --pipeline PIPELINE
```

Replace *`PIPELINE`* with the name or
[unique ID](/ingest/pipeline/v2/configure/metadata#get-pipeline-ids) of your pipeline.

Each item in the resulting list includes a protocol type,
[a frontend port, and a backend port](#frontend-and-backend-ports).

### Plugins

Most [source plugins](/ingest/pipeline/plugins/source-plugins) and some
[destination plugins](/ingest/pipeline/plugins/destination-plugins) expose
an associated port. Plugins that expose a port will set a default value for that
port, but you can override this value when you configure plugins through the
Telemetry Pipeline web interface or through
[pipeline configuration files](/ingest/pipeline/v2/configure/config-files).

### Health check pipelines

By default, the [health check pipeline](/ingest/pipeline/v2/concepts#health-check-pipeline)
within each Core Instance exposes an HTTP server on TCP port `2020`.

### Frontend and backend ports

Each pipeline component uses a triplet that consists of a frontend port, a backend
port, and a protocol type. Frontend ports are exposed externally and let pipelines
communicate with different services to send and receive telemetry data. Backend
ports are only used within a pipeline's internal Kubernetes infrastructure to forward
traffic to pods.

When you set a port number for a pipeline component, the same port number is
applied to both the frontend and backend ports for that component. These frontend
and backend port numbers stay in sync unless a conflict triggers
[automatic reassignment](#automatic-reassignment) for the frontend port.

#### Uniqueness

Within a single pipeline, each backend port must use a unique port number and protocol.
Within a [Core Instance](/ingest/pipeline/v2/concepts#core-instance), backend ports can
overlap across the pipelines associated with that Core Instance, but each frontend port
in the Core Instance must use a unique port number and protocol. However, different
components or pipelines can share a port number if one port uses TCP and the other uses UDP.

For example, two pipelines associated with the same Core Instance can't both have plugins
that expose TCP port `1600`, but Pipeline A can expose TCP port `1600` and Pipeline
B can expose UDP port `1600`. Similarly, Pipeline C can't have two different plugins
that expose TCP port `1850`, but it can have one plugin that exposes TCP port `1850`
and another plugin that exposes TCP port `1851`.

#### Automatic reassignment

If two pipeline components associated with the same Core Instance try to claim the same port,
Telemetry Pipeline resolves this conflict by reassigning the
[frontend port](#frontend-and-backend-ports) of the newer component to a different
port number.

This reassignment process increments the frontend port number of the newer
component by one until it finds a non-conflicting port. For example, if Pipeline
B has a plugin whose frontend and backend port are set to TCP port `2200`, but
that port number is already in use by Pipeline A, Telemetry Pipeline will attempt
to reassign the frontend port of Pipeline B's plugin to TCP port `2201`. If TCP
port `2201` is also already in use, Telemetry Pipeline will attempt to reassign
the frontend port to TCP port `2202` instead.

As a result of this reassignment process, a component can have a different frontend
port number and backend port number. In the previous example, if Telemetry Pipeline
successfully reassigned Pipeline B's plugin on the first attempt, then that plugin's
frontend port number would be `2201` and its backend port number would still be `2200`.

## Proxies

Use the information in this section to configure proxies in Telemetry Pipeline.

<Note>
  Configuring a proxy affects all pipelines associated with the specified
  [Core Instance](/ingest/pipeline/v2/concepts#core-instance).
</Note>

### Configure a proxy between pipelines and their connected services

You can set up an HTTPS proxy between your pipelines and their connected
services, such as sources and destinations. To do so, use the following command:

```shell copy /INSTANCE/ /PROXY/ theme={null}
calyptia update core_instance operator INSTANCE --https-proxy "PROXY"
```

Replace the following values:

* *`INSTANCE`*: The name of the Core Instance associated with your pipelines.
* *`PROXY`*: The proxy to use (for example, `http://localhost:3128`).

You can also specify an HTTP proxy with the `--http-proxy` flag.

### Configure a proxy between pipelines and the Telemetry Pipeline backend

You can set up a proxy between your pipelines and the Chronosphere Telemetry
Pipeline backend. To do so, use the following command:

```shell copy /INSTANCE/ /PROXY/ theme={null}
calyptia update core_instance operator INSTANCE --cloud-proxy "PROXY"
```

* *`INSTANCE`*: The name of the Core Instance associated with your pipelines.
* *`PROXY`*: The proxy to use (for example, `http://localhost:3128`).

## Service types

Each pipeline uses one of the available
[Kubernetes Service](https://kubernetes.io/docs/concepts/services-networking/service/)
types. The Service types supported by Telemetry Pipeline are:

* [`ClusterIP`](https://kubernetes.io/docs/concepts/services-networking/service/#type-clusterip)
* [`LoadBalancer`](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer)
* [`NodePort`](https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport)

### Create a pipeline with a specific Service type

When [creating a pipeline](/ingest/pipeline/v2/build/create-modify#create-a-pipeline),
use the `--service-type` flag to specify its Service type:

```shell theme={null}
calyptia create pipeline --name PIPELINE --core-instance INSTANCE --service-type TYPE
```

Replace the following values:

* *`PIPELINE`*: A short name you'd like to give your pipeline.
* *`INSTANCE`*: The name of your Core Instance.
* *`TYPE`*: The Service type for your pipeline (`ClusterIP`, `LoadBalancer`, or
  `NodePort`).

<Note>
  If you don't specify a Service type, new pipelines use the `LoadBalancer` Service
  by default.
</Note>

### Modify the Service type of an existing pipeline

To modify the Service type of an existing pipeline, use the following command:

```shell theme={null}
calyptia update pipeline PIPELINE --service-type TYPE
```

Replace the following values:

* *`PIPELINE`*: The name or [unique ID](/ingest/pipeline/v2/configure/metadata#get-pipeline-ids)
  of your existing pipeline.
* *`TYPE`*: The Service type for your pipeline (`ClusterIP`, `LoadBalancer`, or
  `NodePort`).

<Note>
  Modifying a pipeline's Service type affects all [ports](/ingest/pipeline/v2/configure/networking#ports)
  within that pipeline.
</Note>
