FlameK8s
Kubernetes backend integration for FLAME.
This library implements FLAME.Backend and delegates runner lifecycle to
Kubernetes through the FlameRunner and FlamePool custom resources managed
by the flame-k8s operator.
Installation
Add the dependency to your mix.exs:
def deps do
[
{:flame_k8s, "~> 0.1.0"}
]
end
Configure Your Application
Enable the backend in your runtime configuration (usually in production):
if config_env() == :prod do
config :flame, :backend, FLAME.K8sBackend
config :flame, FLAME.K8sBackend,
log: :debug,
boot_timeout: 30_000
end
How It Works
- Your app invokes FLAME work (
FLAME.call/3,FLAME.cast/3). FLAME.K8sBackendcreates aFlameRunnercustom resource.- The operator reconciles
FlameRunnerand creates the runner pod. - The runner pod connects back via distributed Erlang.
- Work executes remotely and runner resources are cleaned up.
Install The Operator
This backend requires the operator and CRDs installed in the target cluster.
Option 1: use project release manifest.
kubectl apply -f <release-manifest-url>
Option 2: generate manifests from this repository and apply with kustomize.
make generate-k8s-manifests
kubectl apply -k .k8s/install/manifests
Generate A FLAME-Ready Deployment
The library includes a mix task that generates a Deployment with the FLAME annotations already filled in.
mix flame.gen.deployment \
--name flame-parent-example \
--namespace default \
--image ghcr.io/eigr-labs/flame-parent-example:latest
Optional flags include --pool-config-ref, --otp-app, --cookie-secret-ref,
and --runner-termination-timeout.
Apply Example CR Instances
After installing the operator, apply example resources:
kubectl apply -f examples/crds/flamepool-apply.yaml
kubectl apply -f examples/flame_example/.k8s/deployment.yaml
The direct FlameRunner manifest is still available for manual CR testing, but
the normal application flow is driven by the annotated Deployment and the
mutating webhook.
Inspect status:
kubectl get flamepools -A
kubectl get flamerunners -A
Environment Notes
- In cluster, backend auth uses service account credentials.
- Outside cluster, backend reads kubeconfig from
KUBECONFIG(first path when multiple are provided), with fallback to~/.kube/config. - Backend includes
FLAME_NODE_BASEin generatedFlameRunnerenv so runner pods can deriveRELEASE_NODEas$(FLAME_NODE_BASE)@$(POD_IP).