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

#581

Post by imtringued » Thu, Mar 05, 2020, 2:32 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.

Ok, lets say I store all my backups at AWS, Google and Azure. My credit card expires and all backups are gone. What's the point of additional backups in this scenario?

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

#582

Post by qzx_pierri » Thu, Mar 05, 2020, 2:33 PM UTC

justlexi93 wrote: post #502

A very basic truth that AWS understands is that you introduce a product at price X, and then either keep it at X or reduce the price moving forward. You never, ever, EVER increase prices on established products. You also basically never discontinue products, even if there's only a handful of customers still using it (ex: SimpleDB). Apparently it's just too tempting to Google management to juice revenue in the short t…

We see it again and again and again and again. I’m amazed that people still put trust into Google’s services.

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

#583

Post by seneca » Thu, Mar 05, 2020, 2:46 PM UTC

thockingoog wrote: post #240

seneca wrote: post #62

Earlier quoted context omitted.

Tim, would you be willing to elaborate on why you dislike the "many small clusters" pattern?

Many small clusters just do not deliver on a lot of the value of Kubernetes. Clusters are still hard boundaries to cross (working to fix that). Utilization and efficiency are capped. OpEx goes up quickly. There are reasons to have multiple clusters, but I think the current trend takes that too far. TO BE SURE - there's more work to do in k8s and in GKE.

As always, the insight is appreciate, Tim!

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

#584

Post by ak217 » Thu, Mar 05, 2020, 2:54 PM UTC

fluuuhi wrote: post #551

ak217 wrote: post #488

Earlier quoted context omitted.

Both AWS and Google offer free tier products and pay-for-what-you-use products. Reserved instance pricing starts at around $25/year. Many other incredibly useful products (S3, Lambda, VPC, etc.) are free with an instance or start at $0. You can set billing alerts that will project your monthly budget every hour, and send you an alert when it's projected to be exceeded. IMHO your claim (that there is an entry cost bar…

My main concern is, that i can't define an upper limit. My billing alert is nice and im aware of it, but it doesn't help you if someone takes over your account, mines bitcoins on expensive machines and a day later you read your email.

AWS refunds you when that happens.

The fundamental issue with setting a limit is it's technically infeasible to decide what to do when it's exceeded. They have no way of knowing what assets to terminate. The way to avoid what you describe is to shut off access to APIs that you don't want to use, and keep your credentials safe.

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

#585

Post by b34r » Thu, Mar 05, 2020, 3:12 PM UTC

That’s kind of a lot. $876 per year for a toy cluster that might not do anything...

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

#586

Post by praveenperera » Thu, Mar 05, 2020, 3:25 PM UTC

atombender wrote: post #426

tie_ wrote: post #393

Earlier quoted context omitted.

If it takes more than a month to migrate a 20-node K8s cluster, then that's a red flag. Too much tech debt or a strong vendor lock-in? Either deserves attention.

Doing the migration might take a few late evenings; deploying all our apps and Helm charts to a new cluster takes just a few commands. Learning what needs to be migrated, deciding on how the configuration should look on the destination end of it, and designing a detailed plan and checklist for the whole process is the big task. Adding the onboarding of someone who's never seen the inside of your company and you're ta…

> Learning what needs to be migrated, deciding on how the configuration should look on the destination end of it ...

Sounds like you've identified an area of risk you should address

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

#587

Post by stickfigure » Thu, Mar 05, 2020, 3:50 PM UTC

Glyptodon wrote: post #575

stickfigure wrote: post #570

Earlier quoted context omitted.

Google App Engine has been exactly this since 2008.

My impression of app engine is that you have to use all the cloud* services like SQL, cache, etc, which will make it significantly more expensive, even if it does that app layer fine. Is that wrong?

It's wrong today. It was true in 2008, when GAE was Google's entire cloud offering (and there was no Docker or K8s).

Around the time "Google Cloud Platform" became a thing, Google changed GAE from an encapsulated bubble into a basic frontend management system that interacts with normal services through public APIs (either inside or outside GCP). It's more expensive than GCE, but it's fully managed and lets you skip the devops team.

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

#588

Post by zerotolerance » Thu, Mar 05, 2020, 4:22 PM UTC

thockingoog wrote: post #271

dcolkitt wrote: post #266

Earlier quoted context omitted.

Hi Seth, What about clusters that are used for lumpy work loads? Like data science pipelines? For example, our org has a few dozen clusters being used like that. Each pipeline gets its own cluster instance as a way to enforce rough and ready isolation. Most of the times the clusters sit unused. To keep them alive we keep a small, cheap, preemptive node alive on the idle cluster. When a new batch of data comes in, we…

Those empty clusters that you get for free cost Google money. Perhaps it never should have been free, because that skewed incentives towards models like this.

The term is "loss leader." GKE provides the manager node, and cluster management so that we don't have to. And in exchange you sell more compute, storage, network, and app services. This is some ex-Oracle, "what can we do to meet growth objectives," "how can we tax the people who we own" thinking. They're customers, not assets Tim. Your cloud portability play should be the last project to jerk them around on.

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

#589

Post by yoshiat » Thu, Mar 05, 2020, 4:36 PM UTC

fluuuhi wrote: post #549

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.

If it is only workload isolation, why not?

For secure isolation, we learned it's not sufficient. It's good for resource isolation though.

PTAL at https://www.youtube.com/watch?v=6rMGRvcjvKc

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

#590

Post by aaronblohowiak » Thu, Mar 05, 2020, 4:47 PM UTC

yoshiat wrote: post #368

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

Yes, namespace alone isn't sufficient for isolation. Would you be able to look at our latest Multi-Tenancy best practices? https://cloud.google.com/kubernetes-engine/docs/best-practic... It's a living product which comes with Terraform modules. We introduced various features to enable doing Multi-Tenancy as well (and more on their way!)

I’m sorry if i am reading it wrong, but this guide to multi-tenancy seems to suggest not being multi-tennant and instead running a separate cluster per project. This seems more like scaling single-tenancy than multi-tenant (no bin packing oppty for instance.) or did i read it wrong?