一 pod中容器的limits属性的作用
1.1 创建一个带有资源limits的pod
apiVersion: v1 kind: Pod metadata: name: limited-pod spec: containers: - image: busybox command: ["dd","if=/dev/zero","of=/dev/null"] name: main resources: limits: cpu: 1 memory: 20Mi
- 限制了cpu使用的时间，可以使用cpu的所有运行时间
- 限制了内存只能有20Mi
- 与requests资源不同limits资源可以超卖，即节点上面所有的pod的limits属性之和相加起来可以大于等于100
1.2 当容器内的应用超过这个使用配额的时候会发生什么？
当容器运行的应用超过这个配额的时候，kubernetes会将这个pod杀掉，并且当这个pod的重启策略是always的时候，第一次重启之后，接下来他还会继续重启，而且第二次重启的时间比第一次时间间隔要长，然后一直这样循环往复下去，直达达到300点这个临界值，之后会一直以这个时间进行重复启动，而且pod也会一直处于CrashLoopBackOff状态查询日志或者通过时间可以知道详细的原因
- 这个例子中，容器因为内存不足而被杀死了
1.3 容器中的应用是如何看待limits
在容器中查看内存的时候，显示的是容器所在节点上面的数量，而容器无法感知这个限制，任何利用这个信息来决定使用多少应用来说都具有非常不利的影响，在java应用程序中很有可能会出现OOMkill
容器内同样可以看到所有的所有节点的cpu内核，与内存完全一致，当在容器的limits上面限制了1，容器里面查看的时候也会是64，而且应用能够占用的cpu时间也只能1/64.并且它还不会只在一个cpu上面进行运行，而是会跑满所有的cpu，这对实际生产简直是灾难，它会占用大量的内存
综上所示，不能够依赖应用程序从系统里面或者cpu的数量，而是应该通过downwardAPI的形式将CPU限额传递到容器并使用这个值，或者也可以通过cgroup系统直接获取配置的CPU限制，查看下面所示文件
- /sys/fs/cgroup/cpu/cpu.cfs_quota_us
- /sys/fs/cgroup/cpu/cpu.cfs_period_us