kubernets之带有limit的资源

一  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