In order to solve the problem of joint operation of such multiple applications without breaking the isolation of the container, it is necessary to build a "storage compartment" outside the container, so that multiple containers can remain relatively independent and share the network, storage, etc. in a small range. Resources, and are always in a state of "tied together".
The concept of Pod is about to come out. Containers are the little "peas" in "pods". You can see in the YAML of Pod that the "spec.containers" field is actually an array, which allows multiple containers to be defined .
Because Pod is a "package" of containers, the containers inside are a whole, they can always be scheduled and run together, and there will never be separation. Moreover, Pods belong to Kubernetes, and can be arbitrary without touching the underlying containers. Custom modifications. So with the abstract concept of Pod, Kubernetes will be "handy" in managing applications at the cluster level.
Kubernetes allows Pods to arrange and process containers, and then uses Pods as the smallest unit of application scheduling and deployment. Pods have thus become "atoms" in the Kubernetes world (of course, this "atom" has a structure inside and is not monolithic). Based on Pods, More and more complex business forms can be constructed.
All Kubernetes resources are directly or indirectly attached to Pods, and all Kubernetes functions must be implemented through Pods, so Pods naturally become the core object of Kubernetes.
When we use Docker to create a container, we don't need to name the container, but in Kubernetes, Pod must have a name, which is also a convention for all resource objects in Kubernetes.
"containers" is an array, and each element in it is a container object, that is, a container.
Like a Pod, a container object must have a name to indicate its name, and of course an image field to describe the image it uses. These two fields are required, otherwise Kubernetes will report a data validation error.
- ports: List the exposed ports of the container, similar to Docker's -p parameter.
- imagePullPolicy: Specifies the pulling policy of the image, which can be Always/Never/IfNotPresent. Generally, the default is IfNotPresent. That is to say, the image will be pulled remotely only if it does not exist locally, which can reduce network consumption.
- env: defines the environment variable of the Pod, which is somewhat similar to the ENV instruction in the Dockerfile, but it is specified at runtime and is more flexible and configurable.
- command: Define the command to be executed when the container starts, which is equivalent to the ENTRYPOINT instruction in the Dockerfile.
- args: It is the parameter when the command is running, which is equivalent to the CMD command in the Dockerfile. These two commands have different meanings from Docker, so special attention should be paid.
However, the command format of kubectl exec is slightly different from that of Docker. You need to add -- after the Pod to separate the kubectl command from the Shell command. You need to be careful when using it:
kubectl exec -it ngx-pod -- shPod shields some of the underlying details of the container, and at the same time has sufficient control and management capabilities. Compared with the "fine-grained" of the container and the "coarse-grained" of the virtual machine, the Pod can be said to be "medium-grained", flexible and lightweight, and is very suitable for As the basic unit of application scheduling in the field of cloud computing, it has become the "atom" of building all services in the Kubernetes world.
This article is a study note for Day 12 in July. The content comes from Geek Time "Kubernetes Introductory Practical Course". This course is recommended.