Kubernetes Pod(s) continued
- Pod life cycle
- Pod-Phases Refer Here
- Container states in a Pod Refer Here
- Container restart policy: Refer Here
- When a request for a Pod creation arrives to api server it stores the details in etcd and informs scheduler to schedule the pod on a node by identifying suitable node and informs the kubelet,kubelet with the help of container runtime creates contianer in the pod. Each pod gets an ip address with the help of CNI plugin.
- CNI Plugin is responsible for low level networking to Pod.

Choosing CNI Plugin
- Calico:
- Network policy: supported
- Used for large clusters
- Flannel
- Network policy: unsupported
- For dev, test environments,
- Weavenet
- Network policy: supported
- Simple and seamless networking, suitable for small clusters
- Cilium
- Network policy: supported
- using eBPF networking standard which implements the network observability. Generally used for large enterprise applications
- AWS VPC-CNI:
- This CNI implemented by AWS to create Pods in Elastic Kubernetes Service which are VPC functionality aware.
- Azure CNI
- This CNI implemented by AWS to create Pods in Azure Kubernetes Service which are VNet functionality aware.
Container types in Pod
- Inside Pods we can create the following types of contianers
- init container
- container: these are main contianer which run the application
- ephemeralContainers
- sidecarContainers
Trail 5:
- Create a k8s pod manifest with following
- init container: create an alpine container with sleep 30s
- container: run nginx or httpd
- Apply the manifest Refer Here for the spec
- Watch the pods
kubectl get pods -o wide -w

-
Lets add two more init continers with sleep 10s and add one more container in containers Refer Here
- Init contianers execution happens first in a specific order and contianers are created parallely
- Exercise:
- try to fail init 2 by cmd
exit 1i.e. error code observe the behavior
- try to fail init 2 by cmd
-
Purpose of init containers: To configure any preconditions for running your applications in contianers
- changing configuration values
- data correctness check
- migrate data (orm to db data creation)
-
Controller Objects: they ensure pods are running which include
- Replica sets
- Replication Controller
- Daemonsets
- Deployments
Labels
- k8s stores the data of objects in etcd and it fetches the data of related objects with the help of labels
- Label in k8s is a key value used to group objects logically
- Refer Here for official docs
- Watch classroom video for label practice
- labels can be selected/queried by two types of queries
- equality operators: Refer Here equals (=) and not equals (!=)
- set based operators Refer Here
- in
- not in
- trail 6: Create a pod manifest with the following labels
- env = dev
- app = nginx
- version = 1.0
- Refer Here for the manifest
Replica Set
- Refer Here for official docs

Trail 1
- Create 3 nginx pods in a replica set Refer Here for manifest
---
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: trail1-rs
labels:
name: trail1
spec:
minReadySeconds: 10
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
env: dev
version: "1.0"
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
cpu: 500m
memory: 256Mi

trail 2
- create 3 pods manually with label app=nginx and then create the rs from trail1
- replicaset will not create a new pod as long as manual pods created above are running as the desired is already met
Exercise
- create a replicaset with pod spec running alpine container without any args
Replication Controller (RC)
- Replicaset is the replacement for Replication Controller.
- RC can perform only equavality based label selections on Pods where as RS supports set based criteria
- RS supports rolling updates which is used in Deployments, (RS is used by Higher objects such as Deployments and Daemonsets supporting zero downtime deployments)
Trail3
-
Create a manifest for ReplicationController with 3 nginx pods with label
app=nginx -
To be discussed
