Kubernetes glossary
Kubernetes has a large vocabulary. This page covers the terms that appear in the Hyperkub control plane and API. It is deliberately practical rather than exhaustive — for the full picture, see the upstream Kubernetes glossary.
The cluster
Section titled “The cluster”Cluster
Section titled “Cluster”A set of machines that run your containers, plus the software that schedules them. In Hyperkub, a cluster is the top-level thing you create: it has a region, a Kubernetes version, and one or more node pools.
Control plane
Section titled “Control plane”The “brain” of a cluster. It decides what runs where, reacts when something crashes, and serves the Kubernetes API.
Hyperkub runs and maintains the control plane for you. You never SSH into it, patch it, or pay for it as a separate machine. This is the main difference between Hyperkub and building a cluster yourself.
A single machine — in Hyperkub, a virtual machine — that runs your workloads. Nodes join a cluster and are given work by the control plane.
Node pool
Section titled “Node pool”A group of nodes that share the same size and configuration. You scale a pool rather than adding nodes one at a time. Most clusters have one pool to start with; you add more when you need different machine sizes for different jobs.
Region
Section titled “Region”The physical location a cluster runs in. Choose the region closest to your users — it determines latency, and often which data-protection rules apply.
Running workloads
Section titled “Running workloads”The smallest thing Kubernetes runs: one or more containers that are always scheduled together on the same node and share a network address.
Pods are disposable by design. If a pod dies, Kubernetes replaces it — usually with a new one somewhere else, with a new IP. Do not treat a pod as a long-lived server.
Deployment
Section titled “Deployment”A declaration that says “keep N copies of this pod running”. If a pod or a whole node dies, the Deployment notices and creates replacements. This is how you run almost anything long-lived.
Service
Section titled “Service”A stable network address in front of a changing set of pods. Because pods come and go, you point other parts of your system at a Service rather than at individual pods.
Ingress
Section titled “Ingress”Routes HTTP traffic from outside the cluster to Services inside it, based on
hostname and path. This is how a request to app.example.com reaches your pods.
Namespace
Section titled “Namespace”A folder for Kubernetes objects. Namespaces let one cluster be shared by several
teams or environments without name collisions. default is where objects go if
you do not say otherwise.
Talking to a cluster
Section titled “Talking to a cluster”Kubernetes API
Section titled “Kubernetes API”The single HTTP interface the control plane exposes. Every tool — kubectl,
CI pipelines, dashboards — talks to this API. Each Hyperkub cluster gets its own
public endpoint.
kubeconfig
Section titled “kubeconfig”A file holding the address of a cluster and the credentials to reach it.
kubectl reads it from ~/.kube/config by default.
In Hyperkub you download a kubeconfig as a cluster credential. Credentials are short-lived and can be revoked individually — see Connecting with kubectl.
kubectl
Section titled “kubectl”The official command-line client for Kubernetes. It is how you inspect and change what runs inside a cluster.
How the terms map to Hyperkub
Section titled “How the terms map to Hyperkub”| Kubernetes concept | In Hyperkub | Who manages it |
|---|---|---|
| Control plane | Created with the cluster | Hyperkub |
| Node | Cluster node | Hyperkub provisions, you scale |
| Node group | Cluster pool | You |
| kubeconfig | Cluster credential | You create and revoke |
| Ingress endpoint | Cluster domain | You |