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:
https://gist.github.com/1bed3af9bc835ad5867585fce8f61db6
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
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.
https://gist.github.com/df1a624ab23d508640ee66e3239bb904
The following picture shows the topology of the Pod user-msvc in Kubernetes.
From the above Pod configuration, we can see that:
-
The ConfigMap
user-msvcand Secretuser-msvcare created for storing configurations and sensitive data. -
The field
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. -
The field
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 and /var/log/monitor in the container user-msvc and monitor.
Both containers share the data in this Volume. Because of this, the container user-msvc can create a file called /var/log/user-msvc-error.log
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.
The Secret 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 datadog-agent.
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 127.0.0.1:3306.
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.
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.