You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we have one ingress controller serving all our public facing applications. This is fine as our applications are not getting much traffic, but following standardization/best-practices in the IT SRE team we want to have one per namespaces with public facing applications on it.
The text was updated successfully, but these errors were encountered:
Starting to work on this in parallel with the Calico namespace isolation (#175). I thought it makes sense to get this in place before writing complex network ACLs, as this will ease them up.
After reading docs and playing with Kubernetes manifests, I see several benefits of having one ingress-controller per namespace, as well as few disadvantages.
In the good side this allow as to:
Add different configurations based on what's more beneficial to the applications in that ns.
Better isolate namespaces which increases our security posture and creates more portable applications.
Replacing a "single point of failure". Having this setup will allow us to better test upgrades, and do faster rollbacks.
In the bad side:
Adds more computing resources to the cluster. We should carefully size these.
Increases the number of manifests to handle/complexity.
Currently we have one ingress controller serving all our public facing applications. This is fine as our applications are not getting much traffic, but following standardization/best-practices in the IT SRE team we want to have one per namespaces with public facing applications on it.
The text was updated successfully, but these errors were encountered: