Kubernetes is a very open system allowing developers a great extent of freedom. However it still follows rules, design principles and sets well-described boundaries. It constrains developers to well understood cans and cants. Prohibiting cross-namespace ownership of resources is one of such rules. A namespace scoped resource can't be an owner to a resource in a different namespace. Yet, there always is that one use case that we can't solve in any other way than by smashing through those walls of rules. We will explore why such a use case makes sense. And what challenges rigid namespace isolation brings to integration between Kubernetes native services. We will discover how one can construct a solution to this problem. Without re-implementing or replacing default core services - like the native garbage collection mechanisms.
Click here to view captioning/translation in the MeetingPlay platform!
