This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Miscellaneous

Documentation that we can’t find a more organized place for. Like that drawer in your kitchen with the scissors, batteries, duct tape, and other junk.

1 - Compatibility

A list of compatible Kubernetes distributions and platforms for running SpinKube.

See the following list of compatible Kubernetes distributions and platforms for running the Spin Operator:

Disclaimer: Please note that this is a working list of compatible Kubernetes distributions and platforms. For managed Kubernetes services, it’s important to be aware that cloud providers may choose to discontinue support for specific dependencies, such as container runtimes. While we strive to maintain the accuracy of this documentation, it is ultimately your responsibility to verify with your Kubernetes provider whether the required dependencies are still supported.

How to validate Spin Operator Compatibility

If you would like to validate Spin Operator’s compatibility with a new specific Kubernetes distribution or platform or simply test one of the platforms listed above yourself, follow these steps for validation:

  1. Install the Spin Operator: Begin by installing the Spin Operator within the Kubernetes cluster. This involves deploying the necessary dependencies and the Spin Operator itself. (See Installing with Helm)

  2. Create, Package, and Deploy a Spin App: Proceed by creating a Spin App, packaging it, and successfully deploying it within the Kubernetes environment. (See Package and Deploy Spin Apps)

  3. Invoke the Spin App: Once the Spin App is deployed, ensure at least one request was successfully served by the Spin App.

Container Runtime Constraints

The Spin Operator requires the target nodes that would run Spin applications to support containerd version 1.6.26+ or 1.7.7+.

Use the kubectl get nodes -o wide command to see which container runtime is installed per node:

# Inspect container runtimes per node
kubectl get nodes -o wide
NAME                    STATUS   VERSION   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
generalnp-vmss000000    Ready    v1.27.9   Ubuntu 22.04.4 LTS   5.15.0-1056-azure   containerd://1.7.7-1
generalnp-vmss000001    Ready    v1.27.9   Ubuntu 22.04.4 LTS   5.15.0-1056-azure   containerd://1.7.7-1
generalnp-vmss000002    Ready    v1.27.9   Ubuntu 22.04.4 LTS   5.15.0-1056-azure   containerd://1.7.7-1

2 - Integrations

A high level overview of the SpinKube integrations.

SpinKube Integrations

KEDA

Kubernetes Event-Driven Autoscaling (KEDA) provides event-driven autoscaling for Kubernetes workloads. It allows Kubernetes to automatically scale applications in response to external events such as messages in a queue, enabling more efficient resource utilization and responsive scaling based on actual demand, rather than static metrics. KEDA serves as a bridge between Kubernetes and various event sources, making it easier to scale applications dynamically in a cloud-native environment. If you would like to see how SpinKube integrates with KEDA, please read the “Scaling With KEDA” tutorial which deploys a SpinApp and the KEDA ScaledObject instance onto a cluster. The tutorial also uses Bombardier to generate traffic to test how well KEDA scales our SpinApp.

Rancher Desktop

The release of Rancher Desktop 1.13.0 comes with basic support for running WebAssembly (Wasm) containers and deploying them to Kubernetes. Rancher Desktop by SUSE, is an open-source application that provides all the essentials to work with containers and Kubernetes on your desktop. If you would like to see how SpinKube integrates with Rancher Desktop, please read the “Integrating With Rancher Desktop” tutorial which walks through the steps of installing the necessary components for SpinKube (including the CertManager for SSL, CRDs and the KWasm runtime class manager using Helm charts). The tutorial then demonstrates how to create a simple Spin JavaScript application and deploys the application within Rancher Desktop’s local cluster.