prryb
commented
2 years ago Hi! Thank you for your message. I do see your point.
When that comment was made, there were no admission controllers. That has changed since that time, that's true. There were some efforts made so that you don't need to have cluster admin permissions to run the operator in a namespace.
It was easier development-wise, to focus on watching one namespace, one Jenkins, etc and there were no strong enough arguments to try to change that.
Now, I think, might be a good time to reconsider that. I'd say making that change (so that one operator supports multiple Jenkins instances) is doable.
stale[bot]
TueDissingWork
brokenpip3
I just ran into this comment https://github.com/jenkinsci/kubernetes-operator/issues/250#issuecomment-596203542 from @tomaszsek, that basically makes a recommendation to have separate operator per each controller. This really sounds like an anti-pattern and this is not what other operators like Prometheus Operator or Redis Operator do or recommend. Not to mention that each operator registers itself as an admission controller...
In a typical CI/CD implementation in a shared K8s environment, most typical roles would include:
Obviously, not necessarily that these five are all different people physically - some of these roles might be shared by same teams, and some - be a self-service automation. However, with the current implementation - separation of privileges, wether it is in between people or automation, looks broken to me.
With that said - to me the most optimal, the most secure, and the most flexible topology would be to have one shared operator in the cluster, each controller in its own separate namespace, which in turn each use one more namespace designated to just build pods.
Although I can see some might want to have more than one operator to watch groups of namespaces instead of a single ns per operator as it is now - but that'd require admission controller to be separated as operator admins would typically not have permissions to deploy it. Not to mention multiple instances of the same admission controller registered as a separate webhooks each sounds like too much overhead for the control plane and can potentially lead to performance degradation in the cluster.