在K8s中定义Pod中运行容器有两个维度的限制：
- 资源需求(Requests)：即运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod。否则pod无法启动。如 Pod运行至少需要2G内存，1核CPU。（硬限制）
- 资源限额(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
