How Docker's Support for Kubernetes Will Impact Developers – The New Stack

How Docker's Support for Kubernetes Will Impact Developers – The New Stack(thenewstack.io)

65 points by ollemasle 8 years ago | 5 comments

clhodapp 8 years ago |

Heh? The Docker company line seems to be that Swarm has been and will continue to be faster-evolving than Kubernetes. That feels really disconnected from reality. For one, the ground-up rethink of Swarm that happened last year felt mostly like an attempted to rebase Swarm on more Kubernetes-like ideas. Further, the specific example given in the podcast seems to be factually incorrect: The Docker guy says that secrets are an example of something that was added to Swarm first and then later added to Kubernetes. However, Kubernetes had support for secrets in its 1.0 release all the way back in 2015, while Swarm just added secret support in February.

shykes 8 years ago | |

> The Docker company line seems to be that Swarm has been and will continue to be faster-evolving than Kubernetes

Not exactly. Kubernetes has a much larger development community than Swarm, and therefore its overall development throughput is of course higher. At the same time, Swarm is narrowly focused on a single use case: integration with the Docker platform. This narrowed scope allows for more rapid development cycles. When a Docker customer asks for a feature, it can be implemented in Swarm, integrated into Docker, packaged and released, more rapidly than the corresponding feature in Kubernetes - not because Swarm developers are smarter, but because they have a narrower problem space to worry about.

This focus and rapid development loop makes Swarm extremely useful to Docker and its users, even as it embraces Kubernetes and integrates it into the platform. It also benefits the Kubernetes community: they get an incubator for new ideas and designs which they can then generalize and adapt for their own uses. Again - this is a natural result of focus, not a sign that one project has better ideas than the other.

Examples of this "incubator pattern" include: Windows support; secrets implementation; user experience for node promotion/lifecycle.

shykes 8 years ago | |

You're correct that Kubernetes 1.3 introduced a "secrets" API resource, but it was backed by a naive implementation which did not encrypt secrets at rest. This made it impractical for production.

Encryption at rest was introduced in Kubernetes 1.7, making it usable in production. This was done in collaboration with the Docker security team, which had previously implemented encryption at rest in Swarm.