这篇文章给大家分享的是有关Kubernetes有哪些新特性的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。
不同的应用程序业务价值不同，其对扩缩容的要求也不同，比如以下三种类型应用：
关键流量处理应用：该类应用希望在流量到来时快速的扩容，在流量高峰过去后，希望慢慢的缩容，以避免流量反弹；
关键数据处理应用： 该类应用希望当大量数据到达时希望快速扩容，在数据减少时，希望快速的缩容，以节省成本；
常规流量/数据处理应用：该类应用不那么重要，可以缓慢的扩容和缩容，以避免快速扩缩容带来抖动；
然而当前版本的实现（1.15 & 1.16）并不能很好的满足这类应用的期望。
当前版本的 kube-controller-manager 参数 --horizontal-pod-autoscaler-downscale-stabilization 可以在一定程度上控制缩容的速度。在每个调度周期（默认为30s）都会计算出一个缩放的推荐值并记录下来，在每次计算缩放值时都会查看历史的推荐值，从最近的一段历史推荐值中挑选最大的，downscale-stabilization 就是用来指定这个时间窗口，默认为5min。
另外在 HPA controller 层面，有两个硬编码的常量控制扩容的速度：
scaleUpLimitFactor = 2.0 // 扩容倍数
scaleUpLimitMinimum = 4.0 // 扩容个数
在计算扩容的目标值时算法如下：
Max(scaleUpLimitFactor*当前副本数, scaleUpLimitMinimum))
也就是说，扩容要么扩成原来的2倍，要么扩大4个 pod，二者取大者。 一方面这个扩容速度并不能满足上面提到的应用诉求，另一方面，这个硬编码也确实不够友好，尽管它设计本意是希望稳定的扩容以避免抖动。 注：这里提到的算法是HPA controller层面的，跟据每个HPA的当前值和目标值计算出扩容比例后再套用该算法，以限制扩容速度。
缩上所述，当前版本的实现并不能满足一些应用对扩缩容的诉求，我们需要做一些改进。 本文的目标就是分析社区对此需求的讨论结果，算是提前剖析新特性，但最终实现有可能跟此不一致。
结合前述的背景，不难得出，本次改进目标有两点：
允话用户更精确的控制扩缩容速度；
允话用户在 HPA 层面控制扩缩容速度（每个HPA可以有个性化的控制）；
既然要对每个 HPA 单独控制，那就需要在 HPA 资源API中增加相应的参数，所以将会引入下面4个参数：
我们知道在kube-controller-manager有个参数（--horizontal-pod-autoscaler-sync-period）控制的是 HPA controller 处理周期，每个周期中处理所有的 HPA（为HPA生成扩缩容建议，并执行扩缩容）。
本次计划引入的这个周期（periodSeconds）控制每个HPA两次扩缩容操作的间隔，也可以叫冷却时间。
顾名思义，这个是控制扩缩容的百分比，可以简单的理解成把硬编码的 scaleUpLimitFactor = 2.0 改成可配置项。
例如，ScaleUpPercent = 150，那么每次扩容比例为150%（10-->25）。
这个是控制每个扩缩容的绝对个数，可以简单的理解成把硬编码的 scaleUpLimitMinimum = 4.0 改成可配置项。
例如：ScaleUpPods = 5，那么每次扩容的数量将是5个（10-->15）。
这个参数与kube-controller-manager的horizontal-pod-autoscaler-downscale-stabilization含义一样， 就是在计算扩缩容时，我们需要回头看多久的建议值（从中选最大），可以简单理解成把kube-controller-manager的参数下沉到 HPA 层面
需要注意的是，这几个参数既可以控制扩容，也可以控制缩容，下面我们给出几个示例来说明用法。
当希望应用能尽快的扩容时，可以使用大一点的percent。比如：
scaleUp
percent = 900 (每次扩容900%，即10倍速扩容)
假如pod最开始数量为1，那么扩容路径如下：
1 -> 10 -> 100 -> 1000
当然，HPA既有的maxReplicas仍然有效，最大pod数不能超过此设置。
当希望应用能尽快的扩容，同时缩容的慢一些时，可以使用如下配置：
scaleUp
percent = 900
scaleDown
pods = 1 (每次缩容减少一个pod)
periodSeconds = 600 (每10分钟缩容一次)
假如pod最开始数量为1，那么扩容路径如下：
1 -> 10 -> 100 -> 1000
同时，缩容路径如下(每10分钟缩容一次，每次减少一个pod)：
1000 -> 1000 -> 1000 -> … (7 more min) -> 999
希望缓慢的扩容、正常的缩容，可以使用如下配置：
scaleUp
pods = 1
假如pod最开始数量为1，那么扩容路径如下：
1 -> 2 -> 3 -> 4
如果希望能正常的扩容，但是不要自动缩容，可以使用如下配置：
scaleDown:
percent= 0
pods = 0
把缩容的百分比和pod都置为0，那么就永远不会缩容。
如果希望缩容时再谨慎些，可以使用delaySeconds(这个跟kube-controller-manager的horizontal-pod-autoscaler-downscale-stabilization非常类似），配置如下：
scaleDown：
pods = 5
delaySeconds = 600
那么，每次缩容最多减少5个pod，同时每次缩容，至少看到之前600s的推荐值，从中选择最大的值。 这样，缩容时就会变得非常谨慎。
API的变化，主要是在HorizontalPodAutoscalerSpec中增加一个Constraints字段。
type HPAScaleConstraintValue struct {
Rate *HPAScaleConstraintRateValue
DelaySeconds *int32
type HPAScaleConstraintRateValue struct {
Pods *int32
Percent *int32
PeriodSeconds *int32
}
type HPAScaleConstraints struct {
ScaleUp *HPAScaleConstraintValue
ScaleDown *HPAScaleConstraintValue
}
type HorizontalPodAutoscalerSpec struct {
ScaleTargetRef CrossVersionObjectReference
MinReplicas *int32
MaxReplicas int32
Metrics []MetricSpec
Constraints *HPAScaleConstraints
}感谢各位的阅读！关于“Kubernetes有哪些新特性”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
