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

91–100 of 124 posts

Re: Convergence to Kubernetes

#91

Post by barrkel »

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?

Some of us have contractual obligations not to deploy during the week, and require us to notify and receive permission from our customers for out of band deployments.

Re: Convergence to Kubernetes

#92

Post by barrkel »

lkrubner wrote: post #23
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?

Docker is a dangerous gamble and you can get more of an automated build system, with less devops effort, from Terraform and Packer. Avoid containers and stick with real servers “baked” by Packer: http://www.smashcompany.com/technology/docker-is-a-dangerous...

I've not been impressed by docker outside of the local development experience (primarily, creating sandboxes and avoiding installing stuff on the main OS, and not having the latency of starting up a VM).

This discussion is about Kubernetes though. Docker is mostly only incidental to Kubernetes. It's a much better thought through system than anything I've seen come out of the Docker world. Docker images are adequate; Dockerfile as a build mechanism for images is deeply flawed, requiring so many kludges and duct tape to accommodate shared dependencies, rebuild on upstream change, shrinking after building, etc.

Hopefully a better system for building images to run on Kubernetes will crop up.

Re: Convergence to Kubernetes

#93

Post by bsenftner »

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?

From Saturday's posts: http://catern.com/posts/docker.html An assessment of what Docker and similar actually are, and why they are unneeded redundant, insecure technology.

Re: Convergence to Kubernetes

#94

Post by AaronM »

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 think Nomad is a good solution when your unable to containerize your application, used it a bit at my last job in a prototype we were building to manage windows services, and it seemed to work pretty well

Re: Convergence to Kubernetes

#95

Post by draw_down »

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…

Ahhh man, you quoted all that just to say “this time it’s different”?!

Re: Convergence to Kubernetes

#96

Post by falsedan »

hardwaresofton wrote: post #80
falsedan wrote: post #79

Earlier quoted context omitted.

Yeah with bare mesos I don't have to do any of that, I just accept resource offers and release them when I'm done. The scheduler decides how much it will scale, not mesos. We like to create a new framework for each instance of the job (so we can track slow runs, trial-run new versions), so we can have anywhere between 0 and 50 similar frameworks all running and vying for 100% of the cluster. Naturally, we have cluste…

It was kind of hard to understand what you were describing without reading the Mesos Architecture documentation[0], but I think I get it now. When you say "you" just accept resource offers, you mean the frameworks (in mesos terminology) you're deploying correct? Weirdly enough, Mesos resembles a system I was building in my head that I thought could compete with Kubernetes... Taking the resource supplier (agents in me…

Essentially, yeah. You don't really deploy a framework, you just start its scheduler. I recommend the technical paper, it's clear and short[0].

0: https://people.eecs.berkeley.edu/~alig/papers/mesos.pdf

Re: Convergence to Kubernetes

#97

Post by erikb »

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.

Swarm:

- works out of the box

- has much less overhead in getting something started

- tracks dependencies between services

Re: Convergence to Kubernetes

#98

Post by erikb »

snuxoll wrote: post #48
oso2k wrote: post #27

Earlier quoted context omitted.

Full-disclosure: I’m a Consulting Architect for Red Hat focused on OpenShift. No. In Kubernetes and OpenShift you can control whether builds and deployments are automatic or manual, & which events triggers them [0][1]. Combined with fact that each application’s config is an independent object, this allows an admin to host hundreds of apps on a single cluster node. Usually you’re using IaC practice and storing each ap…

OpenShift has an answer to what GP was asking, but build triggers are not it. Security vulnerabilities in images is the concern, OpenShift handles this through ImageStream('s) - parent images are tracked in the integrated registry and when one is updated all dependent images are updated. Good example, the dotnet image in our OpenShift cluster was updated late last week - all of our .Net Core projects were automatical…

Kubernetes itself is not a PaaS though. It won't do all of that for you, which has the advantage of being more flexible but the disadvantage that nothing happens if you don't code it.

Re: Convergence to Kubernetes

#99

Post by erikb »

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…

> [...] this time, it is different.

Literally a quote from my managers (not related to k8s or aws alone, though). They also made sure to repeat that phrase a few times so it becomes more believable.

Re: Convergence to Kubernetes

#100

Post by erikb »

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?

On premise I wouldn't suggest to run your DB inside kubernetes. It's ugly. Because on prem storage is not really solved yet (and google has no interest in changing that).

And in the cloud what would be a migration scenario? (serious question, never did it in the cloud but would suspect there are fewer scenarios in which migration is necessary)

Post reply on HN