Overview

WolfKube is WolfStack’s Kubernetes management feature. It provisions clusters from scratch on your own hardware and manages clusters that already exist — cloud or on-prem — through a single dashboard. No new control-plane to learn: WolfKube drives kubectl directly, so anything you can do at the command line, you can do here.

If you already run Proxmox VE or libvirt nodes alongside WolfStack, you don’t need to choose. WolfKube clusters live next to your VMs and containers, share the same node tree, and use the same WolfNet overlay for east-west traffic where you want it.

Key Features

  • Provision clusters in minutes — Pick a distribution, point WolfStack at one or more nodes, and WolfKube installs and joins them. No external installers, no Ansible runs.
  • Five self-hosted distributions — k3s, MicroK8s, kubeadm (vanilla Kubernetes), K0s, and RKE2 are all first-class. Pick whichever matches your operational preference.
  • Three managed providers — Import existing EKS, GKE, or AKS clusters by uploading a kubeconfig. They show up alongside your self-hosted clusters in the same UI.
  • Multi-cluster from day one — Manage as many clusters as you like; each one keeps its own kubeconfig in /etc/wolfstack/kubernetes/. Switch contexts with one click.
  • App Store integration — Deploy any of the 530+ apps from the WolfStack App Store straight into a Kubernetes namespace. WolfStack writes the manifests; you click apply.
  • Resource management — Browse pods, deployments, services, secrets, configmaps, namespaces, ingresses, and CRDs. Edit YAML inline. Tail logs. Exec into pods.
  • Zero SDK lock-in — All cluster interactions go through the kubectl CLI, not the Kubernetes Go SDK. New API versions keep working without a WolfStack release.
  • Sits beside, not above — Use WolfKube only for the workloads that fit Kubernetes. Keep your VMs in VMs, your stateful services in WolfRun — no migration mandate.

Supported Distributions

WolfKube supports nine cluster types out of the box. Self-hosted ones can be provisioned by WolfStack; managed ones are imported by uploading their kubeconfig.

Self-hosted (provisioned by WolfStack)

  • k3s — Lightweight Kubernetes from Rancher Labs / SUSE. Single binary, sqlite-by-default, sub-100 MB memory floor. Ideal for homelabs, edge sites, and small clusters.
  • MicroK8s — Canonical’s production-grade Kubernetes distribution. Snap-installed, opinionated add-ons, easy to upgrade in lockstep across nodes.
  • kubeadm — Vanilla upstream Kubernetes. The closest you can get to “reading the official docs” without doing it by hand. Use this if your team already speaks fluent kubeadm.
  • K0s — Mirantis’s zero-friction distribution. Single binary, no host dependencies (no Docker, no containerd preinstalled), fast-pace upstream tracking.
  • RKE2 — Rancher Government’s FIPS-compliant distribution. A drop-in for environments that need CIS hardening and FedRAMP-compatible defaults.

Managed (imported by kubeconfig)

  • Amazon EKS — Run aws eks update-kubeconfig --name <cluster>, paste the resulting file. Works with IAM-based auth.
  • Google GKE — Run gcloud container clusters get-credentials <name>, import. Workload identity tokens are passed through.
  • Azure AKS — Run az aks get-credentials --name <cluster>, import. Azure AD bearer tokens are honoured.
  • Other — Any cluster reachable from your WolfStack node with a valid kubeconfig. Bare metal, OpenShift, Rancher-managed, you name it.

Provisioning a Cluster

Open WolfKube from the datacenter sidebar. Click Add Cluster — you’ll be asked whether you want to provision a new one or import an existing one.

Self-hosted: server node first

  1. Pick the distribution (k3s / MicroK8s / kubeadm / K0s / RKE2).
  2. Pick the WolfStack node that will run the control plane — any Linux server you’ve already added to your cluster.
  3. Give the cluster a friendly name (used in the UI; not the Kubernetes API server name).
  4. WolfStack runs the distribution’s installer remotely over SSH, captures the join token, and pulls the kubeconfig back. The whole thing usually finishes in 60–120 seconds for k3s, 3–5 minutes for kubeadm.

Self-hosted: adding agent (worker) nodes

  1. From the cluster detail page click Add Worker.
  2. Pick a WolfStack node that isn’t already a member of any cluster.
  3. WolfStack reuses the join token captured at server install and runs the agent installer for the matching distribution.
  4. Within ~30 seconds the new node appears under kubectl get nodes with status Ready.

Managed: import by kubeconfig

  1. Click Import Cluster.
  2. Paste the contents of your existing kubeconfig — the same file kubectl reads from ~/.kube/config. WolfStack stores it under /etc/wolfstack/kubernetes/<cluster>.kubeconfig with mode 0600.
  3. WolfStack runs kubectl --kubeconfig=… cluster-info to verify the connection and reads the API version, node count, and namespaces.

Day-to-Day Cluster Management

Once a cluster is registered the dashboard exposes the resources you actually use.

Workload browsing

  • List pods, deployments, statefulsets, daemonsets, services, ingresses, and jobs — per-namespace or cluster-wide.
  • Click any resource to see a YAML view that matches kubectl get -o yaml. Edit and apply changes inline.
  • Tail pod logs in the browser; multi-container pods get a container picker.
  • Open an exec shell into any container — xterm.js terminal opens in a separate window so the session survives navigation.

Configuration

  • Manage secrets and configmaps with a paste-and-apply editor — no need to base64-encode by hand.
  • Manage namespaces, RBAC roles and bindings, service accounts, and resource quotas.
  • View and edit CustomResourceDefinitions and any installed CRD instances.

Cluster health

  • Live cluster overview: node count, ready/not-ready breakdown, pod density, control-plane health, certificate expiry.
  • Resource usage from kubectl top — per-node and per-pod CPU/memory.
  • Event stream — the same kubectl get events --watch output, surfaced as a virtualised log view with severity filters.

Deploying Apps from the App Store

Every app in the WolfStack App Store with a Kubernetes-compatible manifest can be deployed straight into a WolfKube cluster — not just Docker or LXC.

  1. From the app detail panel pick the cluster as the install target instead of a Docker host.
  2. Choose the namespace (existing or new) and any user inputs the manifest declares.
  3. WolfStack renders the install as a Kubernetes manifest (Deployment + Service + optional Ingress + PVC) and applies it via kubectl apply -f.
  4. The install is tracked in the same App Store dashboard as your Docker / LXC installs — uninstalling deletes the manifest cleanly.

Browse the full catalogue without installing WolfStack: App Store Catalogue →

How WolfKube Talks to Clusters

Every cluster operation is a kubectl invocation under the hood. WolfStack stores one kubeconfig per cluster in /etc/wolfstack/kubernetes/ and runs commands like:

kubectl --kubeconfig=/etc/wolfstack/kubernetes/prod.kubeconfig get pods -A
kubectl --kubeconfig=/etc/wolfstack/kubernetes/prod.kubeconfig apply -f -

Two consequences worth knowing:

  • If kubectl can do it, WolfKube can do it. WolfStack doesn’t pin a particular Kubernetes API version — new resource types and new fields keep working.
  • You can always go around WolfKube. Drop into a terminal, point KUBECONFIG at one of the files in /etc/wolfstack/kubernetes/, and you’ll see the same cluster.

WolfKube vs WolfRun — which one should I use?

WolfStack ships two orchestration layers because Kubernetes is great for some workloads and overkill for others. They share the App Store and the cluster sidebar; you can use both at once.

  • Use WolfRun when you want to run a handful of services across a few servers, you don’t want to learn Kubernetes, you need LXC system containers, or your apps are stateful and Kubernetes feels heavy.
  • Use WolfKube when your app already ships Kubernetes manifests, you need cluster autoscaling / pod-level scheduling / Helm charts, your team already speaks fluent kubectl, or you’re onboarding a managed cloud cluster (EKS / GKE / AKS).

Requirements

  • For self-hosted provisioning — one or more Linux servers (Debian/Ubuntu/RHEL family) added to your WolfStack cluster. Root SSH access is set up automatically when you add a server.
  • Each control-plane node should have at least 2 vCPU and 2 GB RAM (k3s / MicroK8s tolerate less; kubeadm wants 2 GB minimum).
  • For managed clusters — nothing on the cluster side; just a working kubeconfig and network reachability from the WolfStack node.
  • kubectl on the WolfStack node. WolfStack auto-installs it on first cluster creation if the binary isn’t present.
Esc