Baremetal k8s - nginx as DaemonSet configuration

Hey, I would like to ask you about some assistance:

Entrypoint to cluster for http/https is NGINX: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.25.0 running as deamonset

I want to achieve 2 things:

  1. preserve source IP of client
  2. direct traffic to nginx replica on current server (so if request is sent to server A, listed as externalIP address, nginx on node A should handle it)
  • How is it possible?
  • Is it possible without nodeport?

Control plane can be started with custom --service-node-port-range so I can add nodeport for 80 and 443, but it looks a little bit like a hack (after reading about nodeport intended usage)

Cluster information:

Kubernetes version: v15.1
Cloud being used: bare-metal
Installation method: Manual, using deployments
Host OS: Ubuntu 18.04
CNI and version: Weavenet 2.6
CRI and version: Docker 18.9

I would not recommend doing this. :grimacing:

Is there a particular reason you’re going the daemonset route and not using something like metallb to function as a bare metal LoadBalancer service type? How are you directing traffic to each node externally?

Hey,
Some background:
Our cluster server static files (several hundred TB/m). Thus we need direct connection to some services from outside, and preferably without networks hops (in last configuration this was causing link saturation). We are doing DNS load balancing - to be replaced in the future).

The issue with MetalLB is that in layer 2 config one host attracts all traffic from kubelet - so no go for me. BGP looks better however im not sure if my provider supports it on router (online.net).

I understand that Kubernates is not designed to solve such problems - bare metal servers without k8s would be better, but apart from serving static content I have plenty of microservices running - and extra I want to keep same application setup as in other projects (K8s).

Do you have some ideas?
@mrbobbytables

I had to go lookup what online.net provides as far as network goes. If all the servers have a public IP, honestly you may want to go the host networking route and bind to 80/443 that way.

You will really want to be careful how you manage your systems though :grimacing: An accidental nodeport service will expose it externally to everyone.


robertsz

    July 23

Hey, I would like to ask you about some assistance:

Entrypoint to cluster for http/https is NGINX: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.25.0 running as deamonset

I want to achieve 2 things:

  1. preserve source IP of client
  2. direct traffic to nginx replica on current server (so if request is sent to server A, listed as externalIP address, nginx on node A should handle it)

A service with the field external traffic policy: local. That will do just that: only direct traffic to the local pods, and as there are no extra hops you preserve the client IP.

  • How is it possible?
  • Is it possible without nodeport?
  • Control plane can be started with custom --service-node-port-range so I can add nodeport for 80 and 443, but it looks a little bit like a hack (after reading about nodeport intended usage)

You may want to consider using hostPort on your pod, and just use that port. Then port 80 and 433 will be opened in the node. I think it is simpler.

If your provider supports BGP, metalLB is a great choice because it will let you achieve what you want: route without hops. To do it, you just need a service type load balancer and with external traffic policy set to local.

A cloud provider that does support this and has cheap BW is packet.com (I’m just using it with metalLB, works great). I’m not familiar with metalLB layer 2 support :frowning:

If can’t use metalLB, another approach would be to have some nodes dedicated to receive the traffic and making sure you can move those IPs to other nodes if they fail. So DNS records are not an issue.

But are you completely sure you need to expose this without any hop? Like, not even an efficient load balancer as contour/nginx? And are you completely sure metalLB is not an option? I’d try to make sure of this before going that route, because it seems it will create some pain to manage.