A kubernetes service is a group of pods running in a cluster.

ClusterIP is a service which is accessible only within the Kubernetes cluster. Hence, it is the internal IP of the components inside a Kubernetes cluster.

NodePort is an open port for every node in the cluster. This is accessible from outside the cluster.

LoadBalancer distributes the external request among the workers of the cluster.

Following commands are used to create 4 PODS using four Manifest files (pod1.yaml, pod2.yaml, pod3.yaml, pod4.yaml)

After the PODS are created, a CLUSTERIP service with the same label as the pods is created with port forwarding 80 to 5666.
With the cluster ip and port 5666, the application is hit.

After that, NodePort service is created with the same “label” as the PODs and port forwarding to 5667. When it is described, an external port 32350 is generated. The IP of the NodePort with the port 5667 or the IP of the worker (A.X.Y.Z) with the port 32350 is used to access the application.

After that, a Load Balancer is created with the same label as the pods and forwarded to port 5668.


1057 kubectl get pod | grep manu
1058 clear
1059 ls
1060 cp pod.yaml pod2.yaml
1061 cp pod.yaml pod3.yaml
1062 cp pod.yaml pod4.yaml
1063 cp pod.yaml pod1.yaml
1064 vi pod1.yaml
1065 vi pod3.yaml
1066 vi pod4.yaml
1067 clear
1068 kubectl apply -f pod1.yaml
1069 kubectl apply -f pod2.yaml
1070 vi pod2.yaml
1071 kubectl apply -f pod2.yaml
1072 vi pod2.yaml
1073 kubectl apply -f pod2.yaml
1074 vi pod3.yaml
1075 kubectl apply -f pod3.yaml
1076 vi pod4.yaml
1077 kubectl apply -f pod4.yaml
1078 kubectl get pod|grep manu
1079 kubectl get pod -o wide | grep manu
1080 clear
1081 kubectl get pod -o wide | grep manu
1082 ipconfig
1083 ifconfig
1084 clear
1085 kubectl create service clusterip manucs –tcp=5666:80
1086 kubectl get svc
1087 kubectl get svc|grep manu
1088 kubectl delete svc manunp
1089 kubectl get svc|grep manu
1090 curl http://10.109.100.213:5666
1091 kubectl edit svc manucs
1092 curl http://10.109.100.213:5666
1093 watch curl http://10.109.100.213:5666
1094 clear
1095 kubectl create service nodeport manunp –tcp=5667:80
1096 kubectl get svc manunp
1097 kubectl get svc | grep manu
1098 kubectl get svc|grep manu
1099 kubectl edit svc manunp
1100 curl http://10.109.229.155:5667
1101 watch cur; http://10.109.229.155:5667
1102 watch curl http://10.109.229.155:5667
1103 watch curl http://10.109.229.155:32350
1104 curl http://172.31.15.134:32350
1105 watch curl http://10.109.229.155:5666
1106 clear
1107 kubectl create service loadbalancer manulb –tcp=5668:80
1108 kubectl get svc|grep manu
1109* kubectl t svc manulb
1110 watch curl http://10.104.37.37:5668
1111 watch curl http://172.32.15.134
1112 watch curl http://172.32.15.134:5668
1113 watch curl http://172.32.15.134:32158
1114 watch curl http://10.104.37.37:5668
1115 watch curl http://172.31.15.134:32158
1116 clear
1117 history

Kubernetes runs the containers through pods only.
When scaling is required, the pod is replicated.
Pods are ephemeral and disposable – they cannot be reinstantiated after the lifecycle, a similar pod can be instantiated.

It has three components:

1. Kubelet
   Registers a node with its cluster
   It watches the AI server for changes in the definition of the application
   instantiates pods
   reports the health status of the pods to the master
   endpoint is 10255
2. Kube proxy
   Handles the networking for the Kubernetes
   All containers in a pod shares the same IP address
   Load balancing across all pods
   
3. Container engine
   This is where the container runs (container runtime environment like Docker engine)
   It does everything like pulling an image, starting a container, stopping etc
   

In the Master (representation above), there is a Control plane which has 4 components:

1. API Server
   Acts as the entry point to the control plane.
   It exposes a REST API which consumes JSON files that has the application definition and state defined.
   Master checks the JSON file and pass the task onto one of the nodes in the cluster.
2. Cluster store
   Stores the configuration and state of the cluster.
   Uses etcd (key value store) for storage
   Acts as a source of truth to the cluster
3. Controller Manager
   It controls the multiple controllers that are in the cluster – like Node controller, Namespace controller…
   Continuously watches the state of the system and updates the API server
   It ensures that current state of the cluster is equal to the desired state of the cluster
4. Scheduler
   Continuously watches out for pods that are unassigned and schedules them to different nodes in the cluster.
   Assigns work to these nodes.

2. Improves productivity through container orchestration and easy installation. hence makes it easy for managing deployment.

3. Faster and Simpler deployment of containerized applications. Hence provides consistency for different environments – QA, Dev, Staging etc – hence a better reliability.

4. Uses lesser system resources compared to VM and other infra envts

5. Application isolation separates the processes of each application into different containers

6. Portability – move the workload to different places

7. Immutability – encourages the development of distributed systems which follows immutable infra that is not affected by user modifications

8. Self monitoring – checks the health of nodes and containers constantly. Also, self-healing – able to restart containers when they are dead

9. Scalability – scale resources and applications realtime