navicat怎么添加check约束
290
2022-10-27
Kubernetes的Node和Pod的调度策略
Kubernetes的Node和Pod的调度策略
在Kubernetes系统中，Pod大部分场景下都只是容器的载体而已，通过都是通过Deployment、DaemonSet、Job、RC等资源对象来完成一组Pod的调度与自动控制功能。
Pod的调度主要有：
1.Deployment/RC:全自动调度
通过Deployment和RC创建的Pod，完全是由master的Scheculer经过一系列的算法进行自动调度。
例如：
#Deployment apiVersion: apps/v1 kind: Deployment metadata: name: oper-server namespace: dev spec: selector: matchLabels: app: oper-server replicas: 2 template: metadata: labels: app: oper-server spec: imagePullSecrets: - name: cd-registry containers: - name: oper-server image: harbor.ttsingops.com/oper-server/oper-server:18 imagePullPolicy: IfNotPresent volumeMounts: - name: host-time mountPath: /etc/localtime volumes: - name: host-time hostPath: path: /etc/localtime |
2.NodeSelector：定向调度
可能需要将Pod调度到指定的一些Node上，可以通过Node的标签(Label)和Pod的nodeSelector属性来相匹配
（1） 通过给Node打上标签
#查看所有node的默认标签
kubectl get nodes --show-labels
语法：
kubectl label nodes
kubectl label node cd-k8s-node-3 type=node3
#删除Node标签
#只需在命令行最后指定Label的Key名并与一个减号相连即可
语法：kubectl label nodes nodename key-
kubectl label nodes cd-k8s-node-6 failure-domain.beta.kubernetes.io/zone-
#修改Node标签
语法：kubectl label nodes nodename key=value --overwrite
kubectl label nodes cd-k8s-node-3 type=node3 --overwrite
（2）在Pod的定义中加上NodeSelector的设置即可。
apiVersion: v1 kind: Pod metadata: name: hostpath spec: imagePullSecrets: - name: cd-registry nodeSelector: type: node3 containers: - name: busybox image: harbor.ttsingops.com/busybox/busybox:1.28 imagePullPolicy: IfNotPresent command: ["sh","-c"," echo `date '+%H:%M:%S'` >> /data/logs/app.log;sleep 60 "] volumeMounts: - name: app-logs mountPath: /data/logs/ - name: log-collector image: harbor.ttsingops.com/busybox/busybox:1.28 imagePullPolicy: IfNotPresent command: ["sh","-c","cat /logs/app.log"] volumeMounts: - name: app-logs mountPath: /logs volumes: - name: app-logs hostPath: path: /opt/logs |
说明：
a.若指定了Pod的NodeSelector条件，但集群中不存在包含相应标签的Node，则及时集群中还有其他的Node可用，这个Pod也无法调度成功。
b.Kubernetes系统默认给Node添加了一些Label，也可使用这些默认的系统Label进行调度。
亲和性调度包括：节点亲和性（NodeAffinity）和Pod亲和性（PodAffinity）
3.NodeAffinity：Node亲和性调度
亲和性调度的主要功能：
更具表达力（不仅仅是“符合全部”的简单情况）可以使用软限制，代替之前的硬限制，这样调度器在无法满足优先需求的情况下，会退而求其次，继续运行该Pod可以依据节点上正在运行的其他Pod的标签来进行限制，而非节点本身的标签。这样就可以定义一种规则来描述Pod之前的亲和或互斥关系。
NodeAffinity 字面意思为Node亲和性的调度策略，用于替换NodeSelector的全新调度策略。目前有两种节点亲和表达：
RequiredDuringSchedulingIgnoredDuringExecution：
必须满足指定的规则才可以调度Pod到Node上。硬限制
PreferredDuringSchedulingIgnoredDuringExecution：
优先满足指定规则，调度器会尝试调度Pod到Node上，但不是强求。软限制
例如：
将一个Pod调度到带有node-affinity标签的Node上
kubectl get nodes --show-labels
kubectl label nodes cd-k8s-node-6 affinity=node-affinity
kubectl get nodes --show-labels
cat node-affinity.yaml
apiVersion: v1 kind: Pod metadata: name: with-node-affinity namespace: ops spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: affinity operator: In values: - node-affinity containers: - name: with-node-affinity image: harbor.ttsingops.com/google-containers/pause-amd64:3.0 |
kubectl apply -f node-affinity.yaml
kubectl get po -n ops -o wide
NodeAffinity规则设置的注意事项如下：
如果同时定义了nodeSelector和nodeAffinity，那么必须两个条件同时得到满足，Pod才能最终运行在指定的Node上如果nodeAffinity指定了多个nodeSelectorTerms，只需要其中一个能够匹配成功即可。如果nodeSelectorTerms中有多个matchExpressions,则一个节点必须满足所有matchExpressions才能运行该Pod
4.PodAffinity：Pod亲和性与互斥调度策略
4.1 Pod亲和性调度
调度规则：根据节点上正在运行的Pod标签而不是节点的标签来进行判断和调度，要求对节点和Pod两个条件进行匹配。可简单描述为：如果在具有标签X的Node节点上运行了一个活多个符合Y的Pod，那么Pod应该运行在这个Pod上。
Pod是属于某个namespace，所以条件Y表达的是一个或者全部空间中的一个Label Selector。
Pod亲和与互斥的条件设置也是requiredDuringSchedulingIgnoredDuringExecution和preferredDuringSchedulingIgnoredDuringExecution。
例如下面的示例：
a.先定义一个参照的Pod，带有标签security=S1和app=nginx。
cat pod1.yaml
apiVersion: v1 kind: Pod metadata: name: pod-flag labels: security: "S1" app: "nginx" namespace: ops spec: containers: - name: nginx image: harbor.ttsingops.com/nginx/nginx:1.16.0 |
b.再创建一个Pod，测试Pod的亲和性调度
这里Pod2定义亲和性标签是：security=S1，对应上面的Pod1
cat pod2.yaml
apiVersion: v1 kind: Pod metadata: namespace: ops name: pod-affinity spec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - S1 topologyKey: kubernetes.io/hostname containers: - name: with-pod-affinity image: harbor.ttsingops.com/google-containers/pause-amd64:3.0 |
kubectl apply -f .
kubectl get pods -o wide -n ops
可以看到，这个两个Pod都处于同一个Node上运行。
若我们将pod-affnity的Pod的Node亲和性填写节点的value，则这个Pod将一直处于Pending状态。
pod1.yaml内容不变，pod2.yaml内容如下：
cat pod2.yaml
apiVersion: v1 kind: Pod metadata: namespace: ops name: pod-affinity spec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - S1 topologyKey: kubernetesxxxxx.io/hostname containers: - name: with-pod-affinity image: harbor.ttsingops.com/google-containers/pause-amd64:3.0 |
kubectl apply -f .
kubectl get pods -n ops -o wide
4.2 Pod的互斥调度
现在创建第三个Pod，希望它不能与上面第一个Pod运行在同一个Node上
cat pod3.yaml
apiVersion: v1 kind: Pod metadata: namespace: ops name: anti-affinity spec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - S1 topologyKey: failure-domain.beta.kubernetes.io/zone
podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - nginx topologyKey: kubernetes.io/hostname containers: - name: pod3 image: harbor.ttsingops.com/google-containers/pause-amd64:3.0 |
kubectl get po -n ops -o wide
#查看其日志信息，发现没有匹配的规则满足Node
kubectl describe pod anti-affinity -n ops
版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。
相关文章
发表评论
暂时没有评论，来抢沙发吧~