kubernetes the initial container (init container)

Series catalog

Understand the initial container

A pod where you can run multiple containers, it can run one or more of the initial container, the container before running the initial application container, except for the following two points, the initial container and container general is no different:

They alwaysrun to completion
The initial success of a vessel must run to another run

If an initial run pod in the container fails, kubernetes will try to restart the pod container until initial run successfully, if pod restart policy is set 从不(never), it will not restart.

When the container is created, added podspec in initContainersthe field, that is, the initial container vessel is designated, their return stored as an array in a state .status.initContainerStatuseswhere (ordinary container status storage field .status.containerStatusessimilar)

Different initial container and ordinary containers:

Wherein the initial container supports all common container, comprising resource quota and security settings, and the storage volume, but the resource request and an initial restriction processing vessel is slightly different and will be described. Furthermore, the initial container does not support the availability of the probe (readiness probe) because it readymust be beforerun to completion

If you specify more than one initial container in a pod where they will 依次start up (the pod ordinary container started in parallel), and only on a successful start to the next. When all of the initial container has already started, kubernetes began to start general application container.

What do the initial container

Since the initial container and the container is separate from the general application of a mirror, so he's doing some initialization great advantage:

They can contain and run some gadgets for security reasons and is not suitable for use on a piece of.
They may be some small tools and custom code to do some initialization work, so you do not need to use common application container sed, awk, pythonor digto do the initial work of the
Application builders and publishers can work independently, without having to deal with a pod together
They use linux namespacesso they and the general application pod has a different view of the file system, so they can be given to common applications get less than containersecrets
They start running before the application container, so they can prevent or delay the general application container initialization until the conditions required to meet

Example:

By executing shell command to wait for a service created with the following commands:

for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1

By downward APIthe current pod registered to a remote server, the command is as follows:

curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'

Wait a certain time before the start of the container: for example,sleep 60
Clone a git repository to store directory
Dynamic some value is written to the configuration file via the main application's template tool.

More detailed examples, please see the application environment pod arranged Guide

The initial use of the container

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: busybox
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

Defined above containing two initial pod containers, a first waiting myserviceservice is available, waiting for a second mydbservice is available, the two pod execution is completed, the container application begins execution.

The following is a myserviceand mydbtwo service yaml file

kind: Service
apiVersion: v1
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
---
kind: Service
apiVersion: v1
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377

Defined above can pod and debugging by using the following initialization

kubectl create -f myapp.yaml
pod/myapp-pod created

kubectl get -f myapp.yaml

NAME        READY     STATUS     RESTARTS   AGE
myapp-pod   0/1       Init:0/2   0          6m

Name:          myapp-pod
Namespace:     default
[...]
Labels:        app=myapp
Status:        Pending
[...]
Init Containers:
  init-myservice:
[...]
    State:         Running
[...]
  init-mydb:
[...]
    State:         Waiting
      Reason:      PodInitializing
    Ready:         False
[...]
Containers:
  myapp-container:
[...]
    State:         Waiting
      Reason:      PodInitializing
    Ready:         False
[...]
Events:
  FirstSeen    LastSeen    Count    From                      SubObjectPath                           Type          Reason        Message
  ---------    --------    -----    ----                      -------------                           --------      ------        -------
  16s          16s         1        {default-scheduler }                                              Normal        Scheduled     Successfully assigned myapp-pod to 172.17.4.201
  16s          16s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulling       pulling image "busybox"
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulled        Successfully pulled image "busybox"
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Created       Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Started       Started container with docker id 5ced34a04634

kubectl logs myapp-pod -c init-myservice # Inspect the first init container
kubectl logs myapp-pod -c init-mydb      # Inspect the second init container

When we start mydband myserviceafter two services, we can see the completion of the initial container and myapp-podpod is created.

kubectl create -f services.yaml

service/myservice created
service/mydb created

kubectl get -f myapp.yaml
NAME        READY     STATUS    RESTARTS   AGE
myapp-pod   1/1       Running   0          9m

These examples are very simple but should be able to provide some inspiration for you to create your own original container

Behavioral details

During the launch pod in, after the storage volume and network creation, original container in order to create. A container must return the next success a to start, if for runtime errors or other abnormal exit, it will follow the restartPolicyretry, however, If restartPolicyset to Alwaysan initial container actually use OnFailurestrategy
If the pod restart, and then all of the original container to be re-run
Initial container specchanges only 镜像(image)restart pod modified field image field, corresponding to change the initial container
Since the initial container can be restarted, and re-executing the retry, so that there should be a power code or the like, in particular, to write the file EmptyDirscode to be noted that the file may already exist
All initial container vessels and ordinary container name must be unique.

Resources

Based on the order of execution of the initial vessel, the following rules apply with respect to resources:

For a particular resource, the highest initial entry into force of all container applications
For the pod, the same resource request to take a higher following two:

1) the sum of all common resources application container application
2) of the container resource initial application force (the above said, an initial resource request to take the container all the initial application of the largest container)
Scheduling based on the initial request to take effect, which means that the initial container can apply to reserve resources, even if the entire life cycle after the pod are less than

pod restart reason

A pod reasons listed below, will restart, re-run the initial container:

Updating the initial user of the container PodSpecresults in a change in the mirror. Common application container change will only restart the application container
Since restartPolicybeing set Always, cause all containers are suspended force restart, since the initial state of the garbage container initial loss of records