9.5. Glossary
Basic Concepts
| Term | Meaning |
|---|---|
| Cluster | The unit that groups several servers to be used as one |
| Node | One server making up the cluster |
| Control-plane node | The node running the components that control the cluster |
| Worker node | The node running application pods |
| Namespace | A logical partition dividing resources. Used per team or environment |
| API server | The gateway every cluster operation passes through |
| Declarative | The approach where you write "it must be in this state" and the system maintains it |
| Controller | The program that continuously matches the actual state to the desired state |
| Label | A name tag attached to a resource. A key-value pair such as app=web |
| Selector | The condition for selecting targets by label |
| Annotation | Extra information attached to a resource. Not used as a selector |
Workloads
| Term | Meaning |
|---|---|
| Container | A process running in an isolated environment |
| Pod | The smallest deployment unit holding containers. It can hold several |
| Deployment | The controller that maintains a desired number of pods and replaces them without downtime |
| ReplicaSet | The controller that maintains a set number of pods. Created by a Deployment |
| StatefulSet | The controller used when each pod needs its own name and storage |
| DaemonSet | The controller that runs one pod on every node |
| Job | Work that runs once and finishes |
| CronJob | Repeatedly creates Jobs at set times |
| Replica | How many copies of the same pod to run |
| Revision | The ordinal that increases with each deployment. Used when reverting |
| Rolling update | The replacement style of starting new pods one at a time and taking old ones down one at a time |
| Blue-green deployment | The style of bringing the new version up separately and shifting traffic at once |
| Rollback | Returning to an earlier revision |
| ConfigMap | A collection of setting values that need not be hidden |
| Secret | A collection of values that must be hidden, such as passwords and certificates |
| HPA | The feature that adjusts the pod count automatically based on utilization |
| CronHPA | The feature that adjusts the pod count at set times |
| PodDisruptionBudget | The limit on how many pods may go down at once during maintenance |
| QoS class | The grade deciding the order of eviction when resources run short |
| Taint | A marker on a node making it accept only certain pods |
| Toleration | The pod setting allowing placement on a node with a taint |
| Probe | A check that asks the application directly about its state |
| Readiness probe | Checks whether it can take requests. On failure, no traffic is sent |
| Liveness probe | Checks whether it is alive. On failure, the container is restarted |
| Startup probe | Checks whether startup has finished. Other probes are deferred until it does |
Networking
| Term | Meaning |
|---|---|
| Service | The resource giving a group of pods a fixed name and address |
| ClusterIP | A Service address used only inside the cluster |
| Endpoint | The list of pod addresses a Service actually sends traffic to |
| Ingress | The rule connecting external HTTP requests to internal Services |
| Ingress controller | The program that actually handles Ingress rules. COP uses HAProxy, with the class name default |
| Network policy | The rule restricting communication between pods |
| Port forwarding | The feature connecting a port on your local PC to a pod inside the cluster |
Storage
| Term | Meaning |
|---|---|
| Volume | Storage attached to a container |
| Mount | Attaching a volume at a particular path in a container |
| PV (PersistentVolume) | The actual storage |
| PVC (PersistentVolumeClaim) | A storage request. It states only how much is needed |
| Storage class | The configuration defining how storage is created |
| Dynamic provisioning | The approach where creating a PVC creates a PV automatically |
| Access mode | On how many nodes reading and writing is possible |
| Reclaim policy | Whether to delete or keep the data when a PVC is deleted |
Build and Deployment
| Term | Meaning |
|---|---|
| Container image | A file bundling an application with its runtime environment |
| Registry | The store holding container images. COP uses Harbor |
| Tag | The version marker on an image. The 1.0.3 part of app:1.0.3 |
| S2I | The approach of building a container image directly from source code |
| Builder image | The image responsible for compilation in an S2I build |
| BuildConfig | A reusable template defining what to build and how |
| Build | One execution of a build config |
| Helm | The tool for bundling several resources to install and delete them together |
| Chart | Helm's bundle of deployment definitions |
| Release | One result of installing a chart |
| Revision | The number that increases each time a release is changed |
| GitOps | The approach of matching the cluster state to definitions in a Git repository |
Security
| Term | Meaning |
|---|---|
| SSO | Integrated authentication letting one sign-in serve several systems |
| RBAC | The approach of managing access permissions based on roles |
| Service account | The account a pod uses when calling the cluster API |
| Role | A collection of what can be done. Within one namespace only |
| ClusterRole | A role that applies across the whole cluster |
| Role binding | Linking a role to a user, group, or service account |
| cert-manager | The component that issues and renews certificates automatically |
| ACME | The protocol for obtaining certificates without human hands. It verifies domain ownership automatically. It requires external communication, so it cannot be used in an air-gapped environment |
| Let's Encrypt | The public certificate authority that issues certificates free of charge over ACME |
| Issuer · ClusterIssuer | The configuration deciding where certificates are obtained from |
| CIS benchmark | The secure configuration standard and the checks against it |
| Webhook | The mechanism that inspects or modifies values in the middle of creating or editing a resource |
Status Values
These are the statuses seen most often on list and detail screens.
| Value | Where it appears | Meaning |
|---|---|---|
| Running | Pod | Running normally |
| Pending | Pod, PVC, build | Waiting to be readied |
| Succeeded | Pod | Finished its work and exited normally |
| Failed | Pod, build | Failed |
| CrashLoopBackOff | Pod | Repeatedly starting and stopping |
| ImagePullBackOff | Pod | Could not fetch the image |
| OOMKilled | Container | Killed for exceeding the memory limit |
| Evicted | Pod | Pushed out due to node resource shortage |
| Bound | PVC | Connected to storage |
| Released | PV | The claim was deleted but the space is not cleaned up |
| Ready / NotReady | Node | Whether pods can be scheduled on it |
| deployed | Helm release | Installed normally |
| superseded | Helm release | Replaced by a newer revision |
| PASS / FAIL / WARN | CIS benchmark | Meets the standard / does not / cannot be determined |