K8s 比例缩放（Proportional scaling）

# 纯理论学习，可能对解决问题有那么一丝丝的帮助

#比例缩放是滚动更新策略的一种机制。主动触发

官方的解释如下：
        当自动缩放器缩放处于上线进程（仍在进行中或暂停）中的 RollingUpdate Deployment 时， Deployment 控制器会平衡现有的活跃状态的 ReplicaSet（含 Pod 的 ReplicaSet）中的额外副本， 以降低风险。这称为 比例缩放（Proportional Scaling）。

目录

为什么要有比例缩放？

        滚动更新的Deployment 支持同时运行应用程序的多个版本，当自动缩放器处于部署新版本的过程（进行中或暂停，为什么暂停，可能是失败或者手动暂停了）。决定每次扩容几个，关停几个RepolicaSet，降低风险。那么到底扩几个和关几个的？以什么比例作为依据？

使用场景？

1. 正常更新场景 

       学习以下参数

           RollingUpdateStrategy:  25% max unavailable, 25% max surge

           max unavailable:更新过程中不可用数量比例
           max surge：最大冗余，除当前数量外还可增加最大比例（最多125%）

           Events:中Message的输出
   
   先看下面这一段输出：

   RollingUpdateStrategy:  25% max unavailable, 25% max surge
   Pod Template:
     Labels:  app=nginx
      Containers:
       nginx:
         Image:        nginx:1.16.1                  
         Port:         80/TCP                            
         Environment:  <none>                     
         Mounts:       <none>
       Volumes:        <none>
     Conditions:
       Type           Status  Reason
       ----           ------  ------
       Available      True    MinimumReplicasAvailable
       Progressing    True    NewReplicaSetAvailable
     OldReplicaSets:  <none>
     NewReplicaSet:   nginx-deployment-new (3/3 replicas created)
     Events:
       Type    Reason             Age   From                   Message
       ----    ------             ----  ----                   -------
   xx   xx   xx   xx   Scaledup replica set nginx-deployment-old to 3  #旧的要更新3个

   xx   xx   xx   xx   Scaledup replica set nginx-xx-new to 1  #因为参数“25% max surge”，首先生成只生成1个新的，总的运行数是4

   xx   xx   xx   xx   Scaleddown replica set nginx-XX-old to 2  #又因为参数25% max unavailable，旧的减少一个，数值减少到2，总的运行数是3

   xx   xx   xx   xx  Scaledup replica set nginx-XX-new to 2  #新的扩容到2个

   xx   xx   xx   xx  Scaleddown replica set nginx-XX-old to 1  #旧的减少到1个
   xx   xx   xx   xx  Scaledup replicaset nginx-XX-new to 3  #新的扩容到3个
   xx   xx   xx   xx  Scaleddown replica set nginx-XXold to 0  #按此进行，直至完成

        从Events:的messages信息输出中，可以看出更新是按照比例进行的。

2. Deployment被暂停的场景
   因为RollingUpdate 的 Deployment 支持同时运行应用程序的多个版本的能力（我在这里复制粘贴了官方的示例）

例如，你正在运行一个 10 个副本的 Deployment，其 maxSurge=3，maxUnavailable=2。

• 确保 Deployment 的这 10 个副本都在运行。

  kubectl get deploy
  

  输出类似于：

  NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
  nginx-deployment     10        10        10           10          50s
  

• 更新 Deployment 使用新镜像，碰巧该镜像无法从集群内部解析。

  kubectl set image deployment/nginx-deployment nginx=nginx:sometag
  

  输出类似于：

  deployment.apps/nginx-deployment image updated
  

• 镜像更新使用 ReplicaSet nginx-deployment-1989198191 启动新的上线过程， 但由于上面提到的 maxUnavailable 要求，该进程被阻塞了。检查上线状态：

  kubectl get rs
  

  输出类似于：

  NAME                          DESIRED   CURRENT   READY     AGE
  nginx-deployment-1989198191   5         5         0         9s
  nginx-deployment-618515232    8         8         8         1m
  

        #New nginx-deployment-1989198191 为什么DESIRED、CURRENT的值是5

        #因为maxSurge=3，nginx-deployment-1989198191更新第一步生成3个，这样总数就是13个。

        #再根据maxUnavailables=2，nginx-deployment-618515232减去2个，总数11个
        #nginx-deployment-1989198191第二步更新只能扩容2个，保证总数是13个。

        为什么更新到第二步就不更新了，我也没想明白，可能我这个推论就是错误的，以后有时间再研究一下

        
        #Deployment可以确保所创建pod数量比期望值高（默认情况，最多多出125%）
        
        #Old nginx-deployment-618515232 为什么DESIRED、CURRENT、READY的值变成8了，因为maxUnavailables=2。

        #10个运行中的减去2个最大不可运行的

• 然后，出现了新的 Deployment 扩缩请求。自动缩放器将 Deployment 副本增加到 15。 Deployment 控制器需要决定在何处添加 5 个新副本。如果未使用比例缩放，所有 5 个副本 都将添加到新的 ReplicaSet 中。使用比例缩放时，可以将额外的副本分布到所有 ReplicaSet。 较大比例的副本会被添加到拥有最多副本的 ReplicaSet，而较低比例的副本会进入到 副本较少的 ReplicaSet。所有剩下的副本都会添加到副本最多的 ReplicaSet。 具有零副本的 ReplicaSet 不会被扩容。
  
  #Eg:比例计算
  #nginx-deployment-1989198191 的比例为 5 / (5 + 8) ≈ 0.385，追加的个数 5*0.385 ≈ 2
  #nginx-deployment-618515232 的比例为 8 / (5 + 8) ≈ 0.615，追加的个数 5*0.615 ≈ 3

在上面的示例中，3 个副本被添加到旧 ReplicaSet 中，2 个副本被添加到新 ReplicaSet。 假定新的副本都很健康，上线过程最终应将所有副本迁移到新的 ReplicaSet 中。 要确认这一点，请运行：

kubectl get deploy

输出类似于：

NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment     15        18        7            8           7m

 #这种命令输出结果是代表是有异常的，需要排除问题
 

上线状态确认了副本是如何被添加到每个 ReplicaSet 的。

kubectl get rs

输出类似于：

NAME                          DESIRED   CURRENT   READY     AGE
nginx-deployment-1989198191   7         7         0         7m
nginx-deployment-618515232    11        11        11        7m

#这种命令输出结果是代表是有异常的，需要排除问题

       

       

---