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

The full-time job of keeping up with Kubernetes

gravitational.com

Post reply on HN
Print view View original

51–60 of 237 posts

Re: The full-time job of keeping up with Kubernetes

#51

Post by nova22033 »

mbrumlow wrote: post #24

Every time a new framework or tool comes out and everybody jumps on it. I always wonder if somebody will realize that you are trading one set of problems and work for another. As engineers we really need to stop supporting these sort of effort and take the time to help each other become better engineers that write and maintain our own code. We need to promote learning and mastering the underlying concepts that things…

>We need to promote learning and mastering the underlying concepts

Should we do the same thing for programming languages? Make sure people are learning and mastering assembly?

>Only to be stuck with a solution that requires constant care and work around.

I've seen this attitude from people who didn't want to use ansible/chef/puppet because their shell scripts were "good enough". Like the shell scripts didn't require constant care..

Re: The full-time job of keeping up with Kubernetes

#52

Post by mbrumlow »

gouggoug wrote: post #40
mbrumlow wrote: post #24

Every time a new framework or tool comes out and everybody jumps on it. I always wonder if somebody will realize that you are trading one set of problems and work for another. As engineers we really need to stop supporting these sort of effort and take the time to help each other become better engineers that write and maintain our own code. We need to promote learning and mastering the underlying concepts that things…

I don't think your comment applies at all to Kubernetes. K8s truly simplifies dev-ops and even the smallest team and website can greatly benefit from it. I speak from 7 years of experience managing my company's infrastructure's website: Before kubernetes, I ran my company's stack on very cheap bare metal from OVH. It was great while it lasted, but as the company grew and my team grew, it's become harder and harder to…

> and no amount of Ansible/SaltStack/Puppet script will save you from this.

And I am afrade you missed my point entirely if you are bring up yet again more tools and frameworks.

Owning your stack from the top to the bottom - with very few exceptions is what I am suggesting.

I too also speak from experience, and have a few years on you -- not that any of that matters.

If your environments diverged then you did not own your stack properly. It is within every engineers ability to build out a stack that runs the same on each environment. It just means understanding that problem domain and taking the time to write the code that fits.

Far too many times have I smacked the hand of a coworker suggesting using any of these bail wire and duct tape solutions you just mentioned. The end result is we have a wonderful system that we own and can ensure meets our needs. The same binaries, configurations and images are pushed from alpha to staging and finally production with full control of evey artifact at the start of the pipeline.

Re: The full-time job of keeping up with Kubernetes

#53

Post by gtirloni »

shruubi wrote: post #35

This article concerns me, especially considering the first thing you see is "There is no such thing as Kubernetes LTS (and that’s fantastic)". What is so great about running your infrastructure on a platform that has no intention of ensuring long-term stability? Irregardless of how well backward-compatibility is maintained, the idea that we should all move our infrastructure to something that lacks the fundamental pr…

> What is so great about running your infrastructure on a platform that has no intention of ensuring long-term stability?

Kubernetes uses API versioning and takes backward compatibility very seriously for stable APIs.

Regarding LTS, these discussions are happening and increasing in number as time passes. Example: https://www.youtube.com/watch?v=fXBjA2hH-CQ

Re: The full-time job of keeping up with Kubernetes

#54

Post by wwweston »

SteveNuts wrote: post #34
halayli wrote: post #14

This is a problem I faced using ansible, webpack + js modules, and more. it's a moving ground and you always need to keep up to date with the latest changes often which are breaking. I tend to design my systems so that they work even if I haven't touched a line in a year but when using such tools it's always a pain. I wish things were as stable as a bourne shell and unix environment in general. Not that they achieve…

I wasn't around for it, but I bet you'd say the same thing about Bourne Shell when it was new. The tools will stabilize as they mature, they're still very new comparatively.

Or... as they "mature", people will start talking about how kubernetes is for old crusty engineers over 27 who just don't want to learn anything new, why don't they just learn ganymandias which is much more modern.

Re: The full-time job of keeping up with Kubernetes

#55

Post by aberoham »

iooi wrote: post #50
aberoham wrote: post #12

Earlier quoted context omitted.

Author here. I do have a bias toward GKE but that is after trying to use everything else -- DIY, kubespray, OpenShift, Juju, Tectonic, Azure, Fargate, kops, Rancher v2 preview, kubeadm, etc. In my experience nothing (yet) has been as nice and clean as Google Cloud.

Have you tried EKS?

Have not, was not invited to the preview. Friends behind bootkube hinted that the EKS team seamed to be heading in directions that were odd relative to upstream. Happy to try it and be pleasantly surprised!

Re: The full-time job of keeping up with Kubernetes

#56

Post by mbrumlow »

nova22033 wrote: post #51
mbrumlow wrote: post #24

Every time a new framework or tool comes out and everybody jumps on it. I always wonder if somebody will realize that you are trading one set of problems and work for another. As engineers we really need to stop supporting these sort of effort and take the time to help each other become better engineers that write and maintain our own code. We need to promote learning and mastering the underlying concepts that things…

>We need to promote learning and mastering the underlying concepts Should we do the same thing for programming languages? Make sure people are learning and mastering assembly? >Only to be stuck with a solution that requires constant care and work around. I've seen this attitude from people who didn't want to use ansible/chef/puppet because their shell scripts were "good enough". Like the shell scripts didn't require…

Well it is a good thing I did not suggest shell scripts, ansible or puppet. I suggested owning it stack. Which means wiring code and tools to suite your needs.

Deployment and upgrades should be built in - as in it is part of your product. Not some afterthought.

It's odd how the two replies have read have jumped to conclusions about what one might use if they were not using kubernetes.

Re: The full-time job of keeping up with Kubernetes

#57

Post by lugg »

icebraining wrote: post #42
mancerayder wrote: post #32

Earlier quoted context omitted.

These are excellent points and very interesting food-for-thought, the 'organizational thinking' that leads to the tools being terribly complex and steep to learn for individuals. But don't these tools have product managers, and don't product managers create tools to serve customers? The only cynical viewpoint that I can think of for artificial (or lazy) complexity is consulting dollars.

Google does consulting now?

Now?

If you spend enough they always have.

Re: The full-time job of keeping up with Kubernetes

#58

Post by VHRanger »

jstimpfle wrote: post #39
kakarot wrote: post #26

Earlier quoted context omitted.

The most valuable skill is knowing when to externalize your tools. You don't always want to reinvent the wheel every time you need something, when you have deadlines to consider.

Is that in support of using the Boost filesystem API?

IMO, only if you're using g++ or older versions of the standard. MSVC, clang and ICC have all supported the experimental::filesystem module for years at this point.

Re: The full-time job of keeping up with Kubernetes

#59

Post by mbrumlow »

nova22033 wrote: post #51
mbrumlow wrote: post #24

Every time a new framework or tool comes out and everybody jumps on it. I always wonder if somebody will realize that you are trading one set of problems and work for another. As engineers we really need to stop supporting these sort of effort and take the time to help each other become better engineers that write and maintain our own code. We need to promote learning and mastering the underlying concepts that things…

>We need to promote learning and mastering the underlying concepts Should we do the same thing for programming languages? Make sure people are learning and mastering assembly? >Only to be stuck with a solution that requires constant care and work around. I've seen this attitude from people who didn't want to use ansible/chef/puppet because their shell scripts were "good enough". Like the shell scripts didn't require…

You should master any subject you were hired for to do work in.

I find it hard to equate deploying and maintaining your production environments to assembly.

Re: The full-time job of keeping up with Kubernetes

#60

Post by lugg »

aberoham wrote: post #12
hueving wrote: post #5

This reads like a giant ad for GKE. It emphasizes several times to just use GKE for pretty lame reasons (Google has good SREs and Google started the project). The people that work on upstream k8s in Google (Tim et al) have a pretty limited overlap with the Google Cloud people that run GKE. Upstream k8s is a full time job so they are most certainly not spending their time also writing internal GKE code. I don't have a…

Author here. I do have a bias toward GKE but that is after trying to use everything else -- DIY, kubespray, OpenShift, Juju, Tectonic, Azure, Fargate, kops, Rancher v2 preview, kubeadm, etc. In my experience nothing (yet) has been as nice and clean as Google Cloud.

Curious why swarm isn't in that list.

How many services / nodes are you managing?

I found the docker swarm learning curve to be very sharp but plateaued super quick, maybe a month of reading docs and bug reports then I was up to speed and don't really run into day to day issues.

Once your prod is setup and you've worked out all the hard decisions around stack and how to do things, getting Devs up to speed is really easy because all they need to know is how to read the docker compose reference.

Even less of any issue learning everything now too because they redesigned their documentation (wording etc as well) and it's much clearer, gotchas are explained etc.

Post reply on HN