使用Kubernetes常犯的一些错误

参考文章:

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

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

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

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

使用建议:

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

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

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

关于Memory的有:

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

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

2. Liveness和Readiness探针

使用建议:

除非你有很明确的场景，或者非常了解后果的情况下，通常建议定义且只定义readiness，因为liveness prob是有风险的。
- 确保readiness定义了
- 确保readiness能真实的反映webserver以及对应端口的可用情况
- readiness包含了数据库初始化和migration
- 理解readiness的默认行为：interval: 10s，timeout: 1s，successThreshold: 1， failureThreshold: 3
- 使用一个不同的端口如果可能的话；与正常的流量区分开来
- 可以使用readiness probe作为prewarming / cache loading, 预热节点
Liveness和Readiness probe 尽量不要依赖于外部的dependencies(例如数据库)，
- 避免导致级联失效;
- 低耦合，其他服务的状态由他自己的探针负责;
如果非要设置Liveness，不要使用和Readiness同一个接口
不要使用 "exec" probes

常见错误场景:

没有配置readiness
错误的配置readiness探针
readiness == liveness
没有优雅的关闭
优雅的关闭不够优雅

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

Liveness在探测失败时候会重启节点；
Readiness在探针失败时候，会断开pod与k8s service的连接，并且不会把请求往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"

因为只是调度时候需要检查，因此requiredDuringSchedulingIgnoredDuringExecution。
以上配置会根据"kubernetes.io/hostname"来适用反亲和性，如果有更定制化的HA需求，比如多区域部署，可以go deeper。

常见错误场景：
如果一个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, 导致线上环境出现版本问题。