4 ms·
We started nginx-ingress as a deployment, and we converted it to a DaemonSet: - We rarely deploy new versions of the ingress controller - We can't (or don't k
by maktouch 10y ago
We started nginx-ingress as a deployment, and we converted it to a DaemonSet:
- We rarely deploy new versions of the ingress controller
- We can't (or don't know how to) choose in which nodes the pods will go. If I make a deployment with 10 replicas, there's a chance that it'll all go in the same node
- Because we can't choose to distribute the pods, when a node containing the ingress pod went down, there was a noticeable blip of downtime (~27 seconds approx.). That's kinda unacceptable.
- Nginx ingress is pretty light. I don't mind it having just 1 of them in each node.
- Since we put our databases and stateful stuff outside kubernetes, we also decided to separate web facing kubernetes cluster and worker ones. This solves the problem of the "spin up 50 new nodes to handle some batch machine learning job".
So far, so good. I would actually suggest that you use a DaemonSet for this, just like I suggest you convert Kube-DNS to a daemonset (it's not by default on GKE for some obscure reason).