Pod Kubernetes scheduling is a minimum unit. A Pod may comprise one or more containers, it can be seen as a logical host interior of the container. Pod design to support multiple containers and shared network file system in a Pod is therefore in a plurality of containers in a Pod share the following resources:
PID namespace: Pod in different applications can see the processes of other applications ID.
network namespace: Pod plurality of containers in a network are in the same namespace, it is possible to access the IP and port ranges are the same. You can also access each other via localhost.
IPC namespaces: a plurality of containers Pod shared namespace Inner-process Communication, inter-process communication can be performed by SystemV IPC or POSIX.
UTS namespace: Pod in multiple containers share the same host name.Volumes: Pod in each container may define points shared storage volume (Volume) in the Pod.
Pod, the relationship between the container and the Node (working host) as shown below:
1. Pod definition
By yaml json file or description and its contents Pod's operating environment and a desired state, for example, a simple application running nginx POD, defined as follows:
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
In a production environment, it is recommended to create a Deployment, StatefulSet, Job or CronJob and other controllers, such as Pod, rather than directly created.
Save the file as described above pod nginx-pod.yaml, kubectl apply command to run using the pod
kubectl apply -f nginx-pod.yamlThe following brief analysis Pod at the above definition files:
- apiVersion: Which version of Kubernetes API created using this object
- kind: the type of object to be created, such as Pod, Deployment, etc.
- metadata: metadata used to uniquely identify the object, comprising: name, UID and namespace
- labels: one is a key / value pair is defined such label after Pod, other objects may be positioned by the controller such Pod this label, thereby Pod management. (See Deployment controller object, etc.)
spec: Other description information, comprising a container Pod running, etc. applications running in the container. Objects of different types have different spec definition. For details, see the API documentation: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.9/
Pod Kubernetes at each startup, automatically creates an image of
gcr.io/google_containers/pause:versionthe container, all containers in the Pod in such --net = container will be added at the start: pause --ipc = contianer: pause --pid = container: pause start-up parameters, so pause a source of shared namespace container in Pod. All containers container pause shared IP address, also called Pod IP.
If we want to access these applications from external nginx, then we also need to create Service objects to expose the IP and port.
2. Pod life cycle
Pod Replication Controller life cycle is managed. Pod of a life cycle, including:
Pod be described by yaml or json
After apiserver (running in the host Master) receives a request to create the Pod, this definition is stored in the object etcd the Pod
scheduler (running on the host Master) assigned to this Node running Pod
After all the containers within the Pod this operation also ends Pod
Throughout the process, Pod usually in one of the following five stages:
Pending: Pod defined correctly, submit to the Master, but it contains a mirror container has not been fully created. Typically, Master of Pod takes some time scheduling, the Node download image container also takes some time, the vessel also requires a certain time to start. (ETCD to write data, scheduling, image pull, starting container).
Running: Pod has been assigned to a Node, and all containers are created, there is at least one vessel is in operation, or containers being started or restarted in.
Succeeded: Pod in all containers run successfully ended and will not be restarted. This is a final state Pod
Failed: Pod all containers in the end of the run, at least one container which is non-normal end (exit code is not 0). This is also the Pod a final state.
Unknown: Pod status is not available, usually not due Node Pod and located to communicate.
2.1 Restart policy
Defining Pod, you can specify restartPolicy field, indicating Pod will restart in the container under what conditions. restartPolicy has three candidate values:
Always: as long as the exit to restart
OnFailure: failure exit (exit code is not zero) before restart
Never: Never restart
2.2 management controller by Pod
Pod itself does not have fault tolerance, which means that if running Pod Node is down, then the Pod can not be recovered. It is recommended to use Deployment and other controllers to create and manage Pod.
In general, Pod will not go away, only manually destroy or be destroyed predefined controller. But there is a special case, when the Pod in Succeeded or Failed stage, and after more than a certain time (determined by the master), triggers the timeout expires in order to be destroyed.
Overall, Kubernetes owns three types of controller:
Job. Commonly used to manage will be the end of the Pod. If you want to manage Pod is Job controller, then restartPolicy must be specified as OnFailure or Never.
ReplicationController, ReplicaSet and Deployment. Pod for management always in the running state. If you want to manage Pod is such a controller, you must specify restartPolicy Always.
DaemonSet. It can ensure that your Pod run a copy of each Node.