Google Kubernetes Engine is introducing a cluster management fee on June 6 • Hacker News Board

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#191

Post by nuggien » Wed, Mar 04, 2020, 7:26 PM UTC

whalesalad wrote: post #125

geerlingguy wrote: post #101

Earlier quoted context omitted.

To be fair, what is the best way to handle expiring credit cards? For one of my SaaS products, I give a 30 day grace period, then delete the data. If they didn't have a backup, that's on them... If they delete the droplet the second a single CC payment fails, that's one thing, but I don't believe that's how their system works.

If you are literally in the business of enabling, storing, and protecting production workloads, data, etc.. then catastrophic data loss should be an asbolute last resort. In both of these instances I am referring to a balance of less than $20. So for less than $20 (a few weeks late) DO says, welp fuck this customer we are going to terminate all of their resources immediately. This is what DO and others need to do: Pu…

Or...if it was important enough to you that losing it hurts, then maybe pay attention to your emails and don't let things expire and pay your shit on time. And of course, a sane person would backup anything important.

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#192

Post by geerlingguy » Wed, Mar 04, 2020, 7:26 PM UTC

lazyier wrote: post #148

rolleiflex wrote: post #106

Earlier quoted context omitted.

That’s interesting - I think you’re right. We might move our staging cluster into our main production deployment. More likely though, AWS or OpenShift running on bare metal on a beefy ATX tower in the office. We want to have production and staging as close to each other as possible, so this is an additional reason and a p0 flag on reducing the dependency on Google-specific bits of Kubernetes as much as possible, hope…

Kubespray works well for me for setting up a bare bones kubernetes cluster for the lab. I'll use helm to install metallb for the load balancer, which you can then tie into whatever egress controller you like to use. For persistent storage a simple NFS server is the bees knees. Works very well and a NFS provisioned is a helm install. Very nice, especially, over 10GbE. Do NOT dismiss NFSv4. It's actually very nice for…

(replying to freedomben): NFS has worked fairly well for persistent file storage that doesn't require high performance for reads/writes (e.g. good for media storage for a website with a CDN fronting a lot of traffic, good for some kinds of other data storage). It would be a terrible solution for things like database storage or other high-performance needs (clustering and separate PVs with high IOPS storage would be better here).

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#193

Post by Glyptodon » Wed, Mar 04, 2020, 7:27 PM UTC

sethvargo wrote: post #4

Hey everyone - Seth from Google here. Please let us know if you have any questions! You can learn more about the pricing changes at https://cloud.google.com/kubernetes-engine/pricing .

This change is pretty huge for non-revenue units & small teams at institutions and SMBs. These smaller teams often seem to run two clusters rather than try to split their production and dev environments within one cluster (I think this is even widely recommended for smaller, less experienced outfits). For many the management fee will probably be a large percentage cost increase for units that are very cost sensitive and require significant re-engineering to avoid for units where engineer hours a scarce resource.

Seems weird, given that GKE is basically the main reason people seem to use Google Cloud. These kinds of users aren't big fish, but I suspect a lot of them are going to run.

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#194

Post by geerlingguy » Wed, Mar 04, 2020, 7:27 PM UTC

sethvargo wrote: post #183

geerlingguy wrote: post #94

Earlier quoted context omitted.

The 'cluster control plane is free' selling point was basically the _only_ thing I saw from all the different groups I worked with which was in GKE's favor. Yes you can get one free cluster but anyone serious about using Kubernetes would have _at least_ two clusters (a prod and non-prod staging cluster), so unless you're a true hobbyist (and the use case for K8s in that realm is pretty slim unless it's to backstop wo…

Can you help me understand how these changes would be _more_ than EKS?

Sorry, misread the original post, it would be the same.

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#195

Post by future_i_snow » Wed, Mar 04, 2020, 7:28 PM UTC

sethvargo wrote: post #4

Hey everyone - Seth from Google here. Please let us know if you have any questions! You can learn more about the pricing changes at https://cloud.google.com/kubernetes-engine/pricing .

Hi Seth - I am a LONG time lurker here on HN, but this news just forced me to create an account.

I am part of a small company which has separated our deployment into a number of sub projects, some of which are: dev, staging, production, ci, etc.

The difference for us will be several hundred dollars per month, and that will make an actual (negative) difference for us. We didn't need a "financially backed SLA" before and we don't need it now.

You asked for a question and here it is: Why isn't a financially backed SLA a part of a billing negotiation? I mean, there are some really cool features in "Anthos" but I am not picking up a phone to find out how much that is going to cost.

If a really useful feature like "Cloud Run for GKE" is awkwardly placed in the "Anthos" box, then why isn't the SLA part of "Anthos" too?

Free clusters was a huge part of why we selected GCP. If this SLA nonsense isn't made optional, our next project is not landing on GCP.

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#196

Post by whalesalad » Wed, Mar 04, 2020, 7:28 PM UTC

nuggien wrote: post #191

whalesalad wrote: post #125

Earlier quoted context omitted.

If you are literally in the business of enabling, storing, and protecting production workloads, data, etc.. then catastrophic data loss should be an asbolute last resort. In both of these instances I am referring to a balance of less than $20. So for less than $20 (a few weeks late) DO says, welp fuck this customer we are going to terminate all of their resources immediately. This is what DO and others need to do: Pu…

Or...if it was important enough to you that losing it hurts, then maybe pay attention to your emails and don't let things expire and pay your shit on time. And of course, a sane person would backup anything important.

Yep, and that is something I have since instituted since taking the reigns. Still... DO could turn this lemon of a situation into lemonade by increasing revenue and preventing unnecessary headache for their customers.

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#197

Post by rcconf » Wed, Mar 04, 2020, 7:29 PM UTC

Oh wow, one of the biggest reasons we picked Google Cloud was that you did not have to pay a flat fee for their managed Kubernetes service. Luckily there is Kubernetes support across all Cloud Providers so we're happy we're not vendor locked in. (biggest reason we picked Kubernetes in the first place.)

We were thinking of using Stackdriver for logging, but we were scared of vendor locked in due to price increases or other changes that we've been warned about with Google. In this case, I think it's safe to say we'll be using Prometheus + Grafana + Loki instead since there may be a random Stackdriver flat fee introduced or some other weird fee and we may need to migrate out of Google.

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#198

Post by outworlder » Wed, Mar 04, 2020, 7:29 PM UTC

lvh wrote: post #100

xur17 wrote: post #93

Earlier quoted context omitted.

We currently spin up dev clusters with a single node. $73/mo is going to basically double the cost of all of these..

This highlights a sorta-weird consequence of this pricing change: suddenly pricing incentivizes you to use namespacing instead of clusters for separating environments. (As a security person: ugh.)

Assuming you can do that, and your system is not using namespacing for its own purposes.

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#199

Post by riyadparvez » Wed, Mar 04, 2020, 7:30 PM UTC

taleodor wrote: post #121

rolleiflex wrote: post #58

This is awful - I don’t think GCP is fully aware of their position in the market as the second, inferior choice. I took a bet on the underdog by using GCP and they bit me back in return. Especially considering their ‘default’ kubernetes config automatically sets you up with three(!) control planes in replication, that’s, as far as I understand, $~300 added to our monthly bill, for nothing. Oh, and per their docs, thr…

My approach with any Google b2b product - always have a plan to migrate out of Google and never agree to anything that locks you to Google. After seeing what they did to Google Maps and Api.AI / Dialogueflow jumped from free to 5k$ overnight - just can't trust them.

> never agree to anything that locks you to Google.

How is Google different from other cloud poviders in terms of vendor lock-in?

Re: Google Kubernetes Engine is introducing a cluster management fee on June 6

#200

Post by agoell » Wed, Mar 04, 2020, 7:30 PM UTC

After this, I've been exploring other places to host our team's clusters... copied pricing below

- EKS: $0.10/hour/cluster

- Digital Ocean: Free (only charges for the nodes)

- Azure: Free (only charges for the nodes)

In the long run we'll probably try and build our stack on vendor-agnostic tools..

- Rancher - https://rancher.com/products/rancher/

- Infra.app - https://infra.app (mentioned a few weeks back on the Kubernetes podcast)

- Prometheus https://prometheus.io/ - metrics

The cloud providers all include their own tooling (logging, monitoring) built-in but I'm worried this will only lock us on to further price increases.. has anyone found a good vendor-neutral logging system? We don't really want to use ELK stack right now since it's really heavy and costly to run...