In this lesson, we are going to take a close look at Kubernetes clusters, pods and nodes. It's a Kubernetes cluster is a set of physical or virtual hardware, which essentially constitute a set of hosts or servers or computers. A node is a master node or worker node, It runs a set of services. Every cluster needs at least one master and at least one worker node. The worker nodes can be thought of as a computer where the business enterprise runs and application or applications for business purposes. A node in Kubernetes is either physical or virtual hardware that manages pods and a container runtime. As we all know an individual computer or node can always go offline. If this is the only run time, this would make any applications that were running on available to customers, therefore there must be some strategy for redundancy. A Kubernetes cluster provides an out-of-the-box redundancy model for applications. In Kubernetes, if a node goes offline, the containers and pods will be recreated in a new node, therefore the applications will come back online, or else look like they never went offline. The cluster is the worker node that runs at least one pod. So in a cluster, we always have at least one worker node and at least one pod. The pod is the lowest level of all Kubernetes objects. There also is a container runtime, but that is not part of Kubernetes, Kubernetes uses other products container runtimes. A pod and containers typically run in redundancy. The kubernetes cluster is managed by at least one master node, with it always one primary masternode. The masternode really the API server communicates with the worker nodes and allows administrators to customize the network. We can see here the master node is in communication with the worker nodes. So we have here the API server, the kube-apiserver is the kubernetes front end for the administrators and the cluster. User management is accessed with the kube-apiserver or masternode. The kube-apiserver is the Kubernetes command line in API interface also. The etcd is the distributed high-availability repository that manages the Kubernetes state and also manages the keystore. All cluster management data is stored in the etcd repository. Data such as the number of Master nodes and the number of worker nodes is stored in the etcd. And the etcd also stores configuration data on the master and worker nodes. The kube-scheduler distributes the processing to the containers in the worker notes. The kube-controller manager detects failures in the nodes, pods, and containers, but failure is detected the kube-controller manager starts a new node or pod. The cloud controller manager is a value is valuable when Kubernetes is run on a Cloud solution. When running on a Cloud solution, the cloud controller manager interfaces with the third party Cloud infrastructure. The kubelet is part of the worker node. It's a service that runs on the entire cluster. It listens on the worker node and performs registration with the API server, so it's in communication with the master node. It maintains a set of pod attributes. The kubelet runs and monitors pods to ensure that they are indeed running without any problems. Containers are not Kubernetes objects, therefore the kubelet runs at the pod level. The kube-proxy runs on each nodes for the network level, it distributes the network information. The kube-proxy forwards network connections. The kube-proxy runs TCP, UDP and SCTP stream forwarding or round-robin, a network forwarding across a set of notes. The Kubernetes administrator role covers node installation and configuration. Kubernetes administrators validate hardware requirements and the enterprise requirements. They designed the servers, the nodes and the high availability patterns. Administrators install nodes and designed the pods and container strategy including implementation of selectors and labels. And right here we can see a set of worker nodes with the container runtime, and we can see the actual services that are running. So a service, if you remember from the previous lessons, adds another level of abstraction between the user and the Kubernetes worker nodes with the Kubernetes pods. And we can also set up what are called selectors which are name value pairs. And we can see here that the middleware selector is selecting it's appropriate middleware nodes, and we can see here the app data is selecting its appropriate app data nodes. Administrators also design and pattern deployments, updates, rollbacks and automation tactics. administrators implement monitoring, telemetry and other logging. And telemetry is a fancy word for measuring items that we cannot see immediately. So if an application is writing a lot of logging information that may not be available or they may not be obvious, the application might look like it's fine. But we can use monitoring solutions to find out if there is a lot of data being written to the log and then investigate. The administrator role also includes debugging and creating a consumer secrets. An interesting aspect of Kubernetes is that there are no user objects. However, Kubernetes can use user names for access control and request logging. Kubernetes has two types of users, normal users and service accounts. Kubernetes manages normal users outside of the cluster, service accounts are cluster processes that communicate with the API server. ReplicaSets are replicated pods. So replicaSets or replicas run as pods. ReplicaSets supports scaling up pods to ensure a multi-image solution is running for performance and redundancy. So replicaSets can be applications that are scaled up. ReplicaSets have different attributes one of which is the desired state where the number of desired or or replicas running. So it's the number of replicas that essentially we say have to be running. If the number of replicas running drops below the desired number, Kubernetes creates new replicas to reach the desired number of replicas running with the desired state. So in this case, we see that replicas are replicated pods, so we can see here this template has three replicas pod A, B, and C. The desired replicas is 3, the current replicas are 3, and right here the current equaling the desired is true. However, if one of the replicas goes offline, suddenly we would have the desired replicas is still 3, but the current replicas is 2, end the current state equalling the desired state is false. So what would happen now is a new replica would be created, and we've seen examples of this from our deployments, and when we scaled up our deployments in some of our previous either the exercises or just the videos that we have watched. And we can see here that we are back to the desired state. DaemonSet is a process that makes certain a pod is running on the eligible nodes. DaemonSets are similar to deployments in that they both create pods and those pods are expected to continuously run. Use of a deployment when scaling up and down the number of replicas and rolling out updates that are the most important, and controlling access to the host of which the pod runs. So we want to use deployment when scaling up or down when the number of replicas rolling out, the updates are the most important. We use DaemonSets when it is important that a copy of a pod always run on certain hosts, and when it needs to start before the pods. If a node is removed from a cluster, a garbage collection process is called on the pods. DaemonSets are updatable. If nodes or labels change the DaemonSet will add pods to the newly created matching nodes and remove pods from the non-matching nodes. A stateful set is an API object that runs the workload of stateful applications. Stateful application is ones that require network IDs, persistent storage, scaling, rolling updates. Similar to a Deployment, a StatefulSet manages pods based on an identical container set. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their pods. Therefore pods are from the same spec but are not interchangeable, each pod has a unique number. For a stateful set with n number of replicas during deployment pods are created sequentially in order from 0 to N -1. When pods are being deleted, they are removed in reverse order from N- 1 to 0. Please take a look at the readings that are included with this lesson, and also complete the quiz.
