Such good writing style AND useful technical content. Why can't all blog posts be this good?
Learning to operate Kubernetes reliably
41–50 of 102 posts
Re: Learning to operate Kubernetes reliably
#42I'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.
Re: Learning to operate Kubernetes reliably
#43Is 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?
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
#45Earlier 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…
Re: Learning to operate Kubernetes reliably
#46What is the benefit of using Kubernetes over Mesos (or in conjunction with Mesos)?
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?
Re: Learning to operate Kubernetes reliably
#48Much 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…
Re: Learning to operate Kubernetes reliably
#49What 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…
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.