kubernetes之资源调度的方式

1. 容器资源的限制

表示最多使用多少cpu和内存资源

  • resources.limits.cpu
  • resources.limits.memory

表示最少使用的CPU和内存资源

  • resources.requests.cpu
  • resources.requests.memory
[root@master ~]# kubectl describe nodes node1.example.com  //节点的信息
省略N行
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests   Limits
  --------           --------   ------
  cpu                100m (5%)  100m (5%)  //cpu使用率
  memory             50Mi (1%)  50Mi (1%)  //内存使用情况
  ephemeral-storage  0 (0%)     0 (0%)
  hugepages-1Gi      0 (0%)     0 (0%)
  hugepages-2Mi      0 (0%)     0 (0%)


[root@master test]# cat test.yml 
apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: b1
    image: busybox
    command: ["/bin/sh","-c","sleep 9000"]
    resources:
      requests:
        memory: 100Mi
        cpu: 0.01
    env:
    - name: HN
      valueFrom:
        fieldRef:
          fieldPath: status.podIPs

[root@master test]# kubectl apply -f test.yml  //创建一个pod进行测试
pod/test created

[root@master test]# kubectl get pod -o wide  //运行再node1上
NAME   READY   STATUS    RESTARTS   AGE   IP            NODE                NOMINATED NODE   READINESS GATES
test   1/1     Running   0          57s   10.244.1.60   node1.example.com   <none>           <none>

[root@master haproxy]# kubectl describe nodes node1.example.com
  Resource           Requests    Limits
  --------           --------    ------
  cpu                110m (5%)   100m (5%)  //cpu变成了110,这是再原来的基础上增加的,原来是100,而我们设置requests为0.01就是增加十,因为默认100才能让node1运行,所以设置最少0.01就是在此基础上加10
  memory             150Mi (5%)  50Mi (1%)// 内存变为150,同理
  ephemeral-storage  0 (0%)      0 (0%)
  hugepages-1Gi      0 (0%)      0 (0%)
  hugepages-2Mi      0 (0%)      0 (0%)


[root@master test]# cat test.yml 
---
apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: b1
    image: busybox
    command: ["/bin/sh","-c","sleep 9000"]
    resources:
      requests:
        memory: 30Mi
        cpu: 0.001
      limits:
        memory: 40Mi
        cpu: 0.01
    env:
    - name: HN
      valueFrom:
        fieldRef:
          fieldPath: status.podIPs

2. nodeSelector节点选择器

nodeSelector:用于将Pod调度到匹配Label的Node上,如果没有匹配的标签会调度失败。
作用:

  • 约束Pod到特定的节点运行
  • 完全匹配节点标签
  • 应用场景:
  • 专用节点:根据业务线将Node分组管理
  • 配备特殊硬件:部分Node配有SSD硬盘、GPU
// 查看所有节点的标签
[root@master test]# kubectl get nodes --sh
### Kubernetes资源调度流程详解 Kubernetes 中的资源调度调度器(Scheduler)负责完成,它会根据一系列规则和策略决定 Pod 应该部署在哪一个节点上。以下是详细的调度过程: #### 1. 调度输入 当一个新的 Pod 创建时,API Server 将其存储到 etcd 数据库中,并通知 Scheduler 进行处理。此时,Pod 处于 `Pending` 状态。 #### 2. 预选阶段 (Predicate Phase) 预选阶段的主要目标是从集群中的所有节点筛选出符合条件的候选节点集合。这些条件可能包括但不限于以下内容[^2]: - **Node Selector**: 检查节点上的标签是否匹配 Pod 定义中的 NodeSelector。 - **Taints and Tolerations**: 判断节点是否有未被容忍的污点。 - **Resource Availability**: 确保节点有足够的 CPU 和内存等资源来满足 Pod 的需求。 如果某个节点未能通过任何一项检查,则会被排除在外。 #### 3. 打分阶段 (Prioritize Phase) 在得到一组可行的目标节点之后,进入打分阶段。这一阶段会对每一个合格节点按照预定的标准赋予一定数值范围内的得分,从而选出最优解之一作为最终目的地。常见的评分标准有以下几个方面: - **LeastRequestedPriority**: 倾向于选择剩余容量较大的机器放置新实例; - **BalancedResourceAllocation**: 努力维持各维度间的均衡状态; - **InterPodAffinityPriority & AntiAffinityPriority**: 根据已存在 workload 的分布情况调整位置偏好; #### 4. 绑定操作 (Binding Operation) 一旦决定了最佳目标主机后,就会把对应关系记录下来并通过 API server 更新回数据库里去。随后 kubelet 会在指定服务器上面启动容器进程并报告成功与否的状态变化给 master component知道整个生命周期管理结束。 ```bash # 示例命令展示如何手动触发调度逻辑测试 kubectl create -f my-pod.yaml --dry-run=client -o yaml | kubectl schedule - ``` 以上便是完整的 Kubernetes 资源调度流程概述及其内部运作机制解析[^5]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

彭宇栋

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值