Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cloud.google.com

Post reply on HN
Print view View original

161–170 of 633 posts

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

#161

Post by tmpz22 »

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.

There is a whole generation of future CTO / VP of Engineering types who are coming up on these reputations for GCP, AWS, Azure, etc. and it'll be interesting to see how the biases play out over the next 5-10 years. I predict a strong move back to self-hosting once the pains of i.e. self-managing a bare metal K8s cluster come down, as well as storage/ram/cpu prices continuing to drop. I for one welcome it.

There is a billion dollar company on the horizon for whoever can best commoditize bare metal with an apple-esque usability model.

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

#162

Post by dharmab »

lokar wrote: post #152
lvh wrote: post #100

Earlier quoted context omitted.

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.)

You can dedicated nodes by namespace, at which point the isolation is pretty strong.

* Assuming you also configure strong RBAC, network isolation and don't let persistent volumes cross-talk

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

#164

Post by halbritt »

sethvargo wrote: post #80
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…

Thank you for the feedback. The management fee is per cluster. You are not billed for replicated control planes. You can use the pricing calculator at https://cloud.google.com/products/calculator#tab=container to model pricing, but it should work out to $73/mo regardless of nodes or cluster size (again, because it's charged per-cluster). There's also one completely free zonal cluster for hobbyist projects.

> There's also one completely free zonal cluster for hobbyist projects.

Nice.

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

#166

Post by outworlder »

dward wrote: post #108
rolleiflex wrote: post #90

Earlier quoted context omitted.

Seth — I appreciate you being here to take feedback, and for the clarification as well. The very surprising email I’ve received this morning is very hazy on the details, and the docs linked from the email are not updated yet. The main issue is that not charging for the control plane and charging for the control plane leads to two very different Kubernetes architectures, and as per your docs, those decisions made at t…

GKE can't offer financial backed SLOs without charging for the service. This is something that, I assume, significant customers want and that competitors already have: https://aws.amazon.com/eks/sla/

Workers are not free and never were. So they were already charging.

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

#167

Post by Allower »

sethvargo wrote: post #129
rolleiflex wrote: post #90

Earlier quoted context omitted.

Seth — I appreciate you being here to take feedback, and for the clarification as well. The very surprising email I’ve received this morning is very hazy on the details, and the docs linked from the email are not updated yet. The main issue is that not charging for the control plane and charging for the control plane leads to two very different Kubernetes architectures, and as per your docs, those decisions made at t…

Thank you These changes won't take effect until June - customers won't start getting billed immediately. I'm sorry that you feel trapped, that's not our intention. > You should keep existing clusters in the pricing model they’ve been built in, and apply this change for clusters created after today. This is great feedback, but clusters should be treated like cattle, not pets. I'd love to learn more about why your clus…

>I'm sorry that you feel trapped, that's not our intention.

Bull-fucking-shit.

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

#168

Post by freedomben »

pojzon wrote: post #107
tmpz22 wrote: post #71

Earlier quoted context omitted.

Too many people drank the cloud kool-aid. The move from day one was to create provider agnostic cloud architectures and repent the use of provider-specific services. That said they do make it damn hard. Our k8s cluster is as basic as it comes, no databases, simple deployments, but we do still have a dependency on Google Cloud Loadbalancer (which we hate). If pricing goes up too much from this we'll move, but the GCL…

How about managing own k8s running on VMs / bare-metal? Pretty much anyone who works in ops longer understood from the go that its impossible to be totally provider-agnostic. K8S is just a nice api on top of provider api that still requires provider specific configuration.

Disclaimer: I work for Red Hat and am very biased, but this is my own honest opinion.

If you're going to run on bare-metal or in your own VMs, OpenShift is very much worth a look. There are hundreds, maybe thousands of ways to shoot yourself in the foot, and OpenShift puts up guard rails for you (which you can bypass if you want to). OpenShift 4 runs on top of RHCOS which makes node management much simpler, and allows you to scale nodes quickly and easily. Works on bare metal or in the cloud (or both, but make sure you have super low latency between data centers if you are going to do that). It's also pretty valuable to be able to call Red Hat support if something goes wrong. (I still shake my head over the number of days I spent debugging arcane networking issues on EKS before moving to OpenShift, which would have paid for a year or more of support just by itself).

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

#169

Post by [deleted] »

tmpz22 wrote: post #83
rolleiflex wrote: post #79

Earlier quoted context omitted.

We’re in the same situation — we’ve engineered for minimum provider-specific dependencies but GKE LoadBalancers were where they got us via arm twisting as well. There is no way to expose a cluster to the outside world in a production environment otherwise.

Do you also have occasional outages because the load balancer gets into a confused state and changes take 10+ minutes to propagate with no re-course other then than to destroy and re-create the entire resource?

[deleted]

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

#170

Post by freedomben »

takeda wrote: post #131
pojzon wrote: post #107

Earlier quoted context omitted.

How about managing own k8s running on VMs / bare-metal? Pretty much anyone who works in ops longer understood from the go that its impossible to be totally provider-agnostic. K8S is just a nice api on top of provider api that still requires provider specific configuration.

From what I've seen looks like managing k8s on your own often ends up requiring a dedicated team to keep with their insane release cycle.

Can confirm. Depending on your cluster size you will need at least 2 dedicated people on the "Kubernetes" team. You'll probably also end up rolling-your-own deployment tools because K8s API is a little overwhelming for most devs.
Post reply on HN