Live data from Hacker News

Learning to operate Kubernetes reliably

stripe.com

41–50 of 102 posts

Re: Learning to operate Kubernetes reliably

#41

Such good writing style AND useful technical content. Why can't all blog posts be this good?

The author writes regularly and her posts almost always reach the top of HN. Like most skills, improvement comes with practice. If a person is willing to put in the same time and effort as jvns has, I'm sure they would be rewarded with similar results.

Re: Learning to operate Kubernetes reliably

#42

I'm curious about what people think about HashiCorp's Nad bs Kubernetes. I chose Nomad because I'm already using Consul and I wanted to run raw .Net executables. Would it have been worth it to use Docker with .Net Core? Not trying to change my infrastructure now, but just curious about whether it is worth the time to play with it on the side.

Nomad appears to be better designed, more scalable, and easier to operate than k8s, but it will fall behind pretty rapidly since k8s has 100x more developers.

Re: Learning to operate Kubernetes reliably

#43
I haven't been at a k8s shop yet, but at my last job we used Marathon (on DC/OS). I know you can run Kubernetes on DC/OS, but the default scheduler it comes with is Marathon.

Is there an advantage to one over the other? It looks like in both cases, you need a platform team (at least 2, maybe 3 people; we had a large complex setup and had like 10) to setup things like K8s, DC/OS or Nomad, because they are complex systems with a lot of different components .. components like Flanel vs Weavenet vs some other container networks, handling storage volumes, labels and automatic configuration of HAProxy from them (marathon-lb on DC/OS).

All schedulers (k8s, swarm, marathon) seems to use a json format for job information that's pretty specific, not only to the scheduler, but to the way other tooling is setup at your specific shop.

Re: Learning to operate Kubernetes reliably

#44

> “Sometimes when we do an etcd failover, the API server starts timing out requests until we restart it.” This is likely related a set of Kubernetes bugs [1][2] (and grpc[3]) that CoreOS is working diligently to get fixed. The first set of these, the endpoint reconciler[4], has landed in 1.9. More work is pending on the etcd client in Kubernetes. The good news is that the client is used everywhere, so one fix and all…

I don't get this. Didn't Kubernetes come out of Google Borg that had been in use forever? The second write should be more elegant and impressive -- why so many basic bugs?

Kubernetes takes some concepts from Borg. A system like Borg would be very closely coupled to Google‘s infrastructure that there’s probably very little to open source from there without open sourcing the entire machinery.

Also, any large scale system like Borg developed at a large company like Facebook or Google will have completely opinionated one-way-of-doing-things for a lot of aspects. This doesn’t work for the world outside where lots of developers from different backgrounds, lots of projects with different requirements exist.

Re: Learning to operate Kubernetes reliably

#45
post #14

Earlier quoted context omitted.

I would argue that, while Stripe is going with a scratch build, this could be motived by AWS's lack of a good managed Kube offering, which is changing in the next few months. With a managed Kube offering, setting up Kube is much much easier than this jenkins setup you are suggesting. And, there's no overhead charge. Why would anyone go through the hassle of manually provisioning machines like you suggest when AWS/GCP…

Setting up a K8S cluster isn't that hard actually. From my experience, the hard part kickin when dealing with stateful service which needs to associated with volume. Even with a managed cluster, you still have to solve that problem. Either you pre-provision disk or use dynamic volume. Next is when upgrading K8S version. with a stateless service, it's a walk in a prt to upgrade. With data volume it's more tricky to up…

That's true, but I'm not sure if using Jenkins would avoid these problems you outline. And that's really the crux of what the OP is suggesting; that Jenkins or something smaller than Kube would have been a better choice.

Re: Learning to operate Kubernetes reliably

#46

What is the benefit of using Kubernetes over Mesos (or in conjunction with Mesos)?

FTFA: "We’d previously been using Chronos (with Mesos) as a cron job scheduling system, but it was no longer meeting our reliability requirements and it’s mostly unmaintained (1 commit in the last 9 months, and the last time a pull request was merged was March 2016) Because Chronos is unmaintained, we decided it wasn’t worth continuing to invest in improving our existing cluster."

Though Chronos has a release recently with a bunch of fixes, Mesos is inevitably fading as a legacy platform.

Re: Learning to operate Kubernetes reliably

#47

> “Sometimes when we do an etcd failover, the API server starts timing out requests until we restart it.” This is likely related a set of Kubernetes bugs [1][2] (and grpc[3]) that CoreOS is working diligently to get fixed. The first set of these, the endpoint reconciler[4], has landed in 1.9. More work is pending on the etcd client in Kubernetes. The good news is that the client is used everywhere, so one fix and all…

I don't get this. Didn't Kubernetes come out of Google Borg that had been in use forever? The second write should be more elegant and impressive -- why so many basic bugs?

IIRC from one of their talks.... K8s was supposed to be Borg 2.0 in many respects. They decided early on in development that it was a good tool and had lots of potential, but "fixing" Borg would be less work than replacing it. So k8s takes the Borg 2.0 concepts without being any of Borg code.

Re: Learning to operate Kubernetes reliably

#48

Much as it burns me to admit this, for this usecase, jenkins is king. At previous job, we had migrated from a nasty cron orchestration system to jenkins. It did a number of things including building software, batch generating thumbnails and moving data about on around 30 nodes, of which about 25 were fungible. Jenkins job builder meant that everything was defined in yaml, stored in git and was repeatable. A sane user…

I've often used Jenkins for this use case, and really appreciate how it scales to teams too. While it works well, there are lots of pitfalls in it too, logs filling up disks, lots of configs to tweak. I think you've just gotten past those issues so it's stable for your use case.

Re: Learning to operate Kubernetes reliably

#49
post #46

What is the benefit of using Kubernetes over Mesos (or in conjunction with Mesos)?

FTFA: "We’d previously been using Chronos (with Mesos) as a cron job scheduling system, but it was no longer meeting our reliability requirements and it’s mostly unmaintained (1 commit in the last 9 months, and the last time a pull request was merged was March 2016) Because Chronos is unmaintained, we decided it wasn’t worth continuing to invest in improving our existing cluster." Though Chronos has a release recentl…

> Mesos is inevitably fading as a legacy platform.

Because of Chronos? This is a bizarre thing to say. Mesos actually works extremely well. Whenever I ask the why kube over Mesos question, I never get a good answer. I think because people just don’t know Mesos. Also it wasn’t made by google.

Re: Learning to operate Kubernetes reliably

#50
post #26

What is the benefit of using Kubernetes over Mesos (or in conjunction with Mesos)?

The answer to that depends on your particular usage case and requirements. There is no simple, always-true response.

What are some examples of each?
Post reply on HN