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

441–450 of 633 posts

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

#441

Post by dvcrn »

praveenperera wrote: post #342

Good time for people to look into DigitalOcean managed Kubernetes (DOKS). I've been using it since it was in pre-release and its been great so far. Their support has been very responsive as well. https://www.digitalocean.com/products/kubernetes/

Another happy DO user here. I wanted a k8s cluster for my smaller project when they just started the beta.

Very happy with it, also the resources available helped a lot in actually understanding k8s. On GCP the line between what gcloud and what k8s was a bit blurry for someone new like me, and doing just k8s on DO helped me really 'getting it'.

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

#442

Post by atombender »

thockingoog wrote: post #236
rcconf wrote: post #227

Earlier quoted context omitted.

Honestly I understand the hard work it takes to manage all the clusters, but this was a total bait and switch and hurts the reputation that everyone has with Google Cloud. Telling us to DIY because we cannot pay $71 just sounds like someone who works at Google would say, which you do work at Google. The sentiment with my clients before was that Google Cloud was a great choice because of the security and expertise wit…

I understand the emotional response here, but I don't think it's rational. GKE has to work as a business, or else the whole thing is in trouble. I think GKE provides tons of value, but people tend to under-estmate that. In order to keep providing that value, we need to make sure it is sustainable. I'm really, truly sad that you perceive it as bait-and-switch, but I disagree with that characterization. If you want to…

To be fair, it's unusual for a product at this scale to go from free to paid. It's also unusual for it to happen to a product which already went from paid to free once before.

I don't agree with the parent that it's a bait-and-switch, but I also don't think what's happening is an emotional response. For many people and companies, clusters being free have been a feature of Google Cloud. Making it a paid feature completely changes the dynamic.

It's an unexpected announcement that will further sour sentiment about Google as a company. It's really hard to build trust in this industry, and it's really easy lose it. Google has this thing about announcing changes that blow up negatively on HN, and could learn from this.

(For the record, I'm a big fan of Kubernetes, and I like GKE a lot.)

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

#443

Post by tedk-42 »

The number of people that still trust google not to screw customers over is amazing.

They got you into their tech by offering something for free - now they're upping the price to match the leading competitor (in cloud that is).

Better than getting you into their ecosystem and discontinuing a service I suppose.

I hope this backfires on them and they provide it 'free forever' as they would have received a lot of customers drawn in from their free GKE control plane offering

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

#444

Post by busterarm »

derefr wrote: post #423
sethvargo wrote: post #154

Earlier quoted context omitted.

Hmm - have you considered a tool like Terraform or Deployment manager for creating the clusters? In general, it's best practice to capture that configuration as code.

Why would one want lots of little GKE clusters, anyway? Google itself doesn't part up its clusters this way, AFAIK. I don't want a cluster of underutilized instances per application tier per project; I want a private Borg to run my instances on—a way to achieve the economies-of-scale of pod packing, with merely OS-policy-level isolation between my workloads, because they're all my workloads anyway. (Or, really, I'd r…

We run lots of small clusters in our projects and identical infrastructure/projects for each of our environments.

Multiple clusters lets us easily firewall off communication to compute instances running in our account based on the allocated IP ranges for our various clusters (all our traffic is default-deny and has to be whitelisted). Multiple clusters lets us have a separate cluster for untrusted workloads that have no secrets/privileges/service accounts with access to gcloud.

Starting in June our monthly bill is going to go up by thousands. All regional clusters.

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

#445

Post by hitpointdrew »

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…

> I don’t think GCP is fully aware of their position in the market as the second, inferior choice.

They are 3rd for me, I will take AWS or Azure long before I would take GCP. Hell for some projects I would even take Digital Ocean or Linode over GCP.

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

#446

Post by pm90 »

blazespin wrote: post #390
geerlingguy wrote: post #182

Earlier quoted context omitted.

> clusters should be treated like cattle, not pets Heh... how many teams actually treat their clusters like cattle, though? Every time I advocate automation around cluster management, people start complaining that "you don't have to do that anymore, we have Kubernetes!" Some people get it, yes, but even of that group, few have the political will/strength to make sure that automation is set up on the cluster level—esp…

For any real production system you have to use terraform and their ilk to manage clusters, as you need to be spinning up and down dev/qa/prod clusters. I don't know GCP though. In the past I've seen kube cluster archs which are very very fragile as they spin up. If that's the case with GCP I can see why you wouldn't do the above and rather hand hold their creation.

GKE makes it incredibly easy to spin up + tear down GKE clusters. UI/CLI/Terraform etc, all just work for 99% of the cases.

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

#447

Post by yoshiat »

zomglings wrote: post #440
yoshiat wrote: post #438

Earlier quoted context omitted.

PTAL at doing Multi-Tenancy in GKE! https://cloud.google.com/kubernetes-engine/docs/best-practic... We don't recommend using node pools for isolation.

That guide looks nice. Have you guys thought about releasing a terraform module or even a cloud composer workflow that will set that up in a project?

Thanks! We actually do and shipped together with the best practices.

https://github.com/GoogleCloudPlatform/gke-enterprise-mt

Please give us feedback there in case you hit any issue!

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

#448

Post by busterarm »

The SLA guarantee for stable is interesting because at every turn the documentation and our TAMs encourage us to switch from Stable channel to the Regular.

Workload Identity, for example, is pushed hard, but it's Beta so there's no SLA and it's broken in Stable so if you use it you're going to have outages or be forced onto Regular.

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

#449

Post by rolleiflex »

carterehsmith wrote: post #350
rolleiflex wrote: post #120

Earlier quoted context omitted.

We need MySQL 8 because of window functions, which GCP does not offer. That is available on AWS.

I see. Curious about the latency between your GCP apps and the database on AWS - is it like 1 ms or 100ms? Does it affect the product?

About 4ms for us. However, we chose our data centres on both ends very carefully. There are tables online you can find that for those pings, one such is here: https://medium.com/@sachinkagarwal/public-cloud-inter-region...

However this means we are paying for egress on both sides. This was something we chose to eat due to GCP Kubernetes, but considering today’s changes, it probably no longer makes sense.

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

#450

Post by JeremyNT »

freedomben wrote: post #168
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.

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 allow…

So you move from vendor lock in with the cloud provider, to vendor lock in with an expensive, proprietary* IBM k8s distribution with its strange nonstandard opinions about workflows that you have to manage yourself?

Don't get me wrong, I appreciate RHAT's code contributions very much, they have done a lot for k8s! But running OKD on one's own is a bad idea, while paying for IBM support makes you as much a hostage as anything Google will do to you. Better to just stick with a distribution with better community support and wait for RHAT's useful innovations to be merged upstream (while avoiding the pitfalls of their failed experiments...)

* Yes it's open source, but the community version (okd) isn't really supported, nor is it widely used, so if you're serious about running this you're doing so for the Enterprise support and you're going to be writing those checks

Post reply on HN