Oracle Cloud’s "Always Free" tier is incredibly generous, offering up to 4 ARM OCPUs and 24GB of RAM. However, there is a catch: Oracle will actively reclaim and delete instances that sit idle. To keep your server, you need to maintain a steady baseline of CPU utilization (typically over 20%).
Many people run useless stress scripts just to burn power and keep their nodes alive. But if you are using Kubernetes, there is a much better way: Folding@Home (F@H).
Folding@Home is a distributed computing project that simulates protein dynamics to help researchers develop cures for diseases like Alzheimer's, Cancer, and Parkinson's.
This guide will show you how to configure a Folding@Home "scavenger" workload in Kubernetes. It will run in the background to keep your Oracle node alive, but instantly yield to your actual applications when they need the compute power.
If you just deploy Folding@Home alongside your web apps or databases, F@H will aggressively consume your CPU and slow your important services down to a crawl. To prevent this, we have to manipulate how Kubernetes talks to the Linux kernel.
Kubernetes manages CPU time using a system called cpu.shares.
- Requests dictate priority: When you set a CPU
requestin a Kubernetes manifest, Linux translates that into shares. When the CPU hits 100% usage, pods with more shares get priority. - The Absolute Minimum: A Linux process cannot have fewer than 2 CPU shares. By setting our F@H CPU request to
1m(1 millicore), we force it down to the absolute bottom of the priority barrel (2 shares). - The Hard Ceiling: We use a CPU
limitto ensure F@H never pushes the node past our target utilization when the server is otherwise idle.
For this setup to work, you must set a CPU request on your other, important pods. If your important apps do not have a CPU request set, Kubernetes defaults them to the "BestEffort" class, which also gives them the minimum 2 CPU shares. They will end up fighting Folding@Home on equal footing!
By giving your important apps a tiny baseline request (e.g., requests: cpu: 100m), they get ~102 CPU shares. When the server gets busy, your important apps will mathematically overpower F@H by a massive 51-to-1 ratio, instantly starving F@H of compute time so your apps run flawlessly.
Here are the manifests to deploy the F@H scavenger pod on your ARM64 Oracle node.
Note: Oracle's maximum free ARM instance has 4 cores. We set the F@H CPU limit to 1500m (1.5 cores). This guarantees a constant ~37.5% baseline load, keeping you safely above Oracle's idle reclamation threshold.
Folding@Home v8 uses an account token to link headless workers to your web profile. You can generate this token on the Folding@Home website.
Create a file named fah-secret.yaml:
apiVersion: v1
kind: Secret
metadata:
name: fah-creds
type: Opaque
stringData:
account-token: "YOUR_ACCOUNT_TOKEN_HERE"
This deploys the worker. It uses the linuxserver.io image, which natively supports ARM64 architecture.
Create a file named fah-daemonset.yaml:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fah-worker
spec:
selector:
matchLabels:
app: fah
template:
metadata:
labels:
app: fah
spec:
# Optional: Add a low-priority class if you have one configured
priorityClassName: background-research-priority
containers:
- name: fah-client
image: lscr.io/linuxserver/foldingathome:latest
env:
- name: MACHINE_NAME
value: "k8s-arm64-node"
- name: ACCOUNT_TOKEN
valueFrom:
secretKeyRef:
name: fah-creds
key: account-token
resources:
requests:
cpu: 1m # The magic number: Forces F@H to the lowest possible OS priority
memory: 256Mi
limits:
cpu: 1500m # Hard cap at 1.5 cores to prevent 100% constant usage
memory: 4Gi
Apply the configurations to your cluster:
kubectl apply -f fah-secret.yaml
kubectl apply -f fah-daemonset.yaml
Check your node metrics after a few minutes, and you should see a perfectly flat, steady baseline of CPU utilization that keeps Oracle happy while contributing to science!