k8s的内存分配

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

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

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

在K8s的资源：
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.

内存:
　　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类型：
　Guranteed:
　　每个容器的CPU，RAM资源都设置了相同值的requests 和 limits属性。
　　简单说： cpu.limits = cpu.requests
　　　　　　 memory.limits = memory.requests
　　这类Pod的运行优先级最高，但凡这样配置了cpu和内存的limits和requests，它会自动被归为此类。
　Burstable:
　　　　每个容器至少定义了CPU，RAM的requests属性，这里说每个容器是指：一个Pod中可以运行多个容器。
　　　　那么这类容器就会被自动归为burstable，而此类就属于中等优先级。
　BestEffort:
　　　　没有一个容器设置了requests 或 limits，则会归为此类，而此类别是最低优先级。

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

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

查看nodes使用率

kubectl top nodes

查看cpu、内存使用率

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