Ownership in the Kubernetes Ecosystem

 I was reviewing my presentation on Containers and Kubernetes with my colleague, and one important issue came up that is not widely talked about or discussed. It’s not a technical issue but an ownership issue. Don’t confuse it with the ownership of Kubernetes setup or security. It has to do with the ownership of features like Container Runtime and Service Mesh. This is not a technical article but something to think about as you roll out new features with Kubernetes.

Take Service Mesh, for example. It affects the way pods communicate with each other and offers additional capabilities with respect to metrics, monitoring, and security tooling. There are cases where this may not be the best for applications that look for high performance and don’t want to share the pod’s resources. Also, the application may be exporting the metrics as part of the framework.

Traffic Shaping and Canary Deployment also fall into a similar category. It’s usually the application teams that take ownership of these features. Developers, being fully aware of Kubernetes capabilities, may still choose to do this in microservice-based orchestration rather than relying on Kubernetes, as it may need coordination, approval, and guidance from DevOps.

Most Service Mesh implementations use sidecars. Sidecars consume resources and will affect the HPA. I talked about it here. The burden of successful HPA is not only with developers but also with DevOps, and most of these features will require developers to work closely with DevOps, something that is lacking in most organizations.

What do you think?

Containerization Github List  ->   Github Containers