Original reporting by SDxCentral. Post originally published 2019-07-15.
Overview
Juniper Networks released Juke 2.2, an updated version of the multi-cloud container platform the company acquired when it purchased composable infrastructure firm HTBASE in late 2018. The 2.2 release focuses on two persistent pain points in enterprise Kubernetes deployments: multi-cloud cluster management and the lack of a robust persistent storage platform for containerized workloads.
What Is Juke?
Despite HTBASE’s origins in composable infrastructure, Juke itself is not a composable infrastructure product. According to Scott Sneddon, Senior Director and Evangelist for Multi-Cloud Solutions at Juniper Networks, it is best described as container-focused software-defined storage with orchestration capabilities.
“Juke is primarily a distributed, persistent storage solution. We’re really focused in on the storage problem that exists and would coexist with some of the composable solutions that are out there by delivering storage, and some orchestration capabilities to help manage containers — Kubernetes in particular.”
— Scott Sneddon, Juniper Networks
Where Juke intersects with composable infrastructure is at the multi-cloud boundary: it bridges the storage and orchestration gap that composable offerings often leave unaddressed when workloads span multiple clouds or sites.
The Two Problems Juke 2.2 Addresses
Sneddon identified two core challenges that Juke 2.2 is designed to solve:
- Multi-cloud Kubernetes management complexity — Enterprises running Kubernetes across multiple cloud providers or hybrid environments struggle to manage clusters, workloads, and storage consistently across those boundaries.
- The absence of a reliable persistent storage platform for Kubernetes — Kubernetes was originally designed around stateless workloads. Providing durable, distributed persistent storage for stateful containerized applications remains a significant engineering challenge.
Key Updates in Juke 2.2
Kubernetes and CSI Integration
The headline technical change in Juke 2.2 is native integration with Kubernetes and its Container Storage Interface (CSI). CSI is the standardized API that decouples storage systems from the Kubernetes core, allowing third-party storage providers to expose volumes to pods without modifying Kubernetes itself.
This integration enables Kubernetes cluster scale-out with both compute and storage nodes that can:
- Span multiple clouds and on-premises sites, or
- Remain local to a single cluster availability zone
Volume Snapshots and Clone Management
Juke 2.2 adds volume snapshot and clone management capabilities, improving data reliability and workload mobility. Administrators can snapshot persistent volumes and clone them for use in other environments, making data portability across clouds more practical.
Improved Deployment and Installation
The release also includes deployment improvements intended to simplify the installation process, reducing the operational overhead of getting Juke running in a new environment.
Intelligent Workload Placement via Latency Awareness
One of the more architecturally interesting aspects of Juke 2.2 is its ability to feed storage latency and performance data back into the Kubernetes orchestrator to inform scheduling decisions. Because Juke manages the distributed storage layer, it can measure the latency between running containers and their storage endpoints, then use that data to influence where future workloads are placed.
“Because we are able to orchestrate this persistent distributed storage, we can also understand the latency between running containers and their access to storage. So we can take that latency and performance information, feed that back into the orchestrator, and determine where is the best place to deploy that workload.”
— Scott Sneddon, Juniper Networks
Practical examples of this capability include:
- Cost arbitrage: Run workloads on-premises during low-usage periods (nights, weekends) and automatically burst to the cloud when demand spikes.
- Edge compute proximity: Automatically route workloads to the cloud region or on-premises site closest to the data or the end user, based on real-time latency measurements.
- Multi-cloud resource automation: Use the Juke UI to manage core Kubernetes storage objects and automate resource access decisions across clouds without manual intervention.
Summary
Juke 2.2 represents Juniper’s push to address two real and well-documented gaps in enterprise Kubernetes adoption: persistent storage and multi-cloud cluster management. By integrating with the Kubernetes CSI standard and adding latency-aware scheduling feedback, the platform aims to give platform engineering teams a unified control plane for stateful containerized workloads across heterogeneous infrastructure.
For teams evaluating Kubernetes storage solutions in multi-cloud environments, Juke 2.2’s combination of CSI compliance, snapshot support, and workload placement intelligence makes it a notable option from the networking and infrastructure vendor space.