nxtgauge-gitops/apps/ollama/base/deployment.yaml
sync-test 4ea0e2ae43
All checks were successful
sync-to-forgejo / sync (push) Successful in 15s
fix(ollama): use Recreate deployment strategy to avoid RWO PVC mount deadlock on rollout
2026-07-21 06:33:21 +05:30

62 lines
No EOL
2.1 KiB
YAML

apiVersion: apps/v1
kind: Deployment
metadata:
name: ollama
namespace: nxtgauge-ai
labels:
app: ollama
spec:
replicas: 1
# Default RollingUpdate deadlocks here: the new pod can't mount the
# ollama-models PVC (ReadWriteOnce) until the old pod releases it, but
# the old pod isn't terminated until the new one is Ready — a rollout
# that discovered this the hard way (stuck ContainerCreating). Recreate
# accepts a brief gap in availability in exchange for actually rolling
# out.
strategy:
type: Recreate
selector:
matchLabels:
app: ollama
template:
metadata:
labels:
app: ollama
spec:
containers:
- name: ollama
image: ollama/ollama:latest
ports:
- containerPort: 11434
name: http
env:
- name: OLLAMA_HOST
value: "0.0.0.0:11434"
# Keep a loaded model resident for 30 min of inactivity instead
# of Ollama's 5-minute default — job-description/resume/cover-
# letter traffic is bursty, and reloading a 2.5-5GB model from
# disk on every request would add multi-second latency to each
# first call after a gap.
- name: OLLAMA_KEEP_ALIVE
value: "30m"
volumeMounts:
- name: ollama-models
mountPath: /root/.ollama
resources:
requests:
cpu: 1000m
memory: 3Gi
limits:
# qwen3:4b (~2.5GB on disk) and qwen3:8b (~5.2GB) are already
# pulled onto the PVC, but the previous 1500Mi limit could
# only ever load gemma3:270m — which is why every LiteLLM
# model alias was mapped to gemma3:270m regardless of name
# (see apps/litellm/base/configmap.yaml). Sized to comfortably
# hold qwen3:8b plus KV cache/runtime overhead, with headroom;
# node has 16GB total and was at ~26% memory use.
cpu: 4000m
memory: 8Gi
volumes:
- name: ollama-models
persistentVolumeClaim:
claimName: ollama-models