Protocols for Services

    Kubernetes supports the following protocols with Services:

    • TCP (the default)

    When you define a Service, you can also specify the application protocol that it uses.

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

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

    FEATURE STATE: Kubernetes v1.20 [stable]

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

    Support for multihomed SCTP associations

    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

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

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

    Special cases

    HTTP

    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 (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.

    You might additionally want to specify that the application protocol of the connection is http or . 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.

    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.

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

    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

    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 and the load balancer is the TLS server peer. The connection from the load balancer to your workload can also be TLS, or might be plain text. The exact options available to you depend on your cloud provider or custom Service implementation.