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

The Horrors of Upgrading Etcd Beneath Kubernetes

gravitational.com

Post reply on HN
Print view View original

51–60 of 79 posts

Re: The Horrors of Upgrading Etcd Beneath Kubernetes

#51

Post by jskaggz »

shoo wrote: post #49
jskaggz wrote: post #45

Earlier quoted context omitted.

> Containers allow you to move apps trivially between environments and guarantee that they will just work. Assuming your staff can keep your cluster un-screwed, am I right? Technologies like vmware, (which also give you os independence not just linux flavors) if we're talking on premises also allow you to move apps between environments. It's trivial to, gasp , push a machine out of vmware player to the cloud even. Pi…

> Folks be like, hey a team of consultants just finished building out our new kubernetes cluster, now we want to run our mission critical oracle/mssql servers on it. They said it should work "fine". Too bad they all got jobs at insert mega capacity company here right after we cut the invoice. mmm! http://classicprogrammerpaintings.com/post/131118350394/army... http://classicprogrammerpaintings.com/post/169578560497/r…

Thanks shoo, that made me chuckle - maybe I'm feeling a bit too angsty this Friday evening.

I love all of the new development, we're going great places, we just need to prescribe the right medicine for the patients so to speak. Cocaine was great in coca-cola before folks realized what it was doing to people. :)

Re: The Horrors of Upgrading Etcd Beneath Kubernetes

#52

Post by mirceal »

jskaggz wrote: post #45
threeseed wrote: post #22

Earlier quoted context omitted.

> it's not obvious to me what the business case would be to containerise everything Containers allow you to move apps trivially between environments and guarantee that they will just work. It allows you to isolate dependencies between apps e.g. Python 2 versus Python 3. It allows you to move apps between cloud providers or between on premise and cloud. With platforms like Kubernetes it allows you to easily scale and…

> Containers allow you to move apps trivially between environments and guarantee that they will just work. Assuming your staff can keep your cluster un-screwed, am I right? Technologies like vmware, (which also give you os independence not just linux flavors) if we're talking on premises also allow you to move apps between environments. It's trivial to, gasp , push a machine out of vmware player to the cloud even. Pi…

Have an upvote. Appreciate the pragmatism :)

Re: The Horrors of Upgrading Etcd Beneath Kubernetes

#53

Post by shoo »

jskaggz wrote: post #45
threeseed wrote: post #22

Earlier quoted context omitted.

> it's not obvious to me what the business case would be to containerise everything Containers allow you to move apps trivially between environments and guarantee that they will just work. It allows you to isolate dependencies between apps e.g. Python 2 versus Python 3. It allows you to move apps between cloud providers or between on premise and cloud. With platforms like Kubernetes it allows you to easily scale and…

> Containers allow you to move apps trivially between environments and guarantee that they will just work. Assuming your staff can keep your cluster un-screwed, am I right? Technologies like vmware, (which also give you os independence not just linux flavors) if we're talking on premises also allow you to move apps between environments. It's trivial to, gasp , push a machine out of vmware player to the cloud even. Pi…

I really love how Dan McKinley frames this kind of thing in terms of each company having a budget of "innovation tokens".

http://mcfunley.com/choose-boring-technology

edit: now it's a club! http://boringtechnology.club/

> Let's say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while.

> If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that's existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you're in trouble.

> Any of those choices might be sensible if you're a javascript consultancy, or a database company. But you're probably not. You're probably working for a company that is at least ostensibly rethinking global commerce or reinventing payments on the web or pursuing some other suitably epic mission. In that context, devoting any of your limited attention to innovating ssh is an excellent way to fail.

> There is technology out there that is both boring and bad. You should not use any of that. But there are many choices of technology that are boring and good, or at least good enough. MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring.

Re: The Horrors of Upgrading Etcd Beneath Kubernetes

#54

Post by mirceal »

outworlder wrote: post #44
mirceal wrote: post #24

Earlier quoted context omitted.

Not sure I agree. If you need a container to do the things you mention you’re already in a pretty bad shape. Not to mention that a lot of people don’t understand what a container is.

> Not to mention that a lot of people don’t understand what a container is. Well, I'll bite. Do you? What is a container?

Best definition: there is no such thing as a container. When people say container they usually mean a bunch of kernel features (cgroups, namespaces, apparmor, etc) + an overlay filesystem.

I played with stuff like this since the chroot jail days and knew about containers before they were cool (anyone remember lxc?).

Re: The Horrors of Upgrading Etcd Beneath Kubernetes

#55

Post by mirceal »

mmt wrote: post #48
mirceal wrote: post #24

Earlier quoted context omitted.

Not sure I agree. If you need a container to do the things you mention you’re already in a pretty bad shape. Not to mention that a lot of people don’t understand what a container is.

> Not to mention that a lot of people don’t understand what a container is. That's part of the appeal, the abstraction away of all those pesky, irrelevant details. Developers just want their app to run, as has been mentioned elsewhere in the thread. That desire is understandable. So long as the abstraction isn't too leaky and nothing underneath breaks, there's no downside. It's all upside in terms of human productivi…

Big fan of playing with new tech. In a safe environment where failure is an option. Don’t go betting the farm on shiny things.

Re: The Horrors of Upgrading Etcd Beneath Kubernetes

#56

Post by jskaggz »

shoo wrote: post #53
jskaggz wrote: post #45

Earlier quoted context omitted.

> Containers allow you to move apps trivially between environments and guarantee that they will just work. Assuming your staff can keep your cluster un-screwed, am I right? Technologies like vmware, (which also give you os independence not just linux flavors) if we're talking on premises also allow you to move apps between environments. It's trivial to, gasp , push a machine out of vmware player to the cloud even. Pi…

I really love how Dan McKinley frames this kind of thing in terms of each company having a budget of "innovation tokens". http://mcfunley.com/choose-boring-technology edit: now it's a club! http://boringtechnology.club/ > Let's say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. > If you choose to write your website in NodeJS, you just…

This +1000. :) People, remembering to focus on core-competencies, making the world a better place.

Re: The Horrors of Upgrading Etcd Beneath Kubernetes

#57

Post by smarterclayton »

outworlder wrote: post #38
bonesss wrote: post #35

Earlier quoted context omitted.

> ... not-in-k8s VM One of the cooler innovations we've seen, and I think we're going to see more of, is the ability to take a non-k8s VM and expose it to the cluster as-if it were just another pod. This would let you schedule and expose RDBMs and other specialized servers through kubernetes while keeping them on a standard VM. I think that's the win/win approach to bridge the gap.

Indeed. But I think that doesn't go far enough: I want to provide K8s with a YAML file and have Kubernetes itself go and create and provision a VM for me. I.e, I want to "kill" Terraform. I don't care about a 'fabric' network (although that could be convenient), just give me an IP that I can reach even it if is external to the cluster. VMs could be just one more resource that can be created or destroyed by k8s, just…

We did something simple for GCP and CI jobs, when we needed to have VMs in a certain project to launch Kubernetes single node testing - https://github.com/openshift/ci-vm-operator/

The base pattern should be pretty easy to modify, although the use case here is very specific.

Re: The Horrors of Upgrading Etcd Beneath Kubernetes

#58

Post by mirceal »

outworlder wrote: post #41
mirceal wrote: post #17

This may be an unpopular opinion, but I’m not a big fan of containers and K8S. If your app needs a container to run properly, it’s already a mess. While what K8s has done for containers is freaking impressive, to me it does not make a lot of sense unless you run your own bare metal servers. Even then, the complexity it adds may not be worth it. Did I mention that the tech is not mature enough to just run on autopilot…

> This may be an unpopular opinion, but I’m not a big fan of containers and K8S. It is unpopular for a reason. Disclaimer: if you can run solely on cloud managed services + serveless, please do that and do not even look at the rest of this message. This is a very nice approach, although there are some things you need to setup before calling victory (deployment pipeline is one). And, as you mentioned, there is vendor…

A container is not a process. The fact that you say this makes me wonder if you understand what K8s and how it works.

K8s is not going to solve the issues you outline above (logs, proper monitoring, etc). Even worse, you’re gonna have a bad time migrating them to a proper solution.

Re: The Horrors of Upgrading Etcd Beneath Kubernetes

#59

Post by shoo »

outworlder wrote: post #41
mirceal wrote: post #17

This may be an unpopular opinion, but I’m not a big fan of containers and K8S. If your app needs a container to run properly, it’s already a mess. While what K8s has done for containers is freaking impressive, to me it does not make a lot of sense unless you run your own bare metal servers. Even then, the complexity it adds may not be worth it. Did I mention that the tech is not mature enough to just run on autopilot…

> This may be an unpopular opinion, but I’m not a big fan of containers and K8S. It is unpopular for a reason. Disclaimer: if you can run solely on cloud managed services + serveless, please do that and do not even look at the rest of this message. This is a very nice approach, although there are some things you need to setup before calling victory (deployment pipeline is one). And, as you mentioned, there is vendor…

thank you for writing this up.

> I have spent the last two months implementing automation for deploying a cluster on AWS, with auto-scaling, auto-healing, the works, automatically deployed through Jenkins. It is NOT easy, it is not simple, and it is not focusing on my end application, unless you are ignoring all the technical debt you are incurring.

yes, i can appreciate that having a system automatically handle even some of this necessary plumbing in a reasonable and standardised way is attractive.

Re: The Horrors of Upgrading Etcd Beneath Kubernetes

#60

Post by mmt »

mirceal wrote: post #55
mmt wrote: post #48

Earlier quoted context omitted.

> Not to mention that a lot of people don’t understand what a container is. That's part of the appeal, the abstraction away of all those pesky, irrelevant details. Developers just want their app to run, as has been mentioned elsewhere in the thread. That desire is understandable. So long as the abstraction isn't too leaky and nothing underneath breaks, there's no downside. It's all upside in terms of human productivi…

Big fan of playing with new tech. In a safe environment where failure is an option. Don’t go betting the farm on shiny things.

"Personally" (professionally), neither am I. This kind of conservatism was formed after decades of sysadmin/ops experience.

However, having acquired a strong affinity for startups, I also accept that risk (even complete, betting-the-farm risk) is totally OK, so long as that risk is taken in an informed manner. Startups, especially early ones, are a risky proposition from the get-go, and VC money tends to amplify that.

The market doesn't much punish a web startup that grew like crazy but lost some user-generated content by using some "NoSQL" database when it first came out. It does, however, punish the one that failed to grow by being too conservative.

That's obviously a false dichotomy, but I believe that's essentially the perception that's created, partly by characterizing new technologies as dangerous because they're new and "shiny".

Ultimately, I consider mine to be a service profession and an engineering one. As such, if I think a new tech is too undesirable, it's up to me to provide an alternative that actually addresses the original problems (without offloading the burden onto my users/customers).

Post reply on HN