I'm working on a side project called kubememo, aimed at helping users add context or notes directly to Kubernetes resources. As someone who deals with multiple customer environments, I've noticed that finding the right documentation during a crisis can be a real challenge, especially when context is scattered across different platforms.
The goal of kubememo is to serve as a lightweight memory layer for clusters where you can add notes or context alongside resources like deployments and services. Think of it as a way to leave breadcrumbs for future reference or capture key decisions right where they're relevant. Notes can live as durable or temporary memos, linked to resources through annotations, so everything remains Kubernetes-friendly without cluttering annotations.
Before I invest more time into this, I'd love to hear if you think this tool could genuinely help, if it addresses any pain points you experience, how you currently manage insights about your configuration, or if there's anything crucial I might be overlooking.
7 Answers
I’m curious how this differs from native labels. Aren't labels meant to add metadata? Why not just use them instead for notes?
It's important to store notes off-cluster to protect against losing tribal knowledge if the cluster fails. You might consider creating a controller that syncs these memos to an external repository for backup.
Great point! I’m thinking of offering an export function, so durable notes can be saved outside the cluster, ensuring they remain accessible even if something goes wrong.
Documentation alongside the resource seems like an anti-pattern. It could create confusion if it's not handled properly.
If annotations can store multi-line content, why not just use them for notes instead of a separate tool? This approach seems unnecessary if you can already attach notes directly to resources.
Having proper GitOps with Helm or static YAMLs is the best practice. Treat your cluster as ephemeral and keep documentation in Git. If all your resources are in Git, your notes will stay safe even if the cluster goes down. Adding notes directly in Kubernetes might leave you vulnerable if you lose access to the cluster.
Totally understand, but many clients I work with aren't on GitOps yet. I'm considering integrating an export feature for notes to help during the transition.
This whole idea seems overengineered. If I need to leave a note, I’d just use a ConfigMap or write documentation. Why complicate things?
I only use GitOps, which means I always have access to comments and context through my code. It's a more reliable way to keep track of changes and reasons behind configurations.
That makes sense! For teams that implement GitOps well, this tool might not seem necessary. However, I think it could add value when you're jumping between multiple environments where context gets lost.
Labels are great for organization and selection but they're not intended to provide explanations or context. For instance, a label can tell you the environment, but it won’t give you the reason why certain settings are in place.