This topic provides guidelines for referring to the various components of OpenShift 4 and objects of a running OpenShift system in our documentation. The goal is to standardize terminology across OpenShift content and be consistent in the usage of our terminology when referring to OpenShift components or architecture.
|
Important
|
Do not backport |
For terms that are also API objects, there is different guidance for general usage of the term compared to referencing the actual API object. This glossary mainly defines the general usage guideline (lowercase, separating words), but be sure to use the object formatting (PascalCase, in monospace) when referring to the actual object. See API object formatting for more information.
|
Note
|
If you want to add terms or other content to this document, or if anything must be fixed, send an email to openshift-docs@redhat.com or submit a PR on GitHub. Do not bundle the glossary term update in a regular writing assignment PR. |
Usage: action
An action consists of project, verb, and resource:
-
Project is the project containing the resource that is to be acted upon.
-
Verb is a get, list, create, or update operation.
-
Resource is the API endpoint being accessed. This is distinct from the referenced resource itself, which can be a pod, deployment, build, etc.
Usage: API server(s)
A REST API endpoint for interacting with the system. New deployments and configurations can be created with this endpoint, and the state of the system can be interrogated through this endpoint as well.
Usage: API service(s)
When referencing the actual object, write as APIService. See API object formatting for more details.
Usage: application(s)
Although the term application is no longer an official noun in OpenShift, customers still create and host applications on OpenShift, and using the term within certain contexts is acceptable. For example, the term application might refer to some combination of an image, a Git repository, or a replication controller, and this application might be running PHP, MySQL, Ruby, JBoss, or something else.
OpenShift runs your applications.
The new-app command creates a new application from the components you specify.
My application has two Ruby web services connected to a database back end and a RabbitMQ message queue, and a python worker framework.
You can check the health of your application by adding probes to the various parts.
You can host a WordPress application on OpenShift.
Usage: Assisted Installer
In Red Hat OpenShift, the Assisted Installer is an installation solution that is offered on the Red Hat Hybrid Cloud Console to provide Software-as-a-Service functionality for cluster installations. The Assisted Installer supports installing OpenShift Container Platform on premises in a connected environment. The Assisted Installer is used for connected deployments.
Do not use: AI, assisted installer
Usage: boot image(s)
-
A boot image is a disk image that contains a bootable operating system (OS) and all the configuration settings for the OS, such as drivers.
Usage: build(s), or when speaking generally about Build objects.
-
A build is the process of transforming input parameters into a resulting object.
-
A
Buildobject encapsulates the inputs needed to produce a new deployable image, as well as the status of the execution and a reference to the pod that executed the build.
When referencing the actual object, write as "Build object" as appropriate. See API object formatting for more details.
Usage: build configuration(s) when speaking generally about BuildConfig objects.
A BuildConfig object is the definition of the entire build process. A build configuration describes a single build definition and a set of triggers for when a new build is created.
When referencing the actual object, write as "BuildConfig object" as appropriate. See API object formatting for more details.
Usage: cluster
The collection of controllers, pods, and services and related DNS and networking routing configuration that are defined on the system.
Usage: cluster service version
Operator Lifecycle Manager (OLM), part of the Operator Framework, uses a cluster service version (CSV) to define the metadata that accompanies an Operator container image and assist in running the Operator in a cluster. This metadata is defined in a ClusterServiceVersion API object used to populate user interfaces with information such as its logo, description, and version. It is also a source of technical information that is required to run the Operator, like the RBAC rules it requires and which custom resources (CRs) it manages or depends on.
This is commonly abbreviated as a CSV.
Usage: config map(s)
Config maps hold configuration data for pods to consume.
When referencing the actual object, write as ConfigMap. See API object formatting for more details.
Do not use: configuration map(s)
Usage: containerize(d)
Use "containerized" as an adjective when referring to applications made up of multiple services that are distributed in containers. "Containerized" can be used interchangeably with "container-based."
Usage: control plane
The control plane, which is composed of control plane machines, manages the {product-title} cluster. The control plane machines manage workloads on the compute machines, which are also known as worker machines.
Note that the OpenShift "control plane" was previously known as "master" and could still be in the code.
Usage: custom resource (CR)
A resource implemented through the Kubernetes CustomResourceDefinition API. A custom resource is distinct from the built-in Kubernetes resources, such as the pod and service resources. Every CR is part of an API group.
Do not capitalize.
Usage: deployment(s) when speaking generally about Deployment or DeploymentConfig objects
-
A
Deploymentis a Kubernetes-native object that provides declarative updates for pods and replica sets. -
A
DeploymentConfigis an OpenShift-specific object that defines the template for a pod and manages deploying new images or configuration changes. Uses replication controllers. Predates KubernetesDeploymentobjects.
When referencing the actual object, write as Deployment or DeploymentConfig as appropriate. See API object formatting for more details.
To avoid further confusion, do not refer to an overall OpenShift installation / instance / cluster as an "OpenShift deployment".
Do not use: deployment configuration(s), deployment config(s)
Usage: disconnected environment, disconnected installation
Use "disconnected" when discussing installing a cluster in an environment that does not have an active connection to the internet. Use "disconnected" regardless of whether the restriction is physical or logical.
"Disconnected" is the preferred term over "restricted", "air-gapped", or "offline".
Usage: Dockerfile; wrapped with [filename] markup. See Documentation Guidelines for markup information.
Docker can build images automatically by reading the instructions from a Dockerfile. A Dockerfile is a text document that contains all the commands you would normally execute manually to build a docker image.
Open the Dockerfile and make the following changes.
Create a Dockerfile at the root of your repository.
Usage: event(s)
An event is a data record expressing an occurrence and its context, based on the CNCF CloudEvents specification. Events contain two types of information: the event data representing the occurrence, and the context metadata providing contextual information about the occurrence. Events are routed from an event producer, or source, to connected event consumers.
Routing can be performed based on information contained in the event, but an event will not identify a specific routing destination. Events can be delivered through various industry standard protocols such as HTTP, AMQP, MQTT, or SMTP, or through messaging and broker systems, such as Kafka, NATS, AWS Kinesis, or Azure Event Grid.
When referencing the actual object, write as Event. See API object formatting for more details.
Usage: group/version/kind (GVK) for the first time reference; GVK thereafter.
A unique identifier for a Kubernetes API, specifying its group (a collection of related APIs), version (defines the release and level of stability), and kind (an individual API type or name).
While "GroupVersionKind" does appear in the API guide, typically there should not be a reason to mark up in reference to a specific object. Favor simply "GVK", or "GVKs" for pluralization, after the first time reference as much as possible. Avoid pluralizing the long form (e.g., group/version/kinds or groups/versions/kinds).
Usage: image stream(s)
Image streams provide a means of creating and updating container images in an ongoing way.
Usage: Ignition config file or Ignition config files
The file that Ignition uses to configure Red Hat Enterprise Linux CoreOS (RHCOS) during operating system initialization. The installation program generates different Ignition config files to initialize bootstrap, control plane, and worker nodes.
Usage: Ingress
API object that allows developers to expose services through an HTTP(S) aware load balancing and proxy layer via a public DNS entry. The Ingress resource may further specify TLS options and a certificate, or specify a public CNAME that the OpenShift Ingress Controller should also accept for HTTP and HTTPS traffic. An administrator typically configures their Ingress Controller to be visible outside the cluster firewall, and might also add additional security, caching, or traffic controls on the service content.
Usage: Ingress Controller(s)
A resource that forwards traffic to endpoints of services. The Ingress Controller replaces router from {product-title} 3 and earlier.
Usage: MetalLB, MetalLB Operator, MetalLB project
MetalLB is an open source project that provides a way to add services of type LoadBalancer to clusters that are not installed on infrastructure from a cloud provider. MetalLB primarily targets on-premise, bare-metal clusters, but any infrastructure that does not include a native load-balancing capability is a candidate.
"MetalLB" always has the first letter and last two letters capitalized in general text. Do not use "Metallb."
Usage: Deprecated. Use node instead.
Usage: OpenShift Container Platform, OpenShift Online, OpenShift Dedicated, OpenShift Container Engine
The OpenShift product name should be paired with its product distribution / variant name whenever possible. Previously, the upstream distribution was called OpenShift Origin, however it is now called OKD; use of the OpenShift Origin name is deprecated.
Avoid using the name "OpenShift" on its own when referring to something that applies to all distributions, as OKD does not have OpenShift in its name. However, the following components currently use "OpenShift" in the name and are allowed for use across all distribution documentation:
-
OpenShift Pipeline
-
OpenShift SDN
-
OpenShift Ansible Broker (deprecated in 4.2 / removed in 4.4)
Usage: OpenShift CLI (oc)
The oc tool is the command-line interface of OpenShift 3 and 4.
When referencing as a prerequisite for a procedure module, use the following
construction: Install the OpenShift CLI (oc).
Usage: Operator(s)
An Operator is a method of packaging, deploying and managing a Kubernetes
application. A Kubernetes application is an application that is both deployed on
a Kubernetes cluster (including OpenShift clusters) and managed using the
Kubernetes APIs and kubectl or oc tooling.
The term "Operator" is always captalized.
While "containerized" is allowed, do not use "Operatorize" to refer to building an Operator that packages an application.
Install the etcd Operator.
Build an Operator using the Operator SDK.
See API object formatting for more on Operator naming.
Usage: Operator Lifecycle Manager, OLM
Refer to this component without a preceding article ("the").
You can use OpenShift Lifecycle Manager (OLM) to manually or automatically upgrade an Operator.
Usage: Options menu; use sparingly; not to be confused with Actions menu, which signifies a specific menu seen in the web console.
This describes a menu type commonly called a "kebab", "hamburger", or "overflow" menu that does not have hover text or a given name or label in the web console.
Usage: persistent volume
Developers can use a persistent volume claim (PVC) to request a persistent volume (PV) resource without having specific knowledge of the underlying storage infrastructure.
Usage: persistent volume claim
Developers can use a persistent volume claim (PVC) to request a persistent volume (PV) resource without having specific knowledge of the underlying storage infrastructure.
Usage: pod(s)
Kubernetes object that groups related Docker containers that have to share network, file system, or memory together for placement on a node. Multiple instances of a pod can run to provide scaling and redundancy.
When referencing the actual object, write as Pod. See API object formatting for more details.
Usage: project(s)
A project allows a community of users to organize and manage their content in
isolation from other communities. It is an extension of the Namespace object
from Kubernetes.
When referencing the actual object, write as Project. See API object formatting for more details.
Usage: quick start(s)
There are two types of quick starts in OpenShift:
-
quick starts that are guided tutorials in the web console
-
quick start templates that allow users to quickly get started creating a new application
Be sure to provide context about which type of quick start you are referring to.
Usage: replica set(s)
Similar to a replication controller, a replica set is a native Kubernetes API
object that ensures a specified number of pod replicas are running at any given
time. Used by Deployment objects.
When referencing the actual object, write as ReplicaSet. See API object formatting for more details.
Usage: replication controller(s)
Kubernetes object that ensures N (as specified by the user) instances of a given pod are running at all times. Used by deployment configs.
Usage: route(s)
OpenShift-specific API object that allows developers to expose services through an HTTP(S) aware load balancing and proxy layer via a public DNS entry. The route might further specify TLS options and a certificate, or specify a public CNAME that the OpenShift Ingress Controller should also accept for HTTP and HTTPS traffic. An administrator typically configures their Ingress Controller to be visible outside the cluster firewall, and might also add additional security, caching, or traffic controls on the service content.
Usage: scheduler(s)
Component of the Kubernetes control plane or OpenShift control plane that manages the state of the system, places pods on nodes, and ensures that all containers that are expected to be running are actually running.
Usage: secret(s)
Kubernetes API object that holds secret data of a certain type.
See Secrets - Kubernetes.
Usage: security context constraints
Security context constraints govern the ability to make requests that affect the security context that will be applied to a container.
When referencing the actual object, write as SecurityContextConstraints. See API object formatting for more details.
This is commonly abbreviated as SCC.
Usage: service(s)
Kubernetes native API object that serves as an internal load balancer. It identifies a set of replicated pods to proxy the connections it receives to them. Backing pods can be added to or removed from a service arbitrarily while the service remains consistently available, enabling anything that depends on the service to refer to it at a consistent address.
A service is a named abstraction of software service (for example, mysql)
consisting of local port (for example 3306) that the proxy listens on, and the
selector that determines which pods will answer requests sent through the proxy.
Do not confuse with Open Service Broker API related objects. See Service Catalog Concepts and Terminology.
Usage: service account(s)
A service account binds together:
-
a name, understood by users, and perhaps by peripheral systems, for an identity
-
a principal that can be authenticated and authorized
-
a set of secrets
Usage: single-node OpenShift
Single-node OpenShift (or {product-title} on a single-node cluster) is a deployment footprint that provides control plane and worker node capabilities in a single server for deployments in constrained environments.
Do not use: Single Node Openshift (SNO).
Usage: three-node OpenShift
Three-node OpenShift is a compact cluster deployment footprint on three nodes for deployments in constrained environments. It provides three control plane nodes that you configure as schedulable for workloads.
Do not use: Three Node Openshift.
Usage: SkyDNS
Component of the Kubernetes control plane or OpenShift control plane that provides cluster-wide DNS resolution of internal hostnames for services and pods.
Usage: Source-to-Image for the first time reference; S2I thereafter.
Deprecated abbreviation (do not use): STI
Usage: spec(s)
In addition to "spec file" being allowed related to RPM spec files, general usage of "spec" is allowed when describing Kubernetes or OpenShift object specs / manifests / definitions.
Update the Pod spec to reflect the changes.
Usage: storage class(es)
Kubernetes API object that describes the parameters for a class of storage for
which persistent volumes can be dynamically provisioned. storage classes are
non-namespaced; the name of the storage class according to etcd is in
ObjectMeta.Name.
When referencing the actual object, write as StorageClass. See API object formatting for more details.
Usage: update
Use "update" when referring to updating the cluster to a new version. Although "upgrade" is sometimes used interchangeably, "update" is the preferred term to use, for consistency.