Kubernetes is one of the mos trending technology in the cloud.
It is supported on any cloud platform and supports hosting and enhance complex applications on various kinds of architectures that make it
vast and complex technology.

Kubernets is supported by:

• Cloud Native Computing Foundation
• The Linux Foundation

Link for Certification:  https://www.cncf.io/certification/ckad

Recap on Kubernetes Architecture.

Nodes: A node is a worker machine, physical or virtual in which kubernetes is installed.
A node is a worker machine that is where containers will be lounched by Kubernetes,also known in the past as "Minions".

Cluster: A cluster is a set of nodes grouped together. This way even if one node fails,
you have your application still accessible from the other nodes. Moreover, having multiple nodes helps in sharing the load as well.

Master: The mster is another node with Kubernetes installed on it and is configured as a master. The master watches over the nodes in the cluster
and is responsible for the actual orchestration of containers on the worker nodes.
When you install Kubernetes on a system, you actually installing these components:

• Api Server,
• ETCD Service,
• Kubelet Service,
• Container Runtime,
• Controllers,
• Schedulers.

The API Server acts as a frontend for the Kubernetes. The users, management-devices, command=line interfaces all talk to the AIP Server to interact eith the
Kubernetes cluster,

ETCD is a distributed reliable Key-Value store used by Kubernetes to store all data used to manage the cluster.
Think of it in this way: When you have multiple nodes and multiple masters in you cluster, ETCD stores all that information on all the nodes in the cluster in a distributed manner.
ETCD is responsible for implementing logs within the cluster to ensure that there are no confilcs between masters.

Scheduler: The Scheduler is responsible for distributing work on containers across multiple nodes. It looks for newly created containers and assigns them to nodes.

Controllers: The controllers are the brain behind orchestration. They are responsible for noticing and responding when nodes, containers or endpoints goes down.
The controllers make decisions to bring up new containers in such cases.

The Container Runtime: is the underlying software that is used to run the containers, in our case it happens to be Docker.

Kubelet: Is the agent that runs on each node in the cluster, the agent is responsible for making sure that the containers are running on the nodes as expected.

Master vs. Worker Nodes
The worker node or Minion as in known is where the containers are hosted. For example, Docker containers.
To run containers on a system we need container rundime installed. This is where the container runtime is needed.
There are also other container runtime alternatives available such as "RKT" or "CRI-O".
The master server has the Kubernetes Api Server and that is what makes it Master. The worker nodes have the Kubelet agent that is responsible for interacting with the master to provide health information for the worker node and carry out actions requested by the master on the worker nodes. All the informaton gathered are stored in the key-value store on the master. The key-value store is based in the popular etcd framework. The master has also the scheduler and the controll manager.

Kubectl: Kube command-line tool or Kube Controll as it is also called, is a tool used to deploy and manage applications on Kubernetes cluster.
To get cluster information, to get the status of other nodes in the cluster and to manage other things. The Kubectl run command is used to deploy an appication on the cluster.

[kubectl cluster-info] is used to view the information abut the cluster.

[kubectl get nodes] is used to list the nodes part of the cluster.

Recap PODs

Before going to understand pods, we would lie to assume that the following hasks have been set up alreday. At this point we assume that the application is alreday developed and buid into docker images and its available on docker reposiory like DckerHub, so Kubernetes can pull down the image. Our aim is to deploy our application in the form of containers on a set of machines, that are configured as worker nodes in a cluster. However Kuberenetes does not deploy containers directly on the worker nodes. The containers are encapsulated into a Kobernetes object known as POD.
A Pod is a single instance of your application. A Pod is the smallest object you can create in Kubernetes. If the nuber of users accessing your application increases and you need to scale up your application, you need to add aditional instances of your application to share the load. We create new pods altogether with new instance of the same applicaton.
Pod-s usually have one-to-one relationship with the containers running your application. To scale up you create new pods and to scale down you delete existing Pod-s.
You don't add aditional containers to an existing pod to scale your application. A single Pod can have multiple containers except for the fact they are usually not multiple containers ofthe same kind. If our intention is to scale up the application, then we need to create aditional Pods, but sometimes you might have a scenario when you have a helper container
that might be adding some kind of supporting task for our web application such as processing user data, processing a file uploaded by the user ect, and you want
these helper containers to live alongside your application container.
In that case you have both of these containers part of the same Pod. So when the new application is created the helper is also created and when it dies, the helper also dies
since they are part of the same Pod. The two containers can also communicate with each other directly by referring to each other as localhost since they share the
same network space. Plus they can easily share the same storage space as well.

How to deploy POD-s ?

[ Kubectl run nginx ] -> It Deploys a docker container by reating a pod.

First deploys a pod automatically and then deploys an instance of Nginx instance image.

[ Kubectl run nginx --image nginx ]

[ Kubectl get pods ] -> helps us see the list of the pods in our cluster.

Recap PODs with Yaml

Creating a POD using a YAML based configuration file
Kubernetes uses TAML files as input for the creation of the objects such as PODs, Replicas, Deployments, Services, ect.
All of these follow similar structure, a Kubernetes definition file always contains four top level fields:

Example : pod-definition.yml

apiVersion:
kind:
metadata:
spec:

These are the root level properties, these are also required fields, so you must have them in the configuration file.
apiVersion: -> This is the version of the Kuberenetes API we are using to create the object.
Depending on what we want to create we must use th right API Version. Since we are working with PODS we will set the api version to v1. [apiVersion: v1]
Other properties are:

kind: The kind refers to the type of object we are trying to create, which in this case happens to be a pod. So kind will be set it as pod [ kind:pod ]
Some other possible values should be Service, ReplicaSet, Deployment.

metadata: The metadata is about the object, like its name, labels and ect,

Example:

metadata:
 name:myapp-pod
  labels:
     app:myapp

Everything under metadata is intended to the right a little bit, so name and labels are childern of metadata.
The number of spaces before the two properties "name" and "labels" doesn't matter but they should be the same since they are siblings.
Its important to note that under metadata you can only specify name or labels or anything else that Kubernetes expects to be under metadata.
You cannot add any other properties as you wish under this.

labels:
  app:myapp
  type:front-end

The last section in the configuration file is the specification section which is written as "spec".
Depending on the object we are going to create, this is where we would provide aditional information to kubernetes programming that object.
This is going to be different for different objects. So its important to understand or refer to the documentation section to get the right format for each.
Spec is a dictionary so we can add a property under called containers.

Example:

spec:
  containers:
    -name:nginx-container
     image: nginx

Containers is a list or an array, the reason this property is a list is because thepods can have multiple containers within them.
The "-" right before the name indicates that this is the first item in the list.
Once the file is created run the command : [ kubectl create -f pod-definition.yml ] this command creates the POD.

To get a list of available pods you can run: [ kubectl get pods ]
To see the detailed information about the POD run the command: [ kubectl describe pod myapp-pod ]
This will tell you information about the POD, when it was created, what labels are assgned to it, what docker containers are part of it and events associated
with that POD.