Ingress Controller Deployment and DaemonSet use cases

k0dard

In lab 11.2 we set up nginx ingress controller modifying values.yaml to kind: DaemonSet to deploy ingress controller pods on every node.

The lab says this way there would be a pod on every node to handle traffic. In the beginning I thought that without pods on every node traffic to some nodes would not be handled (?)

Then I've read that on large clusters it would be better to use kind: Deployment but make sure that ingress controller pods are not deployed on the same node...

So I was wondering why use DaemonSet? Is it just a simple way to ensure that there are not multiple ingress controller pods on the same node without setting pod (anti)affinity or there are other reasons?

chrispokorni

Hi @k0dard,

Using a Deployment operator together with custom scheduling rules, such as the pod or node affinity, requires a lot more work that simply using the DaemonSet operator.

The DaemonSet is already programmed to assign only one application pod instance to each node, without any additional input or configuration form the user. And, if needed, the DS can be configured to deploy application pods to a subset of the cluster nodes - still less work in comparison with the custom scheduling rules configured for a Deployment.

Nodes without pods can still receive external traffic on NodePorts. However, in the case of an ingress controller, without an ingress replica on the targeted node the requests fail. In order to avoid such failure, Kubernetes uses redundancy - an ingress pod on every node to ensure that regardless of the node capturing a client request, the request eventually reaches its targeted service - hence the use of a DaemonSet operator, or Deployment with affinity/anti-affinity rules.

Regards,
-Chris