Autonomous pod objects bound by the scheduler to the target node after the work is responsible for kubelet on the corresponding node monitoring viability of its container, the container main process crashes, kubelet can automatically restart the appropriate container. However, kubelet container error classes of non-core process crashes but no perception, depending on the user-pod viability resource object from detection mechanisms defined in order to be able to ascertain kubelet to such failures. However, when the pod was accidentally delete an object, or work node itself fails, how to deal with it.
When kubelet k8s cluster node agents that are running on one instance of each working node. Thus, a cluster of a few work when a failure occurs, it kubelet will also no longer available, so the health status pod resources on the node can not be guaranteed, it can not restart by the kubelet. pod viability of such scenarios are generally guaranteed by the pod controller node outside of work. In fact, resource recovery pod encountered accidentally deleted also depends on its controller.
provided by the pod controller kube-controller-manager master of the assembly, the common controller has this category ReplicationController, ReplicaSet, Deployment, DaemonSet, StatefulSet, Job ConJob and the like, which are managed in different ways pod resource objects.
A, pod Controller Overview
The components of the master, apiserver responsible only for resources stored in etcd, and the changes in its notification to the relevant client program, such as kubelet, kube-scheduler, kube-porxy and kube-controller-manager, etc., kube-scheduler then start to monitor the scheduler in its selection process node adaptation of the object when the pod is not bound state appears, however, one of the core functions of k8s is also to make sure that the current status of the resource object to match the user's desired state, the current state of the container continue to complete application management to the desired state of reconciliation, which is kube-controller-manager task. kube-controller-manager is an independent single daemon, but it contains many features different types of controllers are used to all kinds of reconciliation tasks.
Once you have created for the specific controller object Each controller via the current interface continually monitor resource object apiserver provided and when due to malfunction, update or other causes change in system status, try to get the current status of the resource migration and approximation to the desired state. In simple terms, each controller object is responsible for running a state reconciliation settlement cycle, the current state of the object and the target resource is written to its status field.
One of the key mechanisms for List-Watch when k8s implemented in the state of the resource objects are changed by api server is responsible for writing and by etcd level trigger mechanism to inform the relevant client program to ensure they do not miss any event . Controller api server interface to watch real-time monitoring of changes in the target resource objects and perform reconciliation operations, but does not interact with any other controller, or even simply unaware of each other's existence with each other.
A workload controller class resource types ReplicationController, ReplicaSet, Deployment, DaemonSet, Job ConJob and the like, which represent one type of pod controller resources.
Second, the object controller pod
pod by pod controller resources resource object continuing to monitor the cluster running to ensure that the resources under its control in strict conformity with the user's desired state, such as the number of copies to be precise resources in line with expectations and so on. A resource controller pod generally should contain at least three basic components.
Tag selector: Match pod and associated resource object, and completed based on this subject to the control pod resource counts
The desired number of copies: Expected number of objects precisely running in a cluster pod resources
pod template: template resource for new pod pod resource object.
Three, pod template resource
PodTemplate is k8s api common resource type, commonly used in specifying the required configuration information automatically create pod resource object for the controller. To use as embedded in the controller, the configuration information pod template does not require apiVersion field and kind, but other content in addition to the custom autonomous pod supported by the object field are almost identical, including metadata and spec and various other fields embedded. spec field pod controller class resources usually have built replicas, selector and template fields, which is the definition of template pod template. as follows:
apiVersion: apps/v1 kind: ReplicaSet matadata: name: rs-example spec: replicas: 2 selector: matchLabels: app: rs-demo template: matadata: labels: app: rs-demo spec: containers: - name: myapp image: ikubernetes/myapp:v1 ports: - name: http containerPort: 80