Presented by Kasm Technologies
Enterprise infrastructure teams have spent the better part of a decade bringing workloads to Kubernetes. Applications, APIs, batch jobs, data pipelines: If it runs in a container, it belongs to the cluster. The operational benefits are well established: declarative configuration, horizontal scaling, self-healing, native integration with CI/CD pipelines and observability tools. Kubernetes has become the default operating model for production workloads.
Except for desktops.
Secure application and desktop delivery, the kind that enterprises depend on for remote work, privileged access, and regulated industry workflows, has remained stubbornly outside the Kubernetes model. Legacy virtual desktop infrastructure was built in a different era, for a different set of assumptions: pre-allocated VM pools, custom management planes, proprietary devices, and operational tools that have nothing to do with the way modern platform teams work. The result is a split infrastructure reality: a modern, cloud-native application layer on one side, and an operationally isolated and manually managed desktop layer on the other.
That division is expensive. It means different tools, different scaling behaviors, different observability approaches, and different operational runbooks. Platform engineers who are proficient in Kubernetes still have to context-switch to a completely different mental model the moment a desktop infrastructure issue arises.
The most fundamental issue is that this division is unnecessary. Securely delivering containerized workspaces is a workload that Kubernetes is architecturally well-suited to run. Sessions are containers. Scaling is driven by demand. The configuration must be declarative. The only thing missing was a platform built to take advantage of that alignment.
Why is the time right?
The appetite for delivering Kubernetes-native workspaces has grown significantly as organizations mature their investments in container platforms. Platform teams that have spent years standardizing Helm, GitOps workflows, and native Kubernetes observability are increasingly unwilling to make an exception for desktop infrastructure. The question has gone from "Can we run this on Kubernetes?" to "Why isn’t this running on Kubernetes anymore?"
At the same time, the safety argument for delivering containerized workspaces has become more urgent. Browser-delivered containerized workspaces provide session isolation that VM-based desktops cannot match: each session is ephemeral, isolated at the container boundary, and terminates cleanly without persistent state. For organizations managing sensitive data, internal risks, or third-party access scenarios, this isolation model is a significant security control, not just an implementation convenience.
The convergence of these two trends—expectations for Kubernetes-native infrastructure and containerized session security—creates a clear opportunity for platforms that can address both simultaneously.
What the native Kubernetes deployment looks like
A native Kubernetes deployment uses Kubernetes as the control plane for the workspace infrastructure, handling orchestration, scaling, and lifecycle management through the same declarative model used in the rest of the platform. Instead of relying on dedicated management appliances or pre-provisioned desktop pools, the infrastructure is managed through the same CI/CD, GitOps, observability, and security workflows that the platform team already operates. This gives platform teams a consistent operating model rather than maintaining a separate toolset for desktop infrastructure.
Kasm Workspaces, the browser-delivered workspace platformis designed specifically to use Kubernetes as a control plane for workspace orchestration and delivery. Its deployment model is designed for real enterprise environments (not simplified demos) with production-grade Helm charts that follow Kubernetes conventions, tested upgrade paths between releases, and a standardized backend architecture validated across production deployments. An RDP Gateway component designed specifically for the Kubernetes topology allows access to Windows and Linux virtual machines through the same platform.
Key capabilities include:
-
Horizontal session scaling driven by actual demand, orchestrated by Kubernetes – no pre-warmed VM pools required.
-
Declarative configuration via Helm values, enabling GitOps and CI/CD integration for workspace infrastructure.
-
Namespace-level isolation and support for existing RBAC policies, ingress controllers, and secret management integrations.
-
Exporting metrics for integration with Prometheus and existing observability stacks.
-
Progressive builds by default, reducing maintenance windows and enabling more predictable release management.
Real world applications
Industry regulated remote access. A financial services organization running a Kubernetes-based application platform can deploy Kasm on the same cluster, using the same operational tools, to deliver isolated browser and application sessions to analysts and advisors. Sessions are ephemeral, network egress is controlled, and the entire deployment is managed through the same GitOps channel as your application workloads.
Contractor and third party access. Organizations that regularly onboard third-party contractors or vendors (with the associated privileged access risk) can provide Kasm sessions on Kubernetes that ramp up during periods of engagement and ramp down during periods of low demand. No persistent access. No third-party VPN extension. Isolation in containers at each session boundary.
AI/ML development environments. Teams that build and run AI models need GPU-enabled development environments with security controls that general-purpose cloud desktops rarely offer. Deploying Kasm on Kubernetes with NVIDIA MiG multi-instance GPU support enables platform teams to deliver fractional GPU resources across isolated workspace sessions, giving data scientists the compute they need without exposure to shared infrastructure security.
The operational change
The practical implication of a Kubernetes-native workspace platform is that platform teams can stop treating workspace infrastructure as a special case. The same engineers who deploy applications can deploy the workspace platform. The same pipelines that manage application configuration can manage workspace configuration. The same dashboards that monitor application status can monitor workspace status.
That operational consolidation reduces overhead, improves consistency, and eliminates the cost of context switching that has made desktop infrastructure a persistent problem for cloud-native organizations.
For organizations still running legacy VDI alongside modern cloud infrastructure, the question is no longer whether a Kubernetes-native alternative exists. He does it. The question is when to make the transition.
Organizations interested in evaluating the delivery of Kubernetes-native workspaces can explore the platform at kasm.com and test community edition for yourself.
Daniel Ben-Chitrit is the Chief Product Officer of Kasm Technologies.
Sponsored articles are content produced by a company that pays to publish or has a business relationship with VentureBeat, and are always clearly marked. For more information, contact sales@venturebeat.com.
