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

Convergence to Kubernetes

medium.com

Post reply on HN
Print view View original

51–60 of 124 posts

Re: Convergence to Kubernetes

#51

Post by asfdsfggtfd »

rehemiau wrote: post #41
thawkins wrote: post #35

Earlier quoted context omitted.

We enforced that by giving our devs linux workstations with no sudo rights (iso27001 requirement), but they have access to the docker daemon, and MUST install everything they need in docker images, its massively increased tools sharing between teams, and forced people to learn docker. We have some devs starting to use kubernetes locally using minikube .

Sorry for being off-topic but do you have any links or tips on how to achieve this? My understand was that adding a user to the 'docker' group gives him 'sudo'-equivalent rights.

You can set it up so that the user doesn't have to type sudo docker. But they still effectively have root access via docker.

I guess it gives some social pressure not to do superuser things?

Re: Convergence to Kubernetes

#52

Post by rdsubhas »

polskibus wrote: post #6

Is there a recommended way to handle database migrations in kubernetes? Is there a best practice or a tool for that?

We "kubectl run" the migration in CI as a simple bare pod. It will shutdown itself after migrations are done.

For getting the resource configuration, we render the "helm template", take out the workload's podspec and supply additional parameters to invoke the migration.

Re: Convergence to Kubernetes

#53

Post by amazingman »

gnur wrote: post #50
hardwaresofton wrote: post #30

Can anyone who used Docker Swarm/Mesos/Nomad and then switched to Kubernetes comment on anything that was done better by Swarm/Mesos/Nomad? I invested in Kubernetes early and always meant to give the others a try (so I could at least know the differences), but never got a chance to.

Having used both DC/OS (mesos & marathon) and kubernetes in production. The one thing DC/OS had absolutely nailed was the web interface and bootstrap. The DC/OS interface is brilliant as it allows you to explore all the possibilities and actually have a overview of what is happening. Also, it was a lot easier to reason about because everything is contained in a single marathon job. No need to split everything up in d…

It seems to me that running Kubernetes as a service on DC/OS might be a decent path to take. Mesosphere seem to be pushing this pretty hard, too.

What did you think of DC/OS as a base platform? From an ops perspective, I’m finding a lot to like at least conceptually. Especially the idea of managing one “kind” of cluster that then manages many additional kinds for you. But I have yet to actually use it.

Re: Convergence to Kubernetes

#54

Post by zwischenzug »

keypusher wrote: post #13
ordinaryperson wrote: post #2

Dumb question from someone who doesn't use Kubernetes (or Docker) in production: don't routine security updates mean you're constantly rebuilding and redeploying these images? And if so, how is that more efficient than just using Puppet / Chef / Ansible and a 'real' server?

I don't think people primarily choose Docker because it's more efficient(?) to deploy than a real server. The benefits of Docker, to me, are having a single artifact and reproducible builds where a developer can run the docker image locally, it then gets built once on Jenkins, and the same image is deployed to staging, production, etc. It eliminates an entire class of problems related to the operating system, install…

Depends who's doing the choosing. Where it takes months to provision a 'real' server, Docker saves an awful lot of time and effort.

But most people choose Docker because it's well-known, well supported, and the experience outside corporate environments is a joy.

Re: Convergence to Kubernetes

#55

Post by piva00 »

minieggs wrote: post #40
hardwaresofton wrote: post #30

Can anyone who used Docker Swarm/Mesos/Nomad and then switched to Kubernetes comment on anything that was done better by Swarm/Mesos/Nomad? I invested in Kubernetes early and always meant to give the others a try (so I could at least know the differences), but never got a chance to.

I would love to see a comparison between Docker Swarm and Kubernetes. From talking to peeps I've got that Kubernetes is better for a large number of nodes? I self host all my side projects with Docker Swarm and it's been so good I haven't needed to look into other container management solutions (but I've only got eight nodes).

At the moment I'd say that Kubernetes is only worthy the effort if you have a bunch of idle capacity in your nodes and some tens of machines at least.

The setup can get a bit complex quite early and won't be worth the effort to manage 8 nodes, when you begin to scale to around 20 nodes running a bunch of different workloads (batch jobs, web services, etc.), can avoid provisioning on the application side, etc., then k8s begins to shine more and pay back the investment.

Re: Convergence to Kubernetes

#56

Post by bonesss »

mmt wrote: post #37
101km wrote: post #9

"The result was a system composed of many wavefronts of change: some systems were automated with Puppet, some with Terraform, some used ECS and others used straight EC2. In 2012 we were proud to have an architecture that could evolve so frequently, letting us experiment continually, discovering what worked and doing more of it. In 2017, however, we finally recognised that things had changed. AWS is significantly more…

I do certainly wonder if the ever-increasing levels of complexity in the layers of abstraction will backfire in some way soon. It seems the trend has accelerated recently.

Luckily there's an easy fix for that: adding more layers abstraction :D

Re: Convergence to Kubernetes

#57

Post by bonesss »

MPSimmons wrote: post #36
polskibus wrote: post #6

Is there a recommended way to handle database migrations in kubernetes? Is there a best practice or a tool for that?

What do you mean when you say 'database migration'? In my mind, there could be a few things: 1) Migrating the database from server A to server B where the server is on Kubernetes A1) Don't do this. Don't run a (traditional) database server in Kubernetes. Sure, you can do this - there are all kinds of volume support for all kinds of things. Everything I've ever heard and read has told me that containers aren't a good…

> Don't run a (traditional) database server in Kubernetes.

With node affinities and persistent volumes this might not be A Bad Thing, per se... For something mission critical I'd keep the DB on a VM, though.

One interesting development in the Kubernetes space are plugins which expose VMs outside of the cluster to Kubernetes as though it were just another container. That may provide the best of both worlds: a traditional VM and automated scheduling.

Re: Convergence to Kubernetes

#58

Post by kawsper »

jes5199 wrote: post #21
nh2 wrote: post #16

Earlier quoted context omitted.

> don't routine security updates mean you're constantly rebuilding and redeploying these images? It means you should be constantly rebuilding and redeploying these images. The fewest people I've seen use Docker actually do that. The answer I've heard most commonly so far is "uh hmm ... right, given that I see new CVEs fixed every day, scrolling by in the `apt-get dist-upgrade` I do daily on my desktop, we should prob…

who has an app that they don’t deploy daily?

Many - and our deploys on weekends are almost zero.

Re: Convergence to Kubernetes

#59

Post by adamtulinius »

lowbloodsugar wrote: post #42
hardwaresofton wrote: post #30

Can anyone who used Docker Swarm/Mesos/Nomad and then switched to Kubernetes comment on anything that was done better by Swarm/Mesos/Nomad? I invested in Kubernetes early and always meant to give the others a try (so I could at least know the differences), but never got a chance to.

Mesos is a two layer system. That is what is better about it. Unfortunately, the most common second layer for reliable service execution is Marathon, and it caused us no end of trouble.

Spot on. The two layer system is both a blessing and a curse.

Debugging problems can get really hairy because of the two layer split, and it's just not worth it if one is running Marathon as the only framework.

I came to the conclusion that Mesos' biggest strength is giving people the option to write their own framework. It's not difficult, and gives you a lot of power over execution.

Marathon itself appears to be very simple, but has some really weird shortcomings. For instance, it's not possible to submit a deployment and then check whether everything went well, except if you manually compare the deployment before and after (this was still true as of 1.4.x).

Furthermore, Mesosphere abandoned the Marathon GUI, and I got no clue how the work of transitioning that part into the hands of volunteers are coming along, but this was essentially what tipped the scales for us.

(We're currently migrating from Mesos to K8s.)

Re: Convergence to Kubernetes

#60

Post by majewsky »

jes5199 wrote: post #21
nh2 wrote: post #16

Earlier quoted context omitted.

> don't routine security updates mean you're constantly rebuilding and redeploying these images? It means you should be constantly rebuilding and redeploying these images. The fewest people I've seen use Docker actually do that. The answer I've heard most commonly so far is "uh hmm ... right, given that I see new CVEs fixed every day, scrolling by in the `apt-get dist-upgrade` I do daily on my desktop, we should prob…

who has an app that they don’t deploy daily?

I highly doubt that anyone would deploy everything daily. Your own code, maybe. But what about dependencies? Do you upgrade your Postgres container daily?
Post reply on HN