// Module included in the following assemblies:
//
// * nodes/index.adoc

:_mod-docs-content-type: REFERENCE
[id="nodes-overview-glossary-common-terms_{context}"]
= Glossary of common terms for {product-title} nodes

[role="_abstract"]
This glossary defines common terms that are used in the _node_ content.


[id="commonterms-node-container_{context}"]
Container::
It is a lightweight and executable image that comprises software and all its dependencies. Containers virtualize the operating system, as a result, you can run containers anywhere from a data center to a public or private cloud to even a developer's laptop.


[id="commonterms-node-daemonset_{context}"]
Daemon set::
Ensures that a replica of the pod runs on eligible nodes in an {product-title} cluster.


[id="commonterms-node-egress_{context}"]
egress::
The process of data sharing externally through a network’s outbound traffic from a pod.


[id="commonterms-node-gc_{context}"]
garbage collection::
The process of cleaning up cluster resources, such as terminated containers and images that are not referenced by any running pods.

//cannot create the required namespace for these operators
ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]

[id="commonterms-node-hpa_{context}"]
Horizontal Pod Autoscaler(HPA)::
Implemented as a Kubernetes API resource and a controller. You can use the HPA to specify the minimum and maximum number of pods that you want to run. You can also specify the CPU or memory utilization that your pods should target. The HPA scales out and scales in pods when a given CPU or memory threshold is crossed.
endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]


[id="commonterms-node-ingress_{context}"]
Ingress::
Incoming traffic to a pod.


[id="commonterms-node-job_{context}"]
Job::
A process that runs to completion. A job creates one or more pod objects and ensures that the specified pods are successfully completed.


[id="commonterms-node-label_{context}"]
Labels::
You can use labels, which are key-value pairs, to organize and select subsets of objects, such as a pod.


[id="commonterms-node-nodenew_{context}"]
Node::
A worker machine in the {product-title} cluster. A node can be either be a virtual machine (VM) or a physical machine.


[id="commonterms-node-tuningop_{context}"]
Node Tuning Operator::
You can use the Node Tuning Operator to manage node-level tuning by using the TuneD daemon. It ensures custom tuning specifications are passed to all containerized TuneD daemons running in the cluster in the format that the daemons understand. The daemons run on all nodes in the cluster, one per node.


[id="commonterms-node-self-remediationop_{context}"]
Self Node Remediation Operator::
The Operator runs on the cluster nodes and identifies and reboots nodes that are unhealthy.


[id="commonterms-node-podnew_{context}"]
Pod::
One or more containers with shared resources, such as volume and IP addresses, running in your {product-title} cluster.
A pod is the smallest compute unit defined, deployed, and managed.


[id="commonterms-node-toleration_{context}"]
Toleration::
Indicates that the pod is allowed (but not required) to be scheduled on nodes or node groups with matching taints. You can use tolerations to enable the scheduler to schedule pods with matching taints.


[id="commonterms-node-taint_{context}"]
Taint::
A core object that comprises a key, value, and effect. Taints and tolerations work together to ensure that pods are not scheduled on irrelevant nodes.
