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

491–500 of 633 posts

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

#491

Post by mlthoughts2018 »

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.

boy this comes across really tone deaf. GCP makes it very hard to change e.g. multi-region settings, but I guess it’s the customer’s fault for not already using this contextless name-dropped best practice.

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

#492

Post by jmb12686 »

apple4ever wrote: post #452
p_l wrote: post #405

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. Clusters often are not "cattle". If your operation is big enough, then yes, they might be. Usually they aren't, they are named systems and represent mostly static entity, even if the components of said entity change every hour. Personally, I'm running in production a cluste…

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 prod, I'd say get new architects.

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

#493

Post by zapita »

jfrankamp wrote: post #427

This strikes me as an attribution problem e.g. Within large companies business units are treated as standalone financial entities so you are either making money or a cost center. I think what could be happening here is that the kubernetes group is generating what look like un-paid-for costs, instead of being back-credited for ALL of the compute they are selling via the worker VMs. I would argue that people come to GC…

It would be cool if service teams were credited a referral fee for all future consumption, platform-wide, by consumers that started with their service. As a bonus it would incentivize each service team to prioritize easier onboarding.

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

#494

Post by JeremyNT »

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…

Yes, I realize I will come across as being overly negative here, and I apologize for this.

It's not that openshift is bad per se, I just don't imagine it solves many problems an org that is fretting about lock in or gcp pricing will have. Such an org is probably cost sensitive and looking for flexibility, but openshift is expensive, and if you adopt its differentiating features you are de facto locking yourself in. And if you do not leverage those features out of a desire to avoid lock in, you are effectively paying a whole lot just for k8s support...

And I really should say, for certain orgs (especially bigcos) this may well be worth it, I just don't think it is a good option for anybody worried primarily about avoiding vendor lock in and keeping costs in check.

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

#495

Post by sharms »

yoshiat wrote: post #472
jrockway wrote: post #460

Earlier quoted context omitted.

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

For those that didn't click through, I believe the parent is demonstrating that it is a best practice to have many clusters for a variety of reasons such as: "Create one cluster per project to reduce the risk of project-level configurations"

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

#497

Post by jjeaff »

MuffinFlavored wrote: post #242

How many businesses really need Kubernetes? Can't you orchestrate infrastructure + rolling deploys with Terraform + Docker containers?

I'm not aware of any rolling deploy functionality with terraform or docker.

Docker swarm does, but they are primarily using swarm with kubernetes these days.

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

#498

Post by yoshiat »

sharms wrote: post #495
yoshiat wrote: post #472

Earlier quoted context omitted.

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

For those that didn't click through, I believe the parent is demonstrating that it is a best practice to have many clusters for a variety of reasons such as: "Create one cluster per project to reduce the risk of project-level configurations"

For robust configuration yes. However one can certainly collapse/shrink if having multiple clusters is going to be a burden cost-wise and operation-wise. This best practices was modeled based on the most robust architecture.

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

#499

Post by ChuckMcM »

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…

For obvious reasons, this anecdote reminds me of the adage that one of the things you have to watch out for when saving someone from drowning, is that their flailing about will put your own life in danger.

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

#500

Post by tamale »

thockingoog wrote: post #280
tamale wrote: post #264

Earlier quoted context omitted.

Our cloud service here at confluent is designed around giving customers their own infrastructure. A lot of the times, that means giving them their own k8s cluster. The management overhead there isn't the issue however. The real issue comes into play when you try to make developer environments. To give our developers any semblance of a "real production-like" workload, they need to work with an entire kubernetes cluste…

Try KIND. Much better devex.

ya we're using that in a few places, too actually.
Post reply on HN