Stefan Schimanski
NVIDIA, Principal Engineer
Darmstadt, Germany
Actions
Stefan is a Principal Engineer at Nvidia, working on control planes, Kubernetes, kcp, and as a tech-lead in Sig API Machinery. He contributed a major part of the CRD feature set. Stefan is a 2nd time GoogleSummer of Code mentor with CNCF, loves to teach and help people to learn. Before Nvidia, he worked at Upbound on Crossplane based control planes and at Red Hat as architectural lead of kcp and apiserver lead. By trade, Stefan is a Mathematician and Computer Scientist, with a PhD in Mathematical Logic.
Links
Area of Expertise
Topics
The Life (or Death) of a Kubernetes API Request, 2025 Edition
This presentation takes an in-depth look at the path of an API request (e.g. a user sends a request to create a Pod through kubectl create). We take a deep dive into the phases a request passes through, in a chronological order, starting with its arrival at the k8s API Server, and ending in its departure carrying a response to the caller.
This talk will not dive into any code snippets, but rather will use easy to understand diagrams that dig deep into k8s architecture, and side by side, it will show the related observability artifacts (log, audit, metrics snapshot, and error messages) and clarify their implications. To our knowledge, no kubecon talk has covered this topic from an operator's perspective.
After attending this talk, the audience, whether they are an admin, an SRE, or a DevOps professional, will walk away with a much clearer understanding of "how things work in Kubernetes"; the new insights will make them more effective at finding root causes for complex cluster issues.
Dynamic Multi-Cluster Controllers with controller-runtime
controller-runtime is the most popular SDK to write controllers for individual Kubernetes clusters. But the Kubernetes landscape is changing quickly: multi-cluster is becoming ubiquitous (e.g. through Cluster API), with clusters joining and leaving dynamically. controller-runtime has had no direct support, making writing uniform multi-cluster controllers hard and fracturing the emerging ecosystem.
This talk explores how to build controllers that reconcile resources across a dynamic fleet of Kubernetes clusters. A key change is the ability to plug in a dynamic cluster provider that registers new Kubernetes clusters from a specific source. While implementation internals are briefly discussed, focus is on a hands-on walkthrough for writing your own cluster provider, event handlers and reconciler functions.
We discuss a simplistic cluster provider implementation for “kind” clusters as an example and extrapolate from that how more complex providers could look like (e.g. for CAPI or kcp).
Why Kubernetes is inappropriate for platforms, and how to make it better.
The ecosystem is building platforms on Kubernetes now, starting with a hub cluster and then sticking tools for Gitops, for application descriptions and for infrastructure management together, with the goal to create custom APIs for the platform consumers. This works, but hits limits of Kube as a framework quickly. Can we do better? Oh yes, we can!
This talk is about extending Kube, adapting its architecture to be a better fit for a world where instead of container orchestration two new personas are at the center:
(a) the service & API provider
(b) the self-service consumer, often developers or application owners.
We focus on 3 dimensions to enable Kube to serve platform engineering better:
- from kcp we take the workspace hiararchy as a vastly better multi-tenancy primitive.
- cross-workspace API exports and bindings tailor-made for the service provider and consumer personas.
- cluster mounting that integrates Kube clusters for a unified user interface and identity management.
The Missing Talk About API Versioning & Evolution in Your Developer Platform
In the realm of developer platforms, individuals without extensive experience in the cloud-native ecosystem are now venturing into the creation of Kubernetes-based APIs. Tools like Crossplane are transforming every platform engineer into an API designer. Ten years in, the ecosystem still offers little guidance on Kubernetes versioning and API evolution in practice. A naive understanding is not helpful, and many have been burned by relying on intuition.
This talk will provide deep, yet applicable knowledge, starting from the first principles of the invariants to maintain when changing APIs in Kubernetes. It will cover tools like schemas, conversion, validation, and admission, and present very concrete and directly applicable API Evolution Patterns. These patterns will help navigate the life cycle of CRD-based projects. This talk aims to educate on how to evolve APIs effectively and safely without inadvertently breaking users.
Shift-Left: Past, Present, and Future of Validation in CI for GitOps Workflows
GitOps has become the de facto approach for managing configurations. However; without robust validation mechanisms, automated deployments can lead to unpredictable outcomes and high maintenance costs.
Up until now GitOps users have largely been on their own for this critical step of their pipeline. Ever see a CI hooked up to prod? Or dry-running against a cluster that takes 10 minutes to spin up? Or forget to update an ObjectReference? Many real world usages defer to spinning up an apiserver with hundreds of CRDs installed as part of CI/CD just to test their manifests, since nothing else is reliable; others resort to incomplete and incorrect JSON schema validations. This is slow, expensive, and wastes valuable time.
In this talk you will learn how to reliably, quickly, locally, validate your Kubernetes manifests using kubectl-validate to how avoid common mistakes and reinventing the wheel when setting up CI for your GitOps system.
Deep dive into Generic Control Planes and kcp
The Kubernetes code now allows native construction of generic control planes, without container types and in new form-factors other than your beloved clusters, be it customized apiserver binaries or embedded into other applications.
This talk gives an in-depth explanation of what a generic controlplane is, how to construct it, how to extend it with custom types and how to control which native Kube APIs like secrets, configmaps, etc. or mechanisms like resource quota or RBAC are available.
Specifically, we will cover 3 variants:
1. single-tenant generic control planes using upstream Kubernetes.
2. multi-tenant generic control planes using kcp to scale horizontally in one process.
3. multi-shard and multi-region generic control planes with focus of backing SaaS services.
Stefan Schimanski
NVIDIA, Principal Engineer
Darmstadt, Germany
Links
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top