I’ll be attending KubeCon 2025 in London this week, and made the resolution to write down some of the impressions.

Tuesday, co-located events

The first day of KubeCon was about the co-located events (see schedule), and this ‘slow’ kickoff was already a blast.

I attend mostly the one-day ArgoCon, but switched a bit back and forth based on my interest throughout the afternoon.

This first day was already highly inspiring, and I can’t wait to find the time to experiment and prototype with the different tech that I’ve been seeing.

Argo

We’re already employing GitOps for Alan at Comma Soft, but have been doing that mostly for the apps and not for the services (we distinguish workloads that are developed internally, e.g. frontend/backend, and the external dependencies, e.g. oauth-proxy, kube-prometheus-stack, cloud-native postgres).

When embarking on the technical design journey for Alan, we decided to use flux as the GitOps tool of choice mostly to have a light-weight alternative and to get some experience with a different technology in that space.

Given the maturity (and complexity) that we’ve developed over the last two years, I think it’d be great to benefit from the additional offerings that Argo brings – and this extends beyond ArgoCD to workflows, events and other components from this ecosystem.

One of my favorite talks was on ArgoCD autopilot, which allows you to bootstrap and to recover Argo cluster. I’ll go ahead and use that for an upcoming addition that I’d like to make to the Alan setup.

kserve

kserve offers k8s-based inference for ML models, including LLMs. It is build on top of e.g. ray and vllm, both of which we use extensively in Alan. Choosing the right stack and the right level of abstraction is tricky in this context, and there might be some benefit in experimenting with kserve to replace our current setup. On the other hand, we’ve developed quite the code base here and there is no immediate pain point that warrants such a rewrite.

OpenFeature

One of the dedicated session was on OpenFeature, and their offering matches quite nicely what we need right now to manage the growing complexity in the Alan feature set.

We’ve been following a simple approach for now without a dedicated framework to manage feature flags, so this is high up on my list of possible additions to our stack.

On top of that, I followed two interesting talks: one was on feature flagging instead of rollbacks to simplify your deployments, meaning a strategy in which breaking changes don’t impact production and thus require rollbacks by applying an appropriate canary release strategy.
The other one was by Graham McNicoll on managing complexity and matching feature flags from your different microservices and from your feature configuration, and to resolve mishaps and reduce complexity.

Otel debugging

I sadly only found time to attend one talk in the monitoring session. This talk by Edmo Vamerlatti Costa was about ottl.run, which is open telemetry experimentation tool to debug the open telemetry processors. I think that’ll be a wonderful addition to improve and maintain our monitoring stack for Alan.

Continuous learning in the k8s space, kubestronaut

Towards the end of the day, I was following some lightning talk about the learning path to better proficiency in the kubernetes realm, and I’m excited to complete the first set of certifications (CKAD, CKA) towards obtaining the kubestronaut seal of approval.