Kubernetes 1.19.0——Pod（2）

静态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不受影响