Resource Limits、QOS、Priority 以及Evction整理


所有操作均在 killercoda 环境上完成

$ kubectl get nodes
NAME           STATUS   ROLES           AGE    VERSION
controlplane   Ready    control-plane   7d9h   v1.31.0
node01         Ready    <none>          7d9h   v1.31.0
$ kubectl version
Client Version: v1.31.0
Kustomize Version: v5.4.2
Server Version: v1.31.0

参考

kubernetes QOS
kubernetes resources manage

资源限制 (Resource Limits)

Kubernetes 通过资源请求(Requests)和限制(Limits)来管理 Pod 的资源使用

  1. 请求(Requests):定义 Pod 需要的最小资源量,用于调度决策。如果节点上的可用资源不能满足请求,Pod 将不会被调度到该节点。
  2. 限制(Limits):定义 Pod 可以使用的最大资源量。如果 Pod 试图使用超过限制的资源,Kubernetes 会采取行动(例如,限制 CPU 使用或 OOMKilled)。
resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

单位

CPU

CPU 资源的单位是核(cores)。

表示方法

整数或小数:例如,0.5 表示半个 CPU 核,1 表示一个 CPU 核。
毫核(millicpu 或 m):例如,100m 表示 0.1 个 CPU 核,500m 表示 0.5 个 CPU 核。

示例
  • requests.cpu: 100m 表示请求 0.1 个 CPU 核。
  • requests.cpu: 2 表示请求 2 个 CPU 核。

内存

内存资源的单位是字节(bytes)。

表示方法
  • E 或 Ei:Exbibytes
  • P 或 Pi:Pebibytes
  • T 或 Ti:Tebibytes
  • G 或 Gi:Gibibytes
  • M 或 Mi:Mebibytes
  • K 或 Ki:Kibibytes
示例
  • requests.memory: 64Mi 表示请求 64 兆比字节(64 * 2^20 字节)。
  • requests.memory: 512Mi 表示请求 512 兆比字节。
  • requests.memory: 2Gi 表示请求 2 吉比字节(2 * 2^30 字节)。

总结

  • CPU:使用 CPU 核或毫核(m)表示,例如 100m 或 2。
  • 内存:使用字节表示,并可以使用后缀 E, P, T, G, M, K 及其二进制版本 Ei, Pi, Ti, Gi, Mi, Ki,例如 64Mi 或 2Gi。

仅有限制没有请求

CPU

如果只有 limits.cpu 而没有 requests.cpu,Kubernetes 会将 requests.cpu 自动设置为 limits.cpu 的值。这意味着 Pod 可以使用最多 limits.cpu 指定的 CPU 资源,但调度时会考虑这个值作为其最小需求。

apiVersion: v1
kind: Pod
metadata:
  name: limits-cpu-only
spec:
  containers:
  - name: limits-only-container
    image: busybox
    resources:
      limits:
        cpu: 500m
    command: ['sh', '-c', 'echo "Limits Only" && sleep 3600']
$ kubectl get pod limits-cpu-only -o go-template='
Pod Name: {
   
   { .metadata.name }}
QoS Class: {
   
   { .status.qosClass }}
Containers:
{
   
   {- range .spec.containers }}
  - Name: {
   
   { .name }}
    Requests:
      CPU: {
   
   { .resources.requests.cpu }}
      Memory: {
   
   { .resources.requests.memory }}
    Limits:
      CPU: {
   
   { .resources.limits.cpu }}
      Memory: {
   
   { .resources.limits.memory }}
{
   
   {- end }}
'

Pod Name: limits-cpu-only
QoS Class: Burstable
Containers:
  - Name: limits-only-container
    Requests:
      CPU: 500m
      Memory: <no value>
    Limits:
      CPU: 500m
      Memory: <no value>

Memory

如果只有 limits.memory 而没有 requests.memory,Kubernetes 会将 requests.memory 自动设置为 limits.memory 的值。这意味着 Pod 可以使用最多 limits.memory 指定的 memory 资源,但调度时会考虑这个值作为其最小需求。如果 Pod 请求的内存超过了设置的限制,可能会被终止(OOM Killed)。

apiVersion: v1
kind: Pod
<think>我们正在回答用户关于如何通过资源限制在Linux中禁用核心转储(core dump)的问题。 核心转储是进程在崩溃时保存的内存映像,可以用于调试。但在某些场景下,我们可能希望禁用核心转储,例如节省磁盘空间或提高安全性。 在Linux中,我们可以通过设置资源限制(resource limits)来控制核心转储。资源限制可以通过shell的内置命令ulimit或编程方式(如使用setrlimit系统调用)来设置。 具体来说,我们可以将核心文件大小(core file size)限制设置为0,这样当进程崩溃时,系统将不会生成核心转储文件。 方法一:使用ulimit命令(在shell会话中临时生效) 在终端中执行以下命令: ulimit -c 0 方法二:在程序中设置(针对特定进程) 在C程序中,我们可以使用setrlimit函数: #include <sys/resource.h> ... struct rlimit limit; limit.rlim_cur = 0; // 软限制 limit.rlim_max = 0; // 硬限制(非特权进程只能将硬限制降低到当前值) setrlimit(RLIMIT_CORE, &limit); 方法三:通过配置文件永久设置(针对用户或全局) 我们可以编辑/etc/security/limits.conf文件,为特定用户或组设置核心文件大小限制。例如: * hard core 0 # 所有用户硬限制为0 username hard core 0 # 特定用户 或者,我们可以在/etc/profile或用户的shell配置文件(如~/.bashrc)中添加ulimit -c 0,这样每次登录都会生效。 注意:在某些系统中,核心转储可能由systemd的coredump服务处理。即使设置了资源限制,systemd coredump服务仍可能捕获核心转储。因此,我们可能需要额外禁用systemd-coredump服务。 禁用systemd-coredump服务的方法: sudo systemctl stop coredump.service sudo systemctl disable coredump.service 但是,用户的问题明确要求使用资源限制来禁用核心转储,因此我们主要关注资源限制的设置。 另外,我们还可以通过sysctl设置kernel.core_pattern来禁用核心转储,但这不属于资源限制的范畴,而是系统级别的设置。 总结:通过设置资源限制(核心文件大小为0)是禁用核心转储的一种有效方法,可以在进程级别或用户级别进行控制。 根据引用[1],我们注意到内核启动参数中也有与SMP(多处理器)相关的设置,但这与核心转储无关。引用[2]提到有特定架构的内核参数,但同样不涉及核心转储。引用[3]提到套接字激活的服务排序,与核心转储无关。因此,这些引用与当前问题关联不大。 下面,我们将生成相关问题。</think>### 如何通过资源限制在 Linux 中禁用核心转储 在 Linux 中,可通过设置资源限制(resource limits)禁用核心转储。核心转储功能由 `RLIMIT_CORE` 参数控制,将其值设为 `0` 即可禁用。以下是具体方法: #### 1. **临时禁用(当前会话有效)** ```bash # 设置核心文件大小为0 ulimit -c 0 # 验证设置 ulimit -c # 输出应为: 0 ``` > ⚠️ 此设置在终端会话结束后失效。 #### 2. **永久禁用(用户级)** 编辑用户 shell 配置文件(如 `~/.bashrc` 或 `~/.bash_profile`): ```bash echo "ulimit -c 0" >> ~/.bashrc source ~/.bashrc # 立即生效 ``` #### 3. **系统级全局禁用** 修改 `/etc/security/limits.conf`: ```bash # 添加以下内容(对所有用户生效) * hard core 0 root hard core 0 ``` > 📌 需重新登录或重启系统生效。 #### 4. **验证是否生效** ```bash # 测试触发核心转储 sleep 10 & kill -SIGSEGV $! # 发送段错误信号 ls core.* 2>/dev/null # 应无输出 ``` #### 5. **额外说明** - **systemd 服务**:若使用 systemd,需检查服务配置中的 `LimitCORE=0` 参数[^3]。 - **内核参数**:`/proc/sys/kernel/core_pattern` 若设为 `|/bin/false` 可彻底禁用,但属于系统级设置而非资源限制[^1][^2]。 - **权限要求**:永久设置需管理员权限(`/etc/security/limits.conf` 或 systemd 配置)。 --- ### 核心机制解析 当进程触发崩溃信号(如 `SIGSEGV`)时: 1. 内核检查 `RLIMIT_CORE` 值 2. 若值为 `0` → 跳过核心文件生成 3. 若值非零 → 创建核心转储文件(路径由 `core_pattern` 决定) > 💡 资源限制优先级:进程级限制 > 用户级限制 > 系统级限制。 --- ### 相关问题 1. **如何区分 `ulimit -c 0` 与修改 `core_pattern` 两种禁用方法的适用场景?** 2. **当 `RLIMIT_CORE=0` 时,进程崩溃后会产生哪些日志线索?** 3. **在容器环境中禁用核心转储需要哪些特殊配置?** 4. **为什么 root 用户的 `ulimit -c` 默认值可能与其他用户不同?** [^1]: Linux 内核启动参数控制,如 `nosmp` 可影响 APIC 行为 [^2]: 部分架构特定的内核参数需参考对应文档 [^3]: systemd 单元可通过 `LimitCORE=` 控制核心转储
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值