[HN Gopher] The True Cost of Kubernetes: People, Time and Produc...
       ___________________________________________________________________
        
       The True Cost of Kubernetes: People, Time and Productivity
        
       Author : edouardb
       Score  : 25 points
       Date   : 2021-12-30 15:59 UTC (7 hours ago)
        
 (HTM) web link (www.koyeb.com)
 (TXT) w3m dump (www.koyeb.com)
        
       | ZeroDeth wrote:
       | Great article. Thanks
        
       | amscanne wrote:
       | > For all these offerings [GKE, EKS, AKS], there are no automatic
       | version updates or auto-recovery and you still need to pay for
       | the computing resources like CPU, memory, and ephemeral storage
       | that your worker pods consume.
       | 
       | I don't know about the others, but GKE certainly has automatic
       | updates (for masters and nodes). There's also auto-repair and a
       | backup feature (is this "auto-recovery"?). GKE has also had
       | autopilot for nearly a year, which bills based on Pod requests.
        
       | PaulHoule wrote:
       | I think they could get around the problem of requiring a third-
       | party cluster manager if they really thought through the chicken-
       | and-egg problems, and concentrated the circular dependencies into
       | a very small core.
       | 
       | I've had the experience of working through the design of a system
       | over and over until circular dependencies can be tamed through a
       | bootstrap procedure.
        
       | icedchai wrote:
       | These costs are highly inflated. Not sure why you need 4 people
       | to operate a small 6 node cluster. From my own personal
       | experience, one guy can do that part time. Your cluster has
       | redundancy, so most problems can wait to be dealt with during
       | regular hours.
        
       | zufallsheld wrote:
       | Why do I need four people for on call with a self hosted cluster
       | but only one for a managed cluster? My application still needs
       | the on call support. I think this cost estimate does not add up.
        
         | yann_eu wrote:
         | You're right, having only one person on call for a managed
         | cluster doesn't make a lot of sense. We should probably have
         | planned with at least 2 people for a managed cluster too to
         | cover 24/7/365 operations.
         | 
         | I think our thought process here is that developers are also
         | involved in on call support for the service availability and
         | the k8s cluster availability is mostly managed by the provider,
         | but the cluster can still fail even if the control plane is
         | managed.
        
           | dijit wrote:
           | Self managed cluster needs networking, some kind of
           | persistent volume storage and the nodes themselves need to be
           | somewhat maintained.
           | 
           | I think you could get one person to be on-call for all those
           | things, personally. But then I think that person should not
           | be on-call for application support (IE; not the things
           | running inside k8s, they would be the person the on-call
           | application developer/administrator would call if they
           | couldn't debug issues with networking, for instance).
        
       | mkhnews wrote:
       | What about persistent storage and access costs ? And couldn't
       | that then over time increase managed k8s costs significantly ?
        
         | yann_eu wrote:
         | We focused on estimating the minimum/entry-level cost of
         | Kubernetes here.
         | 
         | If you have a data intensive service, it surely would add up,
         | but it's not specific to Kubernetes. If you go with VMs or a
         | Serverless deployment, you'll have to pay it too.
         | 
         | If you're speaking about the storage and data transfers related
         | to the Kubernetes control plane itself, I don't believe it
         | represents a significant cost, even with a large cluster.
        
       | yuppie_scum wrote:
       | It's a lot easier now with EKS etc maturing. I think people will
       | develop some more wrappers to make things easier.
       | 
       | Regardless, the alternative mentioned (Serverless) comes with its
       | own set of problems.
        
       | renewiltord wrote:
       | Meaningless analysis. If you're the kind of org where running a 6
       | node cluster needs 4 people performing continuous ops, you're not
       | going to succeed. Good luck.
        
       ___________________________________________________________________
       (page generated 2021-12-30 23:01 UTC)