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

Container orchestration: Moving from fleet to Kubernetes

coreos.com

Post reply on HN
Print view View original

21–30 of 74 posts

Re: Container orchestration: Moving from fleet to Kubernetes

#21

Post by hackerboos »

mevile wrote: post #8

I love the suggestion for new users to try minikube. I got started with minikube and kubernetes recently and it was only then when I had an aha moment with containers. I get it now. I know containers have been around a while but with kubernetes the orchestration difficulty has been lowered to the point where I can't imagine going back to the way I was getting things working before. From minikube I moved to kubernetes…

brew cask install minikube

brew install kubectl

Then follow the tutorial https://github.com/kubernetes/minikube#quickstart

Re: Container orchestration: Moving from fleet to Kubernetes

#22

Post by rajivm »

newsat13 wrote: post #12

I am sad to see fleet go. Fleet was quiet simple to setup but k8s was a monster. They have so much terminology and it tries to cover all the cases of cloud orchestration. I think my fallback now is Swarm (hope it gets more stable though)

I was in the same boat of leaning toward the simplicity of Compose/Swarm/Docker Cloud, and even took a look at Rancher which supports Swarm & their own compose/Cattle scheduler. After spending months trying to get these to work effectively, and battling with their continuous changes & instability -- I eventually gave Kubernetes a shot. There's definitely a greater learning curve to understanding what all the terminology is, but for the basic uses of deploying a set of services, it turns out it's actually not as complicated as it first seems.

My shortcut was using https://github.com/kubernetes-incubator/kompose to convert my docker-compose.yml to the equivalent K8S objects. It wasn't as simple as just running it, but it let me see what it would basically take to do the same thing in Kubernetes. It ended up taking just a few days to wrap my head around it all and get it up and running. Probably even easier if you use something like GKE which manages the cluster for you. If you're investing in using containers for the long-haul, I think it's definitely worth the learning overhead.

There are only three key object types you need to understand to start using K8S: Deployments, Pods & Services. Feel free to msg me if you have some questions about getting started.

Re: Container orchestration: Moving from fleet to Kubernetes

#23

Post by wstrange »

newsat13 wrote: post #12

I am sad to see fleet go. Fleet was quiet simple to setup but k8s was a monster. They have so much terminology and it tries to cover all the cases of cloud orchestration. I think my fallback now is Swarm (hope it gets more stable though)

Kubernetes is dead simple to use, but can be a little daunting to set up.

Thankfully, that is changing with things like minikube, kubeadm, kops, and self hosted Kube.

I think the orchestration wars are essentially over. Kube has insane momentum, and is a well architected solution.

Re: Container orchestration: Moving from fleet to Kubernetes

#24

Post by sandGorgon »

simonvdv wrote: post #3

Hmm that's a pity even though it shouldn't come as a surprise for anyone who's actively using/involved with fleet. I like the simplicity and flexibility of fleet (basically distributed SystemD) a lot. Don't necessarily want to switch to a bigger scheduler like Kubernetes. Anyone have any suggestions for/experiences with an alternative simpler scheduler (like Nomad or an alternative solution like the autopilot stuff f…

Docker Swarm - especially 1.13 with the new, simpler yml file based deployment

Re: Container orchestration: Moving from fleet to Kubernetes

#25

Post by Perceptes »

dpratt wrote: post #18

This is interesting, but has a potential problem - what do you use to schedule the control plane? Right now, we use Fleet to schedule a highly available k8s API server and associated singleton daemons. Then API server is required to get anything else scheduled in the cluster. How are they going to solve this bootstrap problem?

As moondev pointed to, eventually bootkube will handle bootstrapping k8s clusters. At my company we just set everything up using cloud-config. A systemd unit boots the kubelet on each server, and static k8s manifests are loaded by the kubelet to run the rest of the k8s components as pods. This way, the kubelet itself is the only component that is not managed by k8s itself.

Re: Container orchestration: Moving from fleet to Kubernetes

#26

Post by zebra9978 »

What do people generally think about Docker Swarm ? The new deployment using .yml files is pretty cool : https://www.infoq.com/news/2017/01/docker-1.13

In fact, IMHO kubernetes has tried to do something similar with .. but it is not engineered ground up for simplicity. Which is why it has MULTIPLE tools for this - minikube, kubeadm, kompose - but nothing matching the ease of use of docker and its yml files.

The last survey showed 32% of the polled used Docker Swarm versus Kubernetes' 40% - and this is back when Docker Swarm was highly unstable. https://clusterhq.com/2016/06/16/container-survey/#kubernete...

Are people here using Swarm ? what have your experiences been like.

Re: Container orchestration: Moving from fleet to Kubernetes

#27

Post by moondev »

zebra9978 wrote: post #26

What do people generally think about Docker Swarm ? The new deployment using .yml files is pretty cool : https://www.infoq.com/news/2017/01/docker-1.13 In fact, IMHO kubernetes has tried to do something similar with .. but it is not engineered ground up for simplicity. Which is why it has MULTIPLE tools for this - minikube, kubeadm, kompose - but nothing matching the ease of use of docker and its yml files. The last…

Kubernetes deployments are done via yml (or json) files too. They are called manifests.

I think you are misunderstanding the tools listed. Minikube sets up a single-node local cluster. Kubeadm sets up a multi-node cluster. No matter how or where your cluster is set up, you still deploy with manifests.

Re: Container orchestration: Moving from fleet to Kubernetes

#28

Post by davidmr »

sytse wrote: post #7
EwanToo wrote: post #6

A brave decision, but I think it's the right one for both CoreOS, and in the long-run, their customers. Definitely pretty painful for people who have already adopted fleet, but a year of support is much better than I would expect

I too salute CoreOS for doing the right thing for their customers and the ecosystem. Kubernetes was something that was hard to predict, it didn't grow organically but was suddenly released by Google. Right now I believe Kubernetes is the project with the most accepted pull requests per day. This came up in a talk from GitHub at Git Merge 2017. It shows that k8s is on its way to becoming the default container schedule…

Completely agreed. The landscape 2-3 years ago looked incredibly different, and I picked Mesos for a rather ambitious project. After it became relatively clear that k8s was going to eclipse Mesos and not by a little bit, trying to unwind that decision basically cost me my job through some political infighting. It's a shame, but such is the price of early adoption, I guess.

Given the same information, I'm really confident that I'd still make both choices the same way.

Re: Container orchestration: Moving from fleet to Kubernetes

#29

Post by zebra9978 »

moondev wrote: post #27
zebra9978 wrote: post #26

What do people generally think about Docker Swarm ? The new deployment using .yml files is pretty cool : https://www.infoq.com/news/2017/01/docker-1.13 In fact, IMHO kubernetes has tried to do something similar with .. but it is not engineered ground up for simplicity. Which is why it has MULTIPLE tools for this - minikube, kubeadm, kompose - but nothing matching the ease of use of docker and its yml files. The last…

Kubernetes deployments are done via yml (or json) files too. They are called manifests. I think you are misunderstanding the tools listed. Minikube sets up a single-node local cluster. Kubeadm sets up a multi-node cluster. No matter how or where your cluster is set up, you still deploy with manifests.

I have deployed several clusters with kubernetes and with Swarm. I think my wording was hyphenated at the wrong place. Swarm has a new yml file format - the compose v3 which is pretty damn awesome. Kubernetes has had yml files for a while, but the gap in simplicity/usability is massive.

Which is what my point was with minkube and kubeadm and kompose - for swarm, you use a single tool for either a single node cluster.. or a multi node cluster. Even more, kompose was invented to read from the same Docker Swarm compose file format - because it is so intuitive.

I'll go one step further - kubeadm does not actually have high availability support, so you actually have to use kargo or kops to reasonably deploy in production.

Kubernetes introduces a lot of upfront complexity with little benefit sometimes. For example, kargo is failing with Flannel, but works with Calico (and so on and so forth). Bare metal deployments with kubernetes are a big pain because the load balancer setups have not been built for it - most kubernetes configs depend on cloud based load balancers (like ELB). In fact, the code for bare metal load balancer integration has not been fully written for kubernetes.

Now, my point is not that kubernetes sucks - I think its a great piece of tech. But its around why do people think Docker Swarm will die.. or that it sucks? Because, relatively speaking, while kubernetes NEEDS all kinds of complicated orchestration tools (and consultants!) to set it up .. Swarm on the other hand is damn easy to setup by a developer building his first stack.

Is Docker Swarm the heroku to Kubernetes AWS ?

Re: Container orchestration: Moving from fleet to Kubernetes

#30

Post by sho »

sytse wrote: post #7
EwanToo wrote: post #6

A brave decision, but I think it's the right one for both CoreOS, and in the long-run, their customers. Definitely pretty painful for people who have already adopted fleet, but a year of support is much better than I would expect

I too salute CoreOS for doing the right thing for their customers and the ecosystem. Kubernetes was something that was hard to predict, it didn't grow organically but was suddenly released by Google. Right now I believe Kubernetes is the project with the most accepted pull requests per day. This came up in a talk from GitHub at Git Merge 2017. It shows that k8s is on its way to becoming the default container schedule…

> The fifth one after mainframes, minicomputers, microcomputers, and virtual machines

Interesting though that the last 3 paradigms are largely built on each other. I'm involved in a deployment at the moment which started with buying servers, implementing VMs on them, and finally laying k8s on top of that.

I know most uses of k8s won't ever really see the layers below, but they're still there...

Post reply on HN