1. 10

  2. 1

    I’ve read so many k8s articles in the past years that I feel like I almost have intimate knowledge of this piece of software, even though I have not used it productively before. It’s obviously pretty strong at allowing applications to scale up whenever in high demand.

    Kubernetes will automatically manage your resources for you. If configured correctly, it can survive even if a “node”, or a server in the cluster, becomes unaccessible, with no input required from the user. Kubernetes through some service providers can scale up workloads to massive amounts temporarily, which can be incredibly useful if your service becomes very popular and you suddenly gain a lot of traffic. Running a Kubernetes system means you can reduce your downtime to an insanely small level, and increase your computational capacity to an insanely large level. While this may not seem useful up front, you may consider it essential down the line.

    Are there persons here who have designed and deployed applications on k8s for non-enterprise use, and have actually gotten to make use of the most important features of k8s: prevented downtime and scaling up (due to high increases in traffic/capacity)? I’m talking here about blogs, web services, apps, mobile apps, mostly deployed and maintained by a single developer.

    1. 4

      I have been working on Kubernetes for my company for about two years. It’s had a lot of benefits for our use cases, but I would never use it for a one-developer project. It’s simply not worth it – the things it solves for you aren’t going to be problems you have. I’d even say things like downtime and scaling up aren’t as big a deal at that level of functionality; I’d think that it’s often better for a blog to fall over than to scale at the level that some of the apps I work on scale, simply due to cost. (Are you okay with paying $900 for one day’s traffic spike?) Some of the things that it does don’t even make sense if you’re not working in a particular type of environment.

      1. 3

        As a sole developer, you have near-zero communications overhead; you can just remember / write down the state of play, and everyone who has to maintain it will automatically know. You never (eg) accidentally try to run two deploys at the same time, even if you don’t implement a mutex around your deploy process. Implementing k8s can consume all of your team-of-ones output for weeks.

        Adding kubernetes (or similar kinds of complex system) can be fantastic for big teams. Having a single source of truth RE the status of the app is a tremendous advantage. It only takes a small fraction of the teams output to implement. The cost/benefit is totally different.