运维实战 容器部分 Kubernetes调度

需求简介

• 生产环境有对Pod调度规划的真实需求, 比如端口冲突的业务不能部署在同一物理机如何实现, 比如某些业务尽可能部署在同一物理机如何实现
• 调度器通过K8S的watch机制来发现集群中新创建且尚未被调度到 Node 上的 Pod. 调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行.
• 集群默认使用kube-scheduler作为调度器, 可以自行编写调度组件替换原有的kube-scheduler
• 也可以在资源清单中指定使用的调度策略
• 做调度分配时需要考虑许多要素, 如: 单独和整体的资源请求, 硬件/软件/策略限制, 亲和以及反亲和要求, 数据局限性, 负载间的干扰等等

具体调度方法

nodeName

• nodeName是最简单的节点约束方法, 通常来说不推荐使用
• 通过在资源清单中指定Node, Pod会被自动部署到该Node上, 但如果Node不存在, 集群也会尝试这么做, 因而导致Pending

局限性

• 指定的节点不存在时不会只能解决

• 节点存在, 但不满足物理需求(如资源/空间不足), 调度也会失败

• 在生产环境中Node的名称并不总是稳定/可预测的

• nodeName.yaml文件内容

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  nodeName: server3

• 测试结果

[root@Server2 Schedule]# kubectl apply -f nodeName.yaml 
Pod/nginx created
[root@Server2 Schedule]# kubectl get Pod -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP               NODE      NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          10s   10.244.141.226   server3   <none>           <none>

• 如果集群中没有符合条件的Node, 比如上面的server3改成server10

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  nodeName: server10

• 则会出现调度失败, 并不会只能解决
• 因为集群中不存在server10而你又要求调度到server10上, 就会一直Pending

[root@Server2 Schedule]# kubectl delete Pod nginx 
Pod "nginx" deleted
[root@Server2 Schedule]# kubectl get Pod -o wide
No resources found in default namespace.
[root@Server2 Schedule]# kubectl apply -f nodeName.yaml 
Pod/nginx created
[root@Server2 Schedule