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

121–130 of 237 posts

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

#121

Post by jacques_chester »

cookiecaper wrote: post #106
kev009 wrote: post #43

Earlier quoted context omitted.

Sounds like full employment theorem at work. I haven't kicked the tires on kubernetes yet but I don't really see what all the fuss is about. I liked AMPLab and Mesos but I guess that doesn't have the branding power of big G.

100% the case. k8s is not a terrible thing and there are good uses for it, but the vast majority of people who are using it don't understand what it's doing, and don't understand that their application is not equipped to handle that type of execution model. Just yesterday I had someone tell me "Kubernetes was like magic and it made everything easy". This is absolutely not the thing a serious/honest Kubernetes user wo…

> There is a serious, concerted effort by Google to put k8s at the forefront, and they are not playing games with it.

Well no, and why would they? Containerisation is one way to crowbar workloads out of VMs and AWS. Since they're coming from behind, their best strategy is to deny everyone else any oxygen by creating an opensource winner. And it worked: Amazon have added EKS to ECS, Azure added AKS to ACI.

Google does a lot of good, but they don't sink millions upon millions of dollars into things just for the hell of it.

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

#122

Post by shruubi »

aberoham wrote: post #49
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…

Author here. The point is that the stable APIs are rock solid, the design of its API versioning and the community's pace of delivery is a huge part of why it's all maturing so quickly.

That's all well and good until it isn't anymore. And to top it off, your recommendation is to either hire someone to manage k8s full-time or be at the mercy of your cloud vendor and hope that one day you don't turn up to work to find that the new update you weren't aware was being rolled out has just broken everything.

You can't ask a large-scale company to take a dice-roll on k8s for their infrastructure when the only promise of long-term reliability is "trust us not to make any breaking changes".

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

#123

Post by smarterclayton »

dralley wrote: post #118
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…

>"There is no such thing as Kubernetes LTS (and that’s fantastic)" OpenShift?

Technically OpenShift isn’t LTS yet, it’s 1 year and 3 year (the latter is special extended support). Right now we’re planning on 1.9 being our first LTS with the longer support commitment (3yr?). Still being sorted out.

We won’t be doing the 10 year support like for RHEL 4/5/6 yet.

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

#124

Post by gouggoug »

cookiecaper wrote: post #104
gouggoug wrote: post #40

Earlier quoted context omitted.

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…

> I don't think your comment applies at all to Kubernetes. It does. I've deployed and maintained our company's infrastructure on Kubernetes for over a year now. > K8s came as a savior to all my issues: I burned all my old ansible scripts and rewrote all my infrastructure in k8s. This doesn't make any sense. Ansible scripts out changes to make to a system. Kubernetes deals only with opaque images and does not change t…

> Ansible scripts out changes to make to a system. Kubernetes deals only with opaque images and does not change them at all, it simply runs them.

You are exactly right.

Ansible makes the best effort possible to bring your system to a given state (the state you coded in Ansible). All those tools (puppet/salt/ansible) do this exact same thing, and they all manage to do it more or less well.

However, the keyword here is "best effort". That is, it is in practice really hard to consistently bring a system from a random state to a given state X, because of the randomness of your starting state.

Kubernetes doesn't do that, it just manages the lifecycle of your state and makes sure that things run. As an added bonus, it allows you to inject some external configuration to your system, and some other "cool stuff".

You build your state in terms of container images, that once they've been built are by matter of fact set in stone. You then instruct K8s to run all those images.

That, to me, is much more powerful than "scripting out changes to a system".

My scripts are always unreliable and run inconsistently because I make mistakes. In contrast, my container images always run the same way, be they scheduled on my dev machine running mac os, or on my GCE cluster, or my microsoft azure nodes.

> your post does not make sense because it is talking about tools that do different things. It's like saying you love hammers and hope to never use wrenches again.

Those tools k8s and ansible/puppet/etc set out to do the _same thing_. That's the nuance here.

They all set out to bring your infrastructure to the state you programmed.

It so happens that k8s (and more precisely container images) are much better at keeping at consistent state for obvious reasons (container images are state).

K8s is just the cherry on the "container technology cake". It schedules things and makes sure they run, for you.

You weren't too far off with your hammer analogy, but it's more like: ansible is a manual saw and it gives me many blisters, K8s is a chainsaw.

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

#125

Post by kckkdkd929292 »

robocat wrote: post #116
jstimpfle wrote: post #23

Earlier quoted context omitted.

And it's not only that - Time spent not doing our own designs (and instead spent memorizing how to use magical frameworks) is time not spent advancing our technical understanding. It's a sad state when otherwise very intelligent people think it's bad practice to use plain C and a clean OS API that has been stable for decades (because that was somehow "magic" und impossible to understand and error-prone), and advise y…

Concatenating two paths is difficult if you care about any of the following: security, multiple OS's, Unicode (multiple code units, validity, combining characters), file system restrictions, etc. Your "two decades" maybe holds for Linux, but what about Windows or MacOS???! I have seen too many people use string concatenation. I think an intelligent person would recommend to use the normal library (appropriate for you…

seems like the sort of thing people should know how to spot then

otherwise you’re getting security through obscurity of a magic framework no one has time to vet

looking at you, openssl, etc, etc

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

#126

Post by kckkdkd929292 »

ionforce wrote: post #72
flukus wrote: post #66

Earlier quoted context omitted.

Bug trackers are one of those areas where a lot of companies should build there own. Everyone has there own workflows and information to capture and end up either conforming their process to the bug tracker or spending more time configuring the bug tracker than they would to build a new system from scratch. Those uber configurable systems always suck to use. Ones like JIRA can takes weeks to setup for your org and in…

> Bug trackers are one of those areas where a lot of companies should build there own. This sounds insane. I have not worked at a place where the workflow was so holy and important that it couldn't be captured in a near default JIRA install. Most of the customization asks I've seen with JIRA come from dysfunctional organizations that demand new swimlanes like "QA" and "product approval" and "spec design".

dont spend money building

spend it on vendor lock-in

i guess if you want to change the world with todo app that probably makes sense

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

#127

Post by kakarot »

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?

I don't use C++ outside of games programming, I'm not familiar with the Boost filesystem API.

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

#128

Post by pjmlp »

jstimpfle wrote: post #23
lkrubner wrote: post #3

Earlier quoted context omitted.

I wish I could give you more upvotes. You are describing a somewhat hidden psychology, which I think provides a rational basis for much of "Not Invented Here" psychology. We tend to think that "Not Invented Here" psychology is irrational, but in fact, the loss of control over possibly crucial technology is an important cost, which makes all of us stop and re-consider whether we really want to use some software develo…

And it's not only that - Time spent not doing our own designs (and instead spent memorizing how to use magical frameworks) is time not spent advancing our technical understanding. It's a sad state when otherwise very intelligent people think it's bad practice to use plain C and a clean OS API that has been stable for decades (because that was somehow "magic" und impossible to understand and error-prone), and advise y…

The amount of security exploits due to memory corruption in software written in C proves that during the last 50 years, it isn't that well understood.

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

#129

Post by sandGorgon »

lugg wrote: post #60
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.

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

Agreed. I absolutely love Swarm and think they have done a great job of an integrated solution.

However, I'm keen to see if Swarm becomes a later on top of Kubernetes instead of a separate piece if infrastructure.

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

#130

Post by jrochkind1 »

bigiain wrote: post #74
jrochkind1 wrote: post #11

Earlier quoted context omitted.

I dunno, if it's an ad for GKE, then "you typically have only about nine months until the latest version goes out of support" is indeed pretty persuasive marketing to me to let someone else deal with it.

This is a showstopper for me. All our best clients are on a 12 or 24 month upgrade cycles. I need to be confident I can deliver them the latest version of their project knowing there's only regular security updates required over then next 1-2 years. While I'd love to be doing continuous deployment and multiple production feature deliveries a day - that's not how the business I work at makes their money. I can live wi…

Especially cause then you've got to jump 3 significant versions, to get another 9 months of reprieve.
Post reply on HN