Webinar Description
Key Takeaways
- Addresses the kernel-level observability gap in Kubernetes environments that standard container metrics cannot capture
- Explores kernel-per-workload isolation as an architectural pattern for multi-tenant platforms
- Covers practical implementation using Prometheus and Grafana for exposing kernel metrics
- Aimed at platform engineers and cloud native practitioners managing Kubernetes infrastructure
- Demonstrates self-service debugging models that reduce operational burden on platform teams
Introduction
Kernel Observability: The Missing Layer in Cloud Native Engineering is an online session scheduled for 6 August 2026, designed for platform engineers and Kubernetes practitioners grappling with visibility limitations in containerised environments. The session examines why traditional observability tooling fails to capture kernel-level behaviour on a per-workload basis, and how emerging architectural patterns can address this gap. As organisations increasingly adopt multi-tenant Kubernetes platforms, the inability to isolate and expose kernel metrics to individual development teams has become a significant operational bottleneck.
The Observability Gap in Container Environments
Platform engineering has successfully abstracted much of the complexity inherent in Kubernetes deployments. Node management, networking configuration, and deployment pipelines now operate largely behind the scenes, allowing development teams to focus on application code. However, this abstraction has inadvertently created a blind spot at the kernel level.
When workloads experience memory pressure, page cache eviction, or I/O stalls, developers observe symptoms within their applications but lack visibility into root causes. The underlying issue stems from how Linux exposes system metrics through procfs: these metrics reflect node-wide behaviour rather than per-workload statistics. Container isolation through cgroups and namespaces provides resource boundaries, but observability remains tied to the host kernel shared across all tenants.
This architectural reality creates a recurring operational pattern. Developers encounter performance anomalies, lack the data to diagnose them, and escalate to platform teams. Those investigations require node-level access and specialised knowledge, interrupting platform engineers and creating ticket queues that slow incident resolution.
Kernel-Per-Workload Isolation as an Architectural Pattern
The session explores an alternative model: providing each workload with its own kernel instance. While this approach delivers security benefits through stronger isolation boundaries, the primary focus here is observability. When workloads operate against dedicated kernels, their procfs data reflects only their own behaviour. Memory statistics, pressure stall information, and I/O metrics become workload-specific rather than node-wide aggregates.
This isolation enables what platform engineers have long sought: a self-service debugging model. Developers gain access to kernel-level telemetry for their own applications without requiring cluster-admin permissions, without affecting neighbouring tenants, and without filing support tickets. The session will detail the architecture that makes this possible, including how to surface these metrics through Prometheus and Grafana in multi-tenant environments.
Technical Topics Under Discussion
The presentation covers several technical areas relevant to platform engineering teams. Attendees will examine Pressure Stall Information (PSI), a Linux kernel feature that quantifies resource contention, alongside /proc/meminfo interpretation and cgroup v2 statistics. These metrics provide granular insight into memory behaviour, CPU scheduling delays, and I/O wait times that application-level instrumentation cannot capture.
Practical debugging scenarios will illustrate how kernel observability aids real-world troubleshooting. These include identifying memory pressure before out-of-memory conditions occur, predicting OOM events through trend analysis, and diagnosing I/O bottlenecks that manifest as application latency. The session will demonstrate dashboard construction that exposes this data to developers in accessible formats.
Who Should Attend
This session is suited to platform engineers responsible for Kubernetes infrastructure, site reliability engineers investigating performance issues, and cloud native architects designing multi-tenant platforms. Familiarity with Kubernetes concepts, Linux fundamentals, and observability tooling such as Prometheus will provide useful context. Teams experiencing frequent escalations related to resource contention or seeking to reduce operational toil through developer self-service may find the architectural patterns particularly relevant.