Thinking Out Loud: The Future of Kubernetes
Published on 9 Nov 2016 · Filed in Musing · 443 words (estimated 3 minutes to read)I’ve just wrapped up KubeCon/CloudNativeCon 2016 in Seattle, WA. There’s no doubt the Kubernetes community is active and engaged, and the project itself is charging forward. As both the community and the project grow, though, what does that mean for the future of Kubernetes?
Here are my thoughts, hopefully presented in a somewhat logical fashion.
It seems to me that Kubernetes has been successful thus far because of a strong focus on the problem it’s trying to solve. You can see this in the Kubernetes web site, where phrases like “Production-Grade Container Orchestration” and “Automated container deployment, scaling, and management” are found. You can see this in the API abstractions Kubernetes uses (a pod as a group of co-located containers, a service as a stable access point for sets of pods, etc.). You can see it in the real-world customer deployments and use cases. Kubernetes seems focused on addressing the needs of container-based microservices-centric application architectures.
However, there now seem to be some efforts to push Kubernetes to support other types of applications as well. One could look at DaemonSets (which are used to ensure that a particular pod is always running on every node; useful for “infrastructure” services like logging, storage, monitoring, etc.) or StatefulSets (formerly PetSets; used for clustered applications that maintain state and need a stronger sense of identity) as examples. Are there use cases where these constructs are useful? Yes, certainly. Should these use cases attempt to be addressed by Kubernetes? I’m not so sure. The community thinks so, obviously, or we wouldn’t have these features in the project.
All this brings us to these core questions:
- Does the inclusion of DaemonSets and StatefulSets represent an expansion of Kubernetes’ scope? Or are these constructs simply a refining of what Kubernetes was always intended to do?
- Does an expansion of scope for Kubernetes mean a loss of focus on what has made it successful so far?
- If there is a loss of focus, what does that mean for the project?
- Will pushing Kubernetes to support other types of applications make it overly complex? Will that added complexity stop it from being effective in the area(s) that have made it successful so far?
One could make some OpenStack comparisons here (I have a separate post brewing on the future of OpenStack), but I’m not sure such a comparison would be valid. Unlike OpenStack, Kubernetes seems to have really strong technical guidance from a single source (Google), which may outweigh the pull of the community in multiple directions. It’s entirely possible that the influence of a single strong source (Google) may help keep the project on-track and growing effectively. Time will tell.