Kubernetes Note 05

• 对于一个 Deployment 所管理的 Pod，它的 ownerReference 是 ReplicaSet
• ReplicaSet 负责通过控制器模式，保证系统中 Pod 的个数永远等于指定的个数
• Deployment 只允许容器的 restartPolicy=Always
• 水平扩展
  • $ kubectl scale deployment nginx-deployment --replicas=4
• 滚动更新
  • RollingUpdateStrategy，
    • maxSurge 指定的是除了 DESIRED 数量之外，在一次“滚动”中，Deployment 控制器还可以创建多少个新 Pod
    • maxUnavailable 指的是，在一次“滚动”中，Deployment 控制器可以删除多少个旧 Pod
• 如何让 Deployment 回滚到以前的旧版本呢
  • $ kubectl rollout undo deployment/nginx-deployment
  • $ kubectl rollout history deployment/nginx-deployment
  • $ kubectl rollout history deployment/nginx-deployment --revision=2
  • $ kubectl rollout undo deployment/nginx-deployment --to-revision=2
• 如何控制这些“历史”ReplicaSet 的数量呢
  • Deployment 对象有一个字段，叫作 spec.revisionHistoryLimit，就是 Kubernetes 为 Deployment 保留的“历史版本”个数。所以，如果把它设置为 0，就再也不能做回滚操作了
• 金丝雀发布（Canary Deployment）
  • 优先发布一台或少量机器升级，等验证无误后再更新其他机器。优点是用户影响范围小，不足之处是要额外控制如何做自动更新
• 蓝绿发布（Blue-Green Deployment）
  • 2 组机器，蓝代表当前的 V1 版本，绿代表已经升级完成的 V2 版本。通过 LB 将流量全部导入 V2 完成升级部署。优点是切换快速，缺点是影响全部用户

StatefulSet

• 实例之间有不对等关系，以及实例对外部数据有依赖关系的应用，就被称为“有状态应用”（Stateful Application)
• StatefulSet 把真实世界里的应用状态，抽象为了两种情况
  • 拓扑状态
  • 存储状态
• StatefulSet 的核心功能，就是通过某种方式记录这些状态，然后在 Pod 被重新创建时，能够为新 Pod 恢复这些状态
• Service 访问模式
  • Service 的 VIP（Virtual IP，即：虚拟 IP）方式
  • Service 的 DNS 方式
    • Normal Service, 解析到 Service 的 VIP
    • Headless Service, 解析到的，直接就是 svc 代理的某一个 Pod 的 IP 地址
• Headless Service 不需要分配一个 VIP，而是可以直接以 DNS 记录的方式解析出被代理 Pod 的 IP 地址.
• 创建了一个 Headless Service 之后，它所代理的所有 Pod 的 IP 地址，都会被绑定一个这样格式的 DNS 记录
  • <pod-name>.<svc-name>.<namespace>.svc.cluster.local
  • 这个 DNS 记录，是 Kubernetes 项目为 Pod 分配的唯一的可解析身份（Resolvable Identity）
• StatefulSet 保证了 Pod 网络标识的稳定性
• StatefulSet 这个控制器的主要作用之一，就是使用 Pod 模板创建 Pod 的时候，对它们进行编号，并且按照编号顺序逐一完成创建工作。而当 StatefulSet 的“控制循环”发现 Pod 的“实际状态”与“期望状态”不一致，需要新建或者删除 Pod 进行“调谐”的时候，它会严格按照这些 Pod 编号的顺序，逐一完成这些操作。
• 通过 Headless Service 的方式，StatefulSet 为每个 Pod 创建了一个固定并且稳定的 DNS 记录，来作为它的访问入口