Container orchestration: Moving from fleet to Kubernetes • Hacker News Board

Re: Container orchestration: Moving from fleet to Kubernetes

#71

Post by nul_byte » Wed, Feb 08, 2017, 10:52 PM UTC

orf wrote: post #47

EtienneK wrote: post #46

Earlier quoted context omitted.

I would also like to know the answer to this question. Every time I try setting up a Kubernetes cluster, it's an exercise in frustration. Docker Swarm is much easier in comparison. Add to the fact that Docker Swarm is adding Enterprise features (such as Secrets in 1.13) and that is has an Enterprisey version (Docker Datacenter) which supports multiple teams, why would I - an Enterprise developer and architect - look…

My £0.02 is that Kubernetes has the backing of Google who have a tremendous amount of experience with container orchestration. And while using Kubernetes it really shows, things are pretty well thought out, lots of features out of the box etc. With docker swarm it's taken them this long to get simple secrets integrated, and as with all of my experiences with first party docker tools: they seem ok at first, but the de…

Red Hat are doubling down on Kubernetes too (second biggest contributor to Kubernetes), and if there is anyone who is good at taking parts of an opensource eco system and supporting them for an enterprise, its Red Hat.

Re: Container orchestration: Moving from fleet to Kubernetes

#72

Post by schmichael » Wed, Feb 08, 2017, 11:13 PM UTC

pslijkhuis wrote: post #40

schmichael wrote: post #5

Earlier quoted context omitted.

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.

Sorry to hear that! We've definitely focused on stateless containers until 0.5 which introduced sticky volumes and migrations. Useful in some cases but definitely doesn't cover all persistent storage needs.

Extensible volume support will be coming in the 0.6 series via plugins.

Re: Container orchestration: Moving from fleet to Kubernetes

#73

Post by hackerboos » Thu, Feb 09, 2017, 3:33 AM UTC

mentat wrote: post #68

johnhenry wrote: post #60

Earlier quoted context omitted.

Thanks for the quick tip! Might I suggest you change that first line to `brew cask install minikube virtualbox`?

brew install docker-machine-driver-xhyve is a friendly laptop choice.

Yeah. Forgot to mention I had Docker for Mac already installed.

Re: Container orchestration: Moving from fleet to Kubernetes

#74

Post by Perceptes » Thu, Feb 09, 2017, 9:00 AM UTC

dpratt wrote: post #62

Perceptes wrote: post #25

Earlier quoted context omitted.

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.

This is precisely what we do on our cluster as well for the node-level daemons - kubelet and kube-proxy. We use fleet to schedule the HA API server. You cannot use the Kubelet to schedule this, because you need an API server to schedule cluster-wide pods. The only solution I can see is to have a config that launches a special 'master' node that runs the API server, but this is uncompelling to me. I'd rather have ever…

Fleet is still not necessary for HA control planes. There is no danger in running multiple API servers as once. For some time now, the controller manager and scheduler binaries have supported built-in leader election with the --leader-elect option.