静态pod
如果apiserver没有运行的时候，master肯定是不能工作的
Master不能工作，那么是谁把apiserver运行起来的呢？
先有鸡还是先有蛋？
静态pod：不受master管理，完全是由kubelet来管理
所谓静态pod就是，不是master上创建的，而是需要到Node的/etc/kubelet.d/里创建一
个yaml文件，然后根据这个yaml文件，创建一个pod，这样创建出来的node，是不会
接受master的管理的。
静态pod用到的机会不多，这里不作主要演示
调度的三个对象
当我们创建一个pod的时候，scheduler会根据自己的算法来决定此pod到底在哪个节点上运行。
待调度pod列表
可用node列表
调度算法：主机过滤、主机打分
主机过滤
NoDiskConflict
PodFitsResources
PodFitsPorts
MatchNodeSelector
HostName
NoVolumeZoneConflict
PodToleratesNodeTaints
CheckNodeMemoryPressure
CheckNodeDiskPressure
MaxEBSVolumeCount
MaxGCEPDVolumeCount
MaxAzureDiskVolumeCount
MatchInterPodAffinity
GeneralPredicates
NodeVolumeNodeConflict
主机打分
LeastRequestedPriority
公式
score=cpu ( ( capacity - sum ( requested ) ) * 10 / capacity) memory
( ( capacity - sum ( requested) ) * 10 / capacity )/2
BalanceResourceAllocation
公式
score = 10 -abs ( cpuFraction - memoryFraction ) * 10
CalculateSpreadPriority
公式
Score = 10 * （（maxCount -counts）/ （maxCount））
从两个方面来考虑，如何让pod在特定的节点上运行
1. node标签的方式
所有的对象都有标签 --show-labels
标签的格式：
键=值
xxxxx=yyyyy
对所有节点设置标签kubectl label nodes --all aa=bb
对所有节点取消设置标签
kubectl label nodes --all aa-
修改内置标签kubectl label nodes vms62 node-role.kubernetes.io/worker1=""
手动指定pod运行位置
给vms63设置一个标签disktype=ssd
修改pod4.yaml，通过nodeSelector选择器定义，表示此pod只会在含有disktype=ssd的节点上运行注：如果有62和63两台机器都有此标签，那么pod会选择一台运行
2. Node亲和性
软策略：尽可能的在满足条件的节点上运行，如果没有满足条件的节点则在其它节点上也能运行
硬策略：必须满足条件才能运行
affinity:
nodeAffinity:
# requiredDuringSchedulingIgnoredDuringExecution: # 硬策略
# nodeSelectorTerms:
# - matchExpressions:
# - key: kubernetes.io/hostname
# operator: In
# values:
# - vms63
# - vms62
Operator的值还可以为NotIn，Exists，DoesNotExist
创建一个deployment，并添加硬策略配置kubectl create deployment web1 --image=nginx --dry-run=client -o yaml > web1.yaml
红框中的values可以指定在哪台机器上运行，根据情况修改即可
只在vms62上运行也可在多台机器上运行，为节约篇幅这里不作演示
preferredDuringSchedulingIgnoredDuringExecution: # 软策略
- weight: 2
preference:
matchExpressions:
- key: bb
operator: Gt
values:
- "3
Values设置成vms62意思是优先在62这台机器运行调度：警戒线cordon
如果把某个节点设置了cordon，则这个节点会被设置为不可调度，再创建新的pod的时候是不会调度到此节点上的
创建8个副本的pod
通过kubectl cordon vms63设置63这台机器的cordon，则新创建的pod就不会调度到此节点，但不会影响之前创建好的pod
由此可见，新创建的pod将不会运行在被设置了cordon的节点上通过kubectl uncordon vms63取消cordon后恢复正常
调度：节点的drain
如果一个节点被设置为drain，则此节点不再被调度pod，
且此节点上已经运行的pod会被驱逐(evicted)到其他节点，用于节点的维护
kubectl drain vms63 --ignore-daemonsets
kubectl uncordon vms63
此操作不在这里单独演示
调度：节点taint及pod的tolerations
之前的pod都在worker上创建，为什么没有在master上创建呢？
因为设置了污点taint
而另外两台机器是没有污点taint的
检查vms62和vms63上没有设置污点
通过kubectl taint nodes vms63 keyxx=valuexx:NoSchedule将vms63设置污点
因为之前设置了nodeSelector来让此pod运行至vms63节点，现在给此节点加了taint后再创建pod将会一直处于pending状态通过kubectl taint nodes vms63 keyxx-取消污点设置
如果非要在有污点的机器上运行pod怎么办？那就需要配置能够容忍污点
tolerations:
- key:"keyxx"
operator:"Equal"
value:"valuexx"
effect:"NoSchedule"
此参数设置意为能够容忍key为”keyxx”并且value为”valuexx”的污点 成功运行至有污点的机器跟之前的cordon一样，通过设置63这台机器的污点，已经成功运行的pod不受影响
