• Notice of Readiness 什么意思
• 使用Kubernetes常犯的一些错误

Notice of Readiness 什么意思

notice of readiness 英 备装通知，装卸准备完成通知; Give notice of readiness to load by1900 hours local time.当地时间1900时给装货准备就绪通知书。

使用Kubernetes常犯的一些错误

参考文章:

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

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

使用建议 :

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

关于Memory的有:

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

使用建议 :

常见错误场景 :

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

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

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

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

使用建议 : 使用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 来做集群的自动扩容缩容。

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

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

使用建议： 对于有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参数：

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

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

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

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