Implementing Anti-patterns: Kubernetes Cross-namespace Resource Ownership

The presentation discusses the use of Kubernetes namespaces and resource quotas for multi-tenancy and isolation of user groups and workloads. It also introduces the concept of owners and dependents in Kubernetes and provides an anecdote to illustrate the implementation of these concepts.

• Kubernetes namespaces serve for isolating groups of resources and can be used for separating and isolating distinct workloads and user groups
• There are two types of resources in Kubernetes: namespace scope and cluster-wide resources
• Resource quotas ensure that each distinct user group and namespace in a cluster gets its fair share of resources
• Owners and dependents are a well-known Kubernetes concept used for managing the relationship between resources
• An anecdote is provided to illustrate the implementation of these concepts, showing how a few lines of code can be used to bend Kubernetes rules and implement something that is disallowed

The presenter demonstrates how a meteor resource is created and owned by a shower resource in a namespace, and how commas are used as blank shadows of the meteor to own additional generated resources. The presenter then shows how deleting the meteor resource results in the deletion of all dependent resources, including pipelines and image streams, illustrating the use of owners and dependents in Kubernetes.

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!