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

511–520 of 633 posts

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

#511

Post by [deleted] »

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…

[deleted]

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

#513

Post by shaklee3 »

yongjik wrote: post #322
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. Off-topic, but is this really how people do k8s these days? Years ago when I was at Google, each physical datacenter had at most several "clusters", which would have fifty thousand cores and run every job from every team. A single k8s cluster is already a task management system (with a lot of complexity), so what do people gain by having many clusters, other than mo…

I think for one, you cannot easily have Masters span regions without risk of them falling out of communication. Similarly the workers should be located nearby. If there's a counterexample to this I'd love to see it.

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

#514

Post by aaronblohowiak »

ones_and_zeros wrote: post #175
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…

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?

I think you mean opex and not capex here.

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

#515

Post by dang »

cmhnn wrote: post #223
the_duke wrote: post #220

Earlier quoted context omitted.

> dick pic app so fuck em. > fucking > shit > horseshit > arrogant fucksteins > crap I'm not usually one to flaunt the HN guidelines, but I would suggest a read-through, and perhaps exploring different venues for venting frustrations.

Which axe are you grinding? If you took this personal then maybe something stuck because it should? If you mean there is no cussing allowed then I missed that for sure. Edit: ah checked your history. So you say things like "Amazon reviews are about as trustworthy as the selling points of a slimy salesman" thus impugning Amazon and salespeople in general but are coming after me because you are no doubt personally miff…

It's not ok to bring in someone's personal history as ammunition in arguments on this site, so please don't.

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

It's also not ok to do personal attacks with abusive language, so please don't do that either.

https://news.ycombinator.com/newsguidelines.html

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

#516

Post by shaklee3 »

freedomben wrote: post #459
JeremyNT wrote: post #450

Earlier quoted context omitted.

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…

Thanks for the edits (and acknowledging our contributions). I wasn't sure if you were just trolling or not before, so I didn't want to engage. Your concern is valid, and I agree with you that OKD is not supported enough. I have my own theories as to why, but I will keep my criticism "in the family" (but do know there are people that want to see OKD be a first-class citizen, and know we are falling short right now). W…

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.

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

#517

Post by shaklee3 »

theptip wrote: post #458
bcheung wrote: post #364

Earlier quoted context omitted.

I'm running my own on bare metal dedicated servers. You will need to install a few extra things (MetalLB for LoadBalancer, CertManager for SSL, an ingress controller (nginx, Ambassador, Gloo), and one of the CSI plugins for your preferred storage method). It is extra work but as a personal cluster for hobby work, I'm paying $65/mo total for the cluster. Same specs would probably be $1000/mo at a public cloud provider…

MetalLB looks fun, hadn't seen that one. If you want something production-grade (i.e. doesn't say "beta" on the tin) then I think Calico should solve most of the same problems too (it does BGP peering to your ToR switch): https://docs.projectcalico.org/networking/determine-best-net... Does MetalLB do something extra I'm missing?

Metallb had more features than calico before calico had the external service advertisement feature. Now that they do, services can use ecmp load balancers just as metallb does.

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

#518

Post by battery_cowboy »

jmb12686 wrote: post #492
apple4ever wrote: post #452

Earlier quoted context omitted.

I think our architects’ heads would explode if they were told we should treat them like cattle. For us, Clusters are a promise to our developers. We can’t just spin up a new cluster because we feel like it. I must be missing something or maybe our culture is just different.

As an architect, I am currently working on our org's first cloud deployment initiative. Due to federal compliance / regulations, we have no write access in higher / production boundaries, and everything is automated via deployment jobs, IaC, etc. Given the experience of the teams involved, I took the opportunity (burden) of writing nearly all the automation. If your architects can't handle shooting sick cattle in pro…

> If your architects can't handle shooting sick cattle in prod, I'd say get new architects.

For every 1 competent person who can develop a solution to fully automate everything, there are 99 others who can automate most of that, maybe minus a cluster or DB or two, and another 500 whom cannot do either, but can run a CentOS box at a reasonable service level.

You experience using great tools and your vast knowledge of k8s each day to do all that, and you have the support of your org, but those other folks may not have the tools, support, knowledge, or sometimes even the capability to attain the knowledge to do that. That doesn't mean they're useless to anyone, to be cast off at will!

The type of thinking that leads to, "get new engineers/developers/designers/architects if yours aren't perfect" needs to die, and needs to be replaced with, "let's do what we can to train and support our current employees to do a great job" because, frankly, there aren't enough "superstar" people who have your skills to do that at every org.

We need to work on accepting people for who they are-- helping them to strive to be a bit better each day of course-- and utilizing those skills in the right place, rather than trying to make everyone the same person with the same skills doing the same things.

Some applications don't need clusters which can be rebuilt and destroyed at will, so let's not make that the bar for every project.

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

#519

Post by battery_cowboy »

I saw someone mention Digital Ocean k8s products, right now Linode has a Linode Kubernetes Engine (LKE) "Beta" program going on where they give you some credits to fool around. I've been using it to learn k8s myself, and it couldn't be easier to use for a beginner.

https://www.linode.com/products/kubernetes/

I'm not even going to post or give anyone my Linode referral code, because I think their product is so good I'm happy to promote it for free, for no credit, especially if it can help someone leave Google for good.

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

#520

Post by skboosh »

yongjik wrote: post #322
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. Off-topic, but is this really how people do k8s these days? Years ago when I was at Google, each physical datacenter had at most several "clusters", which would have fifty thousand cores and run every job from every team. A single k8s cluster is already a task management system (with a lot of complexity), so what do people gain by having many clusters, other than mo…

There are potentially quite a few benefits of being able to spin up clusters on demand [1]:

* Fully reproducible cluster builds and deployments.

* The type of cluster (can be) an implementation detail, making it easy to move between e.g Minikube, Kops, EKS, etc. After all, K8s is just a runtime.

* Developers can create temporary dev environments or replicas of other clusters

* Promote code through multiple environments from local Minikube clusters to cloud environments

* Version your applications and dependent infrastructure code together

* Simplify upgrades by launching a brand new cluster, migrating traffic and tearing the old one down (blue/green)

* Test in-place upgrades by launching a replica of an existing cluster to test the upgrade before repeating it in production

* Increase agility by making it easier to rearchitect your systems - if you have a pet, modifying the overall architecture can be painful

* Frequently test your disaster recovery processes as a by-product for no extra effort (sans data)

* Reduced blast radius

[1] https://docs.sugarkube.io/#benefits-of-sugarkube

Post reply on HN