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

171–180 of 237 posts

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

#171

Post by Santosh83 »

digi_owl wrote: post #153
brudgers wrote: post #19

Earlier quoted context omitted.

A description of -- not a name for -- is corporate control of an open source project. Trying to keep up with Angular or Kubernetes or Go is not a problem at the Google from whence they come because the technologies are primarily used by and hence primarily designed for use by teams. Not individual developers. A team's brain can schedule a time where part of it is training or studying while the rest of it is making pr…

Been my building worry as i have watched the ongoing changes is the Linux ecosystem in recent years. It feels like thereis a echo chamber happening, where a small group of peope working for maybe 2-3 companies have decided that their vision is the correct vision. And everyone that says otherwise are haters and fossils.

Well, hundreds of medium and large companies now rely critically on Linux so it was expected that slowly they will cooperate to steer its further evolution.

People do respond that the whole codebase is open source and hence if some really bad change happens the community can always fork from the last known good commit. But this ignores a subtler issue: soon enough so many of the critical subsystems and so many of their contributions will come from individuals directly or indirectly working for corps that if/when those subsystems start adversely impacting the original Linux philosophy, stripping them all out and starting over again would be not much better than abandoning the whole platform.

This is exactly why alternative efforts that seek to maintain working and up-to date alternative init systems, display managers and desktops are critical to the long-term health of Linux.

Linux thrives on multiplicity of choices, which is anathema for corps who always want to consolidate. But that road eventually will weaken Linux for the general community and varied use cases.

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

#172

Post by bonesss »

mbrumlow wrote: post #56
nova22033 wrote: post #51

Earlier quoted context omitted.

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

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

Kubernetes is one of several products that offer environment agnostic mechanisms to handle deployment and upgrades.

If you're dealing with hundreds of 'products', or a mountain of microservices, or large batch job scheduling, putting the lot of it on Kubernetes is addressing deploying, upgrading, monitoring, securing, discovering, and many other things up front in a shared, consistent, and portable manner.

A forethought, not an afterthought...

I agree that owning your core systems is valuable. Focusing on core IT competencies and business value creation are more valuable, though, and if you're not dealing with multi-cloud-platform resource management I can't imagine how to justify writing tools that compete with established, mature, industry standard solutions. You're always better to focus on your unique advantages and competencies... If you're ok using an RDBMS system in your stack, then using a scheduling/upgrading framework should be pretty ok, too.

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

#173

Post by jstimpfle »

collyw wrote: post #166
cottonseed wrote: post #134

Earlier quoted context omitted.

> Time spent not doing our own designs (and instead spent memorizing how to use magical frameworks) is time not spent advancing our technical understanding. I can't upvote this enough. I used to do mathematics, and there was the story of a professor would would hold up a book and say, "You should know everything in this book. But don't read it!" Which is to say, you have to go through the process of discovering mathe…

Sure and those of us experienced in writing software tend to avoid reinventing the wheel (in a buggy, untested way). I see the value in learning by building yourself, but from a software engineering point of view, using a tried and tested framework is likely to give you higher quality product in less time.

Well, the framework I was to use last (Qt) had bugs that simply can't be fixed by users (memory leaks, double free leading to segfault when exiting after reloading QML engine) and immature modules (for example translation) and forces complicated types to the user and forces bad architectural decisions to the user and significantly increases compile times...

> using a tried and tested framework is likely to give you higher quality product in less time.

This is a common sentiment, but note that a framework has huge handicaps

- not knowing your business requirements and concepts

- must be suitable for many software projects that need features you'll never need.

- there is a clear maintenance boundary (framework vs your own code), which requires a complex interface with maintenance overhead and typically forces you to use concepts that don't really match your requirements

If you're experienced in the relevant domain it's almost always simpler to do it yourself / reuse your own work.

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

#174

Post by jstimpfle »

robocat wrote: post #168
jstimpfle wrote: post #163

Earlier quoted context omitted.

https://msdn.microsoft.com/de-de/library/windows/desktop/bb7...

Exactly my point - that function doesn't deal with modern windows. MAX_PATH is 260 characters. Yet Windows now supports longer paths (\\?\ prefix). So I presume there is another Windows function to combine long path names (and maybe canonicalise Unicode better).

> Yet Windows now supports longer paths (\\?\ prefix).

I know. And this is the attitude that leads to complex software. It's a self-fulfilling prophecy: "I can't do it on my own since the problem is so complex". In which case the problem does get complex.

I recommend not wasting time supporting this crazy feature (unless you are writing infrastructure code for tools and you're required to - in which case I'm sorry). 260 character paths are more than enough for any project. And I certainly recommend against using the crazy abstractions from Boost::filesystem.

(Personally I think it's an unfortunate example. I'd prefer to avoid paths from the start, since nobody understands the semantics of hierarchical filesystems. Alas, typically you need to deal with them to some degree).

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

#175

Post by kuschku »

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…

I'd also say "kubernetes is magic". It's an insanity to understand and set up once, but once you've done that, and keep up with changes, it makes deploying services much easier.

For example, in the past I first ran several services directly on bare metal, but Ubuntu's LTS versions didn't have the packages yet (and libraries were incompatible) for one service I needed, and while debian had these, it didn't have them for a second service I needed.

So I went with containerization, and properly split these things up, so I could run all services I needed together. But I had two servers, and manually migrating them whenever I needed to restart one server for updates became painful. And it made automated updates impossible, so every ~3 days a crontab would run apt to update, and if a reboot was necessary, email me. So every 3 days I had to manually migrate containers over, and restart. Very annoying. Plus all the ingress rules complications.

Then I started using kubernetes, and despite needing 8 months to actually understand it, and work with it, it actually is magic. I don't have to manually check every 3 days if apt fucked again with the packages. I don't have to check if I need to reboot, and migrate containers. Thanks to k8s and container linux everything migrates automatically and reboots. I don't have to worry about all this stuff anymore, it just works. Yes, I have to worry about k8s updates, and keep my configs up to date — but that's another amazing thing: recently I had to rebuild my cluster from scratch, and thanks to container linux's cloud-init and kubernetes I could simply restart all servers with the new config, and they'd automatically recreate the cluster, and load the storage data back from backups. In 25 minutes the entire cluster was rebuilt from scratch and everything was back up.

Yes, kubernetes is the opposite of easy for setting it up, but that's a constant cost. All additional services you run on it are basically free in terms of maintenance cost.

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

#176

Post by peterwwillis »

outworlder wrote: post #47
peterwwillis wrote: post #33

trigger warning: bitter jaded ops person working in a real company "[...] users are expected to stay “reasonably up-to-date with versions of Kubernetes they use in production.” [...] the upstream Kubernetes community only aims to support up to three “minor” Kubernetes version at a time. [...] if you deployed a Kubernetes 1.6 soon after it came out last March, you were expected to upgrade to 1.7 within roughly nine mo…

I was going to reply to the general point, but I got interested on this: > you try moving 50 different clients off the service they've been using for three years This sounds like a major red flag. Are they on-prem air gapped servers? Do you manage the infrastructure? Because if you do and they aren't, they are not supposed to see it. And if it is automated, what does it matter if there are 50 or 50 thousand clients?…

> they are not supposed to see it

There's a whole lot of things that are not supposed to happen in the tech world, that happen all the time. Most people do not run brand new stateless microservices in K8s. They run stateful apps on VMs in three year old badly configured OpenStack clusters.

For what it's worth, moving the client traffic itself is seamless and totally fine. But first you have to get them to stop hard-coding the names of region and zone specific load balancers into their apps. You switch them over... traffic falls over... and it's your fault. Hence, big moves are coordinated with clients, not to mention feature tested, and then tested by sending some real traffic to the new cluster, before you shift all the traffic. The cloud is not magic, and if you treat it that way, it will bite you.

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

#177

Post by Twirrim »

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…

After watching the deployment team trying to keep up with Docker and their ridiculous pace of breaking changes, and then eventual decision to move entirely away from Docker for containers; I really understand their decision not to want to touch k8s with a 10 ft pole.

If the choice is between "building features based around business needs so other teams can make more awesome stuff" and "throwing lots of dev time at just chasing docker/k8s/whatever", why on earth would they want to choose the latter?

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

#178

Post by robocat »

jstimpfle wrote: post #174
robocat wrote: post #168

Earlier quoted context omitted.

Exactly my point - that function doesn't deal with modern windows. MAX_PATH is 260 characters. Yet Windows now supports longer paths (\\?\ prefix). So I presume there is another Windows function to combine long path names (and maybe canonicalise Unicode better).

> Yet Windows now supports longer paths (\\?\ prefix). I know. And this is the attitude that leads to complex software. It's a self-fulfilling prophecy: "I can't do it on my own since the problem is so complex". In which case the problem does get complex. I recommend not wasting time supporting this crazy feature (unless you are writing infrastructure code for tools and you're required to - in which case I'm sorry).…

It is not a crazy feature.

It is a necessary feature for many development environments originally written for Unix (e.g. nodejs), because Unix file systems usually don't have such a low character limit.

Or maybe Windows has mounted or network sharing, a Unix filesystem... In which case your program better deal with long paths (or just fail?)

Really... You are showing exactly why one uses a library so one doesn't need to care about the "complex" details because one hopes the library does a good job of managing it as well as possible for you (although you still need to know the details to use a library function safely).

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

#179

Post by etaioinshrdlu »

justicezyx wrote: post #94
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…

K8s is different though. It's an incarnation of a highly-effective & efficient infrastructure paradigm, verified in over a decade long serving of entire google's compute tasks. It's not really new. Disclaimer: I work in Google's compute infrastructure team.

There is clearly a lot of unfinished tooling and features, as evidenced by the extremely high commit rate.

Compare that to an old piece of infrastructure like "mount" or "chroot".

Is it too much to ask for base infrastructure to be boring?

Granted, I have nothing against the Kubernetes project and it might be fantastic. I don't think it's wise to encourage people to use/learn it at this point, at least for production projects.

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

#180

Post by jstimpfle »

robocat wrote: post #178
jstimpfle wrote: post #174

Earlier quoted context omitted.

> Yet Windows now supports longer paths (\\?\ prefix). I know. And this is the attitude that leads to complex software. It's a self-fulfilling prophecy: "I can't do it on my own since the problem is so complex". In which case the problem does get complex. I recommend not wasting time supporting this crazy feature (unless you are writing infrastructure code for tools and you're required to - in which case I'm sorry).…

It is not a crazy feature. It is a necessary feature for many development environments originally written for Unix (e.g. nodejs), because Unix file systems usually don't have such a low character limit. Or maybe Windows has mounted or network sharing, a Unix filesystem... In which case your program better deal with long paths (or just fail?) Really... You are showing exactly why one uses a library so one doesn't need…

> Or maybe Windows has mounted or network sharing, a Unix filesystem... In which case your program better deal with long paths (or just fail?)

260 bytes is long. I've never seen a \\?\ path in the wild, and I don't want to. It's a misdesign (well, I'm sure the designer didn't want to design it...). But I'm repeating myself... I can't practically deal with paths longer than, say, 64 characters (can't read them, let alone type them). Fix your paths.

And again, this is off-topic. This thread was about not using a crazy third party library, when the authoritative semantics (however insane) are contained in the OS interface.

Post reply on HN