- Assumption that the application has already been built into a
docker image.
- The image is available in a repository such as
docker hub.
- The Kubernetes Cluster is also assumed to be setup and working.
- All the services need to be in a running state.
- The ultimate aim is to deploy an application across a set of machines, configured as Worker Nodes in the cluster.

- The container is not deployed directly on the Worker Nodes.
- The containers are encapsulated into a Kubernetes Object as pods.
- A pod is a single instance of an application.
- A pod is the smallest object you can create in Kubernetes.
- Example of a single Node running one application in a single container:

- As the number of users increases, you need to scale your application to share the load.

- Where would we bring up additional instances.
- For example, bringing up a container within the same pod?
- No, we create a separate pod with a new instance of the application.

- What if the user base increases further and the node has no sufficient capacity.
- Can deploy additional pods on a new node in the cluster.

- Pods have a 1:1 relationship with containers on the same application.
- To scale up, you create new pods and to scale down, you delete existing pods.
- Don’t add additional containers to an existing pod to scale the application.
- Regarding multi-container pods.
- We are not restricted to having 1 container in 1 pod.
- A single pod can have multiple containers, just not of the same kind.
- There are containers such as
Helper Containers - for example performing a supporting task for the web application.

- When scaling the application, the helper container comes with it.
- When the application container dies, the helper container also dies, due to them both being part of the same pod.
- Each container can communicate to each other directly, by referring to one another as localhost.
- They can easily share the same network and storage space.

- Focusing on
docker containers, for example we try to deploy our application on a docker host.
- We deploy the application using a
docker run python-app command.
- The users can access the
python-app without issue.
- When the load increases, more instances of the application are loaded.
- A helper container comes in to process and fetch data from elsewhere.
- 1 helper container is required per application.
- We need to maintain a map of which app and helper container is connected to each other.
- Need to establish network connectivity between the containers, using links and custom networks.
- Need to create shareable volumes and distribute these among the containers
- Need to monitor the state of the application container and kill the helper container when the application container dies as well.
- For a new container, a helper container would need to be deployed as well.

- With pods, Kubernetes does all of the above automatically.
- We define what containers are included in X pod.
- The containers in the pod will by default have access to the same storage, same network and same namespace.
- These are created together and destroyed together.
- Pods allow for architectural changes and scaling in the near future.
- Multi-container pods are rare to see in the wild.
- The course will stick to single containers per pod.
- What does
kubectl do? It deploys a docker container by creating a pod.
- In the below example, Kubernetes deploys the
nginx application image.
- Using
kubectl, you usually have to specify the image name.
- Where does
kubectl get the image from? Use the --image flag.

- Docker Hub keeps of the latest images for images.
- Kubernetes can pull for a very bad situation.
- How do we see the list of pods available -
kubectl command.
get pods output:

- Haven’t talked about the concepts how a user can access the nginx web server. In this instance, the server has not been made available to exensive users.
