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

31–40 of 74 posts

Re: Container orchestration: Moving from fleet to Kubernetes

#31

Post by emmelaich »

hackerboos wrote: post #21
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

Why does this process involve curl getting from images.rcs.realclearpolitics.com?

Re: Container orchestration: Moving from fleet to Kubernetes

#32

Post by vidarh »

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…

Same here. What made me like fleet despite the many problems with it is the simplicity and that it is not a container scheduler but a systemd unit scheduler, so it is far more flexible than just a container scheduler.

I have projects where Kubernetes is probably the right choice, but I have many more where Kubernetes is massive overkill and where I also need/want the distributed systemd units.

Re: Container orchestration: Moving from fleet to Kubernetes

#33

Post by vidarh »

wstrange wrote: post #23
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.

They're not over. Kubernetes might be dominant in the short term, but it's very complex compared to the use cases a lot of people have been using things like fleet for, and I for one will continue evaluating other options for that reason as most cluster deployments I work on by far have needs where the complexity of something like Kubernetes is totally unnecessary - there will be plenty of space for alternatives for that reason.

Re: Container orchestration: Moving from fleet to Kubernetes

#34

Post by wmf »

davidmr wrote: post #28
sytse wrote: post #7

Earlier quoted context omitted.

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

It could have been worse: You could have tried to run Swarm and k8s on top of Mesos simultaneously.

Re: Container orchestration: Moving from fleet to Kubernetes

#35

Post by wmf »

vidarh wrote: post #33
wstrange wrote: post #23

Earlier quoted context omitted.

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.

They're not over. Kubernetes might be dominant in the short term, but it's very complex compared to the use cases a lot of people have been using things like fleet for, and I for one will continue evaluating other options for that reason as most cluster deployments I work on by far have needs where the complexity of something like Kubernetes is totally unnecessary - there will be plenty of space for alternatives for…

It looks like k8s is simplifying fast enough that it may eclipse the others. kubeadm is already a huge improvement.

Re: Container orchestration: Moving from fleet to Kubernetes

#36

Post by predakanga »

zebra9978 wrote: post #29
moondev wrote: post #27

Earlier quoted context omitted.

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

The issue that I have with the newly imagined Docker Swarm is that it continues Docker's trend of trying to be a jack of all trades.

I have no specific examples for Docker Swarm, but using this approach in other areas has led to some pretty major deficiencies in Docker's design that they have been slow to fix, and I'm not keen on seeing that happen again.

For a concrete example, see https://github.com/docker/docker/issues/19474 - in a minor release, they completely changed how DNS worked and broke previously working systems (i.e. https://github.com/weaveworks/weave/issues/2157), all in the name of service discovery

Re: Container orchestration: Moving from fleet to Kubernetes

#37

Post by vidarh »

predakanga wrote: post #36
zebra9978 wrote: post #29

Earlier quoted context omitted.

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

The issue that I have with the newly imagined Docker Swarm is that it continues Docker's trend of trying to be a jack of all trades. I have no specific examples for Docker Swarm, but using this approach in other areas has led to some pretty major deficiencies in Docker's design that they have been slow to fix, and I'm not keen on seeing that happen again. For a concrete example, see https://github.com/docker/docker/i…

My biggest issue with swarm is when you have clusters that also needs scheduling of non-Docker workloads.

Re: Container orchestration: Moving from fleet to Kubernetes

#38

Post by rckrd »

emmelaich wrote: post #31
hackerboos wrote: post #21

Earlier quoted context omitted.

brew cask install minikube brew install kubectl Then follow the tutorial https://github.com/kubernetes/minikube#quickstart

Why does this process involve curl getting from images.rcs.realclearpolitics.com?

Something is not right on your machine. You can see what the homebrew recipe is doing here:

https://github.com/caskroom/homebrew-cask/blob/master/Casks/...

Re: Container orchestration: Moving from fleet to Kubernetes

#39

Post by rckrd »

hackerboos wrote: post #21
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

Other installers that minikube has:

- Arch linux AUR https://aur.archlinux.org/packages/minikube/

- Windows installer https://github.com/kubernetes/minikube/releases/download/v0....

- Deb package https://github.com/kubernetes/minikube/releases/download/v0....

Re: Container orchestration: Moving from fleet to Kubernetes

#40

Post by pslijkhuis »

schmichael wrote: post #5
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…

Nomad dev here. We should definitely tick the simplicity box for you. If not, let me know. :) Nomad is a single executable for the servers, clients, and CLI. Just download[0] & unzip the binary and run: nomad agent -dev > out & nomad init nomad run example.nomad nomad status example And you have an example redis container running locally! Nomad supports non-Docker drivers too: rkt, lxc templates, exec, raw exec, qemu…

Completely unusable product for us because of the lack of persistent storage.
Post reply on HN