Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create one ingress controller per application exposed #213

Open
the-smooth-operator opened this issue May 15, 2019 · 1 comment
Open

Create one ingress controller per application exposed #213

the-smooth-operator opened this issue May 15, 2019 · 1 comment
Labels

Comments

@the-smooth-operator
Copy link
Contributor

the-smooth-operator commented May 15, 2019

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-smooth-operator
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant