All posts
Muhtalip Dede profile photoMuhtalip Dede · Founder of kprompt

Choosing an LLM for Kubernetes: BYOK providers, privacy, and what to run in prod

Compare Gemini, OpenAI, Anthropic, Groq, and Ollama for Kubernetes CLI workflows with kprompt — BYOK keys, air-gapped setups, model speed vs explain quality, and security rules for operators.

Natural-language Kubernetes tools need a model somewhere. The question platform teams ask first is not which prompt template wins — it's where your data goes, which API key gets billed, and whether an air-gapped cluster forces local inference. kprompt is bring-your-own-key (BYOK) by design: your kubeconfig stays local, your provider keys stay in environment variables, and ~/.kprompt/config.yaml never stores secrets.

This guide compares the LLM providers kprompt supports today — when to pick Gemini Flash for speed, Claude or GPT for hard explains, Groq for low-latency iteration, Ollama for offline — and the security habits that matter when kubectl output flows to a model.

What actually gets sent to the LLM

Transparency matters for security reviews. kprompt sends your prompt plus context the tool gathers to plan or explain — intent parsing, kubectl get/describe/log snippets, cluster metadata needed for the operation. It does not upload your kubeconfig file. API keys travel only to the provider you choose (or to localhost for Ollama). PlanResult JSON and history store plan summaries locally — not full manifests, not env secrets.

  • Sent — user prompt, selected provider/model, operational context for the plan
  • Not stored in config — API keys (env vars only)
  • Not in PlanResult stdout — manifests, kubeconfig, raw secrets
  • Your choice — cloud API vs local Ollama on the same laptop as kubectl

Supported providers at a glance

Set provider in ~/.kprompt/config.yaml or pass --provider on each run. Default models ship sensible for CLI work; override with --model when you need more capacity.

ProviderFlagEnv keyDefault model
OpenAIopenaiKPROMPT_OPENAI_API_KEYgpt-4o-mini
AnthropicanthropicKPROMPT_ANTHROPIC_API_KEYclaude-sonnet-4-20250514
GeminigeminiKPROMPT_GEMINI_API_KEYgemini-2.0-flash
GroqgroqKPROMPT_GROQ_API_KEYllama-3.3-70b-versatile
MistralmistralKPROMPT_MISTRAL_API_KEYmistral-small-latest
DeepSeekdeepseekKPROMPT_DEEPSEEK_API_KEYdeepseek-chat
OpenRouteropenrouterKPROMPT_OPENROUTER_API_KEYopenai/gpt-4o-mini
TogethertogetherKPROMPT_TOGETHER_API_KEYLlama 3.1 8B Turbo
Ollamaollama(none required)llama3.2
OpenAI-compatibleopenai-compatibleKPROMPT_OPENAI_API_KEYset base_url

When to use each provider

Gemini — fast default for daily ops

Gemini 2.0 Flash is a strong default for list/get/scale plans and short explains: low latency, low cost, good structured output. Most kprompt docs and examples use Gemini for that reason. Platform engineers running dozens of prompts per shift often standardize here first.

Gemini setup

export KPROMPT_GEMINI_API_KEY="..."
kprompt config set provider gemini
kprompt config set model gemini-2.0-flash
kprompt "list deployments" -n staging

OpenAI and Anthropic — harder explains

Multi-step troubleshooting — chain Deployment → Pod → Events → Logs with nuance — benefits from larger models. GPT-4o class and Claude Sonnet tend to hold context across ambiguous prompts better than the smallest tiers. Use them for incident explains; use Flash/Mini for routine mutations you already review in the plan anyway.

Switch provider per command

export KPROMPT_ANTHROPIC_API_KEY="..."
kprompt --provider anthropic "explain why api is crashlooping" -n prod

export KPROMPT_OPENAI_API_KEY="..."
kprompt --provider openai --model gpt-4o "explain HPA behavior" -n prod

Groq — low-latency iteration

Groq excels when you're iterating on prompts in a tight loop — tuning safety gates, testing intent phrasing, running history reruns. Pair with staging clusters while you learn how plans look before touching production.

OpenRouter and Together — model shopping

OpenRouter and Together let you route to many underlying models with one key — useful for teams that already centralize LLM spend or want A/B tests on plan quality without changing kprompt config structure.

Ollama — local and air-gapped Kubernetes ops

Run Ollama on the same machine as kprompt; no cloud API call leaves your network except to your Kubernetes apiserver. Quality varies by local model — llama3.2 works for simple get/list; heavier explains may need larger quantized models. Ideal for regulated environments, offline labs, and kind clusters on laptops.

Local Ollama

ollama serve &
ollama pull llama3.2

kprompt config set provider ollama
kprompt config set model llama3.2
kprompt "list pods" -n default

Configuration without leaking secrets

kprompt config persists provider, model, namespace, context, and base_url — never API keys. config view shows api_key: set or unset. That split makes it safe to commit example config snippets in runbooks while keys live in shell profile, 1Password, or CI secrets.

Config vs secrets

kprompt config set provider gemini
kprompt config set namespace staging
kprompt config   # api_key: unset until you export KPROMPT_GEMINI_API_KEY

# Never put this in config.yaml — env only
export KPROMPT_GEMINI_API_KEY="..."

Model choice by Kubernetes task

  • get / list / describe — fast models (Gemini Flash, gpt-4o-mini, Groq Llama)
  • scale / deploy / rollback plans — fast models OK; you approve the kubectl line anyway
  • explain / why-is-it-broken — stronger models when chains get long
  • CI JSON gates — pick one provider per pipeline for deterministic-ish plans; pin model version
  • Air-gap — Ollama only; accept lower quality or run bigger local models

Security checklist for platform teams

  • Use dedicated API keys per team or pipeline — rotate independently of personal keys
  • Scope kubeconfig in CI to the namespace ServiceAccount you intend — not cluster-admin
  • Review provider data policies if log snippets may contain PII from application output
  • Disable history on shared jump hosts if prompts are sensitive (KPROMPT_DISABLE_HISTORY=1)
  • Treat cloud LLM calls like any third-party SaaS — network egress allowlists if required
  • Prefer Ollama when policy forbids operational data leaving the VPC

OpenAI-compatible endpoints

Enterprise gateways, Azure OpenAI, and internal proxies often speak OpenAI-compatible APIs. Set provider to openai-compatible, configure base_url in config, and use KPROMPT_OPENAI_API_KEY for the gateway token. Same plan → approve loop; different upstream.

Custom base URL

kprompt config set provider openai-compatible
kprompt config set base_url https://llm-gateway.internal/v1
export KPROMPT_OPENAI_API_KEY="gateway-token"
kprompt "list nodes"

Cost and rate limits

Read-heavy days (incident explains, log summaries) burn more tokens than a single scale plan. Fast models reduce cost; caching comes from kprompt history replay (rerun prior prompts without rephrasing). For org-wide rollouts, standardize on one cheap provider for mutations and one quality provider for explains — both BYOK, billed to your accounts.

Try multiple providers on staging

Run the same prompt across Gemini, OpenAI, and Ollama on a kind cluster. Compare plan clarity, not just speed. kprompt makes switching a one-flag experiment — your kubeconfig and safety rules stay constant.

Same prompt, three providers

PROMPT='explain why nginx is not ready'
kprompt --provider gemini "$PROMPT" -n default
kprompt --provider openai "$PROMPT" -n default
kprompt --provider ollama --model llama3.2 "$PROMPT" -n default

Full provider table and env var reference: kprompt.ai/docs/providers. Install once, swap models as your security and quality bar evolves — no hosted kprompt account required.