Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Adding Kubernetes support to the Docker platform

docker.com

Post reply on HN
Print view View original

41–50 of 144 posts

Re: Adding Kubernetes support to the Docker platform

#41

Post by shykes »

ealexhudson wrote: post #6
shykes wrote: post #4

Earlier quoted context omitted.

You can disable Swarm or Kubernetes at will in each Docker EE cluster. Hybrid is very useful for enterprises who already have to manage both - it was a highly requested feature.

I think I can understand "We have both and need to manage them more easily" as a request, because it's about pain right now. The thing I'm unsure about - and it would be really interesting to get your perspective on - is what this means for Swarm longer-term. Is there still going to be a reason why people will want hybrid? Is it a migration play? In a hybrid, over time I'd want to two to behave the same, and getting…

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 identity & promotion - those all shipped in Swarm first, then made their way to Kubernetes. Not because Swarm developers are smarter, but because they can focus on a narrower, more integrated problem set.

Longer term, I think all orchestrators will converge to look more and more the same. Orchestration will become a commodity, and it will matter less and less which orchestrator you use, especially to developers. But this process will take a long time, and in the meantime enterprises (our primary customers) need to deal with the situation on the ground, which is a lot of Swarm and Kubernetes living side by side because of historical decisions made in 2015-17.

Re: Adding Kubernetes support to the Docker platform

#42

Post by noway421 »

oblio wrote: post #18
hijinks wrote: post #17

Earlier quoted context omitted.

Amazon did join the CNCF

Yes, but it will be a while, I think, before they actually offer something based on it. I don't see any service based on it at this point. AWS ECS is based on Docker.

Don't they use Xen?

Re: Adding Kubernetes support to the Docker platform

#43

Post by drdaeman »

mrmondo wrote: post #10
sz4kerto wrote: post #7

Seems that people think Docker has gave in, but I am not that sure. If you can switch between Swarm/Kubernetes transparently, then why wouldn't you start with Swarm? (I'm talking about small companies who're just starting with containers.)

Why wouldn’t you start with Kubes? Less vendor lock in and a much bigger community.

Because K8s adds large amount of potentially unnecessary complexity?

- Setting up Swarm is trivial, setting up Kubernetes is not so much (kubeadm is still not recommended for production, and there are valid reasons for this). I guess the only thing that's probably easier on K8s is (totally unsupported) multiarch cluster - it's somewhat messy with Swarm[1]. Although my experiments with multiarch K8s had failed (got issues with CNI stuff and postponed research for later).

- Compose file format is significantly simpler and concise. Less code to write is good.

- Debugging failing Swarm is significantly easier than debugging failing Kubernetes. Well, that's probably subjective and I haven't truly deeply debugged either, but at least I believe so - on occasions I was able to find my way through moby, swarmkit & libnetwork source, and K8s feels a very different beast.

____

Update[1]: I re-checked multiarch status for Swarm and found out that now `docker service create --name test --placement-pref 'spread=node.id' --replicas 2 --no-resolve-image ubuntu sh -c 'while true; do uname -a; sleep 1; done'` just works on a freshy set up mixed x86_64+armhf Swarm cluster (no multiarch alpine images yet, though - promised to come next week). Guess, Swarm had beaten K8s here.

Re: Adding Kubernetes support to the Docker platform

#44

Post by squeed »

ealexhudson wrote: post #2

Have to say, I don't see the value in being able to have Swarm and k8s in the same cluster. "Docker: powered by Kubernetes" seems to be more of a marketing thing to move down the value chain, and not be seen as a basic piece of infrastructure.

Agreed, just seems like marketing vaporspeak. Not exactly a trustworthy source, too.

For example, containerd has been moved to the CNCF and made a broader project. Fine, but Docker runs a separate fork of containerd anyways. A neat marketing sleight-of-hand, but to what end?

Re: Adding Kubernetes support to the Docker platform

#45

Post by m3adow »

mrmondo wrote: post #10
sz4kerto wrote: post #7

Seems that people think Docker has gave in, but I am not that sure. If you can switch between Swarm/Kubernetes transparently, then why wouldn't you start with Swarm? (I'm talking about small companies who're just starting with containers.)

Why wouldn’t you start with Kubes? Less vendor lock in and a much bigger community.

Because K8s has quite some overhead, a steeper learning curve and is more difficult to set up and to maintain. I don't see this as a problem in bigger companies, but in companies with less than 10 IT people and no prior knowledge I'd take Swarm over K8s every day.

Re: Adding Kubernetes support to the Docker platform

#46

Post by organsnyder »

amouat wrote: post #40
grabcocque wrote: post #16

Earlier quoted context omitted.

There's minikube. There's been minikube for a long while.

Yes. And I don't mean to knock minikube, but this is potentially simpler and easier to use.

I don't see how it could be much simpler and/or easier. In my experience, Minikube just works, out-of-the-box.

Re: Adding Kubernetes support to the Docker platform

#47

Post by oblio »

noway421 wrote: post #42
oblio wrote: post #18

Earlier quoted context omitted.

Yes, but it will be a while, I think, before they actually offer something based on it. I don't see any service based on it at this point. AWS ECS is based on Docker.

Don't they use Xen?

For Elastic Compute Cloud (EC2) aka hosted VMs, yes.

For ECS (EC2 Container Service), they use Docker on top of their VMs.

So they have a Docker offering but not a Kubernetes one, at the moment.

Re: Adding Kubernetes support to the Docker platform

#48

Post by throwaway0071 »

shykes wrote: post #41
ealexhudson wrote: post #6

Earlier quoted context omitted.

I think I can understand "We have both and need to manage them more easily" as a request, because it's about pain right now. The thing I'm unsure about - and it would be really interesting to get your perspective on - is what this means for Swarm longer-term. Is there still going to be a reason why people will want hybrid? Is it a migration play? In a hybrid, over time I'd want to two to behave the same, and getting…

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…

"which is a lot of Swarm"

I think that's an overstatement. I talk to a lot of professionals in this area and never seen Swarm deployed to production (from small to big corps). Anecdata warnings apply.

Could you share some numbers?

Re: Adding Kubernetes support to the Docker platform

#49

Post by piva00 »

user15128 wrote: post #30
amouat wrote: 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…

in order to test your app in prod-like env you need to run prod-like env locally. ie. a k8s-cluster that is close enough to prod. for that you will have to at least simulate multi-node-setup and run all cluster-addons like in production. i am excited about this move from docker but i don't think it will solve all the problems. i think once you have a bigger team it is worthwhile to run a second k8s-cluster besides pr…

Not necessarily, we have been using k8s for a while now where I work and what we've been doing is running a simple minikube setup locally, with the production add-ons (DNS, nginx ingress controllers, etc.) and circumventing what is AWS-related.

It's been working quite well, no need for multi-node-setup so far that I'm aware of.

Re: Adding Kubernetes support to the Docker platform

#50

Post by ntnn »

shykes wrote: post #37
bonsai80 wrote: post #27

I see them stating "...for developers using Windows and macOS" but not mentioning Linux. I feel like I'm missing something in how I'm reading that page. How can I make use of this on Linux?

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 of this.

And not only that - the switch will come at some point or another either way, so it doesn't make sense to hold that back from CE on linux so that someone doesn't 'find an unexpected and unwanted kubernetes distribution wedged in'. Those who would find that now would also be surprised by that later on.

To add to that - containers are tested using CI/CD tools anyhow, which are predominantly powered by linux machines, which again makes this decision less convincing. The build may be fine on the developers machine and in production, but the CI/CD environment wouldn't reflect both of these environments.

This looks more like a facade for selling more Docker EE licenses rather than wanting to protect users. Which is fine, of course - but then please say that.

Post reply on HN