Earlier quoted context omitted.
Swarm has a very special role, because it's custom-built to integrate in the Docker platform. Because it's so specific, it has a smaller standalone community than Kubernetes, but it makes up for it in focus and speed. You should expect a lot of bleeding edge features to ship in Swarm first, and a generalized version to land in kubernetes later. That's already been the case in the past: Windows support, secrets, node…
> You should expect a lot of bleeding edge features to ship in Swarm first The development of those bleeding edge features is well hidden. The contributions graphs seem to indicate that Swarm is at best a ghost town. Perhaps the action is happening somewhere else and/or Docker will start investing in Swarm once more. https://github.com/docker/swarm/graphs/contributors
Adding Kubernetes support to the Docker platform
101–110 of 144 posts
Re: Adding Kubernetes support to the Docker platform
#102Earlier quoted context omitted.
Not really sure I see the vendor lock-in here. If you use Docker EE sure you're going to be locked in to their solutions to an extent but then that's true of adopting any commercial supported solution that provides layers on top of the base k8s clustering tech (e.g. Openshift). The API is still k8s and the YAML files are identical, so migration at a technical level off that platform should be easy enough. I think thi…
Huh, how does Openshift compare with Mesos DC/OS? Sounds similar
There is also an OSS version of DC/OS minus some security features. Also, historically Mesos has had better support for running stateful workloads but K8s is catching up too.
Recently, DC/OS announced support for K8s too which is similar to the K8s announcement from Docker.
Disclosure: Apache Mesos committer.
Re: Adding Kubernetes support to the Docker platform
#103Is this a response to cri-o taking Docker out of Kubernetes?
That was my initial thought as well. CRI-O hits 1.0, and then this. To me, it comes across as an attempt to stay in the news. Possibly to start changing the narrative from Docker vs Kubernetes to Docker <3's Kubernetes.
It seems more likely to me that the CRI-O 1.0 announcement was a tactical move from Red Hat to hijack the conversation during Docker's own conference. CoreOS did the same thing 3 years ago when they announced rkt, trying to capitalize on Dockercon as a time to make a bunch of noise for themselves. Docker themselves have been no perfect angels in this regard, for instance with their infamous "accept no imitations" shirt at Red Hat's conference, I'm just calling it as I see it.
Disclaimer: I worked for Docker, Inc. for 3 years.
Re: Adding Kubernetes support to the Docker platform
#104This really helps with the dev-to-production story for containers. When people first started using Docker containers, we were promised things would run identically in dev and production - no more "but it worked on my laptop" issues. Then the rise of orchestrators meant that there again became a significant difference between running an app locally (in compose) and in production (on Kubernetes). Docker for Mac/Windows…
Re: Adding Kubernetes support to the Docker platform
#105Great news for everyone except for VMWare (this is a simple compelling operating system for data centers that spans both windows and mac) and Openshift (which was one of the few viable ways of actually purchasing Kubernetes support). A lot of egos on both sides had to be suppressed to make this happen. Docker Swarm was a key driver in making Kubernetes popular because everyone realized that they needed swarm, but the…
And given enterprise support Openshift is still ongoing as the best solution. They are afaik the only ones that offer a complete set of answers to most questions you can have in the PaaS space. Everybody else is like "here's an API, choose one of 3 billion plugins" (just thinking CNI here). In the end for the customer it doesn't matter though. Customers just want things to run smoothly and if possible reduce their maintenance work force. They don't want choices, they want solutions.
Re: Adding Kubernetes support to the Docker platform
#106Great news for everyone except for VMWare (this is a simple compelling operating system for data centers that spans both windows and mac) and Openshift (which was one of the few viable ways of actually purchasing Kubernetes support). A lot of egos on both sides had to be suppressed to make this happen. Docker Swarm was a key driver in making Kubernetes popular because everyone realized that they needed swarm, but the…
It's not like kubernetes folks very pushing to marginalize docker for bad reasons. docker runtime was one of the bottlenecks of kubernetes in production and docker inc didn't feel like improving it. Hopefully, it is changing now.
There are some technical decisions in docker that could provide similar functionality with better production support. I am not expert and just saying what I heard from dev working on it: for example, btrfs would work better than overlayfs for COW file system or docker would be better of using parts of systemd rather than implementing everything from scratch.
Re: Adding Kubernetes support to the Docker platform
#107So now the last question is how long does it take for AWS to finally abandon ECS and formally support K8S as a service? I think this makes it kind of slam dunk, but it is forcing aWS to give up a lot of proprietary lock in.
Re: Adding Kubernetes support to the Docker platform
#108What does this mean for Docker Swarm, are they saying Kubenetes is "better"?
I think technically and in some regards also politically the Docker people are smarter though. In the most pro-docker comment I answered with "don't start to ignore k8s yet" and here I feel like saying "don't start to ignore docker(-swarm) yet".
The battle is ongoing and these two are both possible leaders.
Re: Adding Kubernetes support to the Docker platform
#109Earlier quoted context omitted.
We're going to support Linux also. But we want to careful not to disrupt the users of the original container engine, as we transition it to Moby. In the future there will be a cleaner separation between "Docker CE, the developer tools" and "Moby engine, the open-source container engine". The last thing we want is someone to upgrade their production Linux engine to find an unexpected and unwanted kubernetes distributi…
That sounds like a shoehorned explanation. You're leaving developers on linux out to dry because people aren't paying attention to their production systems? Don't get me wrong, the work you guys do is cool and all, but that isn't a valid explanation from my point of view. Any company should have some sort of staging to test updated before rolling them out - it isn't up to the developers of the software to take care o…
Re: Adding Kubernetes support to the Docker platform
#110Earlier quoted context omitted.
There's minikube. There's been minikube for a long while.
Minikube (and its derivative, MiniShift) have been very helpful for my team in bridging the gap between local development and production for Kubernetes and OpenShift.