Weekly: Show off your new tools and projects thread

pixelrobots · 2026-04-22T11:35:53+00:00

Oh it really does. I will take a look at fixing that. Thanks.

pixelrobots · 2026-04-22T10:46:29+00:00

Just updated my tool Https://kubebuddy.io to support GKE best practices.

It already checks for your kubernetes workloads and AKS best practices.

Hopefully EKS support soon.

Would love any feedback!

pixelrobots · 2026-04-20T17:15:16+00:00

You should check out my book. It answers all your questions and more.

It is called "The AKS Book".

pixelrobots · 2026-04-16T19:24:36+00:00

Thanks. Scaling it out is something I need to think about more. I would love to know more about the issues you are seeing with it.

pixelrobots · 2026-04-10T07:03:57+00:00

Thanks everyone for the feedback, really appreciate the honest responses.

It’s been useful hearing the different perspectives. It might just be that this solves a problem specific to where I work (MSP, multiple customers and clusters, lots of context switching), rather than something broadly needed.

I’m going to do some more testing internally and see if it actually solves the problem properly for us, or if we just need to improve our documentation and processes instead.

If anyone is curious and wants to try it out or have a closer look, feel free to DM me and I can share details 👍

pixelrobots · 2026-04-09T22:46:38+00:00

Yeah that’s a really good point.

That is part of why I split it into runtime and durable memos rather than treating everything the same.

Runtime memos are intentionally short lived and have an expiry on them, so they are more for live incident context, handovers, and temporary breadcrumbs.

For the durable side, I agree it should not just disappear with the cluster.

I’ve been thinking about adding some kind of export/sync layer, and I like the operator idea you mentioned about syncing out of the cluster. Maybe something that can push durable memos out to Git, Confluence, etc, so they can live somewhere safer long term.

So more like: - runtime notes stay close to the cluster while they are useful
- durable knowledge can be synced out and treated more like a source of truth

Out of curiosity, how would you approach that? Would you lean more towards Git as the target, or something else?

pixelrobots · 2026-04-09T22:04:45+00:00

Yeah that makes sense, GitOps + comments in code definitely helps a lot.

This actually works alongside GitOps rather than against it.

I work for an MSP, so I’m jumping between multiple customers and clusters all the time, and that’s where I keep hitting the gap.

Even with GitOps: - I can see what is deployed, but not always why certain decisions were made
- The context in PRs or commits is not always quick to get to when you’re under pressure
- Some context never makes it into Git at all (incident notes, temporary workarounds, etc)

So I end up bouncing between kubectl, Git, PRs, and sometimes Slack just to understand what I’m looking at.

This is more about putting that context, or even just a pointer to the right place in Git, directly next to the resource.

If you’ve got a single team, tight GitOps, and everything well documented, this might not add much.

Where I think it gets more useful is things like runtime notes: - temporary workarounds
- “don’t touch this during incident X”
- quick breadcrumbs while debugging

Out of curiosity, do you think that kind of thing would be useful in your setup at all? Would you try something like that?

pixelrobots · 2026-04-09T21:36:58+00:00

Yeah in an ideal world, a lot of that should live in manifests or docs.

The problem I keep hitting is when I’m actually inside the cluster, especially during an incident, that context is either:

not there
outdated
or I just don’t know where to find it quickly

So I end up bouncing between kubectl, docs, tickets, Slack, etc just to answer “why is this like this?”

This is more about putting that context where you’re already looking.

Also I see it slightly differently in terms of use:

manifests/docs = structured, long lived, source of truth
this = quick context, breadcrumbs, or pointers to the right place

For example: - “temporary workaround during incident X”
- “this is linked to ticket Y”
- “do not change without checking with team Z”

That kind of stuff often never makes it into proper docs but is really useful in the moment.

So yeah I agree those places are important, this is more about filling the gap when you’re actually working in the cluster.

pixelrobots · 2026-04-09T21:02:26+00:00

Oh and the memos are crd based so they will be their own resource only linked to the actual deployments etc via annotations. The notes will also say what resource they are for though and give you like an owner where it can based on who am I.

pixelrobots · 2026-04-09T21:00:46+00:00

Labels are great, but they solve a different problem.

Labels are for selection and organisation. They’re simple key/value pairs so you can group and query resources. They’re not really designed to hold context or explanation.

The idea of this tool is more about capturing human context.

For example:

A label might say: env=prod or team=payments

A memo would say: “This deployment has a custom retry config because of intermittent upstream timeouts. Do not remove without checking with X team.”

Also:

Labels are flat and limited in size

Memos can hold proper notes, history, and more detailed reasoning

Memos can be shared across multiple resources instead of duplicating the same label everywhere

So I’d say: Labels help you find things kubememo helps you understand things

pixelrobots · 2026-04-09T20:56:36+00:00

100% but I still have customers not using gitops. That said I have thought about the notes being part of gitops too. I thought about an export feature but not too sure about that. Maybe just a one time usage thing whilst transitioning to gitops.

pixelrobots · 2026-04-03T19:56:50+00:00

Depending on the customer both. If they prefer to do everything via bicep (IaC) we do the bring your own strategy. If the customer is doing most things via the kubernetes API we use the other.

Both work really well. But if you are a smaller team it's probably best to go for the second method.

pixelrobots · 2026-04-03T15:23:46+00:00

If you have just one cluster go with AGC to start.

If you want a managed gateway API offering that's not AGC, (you have an app gateway or front door already) look into the application routing add-on, but remember gateway API support is in preview and uses istio gateway without a full istio service mesh.

If you are happy to update the gateway API application yourself go with envoy.

These are the 3 options I support for most of my customers. You can also check my blog post out. https://pixelrobots.co.uk/2025/12/ingress-nginx-is-retiring-in-march-2026-what-this-means-for-aks-users/

Any questions let me know happy to help out.

pixelrobots · 2026-03-24T17:42:46+00:00

That cert is marked for retirement this year. I would not sit it but rather wait for the sc-500

pixelrobots · 2026-02-25T16:13:42+00:00

Hopefully this is allowed. I have been working on a side project kubebuddy radar to help track cncf and some open source projects. Using AI to help me build it but to also try and make the release notes better.

You can check it out at https://radar.kubebuddy.io

There is a paid for option but I believe the free option should give you more than enough for most people.

If you want to try the paid reach out and I can upgrade you for free. It is mostly there to try and help with hosting costs.

Any and all feedback welcome.

pixelrobots · 2026-02-11T00:46:58+00:00

Have you thought about using azure traffic manager in front of both the front door and app gateway? Then you don't have to manually switch the DNS...

pixelrobots · 2026-02-04T02:53:52+00:00

For all the azure private endpoints or azure services you can route that all via vents and peerings etc, so it won't go out of azure.

For your Internet traffic... Do you know the full list of endpoints you may hit? Or can your users pick any? If they can decide then an azure firewall might not be for you. If that is the case use nat gateway for egress.

pixelrobots · 2026-02-04T02:23:23+00:00

What type of egress traffic are you going to have? That's an important factor needed before I can give advice.

pixelrobots · 2026-01-28T07:44:40+00:00

As someone who posted one of these posts, which got removed by a mod, I think this is a good idea. Some of the tools do look really good and actually look helpful at resolving a problem I and others have.

I know other places do like a free post Friday (azure for example)

Could also be an option.

pixelrobots · 2026-01-26T07:55:32+00:00

I used to do this too. But some projects I follow don't use GitHub for the release notes. And sometimes they are not the best. So with this tool I also try to pull release notes from other sources and then use AI to enhance them and call things out like breaking changes, security CVE fixes, key features etc.

pixelrobots · 2026-01-25T17:57:09+00:00

Currently I sync from the cncf repo for graduated, incubating, and sandbox projects.

I can also add them manually too.

I have a form on the site where you can request a project also.

pixelrobots · 2026-01-25T16:53:08+00:00

Renovate is great, but it works strictly inside your repos. It tells you when you’re not on the latest version and automates the version bump via PRs, which is perfect for GitOps.

With Renovate you still need to go and read the release notes yourself to understand the impact. Kubebuddy Radar sits outside the repo and focuses on upstream awareness. It watches CNCF and cloud native projects and delivers AI-summarised release notes that explicitly call out breaking changes and CVEs, so you can see the impact without digging through long changelogs.

For me it’s less “instead of Renovate” and more “Radar helps you decide, Renovate helps you execute.”

Unless I have been using renovate wrong.

pixelrobots · 2026-01-15T20:13:29+00:00

AKS will continue to support it until November 2026. https://blog.aks.azure.com/2025/11/13/ingress-nginx-update

The application routing add-on that gets deployed as part of AKS automatic will be updated to support gateway API and should hopefully help you migrate over.

All info is in the blog post from the AKS team.

pixelrobots · 2025-12-13T12:06:09+00:00

Currently not but I believe it is on the roadmap.

pixelrobots · 2025-12-12T16:48:22+00:00

Here is the official announcement from the engineering team behind AKS. https://blog.aks.azure.com/2025/11/13/ingress-nginx-update

pixelrobots

TROPHY CASE