K8s | Depolymnet、ReplicaSet、Pod之间的关系

• 只有容器能保证自己始终是 Running 状态的前提下，ReplicaSet 调整 Pod 的个数才有意义
  也正是 Deployment 只允许容器的 restartPolicy=Always的原因

• deployment状态字段

  • kubectl scale deployment nginx-deployment –replicas=4 水平扩展

  • kubectl rollout status deployment/nginx-deployment
    查看 nginx-deployment 的状态变化

• ReplicaSet 的 DESIRED、CURRENT 和 READY 字段的含义，和 Deployment 一致。
  相比之下，Deployment 只是在 ReplicaSet 的基础上，添加了 UP-TO-DATE 这个跟版本有关的状态字段

• 使用 Pod 的 Health Check 机制检查应用的运行状态，当“滚动更新”停止，旧版本还能继续服务
  容器 Running 状态时，但服务很有可能尚未启动，“滚动更新”的效果也就达不到了

• Deployment、ReplicaSet 和 Pod 的关系.

  • Deployment 的控制器控制的是 ReplicaSet 的数目（描述应用的版本），以及每个ReplicaSet 的属性（来保证 Pod 的副本数量）
    ：Deployment 控制 ReplicaSet（版本），ReplicaSet 控制 Pod（副本数）——deploy的yaml文件中同时定义replicaset和container，replicaset的replicas字段就是控制副本数的

  • 1个应用的版本，对应的是1个 ReplicaSet，这个版本应用的 Pod 数量，则由ReplicaSet 通过它自己的控制器（ReplicaSet Controller）来保证

    • 对 Deployment 进行的每一次更新操作，都会生成一个新的 ReplicaSet 对象,会比较浪费资源

      • 1、kubectl rollout
        在更新 Deployment 前，先执行 kubectl rollout pause deployment/nginx-deployment 让Deployment 处于“暂停”状态，这时对 Deployment 的所有修改，都不会触发新的“滚动更新”，也不会创建新的 ReplicaSet最后执行 kubectl rollout resume deploy/nginx-deployment 恢复回来

      • 2、Deployment 对象字段， spec.revisionHistoryLimit
        k8s为 Deployment 保留的“历史版本”个数，设置为 0，就再也不能做回滚操作了