Hacker News new | comments | show | ask | jobs | submit login

I see the same thing too: a struggle for relevance. The center of gravity has already moved onto k8s, even if it will takw a while for the rest of the developer community to catch up.

There are a lot more exciting work around Helm (packaging for K8S), third party extensions (plugins for K8S), and Operators (embedded managed services). The K8S community already has more contributios going towards the stack, and the three technology I just mentioned reduces enough friction for contributing innovations that k8s will likely phase-shift.

I just don't see Docker catching up. Sure, developers know them and think it has a good developer story. It doesn't. Docker for Mac and Window is practically useless when you have to struggle with file mounting for dev work. Docker Swarm is just not as robust as K8S, and the source of innovation going into Docker Swarm is coming from ideas from K8S.

Someone said it. ... K8S, not Docker, is the Linux of the cloud native platform.




From a production Swarm operator without much experience with k8s:

When you create a new Swarm cluster with `docker swarm init`, Swarmkit creates PKI that is used for everything onward: gRPC cluster state communication, encrypted overlay networks, secrets, and so on. Keys are automatically rolled every 12 hours by default. This is done automatically and transparently to the operator, without any effort on their part. Adding workers or managers after that is as done with `docker swarm join --token <token>` on the new node, that's all.

I believe operation ease for starting a cluster and maintaining it for k8s is something that's going to get a lot easier soon from Moby and k8s joining forces.

Secrets. Swarm got encrypted secrets in January, and you create one with `docker secret create <secret-name> <file/stdin>` or the API. It looks like k8s got it as an alpha feature at the end of June and it doesn't look easy: https://www.twistlock.com/2017/08/02/kubernetes-secrets-encr... They are making secrets functionality plug-able, to match the flexibiliy in networks, volumes, and logging.

As far as development power goes, 9k contributors and 9k pull requests in the last year is nothing to scoff at. That's also a misrepresentation because of the effort put forth for CNI and container standards that make a lot of the work interchangeable.

k8s has a lot of nice stuff and a great, evolving ecosystem, but I think you are being a bit harsh on Swarm. I think Moby (and derivatives) and k8s will benefit mutually from this, as they have over the past year already.


My team pays for GKE. The keys you are talking about are done with K8S + GKE so I don't see how that is much of an advantage other than cost. I want to add a new node, I go to the UI and increment a number.

As far as secrets go, there are a couple approaches the K8S community is trying for with encrypted secrets. The one I am rooting for is the integration with Hashicorp Vault. Chances are, that area will be fairly extensible.

I agree, 9k contributors and 9k pull requests are not to be scoff at. I wasn't scoffing at them. I'm simply saying that (1) center of gravity and where the influence is now has already shifted off of Docker, and (2) Just like Github.com phase-shifted open-source development (in way that Sourceforge never did), there are three technology in K8S that will likely phase-shift K8S development. This isn't about development power, but about a phase-shift.

I don't think I am being harsh on Swarm (and since when was this about being harsh? At the core of this is about whether the technology is fit-for-purpose and helps enable people achieve their mission and Docker is a commercial enterprise) The tipping point has come and gone. I saw Docker squander a lot of developer good-will over the past two years. I remember when CoreOS announced they were creating rkt, there were a lot of backlash to CoreOS. I liked CoreOS but I thought at the time it was a weird move. If that had happened this year, there would not be as much of a backlash.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: