This would allow e.g. the service controller to simply create the correct generic deployment for a service, then have a service mesh webhook mutate the deployment with added containers/annotations/etc.
This would be nice as it would decouple the service mesh from the controllers. Currently there is a servicemesh.Interface that some of the controllers have to use to manipulate some workloads. It would be nice to not have to require service meshes:
be integrated in-tree
implement a specific interface
That said, it may have some drawbacks, such as making it harder to tell whether a deployment spec for a service needs to be updated since the spec that would be generated for a service spec is mutated out of the process.
Would also need to make sure there's nowhere else that needs information from the service mesh, such as the address controller needing to know what port to forward traffic to for example. Would that information also be conveyed through well-known annotations from the webhook?
https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/
This would allow e.g. the service controller to simply create the correct generic deployment for a service, then have a service mesh webhook mutate the deployment with added containers/annotations/etc.
This would be nice as it would decouple the service mesh from the controllers. Currently there is a
servicemesh.Interface
that some of the controllers have to use to manipulate some workloads. It would be nice to not have to require service meshes:That said, it may have some drawbacks, such as making it harder to tell whether a deployment spec for a service needs to be updated since the spec that would be generated for a service spec is mutated out of the process.
Would also need to make sure there's nowhere else that needs information from the service mesh, such as the address controller needing to know what port to forward traffic to for example. Would that information also be conveyed through well-known annotations from the webhook?