Live data from Hacker News

Adding Kubernetes support to the Docker platform

docker.com

101–110 of 144 posts

Re: Adding Kubernetes support to the Docker platform

#101
post #84
post #41

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

You may be looking for swarmkit https://github.com/docker/swarmkit

Re: Adding Kubernetes support to the Docker platform

#102
post #80

Earlier 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

Pretty similar. The main difference from the architecture standpoint is that Enterprise DC/OS uses Mesos+Marathon for container orchestration and OpenShift uses K8s. The other functionalities are mostly overlapping.

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

#103

Is 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.

Docker's conference (Dockercon) is happening right now so announcements coming from them are no surprise. A Kubernetes integration has probably been in the works for a while.

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

#104
post #12

This 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…

Docker for Windows is pretty much unusable at the moment.

Re: Adding Kubernetes support to the Docker platform

#105

Great 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…

Surpressing egos usually means one has found a joker to beat the other in the fight for leadership. I don't think that battle is over yet, though. It's a very strong move Docker does here, but at the same time k8s is considering choosing another container engine as their main component. Currently at least in Enterprise k8s has a lot more traction than docker (I personally love docker more, but every day need to focus 99% of my effort on k8s because of that).

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

#106

Great 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…

> or a continuing push to marginalize docker by the Kubernetes folks.

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

#107

So 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.

It's already the smoothest environment to run vanilla K8S on anyways.

Re: Adding Kubernetes support to the Docker platform

#108

What does this mean for Docker Swarm, are they saying Kubenetes is "better"?

Kubernetes currently has a lot of traction in Enterprise world. Even the CEOs of the big corps currently know what Kubernetes is. That's why you need to support it in some way if you want to continue to compete. At least for the time being.

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

#109
post #50
post #37

Earlier 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…

There has been plenty of hue and cry in the past about the rapid rate of change of Docker, and new features bundled in when many users would have preferred a more deliberate and planned change in what is to them a critical piece of infrastructure. You're assuming quite a lot.

Re: Adding Kubernetes support to the Docker platform

#110

Earlier 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.

As an ordinary developer, I'd love to hear your experience as well.
Post reply on HN