|
Note
|
The guidelines in this branch are specific for OpenShift / OKD 3.x
documentation. See the
enterprise-4.0 branch
for guidelines for OpenShift / OKD 4.x documentation.
|
This topic provides guidelines for referring to the various components of OpenShift 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.
|
Note
|
If you want to add terms or other content to this document, or if anything needs to be fixed, send an email to [email protected] or submit a PR on GitHub. |
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 config, build, etc.
Usage: apiserver(s) as appropriate
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: application(s) as appropriate; italicized
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 may refer to some combination of an image, a Git repository, or a replication controller, and this application may be running PHP, MySQL, Ruby, JBoss, or something else.
Do NOT use the term application in a topic or section heading.
Examples of correct usage
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 backend and a RabbitMQ message queue, as well as 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: authorization
An authorization determines whether an identity is allowed to perform any action. It consists of identity and action.
Usage: cluster
The collection of controllers, pods, and services and related DNS and networking routing configuration that are defined on the system.
Usage: deployment
A deployment is a statement of intent by a user to roll out a new version of a config. A replication controller can be used for that and other purposes. All deployments are replication controllers, but all replication controllers are not deployments.
To avoid confusion, do not refer to an overall OpenShift installation / instance / cluster as an "OpenShift deployment".
Usage: deployment controller(s) as appropriate
Kubernetes object that creates a replication controller from a given pod template. If that pod template is modified, the deployment controller creates a new replication controller based on the modified pod template and replaces the old replication controller with this new one.
Usage: Dockerfile; wrapped with [filename] markup. See Documentation Guidelines for markup information.
Container engines like Podman, Buildah, and 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 in order to build a container image.
Open the Dockerfile and make the following changes.
Create a Dockerfile at the root of your repository.
Usage: identity or identities as appropriate
Both the username and list of groups the user belongs to.
Usage: Kubelet(s) as appropriate
The agent that controls a Kubernetes node. Each node runs a Kubelet, which handles starting and stopping containers on a node, based on the desired state defined by the master.
Usage: Kubernetes master(s) as appropriate
The Kubernetes-native equivalent to the OpenShift master. An OpenShift system runs OpenShift masters, not Kubernetes masters, and an OpenShift master provides a superset of the functionality of a Kubernetes master, so it is generally preferred to use the term OpenShift master.
Usage: OpenShift CLI
This is the command line interface of OpenShift v3, previously referred to as the client tools in OpenShift v2.
Usage: OpenShift master(s) as appropriate
Provides a REST endpoint for interacting with the system and manages the state of the system, ensuring that all containers expected to be running are actually running and that other requests such as builds and deployments are serviced. New deployments and configurations are created with the REST API, and the state of the system can be interrogated through this endpoint as well. An OpenShift master comprises the apiserver, scheduler, and SkyDNS.
Usage: pod(s) as appropriate
Kubernetes object that groups related containers that need to share network, filesystem, or memory together for placement on a node. Multiple instances of a Pod can run to provide scaling and redundancy.
Usage: project(s) as appropriate
A project allows a community of users to organize and manage their content in isolation from other communities.
Usage: replication controller(s) as appropriate
Kubernetes object that ensures N (as specified by the user) instances of a given Pod are running at all times.
Usage: scheduler(s) as appropriate
Component of the Kubernetes master or OpenShift master 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: SkyDNS
Component of the Kubernetes master or OpenShift master that provides cluster-wide DNS resolution of internal hostnames for services and pods.