Kubernetes Glossary

Every term below ends with how kilter uses it — this glossary is about your clusters, not Kubernetes in the abstract. Terms are grouped by theme and alphabetical within each group.

A set of machines (nodes) running Kubernetes workloads, managed by a control plane. Kilter: every project gets its own single-node KIND cluster named kilter-<project>, so experiments can't interfere with each other.

Container

A packaged process with its own filesystem, built from an image and run in isolation. Kilter: your app runs in a container built from image: in kilter.yaml (default node:22-alpine); kilter exec runs commands inside it.

Control plane

The set of components (API server, scheduler, controllers) that decides what runs where and stores cluster state. Kilter: in a KIND cluster the whole control plane runs inside one Docker container — that's what kilter stop pauses and kilter up resumes.

DaemonSet

A controller that runs one pod copy on every node, typically for node-level agents like log collectors. Kilter: rarely relevant in a single-node KIND cluster — there's only one node, so a DaemonSet behaves like a single pod.

Deployment

A controller that keeps N replica pods of a template running and handles rolling updates. Kilter: your app and most catalog services run as Deployments; when Tilt rebuilds an image, the Deployment rolls a new pod.

Job

A workload that runs pods to completion instead of keeping them alive. Kilter: in production, kilter deploy --migration and --seed run as Jobs before the new app pod rolls — a failed Job halts the deploy while the old pod keeps serving.

Namespace

A virtual partition inside a cluster that scopes names, network policies, and quotas. Kilter: your app and services live in <project>-dev (e.g. kilterkb-dev); in-cluster DNS names include it: postgres.kilterkb-dev.svc.

Node

A machine (physical, virtual, or — with KIND — a Docker container) that runs pods. Kilter: each project cluster has one node, which is one Docker container on your machine; docker ps shows it.

Pod

The smallest deployable unit — one or more containers sharing network and storage. Kilter: kilter status lists the pods in your project's namespace; kilter restart postgres bounces one.

ReplicaSet

The controller a Deployment creates to keep the right number of identical pods running. Kilter: you'll see ReplicaSet-derived pod names like app-7f9c4d-x2klm in kilter status; you never manage ReplicaSets directly.

StatefulSet

Like a Deployment, but pods get stable identities and persistent storage that survives restarts. Kilter: stateful catalog services such as postgres use StatefulSets so your data outlives pod restarts (and kilter stop).

Networking

ClusterIP / NodePort

Service types: ClusterIP gives a Service an internal-only virtual IP; NodePort additionally exposes it on a fixed port on every node. Kilter: services are reachable in-cluster via ClusterIP DNS, and NodePorts are how kilter maps them to deterministic localhost ports like 30530 — see Ports.

DNS (in-cluster)

Kubernetes runs an internal DNS server so Services resolve by name: <service>.<namespace>.svc. Kilter: in-cluster connection strings from kilter env use this form — redis.kilterkb-dev.svc:6379 — while your browser and host tools use the localhost:<port> variants.

Gateway API

The modern, role-oriented replacement for Ingress: Gateways define listeners, Routes attach apps to them. Kilter: in production your app is served at <app>.<cluster-domain> through the cluster Gateway — see Production routing.

Ingress

The legacy Kubernetes API for routing external HTTP traffic to Services by host and path. Kilter: not used — kilter-platform clusters route through the Gateway API instead.

Service

A stable virtual IP + DNS name in front of a set of pods. Kilter: connection strings use Service DNS — typesense.<ns>.svc:8108 — which keeps working across pod restarts.

Config & Storage

ConfigMap

A Kubernetes object holding non-secret key/value configuration that pods consume as env vars or files. Kilter: rendered service configuration lands in ConfigMaps; after changing one, kilter restart makes the pod re-read it (same image).

Environment variables

Key/value pairs injected into a container's process environment, sourced from literals, ConfigMaps, or Secrets. Kilter: the env: block in kilter.yaml injects into your app container, and each catalog service provides vars like DATABASE_URL — kilter env prints them all.

Probe (liveness/readiness)

Health checks the kubelet runs against a container: liveness restarts it when broken, readiness gates traffic until it's ready. Kilter: the health: path in kilter.yaml (e.g. /api/health) backs your app's probes; production --bootstrap deploys block until pods are actually Ready.

PVC (PersistentVolumeClaim)

A request for durable storage that Kubernetes binds to a volume, independent of any pod's lifecycle. Kilter: postgres data lives on a PVC, which is why your database survives kilter stop / kilter up but not kilter destroy.

RBAC

Role-Based Access Control — rules defining which identities may perform which API operations on which resources. Kilter: kilter admin cluster register extracts a ServiceAccount token scoped by RBAC, so the platform touches only what it's allowed to.

Resource requests/limits

Per-container CPU/memory declarations: requests reserve capacity for scheduling, limits cap usage. Kilter: the rendered charts set sane defaults for catalog services; kilter eject lets you tune them if a service is starved or greedy.

Secret

Like a ConfigMap but for sensitive values, stored separately and mountable as env vars or files. Kilter: in production, secrets: in kilter.yaml become SOPS-encrypted Secrets committed to the flux repo — plaintext never leaves your machine.

ServiceAccount

An in-cluster identity that pods (and API clients) authenticate as. Kilter: the kilter operator runs under a ServiceAccount, and registering a cluster mints a ServiceAccount token for the platform to use.

Volume

Storage attached to a pod — anything from a temp dir to a PVC-backed disk — mounted into containers at a path. Kilter: Tilt's live_update syncs files into your app container's filesystem; service data directories are volumes backed by PVCs.

Packaging & Delivery

Chart

A Helm package: templated manifests plus default values, versioned as a unit. Kilter: each catalog service (postgres, redis, temporal, …) is rendered from a chart, and production apps deploy via the kilter-app chart — see Helm.

Controller

A loop that watches some declared state and acts to make reality match it. Deployments, StatefulSets, and operators are all controllers. Kilter: the kilter operator is a controller watching KilterApp resources.

CRD (Custom Resource Definition)

A way to extend the Kubernetes API with your own object types. Kilter: KilterApp is a CRD — kilter deploy upserts a KilterApp custom resource, and the operator does the rest.

Flux / GitOps

GitOps: a git repo is the source of truth for cluster state, and a tool (Flux) continuously applies it. Kilter: the operator commits rendered manifests to the cluster's flux repo; Flux applies them, and per-env Flux Kustomizations decrypt SOPS secrets at apply time.

Helm

The Kubernetes package manager: it renders templated charts into manifests and manages them as releases. Kilter: Helm renders every backing service in dev and the kilter-app chart in production — you never run helm yourself.

Manifest

A YAML (or JSON) document declaring a Kubernetes object — the unit everything above is expressed in. Kilter: manifests are generated for you (into ~/.cache/kilter/<name>/); kilter eject copies them into your project when you need to customize.

Operator

A controller plus a CRD: software that encodes operational knowledge for managing an app via custom resources. Kilter: the in-cluster kilter operator provisions credentials, renders the kilter-app chart, and commits to the flux repo whenever a KilterApp changes.

Reconciliation

The act of a controller comparing desired state against actual state and converging them, repeatedly. Kilter: after kilter deploy, reconciliation is what turns the upserted KilterApp into running pods — status errors surface into KilterApp.Status.

Release

A named, versioned instance of a chart installed into a cluster; upgrades roll it forward. Kilter: changing Helm chart values requires kilter up, which performs a release upgrade.

Dev tooling

Context

A named kubeconfig entry combining a cluster, a user, and a default namespace. Kilter: each project's isolated kubeconfig contains exactly one context for its own cluster, so there's nothing to switch and no way to hit the wrong cluster.

KIND

"Kubernetes IN Docker" — runs a full cluster inside Docker containers. Kilter: the foundation of local dev; each project's kilter-<project> cluster is a KIND cluster — see How kilter uses KIND.

kubeconfig

The credentials + endpoint file kubectl uses. Kilter: never touches ~/.kube/config; each project's kubeconfig lives at ~/.cache/kilter/<name>/kubeconfig.

kubectl

The Kubernetes CLI for inspecting and mutating cluster objects. Kilter: mostly unnecessary — kilter status/logs/restart cover the common cases — but always available via KUBECONFIG=~/.cache/kilter/<name>/kubeconfig kubectl ….

live_update

Tilt's fast path: sync changed files straight into a running container instead of rebuilding the image. Kilter: saving an existing .ts/.tsx/.css file reaches the pod in ~1–3s via live_update; new files or dependency changes need a rebuild — see Tilt.

Tilt

A dev-loop orchestrator that watches source files, syncs or rebuilds, and shows service status in a UI. Kilter: kilter up starts Tilt to drive your whole dev environment; kilter down stops Tilt but keeps the cluster running.