Protocols for Services [page]deterministic

referencenetworking

If you configure a [Service](#gloss:service), you can select from any network protocol that Kubernetes supports.

Kubernetes supports the following protocols with Services:

[`SCTP`](#protocol-sctp)
[`TCP`](#protocol-tcp) _(the default)_
[`UDP`](#protocol-udp)

When you define a Service, you can also specify the [application protocol](/docs/concepts/services-networking/service/#application-protocol) that it uses.

This document details some special cases, all of them typically using TCP as a transport protocol:

[HTTP](#protocol-http-special) and [HTTPS](#protocol-http-special)
[PROXY protocol](#protocol-proxy-special)
[TLS](#protocol-tls-special) termination at the load balancer

## Supported protocols {#protocol-support}

There are 3 valid values for the `protocol` of a port for a Service:

### `SCTP` {#protocol-sctp}

When using a network plugin that supports SCTP traffic, you can use SCTP for most Services. For `type: LoadBalancer` Services, SCTP support depends on the cloud provider offering this facility. (Most do not).

SCTP is not supported on nodes that run Windows.

#### Support for multihomed SCTP associations {#caveat-sctp-multihomed}

The support of multihomed SCTP associations requires that the CNI plugin can support the assignment of multiple interfaces and IP addresses to a Pod.

NAT for multihomed SCTP associations requires special logic in the corresponding kernel modules.

### `TCP` {#protocol-tcp}

You can use TCP for any kind of Service, and it's the default network protocol.

### `UDP` {#protocol-udp}

You can use UDP for most Services. For `type: LoadBalancer` Services, UDP support depends on the cloud provider offering this facility.

## Special cases

### HTTP {#protocol-http-special}

If your cloud provider supports it, you can use a Service in LoadBalancer mode to configure a load balancer outside of your Kubernetes cluster, in a special mode where your cloud provider's load balancer implements HTTP / HTTPS reverse proxying, with traffic forwarded to the backend endpoints for that Service.

Typically, you set the protocol for the Service to `TCP` and add an [annotation](#gloss:annotation) (usually specific to your cloud provider) that configures the load balancer to handle traffic at the HTTP level. This configuration might also include serving HTTPS (HTTP over TLS) and reverse-proxying plain HTTP to your workload.

> Note: You can also use an to expose HTTP/HTTPS Services.

You might additionally want to specify that the [application protocol](/docs/concepts/services-networking/service/#application-protocol) of the connection is `http` or `https`. Use `http` if the session from the load balancer to your workload is HTTP without TLS, and use `https` if the session from the load balancer to your workload uses TLS encryption.

### PROXY protocol {#protocol-proxy-special}

If your cloud provider supports it, you can use a Service set to `type: LoadBalancer` to configure a load balancer outside of Kubernetes itself, that will forward connections wrapped with the [PROXY protocol](https://www.haproxy.org/download/2.5/doc/proxy-protocol.txt).

The load balancer then sends an initial series of octets describing the incoming connection, similar to this example (PROXY protocol v1):

``` PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n ```

The data after the proxy protocol preamble are the original data from the client. When either side closes the connection, the load balancer also triggers a connection close and sends any remaining data where feasible.

Typically, you define a Service with the protocol to `TCP`. You also set an annotation, specific to your cloud provider, that configures the load balancer to wrap each incoming connection in the PROXY protocol.

### TLS {#protocol-tls-special}

If your cloud provider supports it, you can use a Service set to `type: LoadBalancer` as a way to set up external reverse proxying, where the connection from client to load balancer is TLS encrypted …(trimmed)