参考: k8s的内存分配

一、简介

在K8s中定义Pod中运行容器有两个维度的限制：

1. 资源需求(Requests)：即运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod。否则pod无法启动。如 Pod运行至少需要2G内存，1核CPU。（硬限制）
2. 资源限额(Limits)：即运行Pod期间，可能内存使用量会增加，那最多能使用多少内存，这就是资源限额。（软限制）

通常来说：Limits >= Requests 并且requests 和 limits 通常要一起配置，若只配置了requests， 而不配置limits，则很可能导致Pod会吃掉所有资源。

二、在K8s的资源：

2.1 CPU：

我们知道2核2线程的CPU，可被系统识别为4个逻辑CPU，在K8s中对CPU的分配限制是对逻辑CPU做分片限制的。也就是说分配给容器一个CPU，实际是分配一个逻辑CPU。
而且1个逻辑CPU还可被单独划分子单位，即 1个逻辑CPU，还可被划分为1000个millicore(毫核), 简单说就是1个逻辑CPU，继续逻辑分割为1000个豪核心。
豪核：可简单理解为将CPU的时间片做逻辑分割，每一段时间片就是一个豪核心。
所以：500m 就是500豪核心，即0.5个逻辑CPU.

2.2 内存:

K，M，G，T，P，E #通常这些单位是以1000为换算标准的。
Ki, Mi, Gi, Ti, Pi, Ei #这些通常是以1024为换算标准的。

demo

apiVersion: v1
kind: Pod
metadata:
name: nginx2
spec:
containers:
- name: nginx2
image: nginx:test
ports:
- containerPort: 80
resources:
limits:
cpu: 200m
memory: 128Mi
requests:
cpu: 200m
memory: 128Mi

上面这个limits: cpu: 200m memory: 128Mi 说明在k8s的master节点调度启动这个pod时，会寻找满足cpu: 200m memory: 128Mi 的node进行调度，如果没有满足的节点就会调度失败，pod起不来。
pod起来之后，主要起作用的是requests: cpu: 200m memory: 128Mi，实际占用的资源应该不能超过这个，否则这个pod就会出问题。

三、QoS类型：

3.1 Guranteed:

每个容器的CPU，RAM资源都设置了相同值的requests 和 limits属性。
简单说： cpu.limits = cpu.requests
memory.limits = memory.requests
这类Pod的运行优先级最高，但凡这样配置了cpu和内存的limits和requests，它会自动被归为此类。

3.2 Burstable:

每个容器至少定义了CPU，RAM的requests属性，这里说每个容器是指：一个Pod中可以运行多个容器。
那么这类容器就会被自动归为burstable，而此类就属于中等优先级。

3.3 BestEffort:

没有一个容器设置了requests 或 limits，则会归为此类，而此类别是最低优先级。

其实用的最多的是Guranteed，因为谁会这么问一个卖鸡蛋的，你有100斤鸡蛋吗？我要1斤！
查看

kubectl describe pod nginx2 |grep "QoS Class"
QoS Class: Guaranteed

3.3.1 查看nodes使用率

kubectl top nodes

3.3.2 查看cpu、内存使用率

kubectl top pods nginx2
NAME CPU(cores) MEMORY(bytes)
nginx2 1m 14Mi