行业网站特点重庆建筑特种作业查询网

行业网站特点,重庆建筑特种作业查询网,免费建音乐网站,小程序定制开发公司前十名Kubernetes 通过对 Cgroups 的精细控制来实现其 requests 和 limits 机制。 简单来说#xff1a; requests - 主要对应 cpu.shareslimits - 主要对应 cpu.cfs_quota_us 和 cpu.cfs_period_us 下面我们进行详细的分解和解释。核心概念对应关系Kubernetes 概念Cgroup 文…Kubernetes 通过对 Cgroups 的精细控制来实现其requests和limits机制。简单来说requests- 主要对应cpu.shareslimits- 主要对应cpu.cfs_quota_us和cpu.cfs_period_us下面我们进行详细的分解和解释。核心概念对应关系Kubernetes 概念Cgroup 文件作用机制性质spec.containers[].resources.requests.cpucpu.shares相对权重Shares软限制、弹性spec.containers[].resources.limits.cpucpu.cfs_quota_uscpu.cfs_period_us绝对上限Quota硬限制、严格1. CPU Request (requests.cpu) -cpu.shares作用requests.cpu在 Kubernetes 中表示容器请求的、保证的最小 CPU 资源量。它主要影响 Pod 的调度——调度器会确保节点上有足够的可用资源CPU 和内存才会将 Pod 分配上去。Cgroups 实现Kubernetes 通过设置 Cgroup v1 的cpu.shares属性来实现这一点。工作原理cpu.shaes是一个相对权重而不是一个绝对的 CPU 核心数。它的默认值是 1024。Kubernetes 的计算公式大致为容器申请的 cpu.shares 1024 * requests.cpu例如如果一个容器设置了requests.cpu: 1.5那么它的cpu.shares将被设置为1024 * 1.5 1536。行为当节点上的 CPU 资源充足时一个设置了requests.cpu的容器可以使用的 CPU可以超过其请求值它几乎可以使用任何空闲的 CPU。当节点上的 CPU 资源紧张多个容器竞争 CPU时CFS完全公平调度器会根据每个容器的cpu.shares比例来分配 CPU 时间。再例如假设一个节点上只有两个 PodPod A:requests.cpu: 1-cpu.shares 1024Pod B:requests.cpu: 2-cpu.shares 2048当两者都全力使用 CPU 时它们将按照1024:2048即1:2的比例分配 CPU 时间。Pod A 大约获得 33% 的 CPUPod B 大约获得 66% 的 CPU。总结requests.cpu通过cpu.shares确保在资源竞争时获得最低保证份额是一种“软”限制。2. CPU Limit (limits.cpu) -cpu.cfs_quota_uscpu.cfs_period_us作用limits.cpu在 Kubernetes 中表示容器能使用的 CPU 资源的绝对硬性上限无论节点上的 CPU 是否空闲它都不能超过这个限制。Cgroups 实现Kubernetes 通过设置 Cgroup v1 的CPU 带宽控制CPU bandwidth control子系统来实现即cpu.cfs_quota_us和cpu.cfs_period_us这两个文件。cpu.cfs_period_us定义了一个时间周期单位微秒通常固定设置为100,000 μs即 100毫秒。cpu.cfs_quota_us定义了在以上一个周期内该容器最多可以使用的 CPU 时间单位微秒。工作原理计算公式为cpu.cfs_quota_us limits.cpu * cpu.cfs_period_us例如如果一个容器设置了limits.cpu: 1那么cpu.cfs_period_us 100000cpu.cfs_quota_us 1 * 100000 100000这意味着在每 100ms 的时间内该容器最多可以使用 100ms 的 CPU 时间即相当于独占 1 个 CPU 核心。再例如如果一个容器设置了limits.cpu: 1.5那么cpu.cfs_quota_us 1.5 * 100000 150000这意味着在每 100ms 的时间内该容器最多可以使用 150ms 的 CPU 时间即相当于独占 1.5 个 CPU 核心。如果容器在周期内耗尽了它的配额cpu.cfs_quota_us它就会被节流Throttled必须等待下一个周期才能继续运行。总结limits.cpu通过cpu.cfs_quota_us和cpu.cfs_period_us设置一个严格的“天花板”是一个“硬”限制。综合示例与实践意义一个 Pod 的配置可以同时包含requests和limitsapiVersion: v1kind: Podmetadata:name: example-podspec:containers:name: example-containerimage: nginxresources:requests:memory: “64Mi”cpu: “0.5” # 请求 0.5 核limits:memory: “128Mi”cpu: “1” # 限制最多使用 1 核在这个例子中调度调度器会寻找至少有 0.5 核空闲 CPU 和 64MiB 空闲内存的节点。Cgroups 设置CPU:cpu.shares 1024 * 0.5 512cpu.cfs_quota_us 1 * 100000 100000cpu.cfs_period_us 100000内存也会设置对应的memory.limit_in_bytes为 128MiB。实践意义设置requests而不设置limits容器可以弹性使用尽可能多的空闲 CPU但在竞争时享有保证的最低份额。适用于可以充分利用空闲资源但不需要严格限制的应用。设置limits而不设置requestsrequests会默认等于limits。这保证了 Pod 的资源但缺乏弹性。通常不建议除非你明确希望如此。同时设置requests和limits这是最常见和推荐的做法。它既保证了 Pod 的调度和最小资源又防止 bug 或异常导致单个 Pod 耗尽整个节点的资源 noisy neighbor 问题。因此Kubernetes 通过将高级别的requests和limits概念映射到 Cgroups 底层的不同控制机制实现了既灵活又严格的混合资源管理策略。