Before testing whether last entry's real Podman number (1.663GB) holds up as an actual Kubernetes resource limit, I wanted a baseline: what happens with nothing set at all. kind runs a full local Kubernetes cluster inside containers acting as nodes — Kubernetes on top of the same containers everything else in this series has been using.
Spun up a fresh cluster and deployed Ollama with no resources section in the pod spec whatsoever:
kind create cluster --name today-i-ran
kubectl apply -f ollama-pod-naive.yaml
kubectl exec -it ollama-naive -- ollama pull llama3.2:1b
kubectl exec -it ollama-naive -- ollama run llama3.2:1b
Asked it a real question — "What does BGP do in OpenShift Networking" — to force a full response, then checked the actual resource configuration:
kubectl describe pod ollama-naive | grep -A5 "Limits\|Requests"
Pulled and loaded with zero constraints. QoS Class: BestEffort, which is Kubernetes plainly telling you no requests or limits were set. One real annoyance worth flagging: the image pull took 4 minutes 26 seconds on this fresh node, against maybe 30 seconds under Podman in the last entry. A brand new kind cluster has nothing cached — the first pull anywhere is always going to be the slow one.
Also worth being honest about: the model's actual answer to the OpenShift networking question wasn't good. It invented a fake expansion for "OpenShift Networking" and made up BGP/BGPsec behavior that doesn't match how OpenShift actually works. A 1B local model sounding confident on something specialized like this is a different risk than the more mechanical oc questions from earlier entries — worth remembering not to trust this stuff just because it sounds sure of itself.
With no limit, Kubernetes will let a pod take whatever it wants — which is exactly why this baseline matters. Without it, there'd be no way to tell whether the Podman number from last entry was actually a safe ceiling or not. Spoiler for the next one: it wasn't.
Top comments (0)