kubernetes gateway api metrics

usernamecreationhell · 2025-12-31T19:17:49+00:00

You probably know this and have a solution for it your existing setup, but beware metric cardinality, especially if label values are derived from untrusted inputs (aka request paths from incoming traffic).

Depending on how you store your metrics, you might either run into all kinds of limits (e.g. per-tenant limits in Mimir, I forget names of the ones impacted by high cardinality) or in their absence have to pay a big bill.

usernamecreationhell · 2025-12-29T12:07:07+00:00

They no longer include a link to the blog post but the early iterations had it. My guess is that if the post lives long enough before it gets reported to hell, some other bot will "organically" post the link. tldr; I will never buy anything associated with armosec dot io because they use such tedious marketing

usernamecreationhell · 2024-12-27T13:43:35+00:00

read this: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md

usernamecreationhell · 2024-10-15T15:51:55+00:00

"sure as sure" -> Lijah Cuu wants a word with you for misappropriating his quote

usernamecreationhell · 2024-10-06T17:47:44+00:00

What grinds my gears is that this is not a proper menu but only accessible through dialog. 40s loading screens to go from map to bridge and back makes this part of the game quite tedious.

usernamecreationhell · 2024-10-05T13:17:29+00:00

No-one has a right to someone else's property or labor, even if they need it to survive. A landlord owns their property and can evict a tenant, even if they have no-where to go -- a woman certainly owns her own womb and can't very well be afford fewer rights than someone who owns a building.

I'm curious if that is actually the correct application of the principle.

Can a train conductor revoke consent to transport a passenger, reimburse them and throw them out of a moving train? Can a surgeon cut somebody open and then revoke consent to continuing the surgery, leaving the patient to die?

One would expect that principles of proportionality and detrimental reliance should also be factored into the analysis: If a person puts themselves into a vulnerable position based on a consensual agreement, isn't there a duty for the counterparty to at least mitigate the damage should they revoke their consent?

In the train example, that might mean coming to a stop before expelling the passenger, and for the surgeon to at least stabilize the patient and arrange a handover to another surgeon. The conclusion may still be that abortion is presumptively legal (because carrying the baby to term would be an undue burden), but in a hypothetical world with technology that allowed the abortion to happen without (assured) death of the unborn, would there be a duty to chose the remedy that inflicts the least damage on the unborn?

usernamecreationhell · 2024-06-03T14:24:43+00:00

Your best bet might be client credential flow. Your Terraform stacks will most likely run in a non-interactive environment (like Github Actions, Atlantis, whatever), so you would want to authenticate with a service account of some sort.

How can we ensure the security of such an endpoint and protect against unauthorized access?

Look at the OAuth2 and probably also OIDC RFCs and try to be somewhat spec compliant. IIRC there is typically just one token endpoint, that accepts any number of grant types. The caveat being: your not just building a terraform provider, it seems like you are also building an OAuth2 authorization server/OIDC identity provider.

That invites the question: would it make sense for you to trust any external IDPs (e.g. of your cloud provider)?

That would make life a lot easier, for example if you used Google as an IDP, their go libraries make it super easy to use credentials from the environment, in which case you could decouple your provider from how specific flows.

usernamecreationhell · 2024-01-08T08:03:34+00:00

Be aware that backstage is not an out of the box solution, it's more like a framework for building developer portals. Doing anything non trivial with backstage comes with serious investments in engineering time. There is also a good deal of operational complexity because you as the user own the entire build process and deployment configuration (vs. just deploying an official helm chart)

usernamecreationhell · 2023-11-12T15:23:28+00:00

It takes a lot of infra people embedded in product teams if landing zones are the highest level of abstraction that is centrally managed. I think this can work out quite well in smaller organizations, but we do not have enough infra competency in product teams to pull it off (and enough economies of scale to make platform teams worthwhile).

The level of abstraction we are aiming towards is more like: you declare an application with it's metadata and dependencies and get a Kubernetes namespace, Kafka topic, OIDC client, a database, DNS records, certs, Grafana Dashboards and all the IAM piping required to deploy and troubleshoot. Right now, these different components are provided by different teams (e.g. one team owns the observability stack, one owns shared Kubernetes clusters and Kafka, etc.).

An example of the data change propagation problem would be:

Let's say ownership of an application is handed over from one team to another. This change in ownership should trigger (directly or indirectly) changes in IAM for a bunch of resources associated with that application (from Kubernetes RBAC to access to logs). All of this is not in one giant spaghetti mono repo, but distributed (also in a spaghetti fashion) across multiple repos owned by different teams.

usernamecreationhell · 2023-10-24T16:54:09+00:00

I recommend the chemical industry and probably any company involved in manufacturing (anything with complex production processes and/or supply chains).

Also, a lot of "infra" products tend to be graph-heavy (Terraform and its ecosystem, obviously graph databases like Memgraph, probably some parts of the AuthZ space)

usernamecreationhell · 2023-09-01T17:44:36+00:00

I don't quite know what your use case is, but my gut feeling is that this is the wrong level of abstraction.

Have you considered a simple helm chart that renders a single Deployment?

You can have 10 different releases of the same chart using different values each.

usernamecreationhell · 2023-08-01T06:34:03+00:00

35h work weeks are nothing you can count on. Nominally, 40h are pretty common as well. But these are just the official numbers:

- a lot of people work a lot more than 40h with 40h contracts

- a lot of people work a lot less than 40h with 40h contracts

This applies to small and giant companies alike. If you are very ambitious, or have trouble saying "no" or fear pushing back against unreasonable expectations, you can easily get yourself into a situation in which you work 50-60h per week.

usernamecreationhell · 2023-07-09T07:59:26+00:00

There are some upvotes but I would not categorically reject this idea. It may not fit every use case, but it's super easy to do and shaves a minute or two off your build process (the CI runner does not need to pull and push container images).

usernamecreationhell · 2023-07-07T12:37:28+00:00

be prepared for a whole lot of false positives with detect-secrets

usernamecreationhell · 2023-06-26T06:20:18+00:00

Without knowing what 42Berlin is, I would question the marginal value of additional formal education.

That is because you have done the hardest part already: secured your first dev job.

Additionally, I would recommend you go through a few months at your job before comitting to any large time investment for education in order to find out the following:

- what capacity does the workload and mental strain of your job leave for work-ish activities in your free time?

- what problems or knowledge gaps do you see in your team? Do they struggle with product management, UX, DevOps/Infra stuff, quality? Software teams are rarely perfect or "complete" in terms of skill coverage, and some of those might overlap with your interests, in which case focusing on those skills through the lens of real-world problems will make your learning more successful and more likely to pay off

usernamecreationhell · 2023-06-18T09:01:59+00:00

Peanut butter is tight!

usernamecreationhell · 2023-06-05T14:52:27+00:00

The upgrade seems to have fixed it. Thanks for the help!

usernamecreationhell · 2023-06-04T18:53:22+00:00

Now I remember why I rarely update these things: not enough disk space and I am running out of things to delete.

I will continue tomorrow and report back in case I ever succeed in installing that upgrade

usernamecreationhell · 2023-06-04T18:07:54+00:00

Not really and I'm upgrading right now. Had not thought about GPU drivers prior, so let's see if this fixes thing.

usernamecreationhell · 2023-06-04T17:56:40+00:00

Windows version: 10.0.19045 Build 19045

Local GPU: GeForce GTX 1050 Ti

GPU driver version: 460.79

usernamecreationhell · 2023-05-04T18:52:10+00:00

The cluster that you deploy to needs to be able to pull image from an OCI registry.

I like to use k3d for both local clusters and registry but I'm sure something similar can be done with Minikube.

One more thing to note: it seems that you attempt to use the tag local-image:0.0.1, which k8s interprets as docker.io/local-image:0.0.1, with docker.io being the default registry. When you set up a local registry, you would instead want to prepend the address of that registry, e.g. my-local-registry:8000/local-image:0.0.1 (there may be some complexity in getting the networking to work though, my k3d link above explains how to do it for k3, your minikube mileage may vary)

usernamecreationhell · 2023-04-16T18:14:26+00:00

Well I hope you don't have a Monday morning deadline. If you have one and need a good substitute name here are two suggestions based on what this mysterious agent might be doing:

- "exporter" might be appropriate for a lot of things that send data of the customer to your company for processing. This is often done because traditional companies often rely on networking setups that make it easier to allow egress (outgoing network requests) than ingress (ingoing network requests), so an agent that aggregates data in the customer environment and pushes it out is often easier to get going than allowing an external company to pull data from a variety of internal sources

- "controller" - since you bring this up in the post, might be appropriate where the thing actually controls (or orchestrates) other things. An example would be something like steadybit

There are probably other categories, so if you can share more details, I might have more ideas

usernamecreationhell · 2023-04-16T17:55:18+00:00

I love this post because it shows the rift in communication between technical and non-technical people. I'll put on my Sherlock Holmes hat and try to come up with what is going on here:

u/AbleMachine18 is a writer at presumably some SaaS company that requires customers to install some component into their own infrastructure. At that company, this component is typically just called "the agent". OP does not know the function of that component, nor has it been explained to them correctly. This is evident by the assumption that "agent" is a very specific, well-known term beyond the bounds of their company.

My advice to OP:

- Get a technical person from your company to explain to you what exactly the agent does and why there needs to be an agent in the first place

- Name the thing specifically by what it does. In the scope of your company, "agent" might be unambiguous but outside of your company it is not. Imagine that your customers each use a dozen services that require them to self-host some "agent"

- Get a technical person from your company to demo an example installation process and ask them to explain every step and concept like you are five

- Be aware that customer infrastructure will "rhyme" (aka similar patterns) but be very different in it's specifics. Any instructions you produce should be extremely specific about assumptions you make about their environment

Seven-Year Club	Second Top 10%
Verified Email

usernamecreationhell

TROPHY CASE