This blog talks about the basic knowledge of Kubernetes Pods. But before exploring Kubernetes Pods, let us first go through what a Docker container is as it is the major container technology that we use to run our applications.
Docker is an open platform that allows you to package and run applications in a loosely isolated environment called a container.
A Docker container is a runnable instance of a Docker image and a Docker read-only template for creating a Docker container.
In other words, we need to construct a Docker image before running a Docker container.
Take the service
foo as an example, here is the Docker file for creating its Docker images:
From the file, you can see a minimal Docker file can be as simple as only containing the following directives:
- FROM directive specifies alpine:3.5, which essentially is a mini Linux system, as its parent container.
- RUN apk update… updates container’s dependencies.
- COPY command copies an executable binary file that contains all the business logic of the sre-reporting service from ./go-server to /user/bin/server.
- ENTRYPOINT tells Docker to executes /user/bin/server as this container’s entry point.
With this Docker file, our continuous integration (CI) tool is able to build and push a new image to
foo service's Docker image warehouse
every time when there is a new change in
foo service’s repo. Then with this Docker image, we can run and deploy the service
foo as a containerized application in Kubernetes.
A Pod is the smallest deployable unit in Kubernetes. It consists of one or more containers. These containers have their own CPU and memory resources but need to share other resources, including storage and network. As shown in the following picture, a Pod is very similar to an application-specific "host" running one or more "processes" (containers). These "processes" work together to construct a containerized workload or service.c
Use of Pods
The following example demonstrates how to use a K8s Pod to construct a single-replica microservice.
This Pod consists of three containers: the container
user-usvc has all the microservice's business logic, the container
cloudsql-proxy proxies all the MySQL requests to a Google Cloud SQL instance,
while the container
datadog-agent sends the logs to datadog server.
The following picture shows the topology of the Pod
user-msvc in Kubernetes.
From the above Pod configuration, we can see that:
user-msvcare created for storing configurations and sensitive data.
spec.containersdefines all the containers of the Pod. For each container, you need to configure which image it is going to run, all the environmental variables and computing resources it needs, including storage, CPU, memory, and network.
spec.volumesspecifies the shared storage resources for all the containers of the Pod. Kubernetes supports many types of Volumes. you can check this doc for more details about Kubernetes Volumes.
In this example, an emptyDir volume is created when the Pod is created.
The volume is respectively mounted to the path
/var/log/monitor in the container
Both containers share the data in this Volume. Because of this, the container
user-msvc can create a file called
and writes logs to this file, while the container
datadog-agent can read the logs from the file
/var/log/monitor/user-msvc-error.log and then sends them to datadog.
user-msvc is also used as Volume in this example.
Then it is mounted in the path
/etc/user-msvc/secret in the container
user-msvc and the path
/etc/datadog-agent/secret in the container
When a Secret is mounted into a directory in a container, each of its data will be created as an individual file in that directory. Moreover, a Secret Volume should be read only.
A ConfigMap can be directly used in a Pod's environmental variables or can be used as a Volume as well.
- Containers within the same Pod share the network, which means these containers reach each other through 127.0.0.1. However, a port can only be exclusively occupied by a container.
In this case, the container
cloudsql-proxy exposes itself by opening the port
3306. Therefore, the container
user-msvc is able to connect to it through
Moreover, the container
user-msvc opens the
443 port for processing incoming requests from the container
user-msvc Kubernetes LoadBalancer Service.
All in all, this example demonstrates that a Pod is like an application-specific “host“ that coordinates one or more “processes“ (containers) to work together to provide some kind of service.
What is Next
It is not a good idea to directly utilize K8s Pods to run applications as Pods are mortal. They cannot be resurrected when they are killed for whatever reason. Because of this, you should use K8s Deployments to run stateless applications and K8s StatefulSets to run stateful applications.
Check this blog if you are curious about how to utilize K8s Deployments to run stateless applications.
Check this blog if you are curious about ho to utilize K8s StatefulSets to run stateful applications.