<p>As a learning project, I've currently got a honeypot running in Kubernetes, which works fine. (only sad thing is that I can't see actual SRC IP's, because everything from K8s perspective is coming from the loadbalancer).</p>
<p>I want to make a cluster of honeypots and eventually make an ELK backend to which all of the logs will be send and visualise some of it. Now I can't seem to figure out how to use 1 loadbalancer with different ports for different containers. Is there a better way to tackle this problem? I kind of get the 1 service 1 loadbalancer thing, but I'm sure I'm not the only one who face(d)(s) this problem?</p>
<p>Any help is appreciated. Thanks in advance.</p>

chr0nk
<p>When it comes to preserving client's source IP when using <a href="https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer" rel="nofollow noreferrer">external load balancer</a>, <a href="https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip" rel="nofollow noreferrer">this fragment</a> of the official kubernetes documentation should fully answer your question:</p>
<blockquote>
<h2>Preserving the client source IP<a href="https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip" rel="nofollow noreferrer"></a></h2>
<p>Due to the implementation of this feature, the source IP seen in the
target container is  <em>not the original source IP</em>  of the client. To
enable preservation of the client IP, the following fields can be
configured in the service spec (supported in GCE/Google Kubernetes
Engine environments):</p>
<ul>
<li><code>service.spec.externalTrafficPolicy</code>  - denotes if this Service desires to route external traffic to node-local or cluster-wide
endpoints. There are two available options: Cluster (default) and
Local. Cluster obscures the client source IP and may cause a second
hop to another node, but should have good overall load-spreading.
Local preserves the client source IP and avoids a second hop for
LoadBalancer and NodePort type services, but risks potentially
imbalanced traffic spreading.</li>
<li><code>service.spec.healthCheckNodePort</code>  - specifies the health check node port (numeric port number) for the service. If
<code>healthCheckNodePort</code>  isn't specified, the service controller
allocates a port from your cluster's NodePort range. You can configure
that range by setting an API server command line option,
<code>--service-node-port-range</code>. It will use the user-specified
<code>healthCheckNodePort</code>  value if specified by the client. It only has
an effect when  <code>type</code>  is set to LoadBalancer and
<code>externalTrafficPolicy</code>  is set to Local.</li>
</ul>
<p>Setting  <code>externalTrafficPolicy</code>  to Local in the Service
configuration file activates this feature.</p>
<pre><code>apiVersion: v1
kind: Service
metadata:
  name: example-service
spec:
  selector:
    app: example
  ports:
    - port: 8765
      targetPort: 9376
  externalTrafficPolicy: Local ### 👈
  type: LoadBalancer
</code></pre>
</blockquote>
<p>The key point is setting the <code>externalTrafficPolicy</code> to <code>Local</code> and it should entirely solve your problem with preserving the original source IP, but keep in mind that this setting has also some downsides. It could potentially lead to less equally balanced traffic. As you can read specifically in this fragment:</p>
<p><em>There are two available options: <code>Cluster</code> (default) and <code>Local</code>. <strong><code>Cluster</code> obscures the client source IP</strong> and may cause a second hop to another node, <strong>but should have good overall load-spreading</strong>. <strong><code>Local</code> preserves the client source IP</strong> and avoids a second hop for LoadBalancer and NodePort type services, <strong>but risks potentially imbalanced traffic spreading</strong>.</em></p>
