1, common policy preselection
2, preferably the function
3, the node scheduling and affinity
3.1, node hard affinity
3.2, node soft affinity
4, Pod and scheduling resources affinity
4.1, Pod hard affinity
4.2, Pod soft affinity
4.3, Pod affinity anti
5, blemishes and tolerance
5.1, the definition of stains and tolerance
5.2 stain, management nodes
5.3, the object of tolerance Pod
After creation request submitted Pod API Server accepts a client object, and then select the best available by a node scheduler (kube-schedule) from the cluster to create and run Pod.
This creates a Pod objects, there are three phases in which the scheduling process: pre node, preferably the node, the selected node to select the best node.
Node pre: pre-selected based on a set of rules for each check node, the nodes that do not match the filter conditions, thereby completing the preselected nodes
Preferably nodes: node preselected prioritize, to select the most appropriate target operation node Pod
Selected nodes: pick the highest priority node from the priority ranking Pod operation result, when more than one such node, the random selection
When we want to have certain requirements Pod run on a specific resource node, we can match specific combination of pre-selected by the policy node label, and the label or tag selector Pod and scheduling is done, such as MatchInterPodAfinity, MatchNodeSelector, PodToleratesNodeTaints other preselected policies, which is commonly used to provide users Pod affinity or anti-affinity and affinity-based stains and node scheduling mechanism to customize tolerance.
Pod resource scheduling
1, common policy preselection
Node preselected strategy is actually a filter, such as a request amount of resource nodes must be able to match the label to the label selector resource Pod (MatchNodeSelector rules implemented), Pod and the container can not exceed the remaining node may allocate resources (PodFitsResource rules), etc. Wait. Perform preselected operations, the scheduler will go through filter according to the rules, if not pre-select an appropriate node could, at this time will remain in the Pending state Pod, until a node is available to complete the schedule.
2, preferably the function
Pre-screening strategy will enter a list of preferred node stage, the scheduler calculates the priority value is preferably a function of passing through a series of preselected nodes in the process to each, the priority scores of between 0-10 rooms, where NA represents 0, 10 represents the most suitable Pod managed object.
Further, the scheduler further supports to each preferably a simple function specifies a value indicating the weight, the priority score for the node is calculated, it first calculates the score of each preferred function is multiplied by a weight, then preferably all functions score added to get the final score of the priority nodes. Weight preferred function allows administrators the ability to define the tendency,
3, the node scheduling and affinity
Pod nodes are used to determine the affinity of an object to which a dispatch rule node These rules are based on custom label at the node and the specified objects Pod tag selector defined.
Affinity rules define nodes of two kinds: rigid affinity (the require) and soft affinity (Preferred)
Hard affinity: implementation is mandatory rules, rules that must be met when scheduling Pod, Pod state otherwise would have been the object is Pending
Soft affinity: scheduling a flexible implementation is limited during Pod scheduling may try to meet its rules, the rules can not be met at the time, can be scheduled onto a node does not match the rule.
Pro-node definitions and rules two points: First node configuration is in compliance with label requirements, but a reasonable definition of the object Pod tag selector, so as to select a desired label based on the destination node.
Note that after preferredDuringSchedulingIgnoredDuringExecution and requiredDuringSchedulingIgnoredDuringExecution name in the second half of the string IgnoredDuringExecution indicated that, after the Pod resource scheduling to a node affinity-based rules, if the node's label is changed, the scheduler can not speak Pod objects removed from the node, because only the rule of new valid objects Pod.
4, Pod and scheduling resources affinity
In the demand for efficient communication, is sometimes necessary to schedule some Pod similar or even the same location area (such as the same node, room, area) and the like, such as a front end and a rear end Pod Pod service, this time between these objects Pod the relationship can be called affinity.
At the same time for reasons of security, it will be isolated between some of the Pod, this time the relationship between these objects is called anti-Pod affinity (anti-affinity).
Pod scheduler into the first arbitrary position, and then the Pod has affinity or an affinity of anti-Pod completion position based on the dynamic scheduling, and it is the role of anti-Pod affinity affinity scheduling. Pod affinity definitions presented as hard and soft affinity for the affinity difference, and a similar meaning to be bound affinity nodes.
Pod Pod respective affinity scheduling requirements related to the operation of the object in the same position, but they do not require anti-affinity run at the same position. The position here really depends on the location of the node topology, topology of different ways, whether in the same location Pod determination result will be different.
If the label of each node based kubernetes.io/hostname be judged, based on hostname then determines whether the node to the same location area.
4.1, Pod hard affinity
Pod forced affinity scheduling constraints are defined for use requiredDuringSchedulingIgnoredDuringExecution. Pod affinity is used to describe the existence of a dependency relationship between the position of objects and a Pod Pod existing objects running, so if you want to test the affinity Pod constraints, requires the presence of an object is dependent Pod, create the following with a app = deployment of resources tomcat deploy a Pod objects:
Pod case based on affinity for a single node will use relatively less often used are based on the same area, region and racks topological location constraints. For example deployment of applications (MyApp) and a database (db) when the service related Pod, both Pod should be deployed in the same area, can accelerate the speed of communication.
4.2, Pod soft affinity
Similarly, hard soft affinity i.e. affinity, Pod also supports soft affinity preferredDuringSchedulingIgnoredDuringExecuttion attributes defined Pod, the scheduler may try to meet affinity scheduling constraints, the constraints can not be satisfied at the time, also allow the Pod scheduled to run on another node.
4.3, Pod affinity anti
podAffinity affinity and constraints defined Pod objects, and scheduling the Pod affinity anti objects are defined with podAntiAffinty properties,
5, blemishes and tolerance
5.1, the definition of stains and tolerance
Stains (taints) is defined on a set of key nodes attribute data type, used to allow a node to refuse to Pod scheduling on the node, unless the object has tolerance Pod receiving node stains. And tolerance (tolerations) is defined on the key object data type Pod, to configure the object may be tolerated so Pod stain node.
Foregoing scheduling mode selector node and nodes are determined by adding the affinity tag selector on the match of the complete object Pod particular type of node labels, is achieved Pod selecting nodes manner. The stain and tolerance is to control the scheduling result Pod objects by adding stain information node, the node has to make the Pod objects which can be scheduled to control one way on that node.
Kubernetes preselected strategy and using PodToleratesNodeTaints TaintTolerationPriority preferably scheduling functions to accomplish this.
Stain defined in the node nodeSpec, tolerance is defined in the Pod in podSpec fall within the type of key data, supports two modes effect a mark syntax is key = value: effect, wherein the key and value user notes and similar formats and resources, and effect is used to define the level of rejection Pod objects, mainly contains the following three types:
NoSchedule: New Object Pod intolerable to this stain can not be scheduled on the node is mandatory constraint node Pod existing objects are not affected.
PreferNoSchedule: NoSchedule belongs flexible constraining, i.e. the object can not tolerate this Pod schedule so as not to stain the node, but no other nodes may schedule the scheduled time may be allowed to accept.
NoExecute: New Object Pod tolerate the stains can not be scheduled on that node, the obligation, because target node existing node stain Pod Pod tolerance variations or fluctuations result in not matching rule, Pod objects will be removed from the node.
When the object is defined tolerance on Pod, which supports the operator 2: Equal and Exists
Equal: equivalence comparison, represents tolerance and must exactly match the stain on the key, value, effect of the three.
Exists: determining the existence of, and the effect key indicates both must match, and the value of the tolerance field nulls.
Kubeadm deployed using a cluster, automatically add the information on the master node stain, the stain preventing tolerated Pod subject to scheduling on the node,
5.2 stain, management nodes
At this time, the object on Pod node01 affected nodes already present, only new objects Pod impact, should be noted that, if the key data is the same, but different final identification information also belong to different stains, such as add a stain to give the node01 identified as: PreferNoSchedule
5.3, the object of tolerance Pod
Pod tolerance objects can be added by spec.tolerations field, there are two identical operators: Equal and Exists manner.