1.Deployments哪些因素，会导致进入失败状态？
1）配额不足
2）就绪探测失败
3）镜像拉取错误
4）权限不足
5）限制范围问题
6）以及应用程序运行时的配置错误等，可能会导致DM失败
2.可以自定义Pod-template-hash标签嘛?
1）k8s官方说明:不要更改此标签
2）这个标签的主要目的是确保DM的子ReplicaSets不重叠。
通过哈希处理,确保DM中的RS具有不同的标签选择器,Pod模板标签不重复，避免上面说的那个竞争排斥问题。
3.什么场景下会触发Deployments上线动作?
1）仅当Deployment Pod 模板(即spec.template)发生改变时，才会触发Deployment上线。
其他更新(如对Deployment执行扩缩容的操作)不会触发上线动作
4.Deployments在更新时会关闭所有Pod？如果不是,默认关闭最大比例是多少?
1）DM在更新时仅关闭一定数量的Pod，maxUnavailable 最大不可用比例为25%,最多关闭25%的Pod。
默认情况下,它确保至少所需Pods 75%处于运行状态,能正常提供服务。
同样默认情况下,它还确保启动的Pod个数比期望个数最多多出25%。
5.简单描述一下Deployments更新时RS和Pod是如何滚动更新的?
1）如果不去更改默认的最大不可用比例和最大运行峰值比例。
那么DM更新时,会创建新版本RS,并将其进行扩容,控制到Pod副本数量满足最大运行峰值比例。
然后达到比例后,DM会停止新版RS扩容,不会再创建新版Pod,直到DM杀死足够多的旧版Pod。
再接下来对旧版本RS进行缩容操作,控制去除Pod副本数量满足最大不可用比例。
同样,达到比例后,DM会停止旧版RS删除。
不会再继续删除旧版Pod,直到DM创建到足够多的新版Pod。
此为一轮更新,DM不断的进行滚动更新上述操作。
直到旧版RS,旧版Pod副本数为0,新版副本数稳定,停止滚动更新。
6.如何判定Deployment上线过程是否出现停滞?
1）检测此状况的一种方法是在Deployment 规约中指定截止时间参数.spec.progressDeadlineSeconds，一旦超过Deployment 进度限期,Kubernetes将更新DM状态和进度状况的原因。
可以使用kubectl rollout status 检查Deployment是否未能取得进展，如果Deployment 已超过进度限期, kubectl rollout status 返回零退出代码
2）判断停滞,这时候我们可以在上线过程中间安全地暂停Deployment ,对其进行上线修复
7.假设排查出停滞原因是配额不足，给出常用解决方案？
1）可以直接在命名空间中，增加配额来解决配额不足的问题。
配额条件满足, Deployment控制器完成了Deployment上线操作。
Deployment 状态会更新为成功状况(Status=True and Reason=NewReplicaSetAvailable)
8.考点之保存修订历史会消耗 etcd 中的资源，并占用 kubectl get rs 的输出，如果给修订历史限制值设置为0是不是就能有效解决这个问题？
1）.spec.revisionHistoryLimit 是一个可选字段，用来设定为回滚操作所备份保留的旧 ReplicaSet 数量。
这些旧 ReplicaSet 会消耗 etcd 中的资源，并占用 kubectl get rs 的输出。
每个 Deployment 修订版本的配置都存储在其 ReplicaSets 中；
因此，一旦删除了旧的 ReplicaSet， 将失去回滚到 Deployment 的对应修订版本的能力。
默认情况下，系统保留 10 个旧 ReplicaSet，但其理想值取决于新 Deployment 的频率和稳定性。
如果给修订历史限制值设置为0，将导致 Deployment 的所有历史记录被清空。
没有了历史备份，因此 Deployment 将无法回滚，无法撤消新的 Deployment 上线。
总结：虽然可以减少etcd的资源消耗，但是不利于k8s集群实现故障容错、高可用。为了节约一些资源，而放弃容错，高可用性质，只能说，非常非常非常，不值得。
网友评论