Use the international standard for punctuation (#7719)
This commit is contained in:
		
							parent
							
								
									934a164a06
								
							
						
					
					
						commit
						be1901c0a4
					
				| 
						 | 
				
			
			@ -88,7 +88,7 @@ feature, currently in beta, greatly expands the types of constraints you can exp
 | 
			
		|||
3. you can constrain against labels on other pods running on the node (or other topological domain),
 | 
			
		||||
   rather than against labels on the node itself, which allows rules about which pods can and cannot be co-located
 | 
			
		||||
 | 
			
		||||
The affinity feature consists of two types of affinity, "node affinity" and "inter-pod affinity/anti-affinity."
 | 
			
		||||
The affinity feature consists of two types of affinity, "node affinity" and "inter-pod affinity/anti-affinity".
 | 
			
		||||
Node affinity is like the existing `nodeSelector` (but with the first two benefits listed above),
 | 
			
		||||
while inter-pod affinity/anti-affinity constrains against pod labels rather than node labels, as
 | 
			
		||||
described in the third item listed above, in addition to having the first and second properties listed above.
 | 
			
		||||
| 
						 | 
				
			
			@ -147,7 +147,7 @@ For more information on node affinity, see the design doc
 | 
			
		|||
Inter-pod affinity and anti-affinity were introduced in Kubernetes 1.4.
 | 
			
		||||
Inter-pod affinity and anti-affinity allow you to constrain which nodes your pod is eligible to be scheduled *based on
 | 
			
		||||
labels on pods that are already running on the node* rather than based on labels on nodes. The rules are of the form "this pod should (or, in the case of
 | 
			
		||||
anti-affinity, should not) run in an X if that X is already running one or more pods that meet rule Y." Y is expressed
 | 
			
		||||
anti-affinity, should not) run in an X if that X is already running one or more pods that meet rule Y". Y is expressed
 | 
			
		||||
as a LabelSelector with an associated list of namespaces (or "all" namespaces); unlike nodes, because pods are namespaced
 | 
			
		||||
(and therefore the labels on pods are implicitly namespaced),
 | 
			
		||||
a label selector over pod labels must specify which namespaces the selector should apply to. Conceptually X is a topology domain
 | 
			
		||||
| 
						 | 
				
			
			@ -203,7 +203,7 @@ empty `topologyKey` is not allowed.
 | 
			
		|||
In addition to `labelSelector` and `topologyKey`, you can optionally specify a list `namespaces`
 | 
			
		||||
of namespaces which the `labelSelector` should match against (this goes at the same level of the definition as `labelSelector` and `topologyKey`).
 | 
			
		||||
If omitted, it defaults to the namespace of the pod where the affinity/anti-affinity definition appears.
 | 
			
		||||
If defined but empty, it means "all namespaces."
 | 
			
		||||
If defined but empty, it means "all namespaces".
 | 
			
		||||
 | 
			
		||||
All `matchExpressions` associated with `requiredDuringSchedulingIgnoredDuringExecution` affinity and anti-affinity
 | 
			
		||||
must be satisfied for the pod to be scheduled onto a node.
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
		Loading…
	
		Reference in New Issue