KubeFox distills deployments to unique components only and shapes traffic at runtime. That’s a mouthful but what it means is that KubeFox can support multiple versions of an app with a minimum number of Pods.

Let’s start at the beginning. KubeFox works from the repository outward. Developers don’t work through what has changed and how they’re going to deploy - they simply publish the app. KubeFox inspects the repo, evaluates what has changed (based upon commits), and builds and deploys only those containers that are unique to the cluster. For example, a developer could modify 3 components of a 20-component app, redeploy, and KubeFox would deploy only the 3 components that changed (this is what we call deployment distillation). Both versions (or deployments) are accessible. This is achieved through an event-driven architecture with a broker running as a DaemonSet. Genesis events (origin events like inbound HTTP requests) have metadata associated with them that the broker evaluates at component-to-component transitions, and routes to the component associated with that version of the application.

Another core KubeFox concept is the notion of Virtual Environments (VEs). You can think of VEs as virtual wrappers around the components composing a specific version of an application. VEs enable developers to exercise different versions of an app with simple query parameters and subpaths, or KubeFox releases. For instance, a developer could rapidly iterate on a prototype by deploying modifications to their own VE, and compare and contrast those changes side-by-side - without redeploying all components composing that app and while sharing unchanged components with other developers or teams. There could be a number of teams and developers sharing the cluster; to each it appears as though they are operating in independent sandboxes.

KubeFox’s architecture enables it to provide some capabilities – security and telemetry – intrinsically. By virtue of building an application with KubeFox, zero trust is built in. Today we’re using the Kubernetes SAT for verification, that will be expanded in the future. Telemetry is also part of the picture. And the telemetry can be specific to a version, so traces associated for a shared components would be broken out by version.

We would greatly appreciate your feedback. XigXog’s mantra is “Kubernetes Simplified” and if we've missed the mark somewhere, we’d like to hear about it.

KubeFox runs on any k8s cluster (note: update pending for Apple silicon). We have a Quickstart tutorial and a KubeFox-with-Hasura tutorial. Both are very approachable (and if they’re not, we’d like to hear about that, too).

Why KubeFox exists… We (my co-founder John and I) are big believers in Kubernetes, but at our last company, we faced the standard challenges of coordinating resource provisioning to support teams and individual engineers, and the folding together of independent efforts at integration time. A common thread was the necessity and degree of DevOps involvement, how some of the DevOps work had to be handled by the engineering teams themselves and how much time all of this subtracted from the progression of the actual application. After we left the company, we wondered if it could be simplified and how we’d go about it, and KubeFox was born (I make it sound like it was an hour discussion – this occurred over several months).

We’ve had a number of internal discussions regarding architecture, scope etc. But one thing that was never in question is our desire for the product to be open source. To that end, we would welcome your involvement with KubeFox.

Last but not least, we’d appreciate any feedback you may have. Please let us know what you think!