sethvargo

See also: https://news.ycombinator.com/item?id=22485679

Thank you for the feedback. The management fee is per cluster. You are not billed for replicated control planes. You can use the pricing calculator at https://cloud.google.com/products/calculator#tab=container to model pricing, but it should work out to $73/mo regardless of nodes or cluster size (again, because it's charged per-cluster).

There's also one completely free zonal cluster for hobbyist projects.

Hey everyone. Seth from Google here. There's another parallel thread at https://news.ycombinator.com/item?id=22485625 and I've responded to items there. I'll try to respond to items here as well.

You keep noting how "easy" it is to provision and manage a Kubernetes cluster. From experience, properly securing and maintaining a Kubernetes cluster is a multi-person full-time job.

Even if your worker nodes are pre-emptible, the master nodes are not. The management fee covers running those master nodes and many other core GCP integrations (like Stackdriver logging and other advanced functionality). Billing is computed on a per-second basis for each cluster. The total amount will be rounded to the nearest penny at the end of the month.

It's slightly different than other cloud pricing because we include a free zonal cluster as a hobby tier.

Just doubling down on the free zonal cluster as a hobby tier. Folks seem to be missing that among the announcement.

We offer one free zonal cluster, which is specifically designed for your use case :)

Thank you for the question. While I can't go into deep detail... as with most free things, people find a way to abuse the system. While we've invested significant effort to curtail such abuse, this is the road we've landed.

To your point about running your own K8S cluster - two things:

1. That's something you have always been (and still are) entitled to do.

2. Having personally run large-scale K8S clusters, the challenge isn't provisioning, it's maintenance, security patches, upgrades, etc.

That's great feedback. I'll relay that to the product team. IANAL, but I think it would be legally challenging.

I'm sorry to hear that. You can use namespaces and and separate node pools to isolate workloads. We'd love to hear more about your use case for having many small GKE clusters.

Thank you for the feedback.

> Google's inability to actually commit to long term support...

This is _exactly_ what Google is doing in this case. We are providing an SLA - a legal agreement of availability and support. These changes introduce a guaranteed availability of the management control plane.

You don't need to do the calculations by hand :). We've updated our pricing tool to account for these changes: https://cloud.google.com/products/calculator#tab=container.

Hey everyone - Seth from Google here. Please let us know if you have any questions! You can learn more about the pricing changes at https://cloud.google.com/kubernetes-engine/pricing.

Thanks :). I'm waiting on Terraform support for Secret Manager[0], then I'll update the configurations to use that for storing the initial root token and certificates.

Vault works great on GCP, and it's used by hundreds of enterprises who want brokered identity management across clouds, dynamic secrets, and an open core model that fits their business.

However, we kept hearing that sometimes Vault was complex for some small problems. If you're not using its advanced functionality, Vault is incredibly cost prohibitive. It doesn't run well in a serverless environment, so you have to pay for VMs 24/7 even when secrets aren't being accessed.

We continue to contribute to Vault and build deeper Vault integrations into GCP - that's not changing. Secret Manager provides choice. Just like there's certain scenarios where you'd prefer a NoSQL database over a relational one, there are scenarios where you'd prefer Secret Manager over Vault and vice versa.

Since this question and "Secret Manager vs Cloud KMS" keep coming up as questions, I'm going to work with our team to put together something in the documentation.

[0]: https://github.com/terraform-providers/terraform-provider-go...

Sure - in short, we partnered with multiple customers in designing and building this service. Let me check with my team and see what we _can_ talk about :)

Secret Manager is a Google Cloud first-party fully-managed service. Vault still works and runs great on GCP for users who want more advanced functionality like dynamic secrets.

Enable Cloud Audit Logging for Secret Manager and give us feedback. We know auditing is super important, so it's built in!

Sorry the pricing is unclear. In Secret Manager, secrets are versioned (a "secret" is a named collection of "secret versions"). We only charge for active secret versions (you can destroy secret versions, usually after a rotation operation).

The secret version contains that actual secret data (i.e. "ABCD1234"), and you can choose the regions in which you want that secret data replicated. Each region you choose is $0.06.

So if you had 1 secret with 12 versions stored in 2 regions, that would be 12 x 2 x $0.06/mo = $1.44. Hope that helps!

EDIT: replaced "*" with "x" in math because it was getting parsed as italics

While I cannot comment on specifics, we are going to provide deeper, first-class integrations with other GCP products.

Hey everyone - sorry for the delayed reply, I've been on a plane. Seth from Google here, the same Seth in the byline of the blog post.

We are very excited to bring Secret Manager to the market. Let us know if you have any questions!

If you read between the lines, it appears to be a liquidation.

That's a big question :). I don't think they're mutually exclusive. GKE provides more flexibility but requires more configuration. GAE is less flexible but more "serverless". GKE is probably more expensive for a single app, so I'd probably pick GAE for a single app. For a _project_, I'd have to understand more about what I'm building and what I need.

I'd also probably use Cloud Run over GAE, but that's a personal preference because I've been working closely with that product lately.

FWIW, we're exploring ways to make this better. We know it's a point of pain for customers. One of the challenges is that the "project owner" isn't always the right person to receive these kinds of alerts, since often that's someone in the finance department or central IT team. There are a few ideas being thrown around about more proactive notification right now.

This is fundamentally incorrect. GAE has many users and is actively being developed.

Correct, this outages is affecting a few (but not all) regions.

GKE runs on GCE. It's affecting both.

There are many downstream impacts. Without more information, it's hard to say for certain, but "most likely".

Unfortunately yes. Most products are currently affected and may experience partially degraded service. See https://status.cloud.google.com/ for the full impact matrix.

As reflected on the status dashboard, we believe a primary cause is related to datastore. Our SREs continue to investigate and attempt mitigation.

Also, we do use GKE internally :)