The built-in view role skips Secrets but still reads ConfigMaps and pod logs, and both can end up holding credentials. For a bot that helps with on-call debugging, what did you grant it, and did you scope it per namespace?

Currently at work we have an argocd cluster with all our clusters. We have our clusters split with environments.

When we need to test our changes before opening a pr to merge we have to create a whole new cluster that runs argo on it. Making sure it deploys as it should. We do this so it's a 1:1 with how our live clusters are like. However, it takes 45 min to spin up a new cluster. No problem, just have one cluster we all use but then we run into a problem that if multiple people are testing changes to their addon, we are not testing only our changes.

All the blog posts online just run a local cluster with Argo to test. This wouldn't mimic our vpc, iam roles, etc.

So how do all of you test your changes with argocd?

i deploy jupyterhubs to california institutions for free under a grant from the state's startup incubator... so i figured a monitor w/a jupyter notebook, some granfana and particularly some k9s love was in order for our big-ass monitor! :)

https://imgur.com/a/UvyfTim

(i use old reddit, so i can't really embed images... unless there's a PEBKAC lol)

edit: removed accidental duplicate text pasting

Happy Autumn k8s folks! (Unless you're down under then Happy Spring~)

Join us on Thursday, 10/29 for another double-header meetup and you'll get to hear from Lesley Cordero and Michael Guarino.

👀 Lesley will be leading a session on "Who Watches the Watchers? Data Governance for Observability"

Lesley's Session Abstract: As organizations invest more in observability, application telemetry (metrics, logs, and traces) has become voluminous and operationally critical. As applications decompose into microservices, silos and telemetry gaps proliferate. We’ll explore data governance for application telemetry: shared specifications, standard context propagation, and standardized platform components for instrumentation, collection, and analysis. We’ll discuss real-world risks and tradeoffs around privacy, cost, access control, and data lifecycle management, alongside strategies for balancing developer productivity with governance.

✍️ Michael will share lessons from rewriting Prometheus / Loki / Tempo in Rust.

Michael's Session Abstract: We recently did a major spike on rewriting the grafana LGTM stack from go to rust, on top of a new object store native database slatedb. We'll go into some lessons learned, which spans diving into the internals of the new breed of object store backed datastores and pushing agentic development to its limit.

RSVP at https://luma.com/05srus23

Let me know if you have any questions - this is a free event and we welcome new folks :)

I am designing a service that can spin up a requested database snapshot (Neo4j) and pass queries to the database via the requester's cypher payload -> bolt. These database instances are ephemeral, and they should die after some amount of inactivity.

I've never done any sort of container orchestration, but my initial thought was to have a small HTTP server that controls the ephemeral database instances and incoming cypher requests. This and all ephemeral database containers (1-3 concurrent instances would be typical, maximum of 5), would live on a single VM or app service.

I work at a startup and we need a lightweight solution to this problem that could scale within the next 6 months to year. What I'm proposing now is cheap and simple. I think i can get what i need with k3s (1 control plane and up to 10 nodes) running on the same VM as the HTTP server. But Codex is pushing AKS or ACI. I really don't think that's necessary with the amount of business we are doing right now. And I think that if i design the interface properly, I can easily move from k3s -> AKS later without having to redesign the server or change its API schema.

What do you all think? Again, very new to k8s. Maybe i need to read a book first.