Class 3 - Deploying app on Kubernetes Cluster Flashcards
What is a pod?
- A pod is a basic building block of Kubernetes
- It is very easy to horizontally scale a Pod
- A pod represents a unit of deployment in Kubernetes cluster
- A pod encapsulates single or multiple containers along with storage and unique network IP.
Relation between pod and containers
A pod can be consumed in two ways
1) Single Container per Pod
2) Multiple containers per Pod
Single container pod
One container per Pod
Widely used when a container runs on physical machine on top of an operating system.
Unique network IP from pod network CIDR
Storage volume for persistent data
NOTE
One should not run individual pods for multiple instances of same application
Most used design patterns for Multi container pod
1) Side car pattern
2) Adapter pattern
3) Ambassador pattern
Describe Side car pattern and when to use it
Side car pattern is used when there is reader and writer relationship between containers. When one container writes and other container reads.
In sidecar pattern there are two or more containers, there will be writer containers and reader container.
Multi Container Pod
When multiple containers live inside same pod. This is not a good design in general. Like keeping application server and web server in a single pod.
Multiple containers share the same IP and share the same volume.
As all the containers will have same IP address, so multiple instances of application will not be able to run on same port in case of Multiple container pod.
Adapter container pattern (Similar to OOP adapter pattern)
We have a Formatter container. Formatter is going to format the output produced by any of container.
When you have FluentDB or Splunk container as part of a single pod. FluentDB or Splunk will take logs from web server or other containers and format in the configurable way.
Ambassador container pattern
We have a proxy service, which is the only point of entry to the application. The proxy acts as API gateway to the web application.
So all the requests will land on proxy and will be forwarded to actual application.
Need for pod
1) Containers can work well alone but when scaled up, it becomes difficult to apply patches to them their management becomes cumbersome.
2) Secondly orchestrator is required to help in scaling out or scaling in
3) This orchestration is provided by Kubernetes by using Pod abstraction
4) Pods are building blocks of Kubernetes
5) Each pod manages single or multiple containers depending upon the application workload.
6) Through pod, one can manage multiple containers as one entity.
What features do pods provide?
1) Self healing - restart pod if it crashes. Restart policies are there.
2) Auto scaling - scale on basis of certain metrics like CPU, disk
3) Load balancing using services - single endpoint for set of pods
4) Rolling update/rollback - zero downtime application upgrade
5) Resource monitoring and logging - Prometheus can be used for monitoring. Kubernetes does not come with inbuilt monitoring capabilities.
Pod Lifecycle phases
Pending - Goes to this state when it is first created. Pod is waiting for a node to be assigned to it. It reflects the time spent in downloading the container images and creating them. It also means that system has accepted the Pod.
Pending status time = (Scheduling time) + (Download and start container)
Running - Pod is tied up with the node, and atleast one of the container is running.
Succeeded - A container’s termination in Kubernetes was successful. “It will not be restarted.” Some pods that are small batch jobs that start and complete after doing their job and don’t need to be run continuously go into this state.
As opposed to webserver or database server that run in daemon mode and run continuously.
Failed - When one or more container’s termination is unsuccessful. Termination due to failure is either because of non-zero exit status of container. Any failure that happens as part of container means that exit status is not zero. Then the pod goes in Failed state.
Unknown - When there is communication problem of a container with the host machine, status of the container cannot be obtained. Since there is no status update, Kubernetes system marks it as “Unknown”
For such errors channels should be checked first.
Unknown state does not mean that pod is not running. It may be running and serving requests but the master is not able to get the current status of the pod due to underlying networking issue or similar. It takes time to troubleshoot this status.
NOTE : Pod does not have to go through all the above phases.
Do containers have private IPs inside pod?
No, container networking is disabled when we install CNI (Container networking interface by CNCF).
The only IP they will have is the one of the pod.
What can be said about Succeeded state and restart in Kubernetes?
By default policy, restart is set as true for all pods as a part of self healing policy.
If pod fails then Kubernetes will try to restart that pod. But if the pod goes in Succeeded state then it will not be restarted.
If we kill the container inside pod, which state will it go to?
When we kill the app the exit status will be > 0, so it will go to the FAILED state.
Which are the bare minimum fields required while creating a pod?
1) apiVersion
2) kind - Pod, Deployment etc
3) metadata
4) spec
Give example of a bare minimum pod yaml file
apiVersion: v1
kind: pod
metadata:
name: mypod
labels:
version: v1
app: webserver
spec:
containers:
- images: nginx:latest
name: myfirstcontainerHow to view detailed events for pod?
kubectl describe pod
will show detail about all the events and status. Like image information, events etc.
How to get pods information in yaml format?
kubectl get pods -o yaml
How to get logs of pods?
kubectl logs
How to preserve the data that is part of pod that will vanish if the pod dies?
We need to mount the volume from the pod to the host machine location. So we need to identify the location from pod that we need to preserve and mount it to physical location on host machine.
How many types of volumes does Kubernetes support?
1) hostPath - this path is located at the host at which pod is running. location on physical VM where to mount the data.
2) emptyDir - Ephemeral. It is present till the lifecycle of pod. Once pod is deleted, the emptyDir will go away
3) configMap
4) GlusterFS
5) ….
Sample hostPath volume mapping yaml
spec:
containers:
- name: mysql
image: mysql
volumeMounts:
- path: /var/lib/mysql
name: mysqlvol
volumes:
hostPath:
path: /data
type: DirectoryOrCreate
name: mysqlvol
Volume mapping is two part
1) VolumeMount - where we provide location inside the container/ pod
2) Volumes - where we provide location of physical VM.
To map volumeMount and Volumes we need to provide the same name for volumeMount and volume
