From 4b2b1542be8525b846ab035c5a56fbf449178de9 Mon Sep 17 00:00:00 2001 From: Shubha Narayanan Date: Tue, 7 Oct 2025 11:47:41 +0530 Subject: [PATCH] Delete unused modules ocp terms --- ...etting-started-openshift-common-terms.adoc | 59 ------------------- 1 file changed, 59 deletions(-) delete mode 100644 modules/getting-started-openshift-common-terms.adoc diff --git a/modules/getting-started-openshift-common-terms.adoc b/modules/getting-started-openshift-common-terms.adoc deleted file mode 100644 index 28003cf49162..000000000000 --- a/modules/getting-started-openshift-common-terms.adoc +++ /dev/null @@ -1,59 +0,0 @@ -// Module included in the following assemblies: -// -// * getting-started/openshift-overview.adoc - -:_mod-docs-content-type: REFERENCE -[id="getting-started-openshift-common-terms_{context}"] -= Glossary of common terms for {product-title} - -This glossary defines common Kubernetes and {product-title} terms. - -Kubernetes:: -Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications. - -Containers:: -Containers are application instances and components that run in OCI-compliant containers on the worker nodes. A container is the runtime of an Open Container Initiative (OCI)-compliant image. An image is a binary application. A worker node can run many containers. A node capacity is related to memory and CPU capabilities of the underlying resources whether they are cloud, hardware, or virtualized. - -Pod:: -A pod is one or more containers deployed together on one host. It consists of a colocated group of containers with shared resources such as volumes and IP addresses. A pod is also the smallest compute unit defined, deployed, and managed. -+ -In {product-title}, pods replace individual application containers as the smallest deployable unit. -+ -Pods are the orchestrated unit in {product-title}. {product-title} schedules and runs all containers in a pod on the same node. Complex applications are made up of many pods, each with their own containers. They interact externally and also with another inside the {product-title} environment. - -Replica set and replication controller:: -The Kubernetes replica set and the {product-title} replication controller are both available. The job of this component is to ensure the specified number of pod replicas are running at all times. If pods exit or are deleted, the replica set or replication controller starts more. If more pods are running than needed, the replica set deletes as many as necessary to match the specified number of replicas. - -Deployment and DeploymentConfig:: -{product-title} implements both Kubernetes `Deployment` objects and {product-title} `DeploymentConfigs` objects. Users may select either. -+ -`Deployment` objects control how an application is rolled out as pods. They identify the name of the container image to be taken from the registry and deployed as a pod on a node. They set the number of replicas of the pod to deploy, creating a replica set to manage the process. The labels indicated instruct the scheduler onto which nodes to deploy the pod. The set of labels is included in the pod definition that the replica set instantiates. -+ -`Deployment` objects are able to update the pods deployed onto the worker nodes based on the version of the `Deployment` objects and the various rollout strategies for managing acceptable application availability. {product-title} `DeploymentConfig` objects add the additional features of change triggers, which are able to automatically create new versions of the `Deployment` objects as new versions of the container image are available, or other changes. - -Service:: -A service defines a logical set of pods and access policies. It provides permanent internal IP addresses and hostnames for other applications to use as pods are created and destroyed. -+ -Service layers connect application components together. For example, a front-end web service connects to a database instance by communicating with its service. Services allow for simple internal load balancing across application components. {product-title} automatically injects service information into running containers for ease of discovery. - -Route:: -A route is a way to expose a service by giving it an externally reachable hostname, such as www.example.com. Each route consists of a route name, a service selector, and optionally a security configuration. A router can consume a defined route and the endpoints identified by its service to provide a name that lets external clients reach your applications. While it is easy to deploy a complete multi-tier application, traffic from anywhere outside the {product-title} environment cannot reach the application without the routing layer. - -Build:: -A build is the process of transforming input parameters into a resulting object. Most often, the process is used to transform input parameters or source code into a runnable image. A `BuildConfig` object is the definition of the entire build process. {product-title} leverages Kubernetes by creating containers from build images and pushing them to the integrated registry. - -Project:: -{product-title} uses projects to allow groups of users or developers to work together, serving as the unit of isolation and collaboration. It defines the scope of resources, allows project administrators and collaborators to manage resources, and restricts and tracks the user’s resources with quotas and limits. -+ -A project is a Kubernetes namespace with additional annotations. It is the central vehicle for managing access to resources for regular users. A project lets a community of users organize and manage their content in isolation from other communities. Users must receive access to projects from administrators. But cluster administrators can allow developers to create their own projects, in which case users automatically have access to their own projects. -+ -Each project has its own set of objects, policies, constraints, and service accounts. -+ -Projects are also known as namespaces. - -Operators:: -An Operator is a Kubernetes-native application. The goal of an Operator is to put operational knowledge into software. Previously this knowledge only resided in the minds of administrators, various combinations or shell scripts or automation software such as Ansible. It was outside your Kubernetes cluster and hard to integrate. With Operators, all of this changes. -+ -Operators are purpose-built for your applications. They implement and automate common Day 1 activities such as installation and configuration as well as Day 2 activities such as scaling up and down, reconfiguration, updates, backups, fail overs, and restores in a piece of software running inside your Kubernetes cluster by integrating natively with Kubernetes concepts and APIs. This is called a Kubernetes-native application. -+ -With Operators, applications must not be treated as a collection of primitives, such as pods, deployments, services, or config maps. Instead, Operators should be treated as a single object that exposes the options that make sense for the application.