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

601–610 of 633 posts

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

#601

Post by YawningAngel »

Glyptodon wrote: post #540
ones_and_zeros wrote: post #175

Earlier quoted context omitted.

I agree the rollout is a little bumpy but I'm curious what workloads you are using k8s for where a $74/mo (or $300/mo) bill isn't a rounding error in your capex?

My boss viewed it as the main way to deploy containerized systems offered by cloud providers and figured we could run most of our internal only things in it for a couple hundred a month - we don't really need the guarantees and scale, and he saw it as a way to avoid creating excess numbers of dedicated VMs, as cloud run isn't sufficient for our non-static stuff. This view up until now has actually been quite accurate…

You could consider the flexible app engine

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

#602

Post by mrbrowning »

aludwin wrote: post #238
mrbrowning wrote: post #178

Earlier quoted context omitted.

I suspect I'm in the minority on this, but I would love for k8s to have hierarchical namespaces. As much as they add complexity, there are a lot of cases where they're just reifying complexity that's already there, like when deployments are namespaced by environment (e.g. "dev-{service}", "prod-{service}", etc.) and so the hierarchy is already present but flattened into an inaccessible string representation. There ar…

Hey - I'm a member of the multitenancy working group (wg-multitenancy). We're working on a project called the Hierarchical Namespace Controller (aka HNC - read about it at http://bit.ly/38YYhE0 ). This tries to add some hierarchical behaviour to K8s without actually modifying k/k, which means we're still forced to have unique names for all namespaces in a cluster - e.g., you still need dev-service and prod-service. B…

Hey, thanks for asking! My interests in it are primarily for quota management -- in my experience, this is inevitably a hierarchical concern, in that you frequently run into the case of wanting to allot a certain cluster-wide quota to a large organizational unit, and similarly subdivide that quota between smaller organizational subunits. Being able to model that hierarchy with namespaces localizes changes more effectively: if you want to increase the larger unit's quota in a flat namespace world, for example, there's no way to talk about that unit's quota except as the sum of all of its constituent namespace quotas.

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

#603

Post by patrec »

patrec wrote: post #548
sethvargo wrote: post #129

Earlier quoted context omitted.

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…

> clusters should be treated like cattle, not pets So my understanding that the official k8s way to upgrade your cluster is also to throw it away and start a new one (with some cloud provider proprietary alternatives). Let's say there is something actually important, stateful, single-source-of-truth in my k8s cluster, like a relational DB that must not lose data. I don't want downtime for readers or writers, and I wa…

It's kind of revealing that there are zero replies to this, 10 hours later.

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

#604

Post by zekrioca »

patrec wrote: post #548
sethvargo wrote: post #129

Earlier quoted context omitted.

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…

> clusters should be treated like cattle, not pets So my understanding that the official k8s way to upgrade your cluster is also to throw it away and start a new one (with some cloud provider proprietary alternatives). Let's say there is something actually important, stateful, single-source-of-truth in my k8s cluster, like a relational DB that must not lose data. I don't want downtime for readers or writers, and I wa…

In this case, one needs fault-tolerance. One way to achieve it is through replication, where an extra copy (or perhaps a reconstruction receipt) of your DB instance runs somewhere else. Usually DBs achieves this through transactions. Additionally, you can have distributed DBs, which then use distributed transactions for achieving so.

I am not expert, but K8s handles task replication, and either spawn or route a request to another task instance somewhere else. However, the application logic itself must handle the fault-tolerance (by handling its states through transactions or something else) should an instance fail. K8s doesn't do that for you.

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

#605

Post by shaklee3 »

freedomben wrote: post #598
shaklee3 wrote: post #516

Earlier quoted context omitted.

Honestly, the fact that it requires rhel or centos was enough to make it not feasible for us. I wish that would change, since I can't think of any reason the distribution should affect openshift.

There are several reasons, many of them are that the nodes themselves are managed by OpenShift operators. If you run (as cluster admin) `oc get clusteroperators` you'll see plenty that are for hosts, such as an upgrader and a tuner. If the operators had to be distro agnostic it would be a support nightmare, and we wouldn't be able to do it. With RHCOS (immutable OS) we also have enough guarantees to safely upgrade sy…

Can you describe what kind of tuning the rhel tuning tools do that are not available using the normal kernel constructs? Last I checked tuna and others did everything you could do in Ubuntu, but without knowing the guts of the system.

Again, I think the idea of OS is great, but you've lost us, and likely other big customers because of that restriction. Having old kernels is just not an option for some people.

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

#606

Post by mitsoz »

sethvargo wrote: post #154
rolleiflex wrote: post #145

Earlier quoted context omitted.

> This is great feedback, but clusters should be treated like cattle, not pets. I'd love to learn more about why your clusters must be so static. What’s inside our clusters are indeed cattle, but the clusters themselves do carry a lot of config that is set via GCP UI for trivial things like firewall rules. Of course we could script it and automate, but your CLI tool also changes fast enough that it becomes an ongoing…

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.

How is this any helpful? Are they supposed to implement everything in terraform or similar, is that your suggestion? Why don't you completely remove the editable UI then, if whoever is using it is doing it wrong. What a typical arrogant and out of touch with customers Google response.

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

#607

Post by itake »

rstupek wrote: post #239
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…

I think the saying "you get what you pay for" would apply in this case. People want to not pay for things, they don't get the things.

I think OP is saying that DO will delete all of those things if your credit card expires. Even if you have those features in place, you will lose everything.

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

#608

Post by rstupek »

itake wrote: post #607
rstupek wrote: post #239

Earlier quoted context omitted.

I think the saying "you get what you pay for" would apply in this case. People want to not pay for things, they don't get the things.

I think OP is saying that DO will delete all of those things if your credit card expires. Even if you have those features in place, you will lose everything.

Yep and I'm saying the reason DO isn't able to call you up to see why your card expired and to get you updated is because you're not paying enough to expect that level of service from them. There simply isn't enough "profit" from a service that costs so little to allow for that many customer service reps.

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

#609

Post by patrec »

zekrioca wrote: post #604
patrec wrote: post #548

Earlier quoted context omitted.

> clusters should be treated like cattle, not pets So my understanding that the official k8s way to upgrade your cluster is also to throw it away and start a new one (with some cloud provider proprietary alternatives). Let's say there is something actually important, stateful, single-source-of-truth in my k8s cluster, like a relational DB that must not lose data. I don't want downtime for readers or writers, and I wa…

In this case, one needs fault-tolerance. One way to achieve it is through replication, where an extra copy (or perhaps a reconstruction receipt) of your DB instance runs somewhere else. Usually DBs achieves this through transactions. Additionally, you can have distributed DBs, which then use distributed transactions for achieving so. I am not expert, but K8s handles task replication, and either spawn or route a reque…

Distributed transactions are a non-starter – I already said I want to run master-slave with synchronous replication, which is basically what you want to do in >99% of cases where you have a DB with important stuff in it.

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

#610

Post by aphistic »

twistedpair wrote: post #572
thockingoog wrote: post #271

Earlier quoted context omitted.

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.

Keep in mind that GKE cluster management was paid in the original GKE. GCP only stopped billing for cluster management when EKS released free cluster management.

When did EKS release free cluster management?
Post reply on HN