第5题：pod的调度：
题目：
- 创建一个pod名称为nginx，并将其调度到节点为 disk=ssd上
解题思路：
本题考点是nodeSelector-节点选择约束的最简单推荐形式。
nodeSelector是PodSpec的领域。它指定键值对的映射。为了使Pod有资格在节点上运行，该节点必须具有每个指示的键值对作为标签（它也可以具有其他标签）。最常见的用法是一对键值对。
具体可参考：https://kubernetes.io/docs/concepts/configuration/assign-pod-node/
解题步骤：
- 将标签粘贴到节点（运行kubectl get nodes以获取群集节点的名称。选择要向其添加标签的标签，然后运行）：
获取Node：
sudo kubectl get nodes
向您选择的节点(ubuntu002 )添加标签:
sudo kubectl label node ubuntu002 disk=ssd
查看标签：
sudo kubectl get nodes ubuntu002 --show-labels
- 向您的Pod配置添加一个nodeSelector字段
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: kucc4
name: kucc4
namespace: ns-ehj
spec:
containers:
- image: nginx
name: kucc4
- image: redis
name: redis
- image: memcached
name: memcached
- image: consul
name: consul
nodeSelector:
disk: ssd
最后apply即可调度到有disk: ssd标签的Node上去：
sudo kubectl apply -f kucc4.yaml
定向调度到ubuntu003
标签为disk=ssd的node
调度策略：
Pod在绝大多数场景下只是容器的载体，我们需要用各种策略将此POD调度到指定的Node上去，调度的方法会有很多种，我们一起来分析下：
1.Deployment/RC全自动调度：
该策略是基于K8S本身的调度算法，我们举个例子来演示下：我们先创建一个有3个repilca的pod，基于Deployment来做调度，Deployment文件如下：
我们照旧先dry-run一个文件出来修改：
sudo kubectl run deploymentTest --image=nginx -n ns-ehj --generator=run-pod/v1 --dry-run -o yaml > deploymentTest.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
name: deployment-test
name: deployment-test
namespace: ns-ehj
spec:
replicas: 3
selector:
matchLabels:
name: deployment-test
template:
metadata:
labels:
name: deployment-test
spec:
containers:
- image: nginx
name: deployment-nginx
全自动调度
2.Node定向调度：（如题干所示即为定向调度）
3.Node亲和性调度：
用于替换NodeSelector的全新调度策略，节点亲和力在概念上类似于nodeSelector–它使您可以基于节点上的标签来限制Pod可以安排在哪些节点上进行调度。
当前有两种类型的节点关联性：
- requiredDuringSchedulingIgnoredDuringExecution：指定了将Pod调度到节点上必须满足的规则，与nodeSelector工作原理类似，只是语法不同，相当于硬限制。
- preferredDuringSchedulingIgnoredDuringExecution
强调优先满足指定规则，调度器会尝试调度至满足该条件的Node上，但是不强求，相当于软限制。可以设置优先级来指定先后顺序。
注意：
IgnoredDuringExecution的意思是如果一个pod所在的节点在pod运行期间标签发生了变化，不在符合该pod的亲和性要求，那么将忽略此变化，该pod能继续在该节点运行。
我们需要在PodSpec里面指定nodeAffinity 和 affinity，下面我们来看个例子：
apiVersion: v1
kind: Pod
metadata:
name: with-node-affinity
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/e2e-az-name
operator: In
values:
- e2e-az1
- e2e-az2
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: another-node-label-key
operator: In
values:
- another-node-label-value
containers:
- name: with-node-affinity
image: k8s.gcr.io/pause:2.0
代码解释：
- 该节点相似性规则表示，只能将Pod放置在带有标签的标签上，该标签的键为 kubernetes.io/e2e-az-name，值为e2e-az1或e2e-az2。
- 另外，在满足该条件的节点中，应首选带有如下标签的节点：该标签的键为another-node-label-key值为another-node-label-value
- 如果同时指定nodeSelector和nodeAffinity，则必须满足两个条件，才能将Pod调度到候选节点上
4.Pod亲和性调度
根据节点上运行的Pod的标签而不是Node的标签进行调度，要求对节点和Pod两个条件进行匹配。可以描述为，如果在具有标签X的Node上运行了一个活多个符合条件的YPod，那么该Pod应该运行在这个Node上
apiVersion: v1
kind: Pod
metadata:
name: with-pod-affinity
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S1
topologyKey: failure-domain.beta.kubernetes.io/zone
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S2
topologyKey: failure-domain.beta.kubernetes.io/zone
containers:
- name: with-pod-affinity
image: k8s.gcr.io/pause:2.0
此Pod上的 亲和性定义了一个Pod亲和性规则和一个Pod反亲和性规则。
在此示例中：
- podAffinityis是：requiredDuringSchedulingIgnoredDuringExecution，指的是该pod承接的Node必须拥有一个Key为security，Value为S1的Pod。
- podAntiAffinityis是：preferredDuringSchedulingIgnoredDuringExecution，指的是如果节点已经运行了一个具有键“security”和值“S2”的标签的 pod，则该 pod 不希望将其调度到该节点上。
网友评论