Using Source IP [page]deterministic

tutorials

Applications running in a Kubernetes cluster find and communicate with each other, and the outside world, through the Service abstraction. This document explains what happens to the source IP of packets sent to different types of Services, and how you can toggle this behavior according to your needs.

### Terminology

This document makes use of the following terms:

If localizing this section, link to the equivalent Wikipedia pages for the target localization.

[NAT](https://en.wikipedia.org/wiki/Network_address_translation) : Network address translation

[Source NAT](https://en.wikipedia.org/wiki/Network_address_translation#SNAT) : Replacing the source IP on a packet; in this page, that usually means replacing with the IP address of a node.

[Destination NAT](https://en.wikipedia.org/wiki/Network_address_translation#DNAT) : Replacing the destination IP on a packet; in this page, that usually means replacing with the IP address of a [pod](#gloss:pod)

[VIP](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies) : A virtual IP address, such as the one assigned to every [Service](#gloss:service) in Kubernetes

[kube-proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies) : A network daemon that orchestrates Service VIP management on every node

### Prerequisites

The examples use a small nginx webserver that echoes back the source IP of requests it receives through an HTTP header. You can create it as follows:

The image in the following command only runs on AMD64 architectures.

```shell kubectl create deployment source-ip-app --image=registry.k8s.io/echoserver:1.10 ``` The output is: ``` deployment.apps/source-ip-app created ```

* Expose a simple application through various types of Services * Understand how each Service type handles source IP NAT * Understand the tradeoffs involved in preserving source IP

## Source IP for Services with `Type=ClusterIP`

Packets sent to ClusterIP from within the cluster are never source NAT'd if you're running kube-proxy in [iptables mode](/docs/reference/networking/virtual-ips/#proxy-mode-iptables), (the default). You can query the kube-proxy mode by fetching `http://localhost:10249/proxyMode` on the node where kube-proxy is running.

```console kubectl get nodes ``` The output is similar to this: ``` NAME STATUS ROLES AGE VERSION kubernetes-node-6jst Ready <none> 2h v1.13.0 kubernetes-node-cx31 Ready <none> 2h v1.13.0 kubernetes-node-jj1t Ready <none> 2h v1.13.0 ```

Get the proxy mode on one of the nodes (kube-proxy listens on port 10249): ```shell # Run this in a shell on the node you want to query. curl http://localhost:10249/proxyMode ``` The output is: ``` iptables ```

You can test source IP preservation by creating a Service over the source IP app:

```shell kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080 ``` The output is: ``` service/clusterip exposed ``` ```shell kubectl get svc clusterip ``` The output is similar to: ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE clusterip ClusterIP 10.0.170.92 <none> 80/TCP 51s ```

And hitting the `ClusterIP` from a pod in the same cluster:

```shell kubectl run busybox -it --image=busybox:1.28 --restart=Never --rm ``` The output is similar to this: ``` Waiting for pod default/busybox to be running, status is Pending, pod ready: false If you don't see a command prompt, try pressing enter.

``` You can then run a command inside that Pod:

```shell # Run this inside the terminal from "kubectl run" ip addr ``` ``` 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0: <BROADCAST,MULTICAST,UP,LOW …(trimmed)