k8s的iptables版本不一样 k8s iptables 性能问题_Pod

QoS

  • 在使用Kubernetes部署时，应用的部署和更新都会经过一系列的调度策略将应用部署在最合适的节点上，但是随着时间的推移，当时“最优”的节点可能已经不再是最佳选择，因为在改服务器上别的应用或者其它管理员部署的应用可能忘记了配置资源限制，所以在日积月累的消耗中，宿主机一些不可压缩的资源（比如内存、磁盘）的使用率将达到最高峰。
  • 例如内存达到最高峰时会引起OOMKilled故障（容器使用的内存资源超过了限制。只要节点有足够的内存资源，那容器就可以使用超过其申请的内存，但是不允许容器使用超过其限制的资源。）此时kubelet会根据某些策略重启上面的容器用来皮面宿主机宕机引来的风险，如果重启的是不叫重要的业务应用，体验很差
  • 这时候就需要Qos来提供某些应用的服务质量

QoS 类

Kubernetes 创建 Pod 时就给它指定了下列一种 QoS 类：

  1. Guaranteed
    最高服务质量，当宿主机内存不够时，会先杀死Qos为Burstable和BestEffort的pod
  2. Burstable
    服务质量低于Guaranteed，当宿主机内存不够时，会先杀死Qos为BestEffort的pod
  3. BestEffort
    尽力而为，当宿主机内存不够时，首先杀死的就是该Qos的pod，用于保证Guaranteed和Burstable级别的pod正常运行

实现一个 QoS 类为 Guaranteed 的 Pod

  • Pod 中的每个容器都必须指定内存限制(limits.memory)和内存请求(requests.memory),并且两者需要相等。
  • Pod 中的每个容器都必须指定CPU 限制(limits.cpu)和CPU 请求(requests.cpu),并且两者需要相等。
apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
  namespace: test
spec:
  containers:
  - name: cpu-demo-ctr
    image: vish/stress
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"
# 查看pod服务质量
[root@vms120 ~]# kubectl get pod cpu-demo -n test -o yaml |grep -i qosClass
  qosClass: Guaranteed

实现一个 QoS 类为 Burstable 的 Pod

  • Pod 不符合Guaranteed的配置要求。
  • Pod 中至少有一个容器配置了requests.memory或者requests.cpu。
apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
  namespace: test
spec:
  containers:
  - name: cpu-demo-ctr
    image: vish/stress
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

# 查看pod服务质量
[root@vms120 ~]# kubectl get pod cpu-demo -n test -o yaml |grep -i qosClass
  qosClass: Burstable

实现一个 QoS 类为 BestEffort 的 Pod

  • Pod 中的所有容器没有设置内存和 CPU 限制或请求。
apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
  namespace: test
spec:
  containers:
  - name: cpu-demo-ctr
    image: vish/stress

# 查看pod服务质量
[root@vms120 ~]# kubectl get pod cpu-demo -n test -o yaml |grep -i qosClass
  qosClass: BestEffort