1. Main K8s Components

Smallest unit of K8s
Abstraction over container
Usually 1 application per Pod
Each Pod gets its own IP address
New IP address on re-creation
- E.g, DB dies and new DB is created which will get new IP address

Permanant IP address
- Can be attached to each pod
Lifecycle of Pod and Service are not connected
- If Pod dies then service and its ip remains

Solves the problem of having static ip, port and protocol assigned to external services
Assigns a domain name and certificate to requests
Acts as a reverse proxy

Problem :-

Suppose DB url was configured inside my-app and its image was built and pushed to dockerhub
Now, the DB url gets changed and image must be modified, rebuilt and pushed to dockerhub then pulled into pod and restart

Solution :-

Thats where ConfigMap comes in, we can store such external configuration of our app and attach it to the pod.

Works to solve similar problem as ConfigMap
ConfigMap stores configuration in plain text format so it should not be used to store secrets such as username, passwords, etc.
Secret should be used instead
Things are stored in base64 encoded format
Built in security mechanism is not enabled by default

Used for data storage, same concept as docker since k8s does not manage data persistance
Storage can be on local machine or remote storage outside of k8s cluster

Solves the problem of single point of failure
- In case Pod dies
We replication everything on another node for fault tolerance or load balancer
Replica is connected to same service
We don't create another pod but define blueprint for pods
It is an abstraction layer on top of pods.
In practice deployment is used instead of pods.
DBs can't be replicated via deployment
- Because database has a state
- To avoid data inconsistencies
Should be used for StateLess apps

Last updated 1 year ago