In each node, we have several components as mentioned already. Let's look at each of them in detail.

The kubelet interacts with the API server to update the state and to start new workloads that have been invoked by the scheduler. As previously mentioned, this agent runs on every node of the cluster. The primary interface of the kubelet is one or more PodSpecs, which ensure that the containers and configurations are healthy.

The kube-proxy provides basic load balancing and directs the traffic destined for specific services to the proper pod on the backend. It maintains these network rules to enable the service abstraction through connection forwarding.

The last major component of the node is the container runtime, which is responsible for initiating, running, and stopping containers. The Kubernetes ecosystem has introduced the OCI runtime specification to democratize the container scheduler/orchestrator interface. While Docker, rkt, and runc are the current major implementations, the OCI aims to provide a common interface so you can bring your own runtime. At this point, Docker is the overwhelmingly dominant runtime.

In your cluster, the nodes may be virtual machines or bare metal hardware. Compared to other items such as controllers and pods, the node is not an abstraction that is created by Kubernetes. Rather, Kubernetes leverages cloud-controller-manager to interact with the cloud provider API, which owns the life cycle of the nodes. That means that when we instantiate a node in Kubernetes, we're simply creating an object that represents a machine in your given infrastructure. It's up to Kubernetes to determine if the node has converged with the object definition. Kubernetes validates the node's availability through its IP address, which is gathered via the metadata.name field. The status of these nodes can be discovered through the following status keys.

The addresses are where we'll find information such as the hostname and private and public IPs. This will be specific to your cloud provider's implementation. The condition field will give you a view into the state of your node's status in terms of disk, memory, network, and basic configuration.

Here's a table with the available node conditions:

A healthy node will have a status that looks similar to the following if you run it, you'll see the following output in the code:

$ kubectl get nodes -o json

"conditions": [
  {
    "type": "Ready",
    "status": "True"
  }
]

Capacity is simple: it's the available CPU, memory, and resulting number of pods that can be run on a given node. Nodes self-report their capacity and leave the responsibility for scheduling the appropriate number of resources to Kubernetes. The Info key is similarly straightforward and provides version information for Docker, OS, and Kubernetes.

It's important to note that the major component of the Kubernetes and node relationship is the node controller, which we called out previously as one of the core system controllers. There are three strategic pieces to this relationship:

• Node health: When you run large clusters in private, public, or hybrid cloud scenarios, you're bound to lose machines from time to time. Even within the data center, given a large enough cluster, you're bound to see regular failures at scale. The node controller is responsible for updating the node's NodeStatus to either NodeReady or ConditionUnknown, depending on the instance's availability. This management is key as Kubernetes will need to migrate pods (and therefore containers) to available nodes if ConditionUnknown occurs. You can set the health check interval for nodes in your cluster with --node-monitor-period.
• IP assignment: Every node needs some IP addresses, so it can distribute IPs to services and or containers.
• Node list: In order to manage pods across a number of machines, we need to keep an up-to-date list of available machines. Based on the aforementioned NodeStatus, the node controller will keep this list current.

We'll look into node controller specifics when investigating highly available clusters that span Availability Zones (AZs), which requires the spreading of nodes across AZs in order to provide availability.

Finally, we have some default pods, which run various infrastructure services for the node. As we explored briefly in the previous chapter, the pods include services for the Domain Name System (DNS), logging, and pod health checks. The default pod will run alongside our scheduled pods on every node.