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

21–30 of 124 posts

Re: Convergence to Kubernetes

#21

Post by jes5199 »

nh2 wrote: post #16
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?

> 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?

Re: Convergence to Kubernetes

#22

Post by manigandham »

ajross wrote: post #15

> We have close to 30 teams that run some or all of their workloads on our clusters. Approximately 70% of all HTTP traffic we serve is generated from applications within our Kubernetes clusters. Sounds big. But then per wikipedia: > uSwitch.com [...] allows consumers to compare prices for a range of energy, personal finance, insurance and communications services. And: > On 30 April 2015, the property website firm Zoo…

Scale isn't everything. Removing "hand-managed" from the entire process is an even bigger benefit.

It's really not that complicated, it's clustering software that lets you encapsulate your applications into containers and just write simple declarative YAML files while it takes care of actually running it as specified, and keeping it running regardless of what happens to the hardware.

Given all the managed offerings now with free master nodes, why would you purposely take on more ops overhead?

Re: Convergence to Kubernetes

#23

Post by lkrubner »

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

Re: Convergence to Kubernetes

#24

Post by baylisscg »

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?

If you're using Helm charts you can add hooks to a few points in the deployment process to give you database migrations. Currently I'm using an install hook to create the DB and upgrade hooks to migrate on deploy.

Re: Convergence to Kubernetes

#25

Post by oso2k »

marcc wrote: post #18
ajross wrote: post #15

> We have close to 30 teams that run some or all of their workloads on our clusters. Approximately 70% of all HTTP traffic we serve is generated from applications within our Kubernetes clusters. Sounds big. But then per wikipedia: > uSwitch.com [...] allows consumers to compare prices for a range of energy, personal finance, insurance and communications services. And: > On 30 April 2015, the property website firm Zoo…

Should any business that has SLAs and needs to be reliable ever rely on “2-3 hand-managed servers”? No. Kubernetes isn’t only about scale. It also provides rolling upgrades and rollbacks. And failover. And DNS based service discovery. And there’s more. You can find solutions to these without Kubernetes but a lot of Kubernetes use is to get these, not simply for scale issues.

Full-disclosure: I’m a Consulting Architect at Red Hat focused on OpenShift.

I like to say Kubernetes & OpenShift focus on availability of the cluster and applications as their primary concern. Many other concerns my customers want to impose are actually detrimental to the goal(s) they’re trying to achieve.

Re: Convergence to Kubernetes

#26

Post by jrs95 »

nh2 wrote: post #16
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?

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

You probably shouldn’t be using Ubuntu base images anyways. The closer you can get to “scratch” the better, and the fewer security related issues you’ll have. For most use cases I think Alpine is a much better base image.

Re: Convergence to Kubernetes

#27

Post by oso2k »

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?

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 app’s config in a git repo or next to the app in git.

[0] https://docs.openshift.com/container-platform/3.9/dev_guide/...

[1] https://docs.openshift.com/container-platform/3.9/dev_guide/...

Re: Convergence to Kubernetes

#28

Post by tonyarkles »

accnumnplus1 wrote: post #20
ajross wrote: post #15

> We have close to 30 teams that run some or all of their workloads on our clusters. Approximately 70% of all HTTP traffic we serve is generated from applications within our Kubernetes clusters. Sounds big. But then per wikipedia: > uSwitch.com [...] allows consumers to compare prices for a range of energy, personal finance, insurance and communications services. And: > On 30 April 2015, the property website firm Zoo…

30 teams' services fit on 2-3 servers? We don't have anywhere near 30 teams, but at my last count end of last year there were ~250 repos, and everyday I get auto-emailed telling me I've been subscribed to a new repo. No way could we have only 2-3 servers.

I'm perpetually curious about what kind of resource usage you'd expect given those 250 repos, and which runtime you're deploying.

I've recently been playing with Go and looking at existing JVM-based services (Spring Boot + starters + our microservices). We've seen rewrites of small services change from ~500MB of RAM to ~10MB of RAM. 250 Go-based services would probably fit very comfortably on a small cluster of cheap-ish servers, depending on what they're doing and how much traffic they're handling.

Re: Convergence to Kubernetes

#29

Post by twblalock »

ajross wrote: post #15

> We have close to 30 teams that run some or all of their workloads on our clusters. Approximately 70% of all HTTP traffic we serve is generated from applications within our Kubernetes clusters. Sounds big. But then per wikipedia: > uSwitch.com [...] allows consumers to compare prices for a range of energy, personal finance, insurance and communications services. And: > On 30 April 2015, the property website firm Zoo…

Hand-managed servers should not exist anymore outside of proof-of-concept work. There is no shortage of tools to automate provisioning and deployment, and Kubernetes is one of many options. Bringing up servers should be as automated and reproducible as your CI pipeline for building software -- when you discover problems, go ahead and fix them manually, but then you should update your automated processes to include them.

Re: Convergence to Kubernetes

#30

Post by hardwaresofton »

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.

Post reply on HN