使用Kubernetes常犯的一些错误

2020-08-09  本文已影响0人  rhuanhuan

参考文章:

主要参考了网上的一些文章和自己日常使用的一些小结，以下是一些我们经常看到的错误：

  1. 资源（resources）——requests和limits配置不合理
  2. Liveness和Readiness探针配置不合理
  3. 为每个http服务都设置负载均衡
  4. 使用非Kubernetes感知的集群自动扩展
  5. 未定义pod的反亲和性
  6. 没有使用PodDisruptionBudget
  7. 多租户或多环境共享集群
  8. 使用latest标签

1. 资源（resources）——requests和limits

这个绝对是最值得注意以及最先拿出来讲解的。

使用建议:

  1. CPU通常只建议设置一个较为合理的 request，而无需设置limit；
  2. Memory通常建议设置成为 Guaranteed QoS，即request == limit；

常见的错误场景及可能导致的结果
关于CPU的有:

  1. 不设置 CPU request; （会导致资源抢占，驱逐pod，乃至集群雪崩）
  2. 将CPU请求设置得很低;（这样我们就可以在每个节点上容纳很多Pod。但是当pod负载过高时，pod仅能获取他所请求的那部分资源，会导致资源的限制成为瓶颈）
  3. 给CPU 设置limit ; (在CPU负载高的时候，workload的CPU limit成为瓶颈，导致延迟、超时等问题；关于CPU的limit有一些围绕CPU CFS和CPU limit的讨论，但是通常认为设置CPU limit会引发更多的问题)

关于Memory的有:

  1. 没有把Memory设置成为 “Guaranteed QoS”
    Memory不像CPU，CPU不够的时候会成为瓶颈，而Memory不够的时候会导致OOM错误；如果想尽量保证服务的稳定性，就设置成 “Guaranteed QoS”；

关于具体值的设置可以通过prometheus这类监控工具查看集群状态和pod的指标来判断。 GCP的VerticalPodAutoScaler 也可以帮助自动化这个过程。

2. Liveness和Readiness探针

使用建议:

常见错误场景:

Liveness和Readiness probe的关系容易混淆。他们都在pod的全生命周期执行

如果一个配置了readiness的节点在请求量过大的时候，readiness可能失效，于是该节点暂时不再处理更多的请求；但是当节点负载慢慢降低，readiness恢复时候，节点又能够正常的处理请求。
但是如果该节点配置了相同的liveness 探针并且也失效了，那么该节点就会重启。为什么你需要重启一个健康的、并且正在处理很多请求的节点呢？

3. 为每个http服务都设置负载均衡

使用建议:
如果需要对外暴露接口的时候，最好使用ingress；或者使用"type: NodePort" 类型的service。

不要把每个Service设置成"type: LoadBalancer" 类型，该类型会调用云提供商的接口创建额外的资源，通常包括IP以及一些额外的计算资源；如果所有Service都是用该类型通常会有很多额外的花费

4. 使用非Kubernetes感知的集群自动扩展

使用建议:
使用auto scaler的时候，使用官方或社区推荐的auto scaler

当在集群里面添加/删除node的时候，你不应该只考虑CPU/Memory的限制这些指标，还要考虑k8s中一些调度的约束，比如：pod & node affinities，taints & tolerations, resource request, QoS等。Scaling-in 也就是移除节点的过程会更加的复杂，例如stateful的pod与pv有绑定，而pv通常又属于某个特定的zone的时候。

在使用auto-scaler 时候，auto scaler也需要理解这些配置，否则会导致pod调度失败。目前社区通常使用cluster-autoscaler 来做集群的自动扩容缩容。

5. 未定义pod的反亲和性

使用建议:
明确的声明反亲和性，确保pod会调度到不同的node上:

// omitted for brevity
      labels:
        app: zk
// omitted for brevity
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

常见错误场景：
如果一个deployment为了高可用声明了三个pod，但是这三个pod被调度到一个node上了，那么当这个node 挂掉的时候，这个deployment所有的服务都不可用了。

6. 没有使用PodDisruptionBudget

使用建议：
对于有HA需求的pod， 设置PodDisruptionBudget。
PodDisruptionBudget 控制器来保证在主动销毁应用POD的时候，不会一次性销毁太多的应用pod，从而保证业务不中断或业务SLA不降级。
Cluster Managers 或者host provider 应当使用能识别 PodDisruptionBudget 的eviction API 而不是直接删除 pod, 例如kubectl drain 命令。当要drain一个node的时候， kubectl drain 会尝试不停的evict对应机器上所有的pods, 请求也许会被temporarily的失败，但是会不停的重试直到所有的pod都Terminated，或者达到了配置的timeout时间。
更多的细节介绍。

1、下面的例子使用了minAvailable参数：

apiVersion: policy/v1beta1  
kind: PodDisruptionBudget  
metadata:  
  name: zk-pdb  
spec:  
  minAvailable: 2  
  selector:  
    matchLabels:  
      app: zookeeper

2、下面的例子使用了maxUnavailable参数：

apiVersion: policy/v1beta1  
kind: PodDisruptionBudget  
metadata:  
  name: zk-pdb  
spec:  
  maxUnavailable: 1  
  selector:  
    matchLabels:  
      app: zookeeper

当zk-pdb对象副本数是3的时候，上面这两个例子所表达的意思是一样的。

7. 多租户或多环境共享集群

使用建议：
k8s的namespace并不提供很强的隔离性，因此尽量不要使用namespace来做多环境多租户的隔离，例如不要把dev，qa，staging，sandbox这些环境和prod部署到一个集群里面。
尽管有一些资源公平性的配置，如: resource requests/limits, quotas, priorityClasses; 以及一些隔离性的配置，如: affinities，tolerations, taints；但是为了达到隔离，通常需要极为复杂的配置。
因此大部分时候，使用多个集群会更加的易于维护。

8. 使用latest标签

使用建议：
不要在deployment中的镜像使用:latest标签，而是使用固定的版本。
否则可能会导致部署时候，k8s node使用本地的旧版本的image, 导致线上环境出现版本问题。

上一篇 下一篇

猜你喜欢

热点阅读