创建一个 pod 时, 可以指定容器对 CPU 和内存的资源请求量, 以及资源限制量.

14.1.1 创建包含资源 requests 的 pod

image.png

  • 200 毫核
    • 一个 cpu 逻辑核 = 1000 m (毫核), 就是一个 cpu 时间片分成1000分
    • 分配最小单位为 100m

虽然指定了 200m, 但是使用了 1000m (top 中约等于50%), 这是因为没有限制使用的 cpu 核数:

image.png

14.1.2 资源 requests 如何影响调度

通过设置资源 request 我们指定了 pod 对资源需求的最小值.

书中提到配置最小值, 我以为上面配置的是最大值, 需要继续阅读看看能否配置最大值.

调度器如何判断一个 pod 是否适合调度到某个节点

image.png

image.png

调度器如何利用 pod requests 为其选择最佳节点

两个基于资源请求量的优先级排序函数:

  • LeastRequestedPriority: 优先将 pod 调度到请求量少的节点上 (也就是拥有更多未分配资源的节点)
  • MostRequestedPriority : 优先调度到请求量多的节点 (拥有更少未分配资源的节点)

调度器只能使用一种优先级函数.

查看节点资源总量

kubelet 会向 API 服务报告相关数据.

  1. $ kubectl describe nodes

image.png

再创建一个 800m, 加上之前的 200m, 现在有 1000m:

image.png

还有1个逻辑核, 所以可以被调度:

image.png

创建一个不适合任何节点的 pod

接着创建1个 cpu:

image.png

查看调度情况:

image.png

查看 Pending 的详细原因:

image.png

查明 pod 没有被调度成功的原因

查看节点资源:

image.png
image.png

总共 2000m, kube-system 占用了 10+5+260, 所以剩下的不够1cpu.

释放资源让 pod 正常调度

方法就是删除某个已有的 pod:

image.png

14.1.3 CPU requests 如何影响 CPU 时间分配

如果没有配置 pod 的 limit, 那么整个 cpu 时间分配按照 request 的比例分配:

image.png

当有 pod 空闲时, 其他 pod 会占用这部分 cpu

14.1.4 定义和申请自定义资源

在 requests 中引用定义的资源.