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

51–60 of 74 posts

Re: Container orchestration: Moving from fleet to Kubernetes

#51

Post by gnur »

EtienneK wrote: post #46
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…

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…

Because Kubernetes, even though it is still young, is a lot more mature then Docker Swarm.

Kubernetes is also based on years of running containers with Google itself, it solves real problems. Allowing containers to run in the same pod allows for much nicer composability than running multiprocess containers.

Have you tried setting up a k8s cluster recently, I believe they added kubeadm for much easier setup in 1.5, which was released a few weeks ago.

Re: Container orchestration: Moving from fleet to Kubernetes

#52

Post by Intermernet »

As someone who's been working with containers since docker was released, I feel like this is the right decision.

CoreOS are awesome, and I hope that rkt takes off (no pun intended)

K8s has been a fun companion to travel with on the road to stability, but I think they've now got it right. I remember the confusion regarding config file formats, network architecture, persistent storage etc and I'm happy to say they've mostly got it nailed now.

Congrats to thocken and team ️

My next experiments are with the smartos docker support and Kubernetes. Hopefully I can get K8s running nicely on solaris zones and get better container isolation happening ️

Once again, I think CoreOS have made the right decision here, but that doesn't preclude major changes in K8s itself!

Re: Container orchestration: Moving from fleet to Kubernetes

#53

Post by raesene6 »

nollbit wrote: post #50
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…

The other responses to your posts are great, but I'd like to add one thing to them; Why are you equating low barrier of entry with quality? I think MongoDB ought to have taught everybody in this field that you can have a low barrier of entry and still be a crap product.

I didn't see any mention of quality in GP's post... For me Docker swarm is a simpler implementation than Kubernetes and likely more suitable for simpler deployments.

Kubernetes whilst a cool product still has a lot of rough edges even now. One I encountered recently was that to upgrade a locally deployed cluster from 1.4 to 1.5 the answer appears to be "re-install from scratch" as the upgrade script is still "experimental" (https://kubernetes.io/docs/admin/cluster-management/#upgradi...)

Re: Container orchestration: Moving from fleet to Kubernetes

#54

Post by raesene6 »

I think Kubernetes is a really interesting product and obviously has a lot of momentum. That said for something thats seeing wide adoption it still has a lot of rough edges and things that need fleshed out.

One I ran across recently was the upgrade process for clusters. Per (https://kubernetes.io/docs/admin/cluster-management/#upgradi...) it seems that unless you're on GCE the best way to upgrade a cluster is by rebuilding it from scratch as the upgrade script is still "experimental", which doesn't seem great.

The other area that I think Kubernetes is lagging Docker quite a bit on is security documentation and tooling. There's no equivalent of the CIS guide for Docker or Docker bench, both of which are useful in understanding the security trade-offs of various configurations and choosing one that suits a given deployment.

Re: Container orchestration: Moving from fleet to Kubernetes

#55

Post by eicnix »

raesene6 wrote: post #54

I think Kubernetes is a really interesting product and obviously has a lot of momentum. That said for something thats seeing wide adoption it still has a lot of rough edges and things that need fleshed out. One I ran across recently was the upgrade process for clusters. Per ( https://kubernetes.io/docs/admin/cluster-management/#upgradi... ) it seems that unless you're on GCE the best way to upgrade a cluster is by re…

Building a cluster from scratch is usually not a bad idea: You create a new cluster with the upgraded version, combine both clusters through federation and start moving pods from the old to the new cluster.

Upgrading a cluster in place will come in the future.

Re: Container orchestration: Moving from fleet to Kubernetes

#56

Post by eicnix »

sytse wrote: post #14
tyingq wrote: post #9

Earlier quoted context omitted.

Might be interesting for the docker runtime in the future as well. That is, assuming k8s spends enough time on supporting alternatives like rkt as well as docker.

Do you think k8s's support for docker and rkt will become the same as the interface becomes standardized with the Open Container Initiative? https://www.opencontainers.org/about

There is currently a ongoing refactoring of the container communication stuff in kubernetes to remove all container engine specific code and just use the Open Container Runtime Interface. This allows any container engine to run with kubernetes as long as they implement the Open Container Runtime Interface.

Re: Container orchestration: Moving from fleet to Kubernetes

#57

Post by raesene6 »

eicnix wrote: post #55
raesene6 wrote: post #54

I think Kubernetes is a really interesting product and obviously has a lot of momentum. That said for something thats seeing wide adoption it still has a lot of rough edges and things that need fleshed out. One I ran across recently was the upgrade process for clusters. Per ( https://kubernetes.io/docs/admin/cluster-management/#upgradi... ) it seems that unless you're on GCE the best way to upgrade a cluster is by re…

Building a cluster from scratch is usually not a bad idea: You create a new cluster with the upgraded version, combine both clusters through federation and start moving pods from the old to the new cluster. Upgrading a cluster in place will come in the future.

Whilst for major upgrades that might make sense, what about instances like a high risk security fix where upgrade speed is important... People don't want to be re-building from scratch in that kind of setup...

Re: Container orchestration: Moving from fleet to Kubernetes

#58

Post by Plugawy »

vidarh wrote: post #41
wmf wrote: post #35

Earlier quoted context omitted.

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

kubeadm is not fixing the underlying complexity - it's putting a veneer on top. It's certainly helpful to simplify the deployment, but kubeadm is only needed in the first place because of how complicatd kubernetes is. To be clear I'm not saying there aren't deployments where the complexity of something like kubernetes isn't necessary. But most people only run a small number of servers. I'd argue most clusters people…

That's the boat I'm I'm - we have less than a dozen services and all we need is packing them neatly on worker nodes and some load balancing. Setting up Kubernetes for that looked like an absolute overkill. I need to try Docker Swarm and Nomad again but either of them has to support rolling deploys out of the box - lasy time o checked neither of them did

Re: Container orchestration: Moving from fleet to Kubernetes

#59

Post by chad-autry »

tvaughan wrote: post #16
chad-autry wrote: post #11

I've been telling friends and co-workers I think kubernetes has won the orchestration war. But even as I did so I wanted something simpler for my own purposes, and so was using fleet. Luckily for me, I'd stuck with making all my units global and driving their deployment off of metadata. I think I'll just strip off the [X-fleet] section, and start deploying them straight to systemd with ansible.

Or just copy them? https://gitlab.com/tvaughan/docker-flask-starterkit/blob/mas...

Ansible brings inventory management to the table. I can have an inventory with my backend and frontend instances tagged, run my playbook, and it will copy/start the appropriate systemd units.

Re: Container orchestration: Moving from fleet to Kubernetes

#60

Post by johnhenry »

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

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