:_mod-docs-content-type: ASSEMBLY
[id="overview-of-nodes"]
= Overview of nodes
include::_attributes/common-attributes.adoc[]
:context: overview-of-nodes

toc::[]

// TODO: Need some help with an intro blurb

[id="nodes-overview"]
== About nodes

A node is a virtual or bare-metal machine in a Kubernetes cluster. Worker nodes host your application containers, grouped as pods. The control plane nodes run services that are required to control the Kubernetes cluster.
ifndef::openshift-rosa-hcp[]
In {product-title}, the control plane nodes contain more than just the Kubernetes services for managing the {product-title} cluster.
endif::openshift-rosa-hcp[]
ifdef::openshift-rosa-hcp[]
In {product-title}, the control plane nodes are hosted in a Red{nbsp}Hat-owned AWS account. Red{nbsp}Hat fully manages the control plane infrastructure for you.
endif::openshift-rosa-hcp[]

ifdef::openshift-rosa,openshift-rosa-hcp[]
[IMPORTANT]
====
Worker nodes are not guaranteed longevity, and may be replaced at any time as part of the normal operation and management of OpenShift. For more details, see 
ifdef::openshift-rosa[]
xref:../rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc#rosa-sdpolicy-node-lifecycle_rosa-service-definition[Node lifecycle].
endif::openshift-rosa[]
ifdef::openshift-rosa-hcp[]
xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc#rosa-sdpolicy-node-lifecycle_rosa-hcp-service-definition[Node lifecycle].
endif::openshift-rosa-hcp[]
====
endif::openshift-rosa,openshift-rosa-hcp[]

Having stable and healthy nodes in a cluster is fundamental to the smooth functioning of your hosted application.
In {product-title}, you can access, manage, and monitor a node through the `Node` object representing the node.
Using the OpenShift CLI (`oc`) or the web console, you can perform the following operations on a node.

The following components of a node are responsible for maintaining the running of pods and providing the Kubernetes runtime environment.

Container runtime:: The container runtime is responsible for running containers. {product-title} deploys the CRI-O container runtime on each of the {op-system-first} nodes in your cluster. The Windows Machine Config Operator (WMCO) deploys the containerd runtime on its Windows nodes. 	 

Kubelet:: Kubelet runs on nodes and reads the container manifests. It ensures that the defined containers have started and are running. The kubelet process maintains the state of work and the node server. Kubelet manages network rules and port forwarding. The kubelet manages containers that are created by Kubernetes only.

DNS:: Cluster DNS is a DNS server which serves DNS records for Kubernetes services. Containers started by Kubernetes automatically include this DNS server in their DNS searches.

ifndef::openshift-rosa-hcp[]
image::295_OpenShift_Nodes_Overview_1222.png[Overview of control plane and worker node]
endif::openshift-rosa-hcp[]

ifdef::openshift-rosa-hcp[]
image::ROSA-HCP-overview-of-nodes-487.png[Overview of control plane and worker node]
endif::openshift-rosa-hcp[]


=== Read operations

The read operations allow an administrator or a developer to get information about nodes in an {product-title} cluster.

* xref:../nodes/nodes/nodes-nodes-viewing.adoc#nodes-nodes-viewing-listing_nodes-nodes-viewing[List all the nodes in a cluster].
* Get information about a node, such as memory and CPU usage, health, status, and age.
* xref:../nodes/nodes/nodes-nodes-viewing.adoc#nodes-nodes-viewing-listing-pods_nodes-nodes-viewing[List pods running on a node].

ifndef::openshift-enterprise,openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]

=== Management operations

As an administrator, you can easily manage a node in an {product-title} cluster
through several tasks:

* xref:../nodes/nodes/nodes-nodes-working.adoc#nodes-nodes-working-updating_nodes-nodes-working[Add or update node labels]. A label is a key-value pair applied to a `Node` object. You can control the scheduling of pods using labels.
* Change node configuration using a custom resource definition (CRD), or the `kubeletConfig` object.
* Configure nodes to allow or disallow the scheduling of pods. Healthy worker nodes with a `Ready` status allow pod placement by default while the control plane nodes do not; you can change this default behavior by xref:../nodes/nodes/nodes-nodes-working.adoc#nodes-nodes-working-marking_nodes-nodes-working[configuring the worker nodes to be unschedulable] and xref:../nodes/nodes/nodes-nodes-working.adoc#nodes-nodes-working-marking_nodes-nodes-working[the control plane nodes to be schedulable].
* xref:../nodes/nodes/nodes-nodes-resources-configuring.adoc#nodes-nodes-resources-configuring[Allocate resources for nodes] using the `system-reserved` setting. You can allow {product-title} to automatically determine the optimal `system-reserved` CPU and memory resources for your nodes, or you can manually determine and set the best resources for your nodes.
* xref:../nodes/nodes/nodes-nodes-managing-max-pods.adoc#nodes-nodes-managing-max-pods-proc_nodes-nodes-managing-max-pods[Configure the number of pods that can run on a node] based on the number of processor cores on the node, a hard limit, or both.
* Reboot a node gracefully using xref:../nodes/nodes/nodes-nodes-rebooting.adoc#nodes-nodes-rebooting-affinity_nodes-nodes-rebooting[pod anti-affinity].
* xref:../nodes/nodes/nodes-nodes-working.adoc#deleting-nodes[Delete a node from a cluster] by scaling down the cluster using a compute machine set. To delete a node from a bare-metal cluster, you must first drain all pods on the node and then manually delete the node.
endif::openshift-enterprise,openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]


=== Enhancement operations

{product-title} allows you to do more than just access and manage nodes; as an administrator, you can perform the following tasks on nodes to make the cluster more efficient, application-friendly, and to provide a better environment for your developers.

* Manage node-level tuning for high-performance applications that require some level of kernel tuning by xref:../nodes/nodes/nodes-node-tuning-operator.adoc#nodes-node-tuning-operator[using the Node Tuning Operator].
ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
* Enable TLS security profiles on the node to protect communication between the kubelet and the Kubernetes API server.
endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
* xref:../nodes/jobs/nodes-pods-daemonsets.adoc#nodes-pods-daemonsets[Run background tasks on nodes automatically with daemon sets]. You can create and use daemon sets to create shared storage, run a logging pod on every node, or deploy a monitoring agent on all nodes.
ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
* xref:../nodes/nodes/nodes-nodes-garbage-collection.adoc#nodes-nodes-garbage-collection[Free node resources using garbage collection]. You can ensure that your nodes are running efficiently by removing terminated containers and the images not referenced by any running pods.
* xref:../nodes/nodes/nodes-nodes-managing.adoc#nodes-nodes-kernel-arguments_nodes-nodes-managing[Add kernel arguments to a set of nodes].
* Configure an {product-title} cluster to have worker nodes at the network edge (remote worker nodes). For information on the challenges of having remote worker nodes in an {product-title} cluster and some recommended approaches for managing pods on a remote worker node, see xref:../nodes/edge/nodes-edge-remote-workers.adoc#nodes-edge-remote-workers[Using remote worker nodes at the network edge].
endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]

[id="pods-overview"]
== About pods

A pod is one or more containers deployed together on a node. As a cluster administrator, you can define a pod, assign it to run on a healthy node that is ready for scheduling, and manage. A pod runs as long as the containers are running. You cannot change a pod once it is defined and is running. Some operations you can perform when working with pods are:


=== Read operations

As an administrator, you can get information about pods in a project through the following tasks:

* xref:../nodes/pods/nodes-pods-viewing.adoc#nodes-pods-viewing-project_nodes-pods-viewing[List pods associated with a project], including information such as the number of replicas and restarts, current status, and age.
* xref:../nodes/pods/nodes-pods-viewing.adoc#nodes-pods-viewing-usage_nodes-pods-viewing[View pod usage statistics] such as CPU, memory, and storage consumption.



=== Management operations

The following list of tasks provides an overview of how an administrator can manage pods in an {product-title} cluster.

* Control scheduling of pods using the advanced scheduling features available in {product-title}:
** Node-to-pod binding rules such as xref:../nodes/scheduling/nodes-scheduler-pod-affinity.adoc#nodes-scheduler-pod-affinity-example-affinity_nodes-scheduler-pod-affinity[pod affinity], xref:../nodes/scheduling/nodes-scheduler-node-affinity.adoc#nodes-scheduler-node-affinity[node affinity], and xref:../nodes/scheduling/nodes-scheduler-pod-affinity.adoc#nodes-scheduler-pod-anti-affinity-configuring_nodes-scheduler-pod-affinity[anti-affinity].
** xref:../nodes/scheduling/nodes-scheduler-node-selectors.adoc#nodes-scheduler-node-selectors[Node labels and selectors].
ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
** xref:../nodes/scheduling/nodes-scheduler-taints-tolerations.adoc#nodes-scheduler-taints-tolerations[Taints and tolerations].
endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
** xref:../nodes/scheduling/nodes-scheduler-pod-topology-spread-constraints.adoc#nodes-scheduler-pod-topology-spread-constraints[Pod topology spread constraints].
// Cannot create namespace to install Operator
ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
** xref:../nodes/scheduling/secondary_scheduler/index.adoc#nodes-secondary-scheduler-about[Secondary scheduling].
* xref:../nodes/scheduling/descheduler/index.adoc#nodes-descheduler-about[Configure the descheduler to evict pods] based on specific strategies so that the scheduler reschedules the pods to more appropriate nodes.
endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
* xref:../nodes/pods/nodes-pods-configuring.adoc#nodes-pods-configuring-restart_nodes-pods-configuring[Configure how pods behave after a restart using pod controllers and restart policies].
* xref:../nodes/pods/nodes-pods-configuring.adoc#nodes-pods-configuring-bandwidth_nodes-pods-configuring[Limit both egress and ingress traffic on a pod].
* xref:../nodes/containers/nodes-containers-volumes.adoc#nodes-containers-volumes[Add and remove volumes to and from any object that has a pod template]. A volume is a mounted file system available to all the containers in a pod. Container storage is ephemeral; you can use volumes to persist container data.


=== Enhancement operations

You can work with pods more easily and efficiently with the help of various tools and features available in {product-title}. The following operations involve using those tools and features to better manage pods.

ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
[cols="2,1,2"]
|===
|Operation |User |More information

|Create and use a horizontal pod autoscaler.
|Developer
|You can use a horizontal pod autoscaler to specify the minimum and the maximum number of pods you want to run, as well as the CPU utilization or memory utilization your pods should target. Using a horizontal pod autoscaler, you can xref:../nodes/pods/nodes-pods-autoscaling.adoc#nodes-pods-autoscaling[automatically scale pods].

|xref:../nodes/pods/nodes-pods-vertical-autoscaler.adoc#nodes-pods-vpa[Install and use a vertical pod autoscaler].
|Administrator and developer
|As an administrator, use a vertical pod autoscaler to better use cluster resources by monitoring the resources and the resource requirements of workloads.

As a developer, use a vertical pod autoscaler to ensure your pods stay up during periods of high demand by scheduling pods to nodes that have enough resources for each pod.

|Provide access to external resources using device plugins.
|Administrator
|A xref:../nodes/pods/nodes-pods-plugins.adoc#nodes-pods-device[device plugin] is a gRPC service running on nodes (external to the kubelet), which manages specific hardware resources. You can xref:../nodes/pods/nodes-pods-plugins.adoc#methods-for-deploying-a-device-plugin_nodes-pods-device[deploy a device plugin] to provide a consistent and portable solution to consume hardware devices across clusters.

|Provide sensitive data to pods xref:../nodes/pods/nodes-pods-secrets.adoc#nodes-pods-secrets[using the `Secret` object].
|Administrator
|Some applications need sensitive information, such as passwords and usernames. You can use the `Secret` object to provide such information to an application pod.

|===
endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
* Secrets: Some applications need sensitive information, such as passwords and usernames. An administrator can use the `Secret` object to provide sensitive data to pods xref:../nodes/pods/nodes-pods-secrets.adoc#nodes-pods-secrets[using the `Secret` object].
endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]

[id="containers-overview"]
== About containers

A container is the basic unit of an {product-title} application, which comprises the application code packaged along with its dependencies, libraries, and binaries. Containers provide consistency across environments and multiple deployment targets: physical servers, virtual machines (VMs), and private or public cloud.

Linux container technologies are lightweight mechanisms for isolating running processes and limiting access to only designated resources.
As an administrator, You can perform various tasks on a Linux container, such as:

* xref:../nodes/containers/nodes-containers-copying-files.adoc#nodes-containers-copying-files[Copy files to and from a container].
* xref:../nodes/containers/nodes-containers-downward-api.adoc#nodes-containers-downward-api[Allow containers to consume API objects].
* xref:../nodes/containers/nodes-containers-remote-commands.adoc#nodes-containers-remote-commands[Execute remote commands in a container].
* xref:../nodes/containers/nodes-containers-port-forwarding.adoc#nodes-containers-port-forwarding[Use port forwarding to access applications in a container].

{product-title} provides specialized containers called xref:../nodes/containers/nodes-containers-init.adoc#nodes-containers-init[Init containers]. Init containers run before application containers and can contain utilities or setup scripts not present in an application image. You can use an Init container to perform tasks before the rest of a pod is deployed.

Apart from performing specific tasks on nodes, pods, and containers, you can work with the overall {product-title} cluster to keep the cluster efficient and the application pods highly available.

//cannot create the required namespace for these operators
ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
[id="nodes-about-autoscaling-pod_{context}"]
== About autoscaling pods on a node

{product-title} offers three tools that you can use to automatically scale the number of pods on your nodes and the resources allocated to pods.

Horizontal Pod Autoscaler::
The Horizontal Pod Autoscaler (HPA) can automatically increase or decrease the scale of a replication controller or deployment configuration, based on metrics collected from the pods that belong to that replication controller or deployment configuration.
+
For more information, see xref:../nodes/pods/nodes-pods-autoscaling.adoc#nodes-pods-autoscaling[Automatically scaling pods with the horizontal pod autoscaler].

Custom Metrics Autoscaler::
The Custom Metrics Autoscaler can automatically increase or decrease the number of pods for a deployment, stateful set, custom resource, or job based on custom metrics that are not based only on CPU or memory.
+
For more information, see xref:../nodes/cma/nodes-cma-autoscaling-custom.adoc#nodes-cma-autoscaling-custom[Custom Metrics Autoscaler Operator overview].

Vertical Pod Autoscaler::
The Vertical Pod Autoscaler (VPA) can automatically review the historic and current CPU and memory resources for containers in pods and can update the resource limits and requests based on the usage values it learns.
+
For more information, see xref:../nodes/pods/nodes-pods-vertical-autoscaler.adoc#nodes-pods-vpa[Automatically adjust pod resource levels with the vertical pod autoscaler].
endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]

[id="commonterms-node"]
== Glossary of common terms for {product-title} nodes

This glossary defines common terms that are used in the _node_ content.


[id="commonterms-node-container"]
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"]
Daemon set::
Ensures that a replica of the pod runs on eligible nodes in an {product-title} cluster.


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


[id="commonterms-node-gc"]
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"]
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"]
Ingress::
Incoming traffic to a pod.


[id="commonterms-node-job"]
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"]
Labels::
You can use labels, which are key-value pairs, to organise and select subsets of objects, such as a pod.


[id="commonterms-node-nodenew"]
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"]
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"]
Self Node Remediation Operator::
The Operator runs on the cluster nodes and identifies and reboots nodes that are unhealthy.


[id="commonterms-node-podnew"]
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"]
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"]
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.
