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

471–480 of 633 posts

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

#471

Post by sneak »

pckhoi wrote: post #418
sneak wrote: post #299

Earlier quoted context omitted.

Furthermore, anyone spending enough on compute to warrant k8s shouldn’t balk at all at $70/mo. I think the threshold for introducing the complexity and overhead of k8s isn’t probably until at least $5-10k/mo of spend (and probably 3-10x that in the normal case). Less than that and k8s is a whole lot of overkill.

I do think that $70/mo is reasonable per cluster but don't dismiss the value of k8s even for small projects. I used to bring a project from Ansible to k8s and even though it use only 2 nodes (~$200/mo), the tooling, the abstraction, the snappiness of gke was very much worth the switch.

For two nodes you need neither ansible nor k8s.

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

#472

Post by yoshiat »

jrockway wrote: post #460
busterarm wrote: post #444

Earlier quoted context omitted.

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…

Namespaces handle most of these issues. A NetworkPolicy can prevent pods within a namespace from initiating or receiving connections from other namespaces, forcing all traffic through an egress gateway (which can have a well-known IP address, but you probably want mTLS which the ingress gateway on the other side can validate; Istio automates this and I believe comes set up for free in GKE.) Namespaces also isolate po…

Exactly!

https://cloud.google.com/kubernetes-engine/docs/best-practic...

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

#473

Post by marcinzm »

bartread wrote: post #383
txomon wrote: post #37

Earlier quoted context omitted.

He means that there was a sales pitch from all gcp sales guys to not charge for that. 99.95% is not enough IMO to charge 73$/mo. As someone else noted, it breaks a lot of recommended architectures where you would have auto provisioning and a lot of clusters to separate concerns and keep costs down. Finally, the pricing changes are starting to look like a pattern, every time Google deems the usage of a product is good…

> Finally, the pricing changes are starting to look like a pattern, every time Google deems the usage of a product is good enough, they will increase the price. To be fair this is hardly new and by no means limited to Google. Any number of SaaS startups that have survived to at least moderate success have done similar things. Look at UserVoice as an example: started out with a free tier plus some reasonable paid tier…

>Any number of SaaS startups that have survived to at least moderate success have done similar things.

Google is not a startup, it is one of the largest companies on the planet.

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

#474

Post by sciyoshi »

agoell wrote: post #200

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

We've been running our own cluster on EC2 nodes built with kops and it's worked well so far. As for logging, which part of ELK is heavy? You can use the cloud operator to run it from within your cluster (https://www.elastic.co/elastic-cloud-kubernetes). We've also switched to https://vector.dev as a more lightweight alternative to filebeat/logstash.

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

#476

Post by bogomipz »

geerlingguy wrote: post #417
bogomipz wrote: post #358

Earlier quoted context omitted.

Maybe I'm misunderstanding your comment but at $0.10 an hour wouldn't GKE pricing be half of what the EKS pricing for managed control plane at $0.20 an hour? https://aws.amazon.com/blogs/containers/cost-optimization-fo...

EKS is $0.10/hour

From my link above:

>"The EKS control plane is the easiest to understand with a fixed cost of $0.20 per hour."

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

#477

Post by iampims »

jrockway wrote: post #460
busterarm wrote: post #444

Earlier quoted context omitted.

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…

Namespaces handle most of these issues. A NetworkPolicy can prevent pods within a namespace from initiating or receiving connections from other namespaces, forcing all traffic through an egress gateway (which can have a well-known IP address, but you probably want mTLS which the ingress gateway on the other side can validate; Istio automates this and I believe comes set up for free in GKE.) Namespaces also isolate po…

Namespace are not always well suited to hermetically isolate workloads.

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

#478

Post by iampims »

yongjik wrote: post #388
slovenlyrobot wrote: post #354

Earlier quoted context omitted.

The most common thing I've heard is "blast radius reduction", i.e. the general public are not yet smart enough to run large shared infrastructures. That seems something that should be obviously true. People had exactly the same experiences with Mesos and OpenStack, but k8s has decent tooling for turning up many clusters, so there is an easy workaround

I still feel like that would only work in very niche cases. I mean, if people aren't smart enough to run a large shared infrastructure, how can I trust them to run a large number of shared clusters, even if each cluster is small. The final scale is still the same.

Updating 100 clusters bares less risk than updating a single giant one.

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

#479

Post by sheeshkebab »

dahfizz wrote: post #463
olafure wrote: post #270

Earlier quoted context omitted.

$3600/year is significant for a startup on a shoestring budget.

Then manage k8s yourself. Or, better yet, don't use k8s. You don't need it, especially as a startup on a shoestring budget. You can migrate later if you decide you really need to, but just a plain LAMP gets you 99% of the way.

But then you can’t put k8s on you resume for when said startup implodes.

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

#480

Post by sheeshkebab »

rolleiflex wrote: post #449
carterehsmith wrote: post #350

Earlier quoted context omitted.

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.

sheesh, the lengths you guys went to build that monstrosity.
Post reply on HN