建站
咨詢
售后
建站咨詢
新聞中心
這篇文章給大家分享的是有關(guān)Kubernetes有哪些新特性的內(nèi)容。小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過來看看吧。
成都創(chuàng)新互聯(lián)公司從2013年開始，先為尤溪等服務(wù)建站，尤溪等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為尤溪企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。
新特性背景
不同的應(yīng)用程序業(yè)務(wù)價(jià)值不同，其對(duì)擴(kuò)縮容的要求也不同，比如以下三種類型應(yīng)用：
關(guān)鍵流量處理應(yīng)用：該類應(yīng)用希望在流量到來時(shí)快速的擴(kuò)容，在流量高峰過去后，希望慢慢的縮容，以避免流量反彈；
關(guān)鍵數(shù)據(jù)處理應(yīng)用： 該類應(yīng)用希望當(dāng)大量數(shù)據(jù)到達(dá)時(shí)希望快速擴(kuò)容，在數(shù)據(jù)減少時(shí)，希望快速的縮容，以節(jié)省成本；
常規(guī)流量/數(shù)據(jù)處理應(yīng)用：該類應(yīng)用不那么重要，可以緩慢的擴(kuò)容和縮容，以避免快速擴(kuò)縮容帶來抖動(dòng)；
然而當(dāng)前版本的實(shí)現(xiàn)（1.15 & 1.16）并不能很好的滿足這類應(yīng)用的期望。
當(dāng)前版本的 kube-controller-manager 參數(shù) --horizontal-pod-autoscaler-downscale-stabilization 可以在一定程度上控制縮容的速度。在每個(gè)調(diào)度周期（默認(rèn)為30s）都會(huì)計(jì)算出一個(gè)縮放的推薦值并記錄下來，在每次計(jì)算縮放值時(shí)都會(huì)查看歷史的推薦值，從最近的一段歷史推薦值中挑選最大的，downscale-stabilization 就是用來指定這個(gè)時(shí)間窗口，默認(rèn)為5min。
另外在 HPA controller 層面，有兩個(gè)硬編碼的常量控制擴(kuò)容的速度：
scaleUpLimitFactor = 2.0 // 擴(kuò)容倍數(shù)
scaleUpLimitMinimum = 4.0 // 擴(kuò)容個(gè)數(shù)
在計(jì)算擴(kuò)容的目標(biāo)值時(shí)算法如下：
Max(scaleUpLimitFactor*當(dāng)前副本數(shù), scaleUpLimitMinimum))
也就是說，擴(kuò)容要么擴(kuò)成原來的2倍，要么擴(kuò)大4個(gè) pod，二者取大者。 一方面這個(gè)擴(kuò)容速度并不能滿足上面提到的應(yīng)用訴求，另一方面，這個(gè)硬編碼也確實(shí)不夠友好，盡管它設(shè)計(jì)本意是希望穩(wěn)定的擴(kuò)容以避免抖動(dòng)。 注：這里提到的算法是HPA controller層面的，跟據(jù)每個(gè)HPA的當(dāng)前值和目標(biāo)值計(jì)算出擴(kuò)容比例后再套用該算法，以限制擴(kuò)容速度。
縮上所述，當(dāng)前版本的實(shí)現(xiàn)并不能滿足一些應(yīng)用對(duì)擴(kuò)縮容的訴求，我們需要做一些改進(jìn)。 本文的目標(biāo)就是分析社區(qū)對(duì)此需求的討論結(jié)果，算是提前剖析新特性，但最終實(shí)現(xiàn)有可能跟此不一致。
新特性目標(biāo)
結(jié)合前述的背景，不難得出，本次改進(jìn)目標(biāo)有兩點(diǎn)：
允話用戶更精確的控制擴(kuò)縮容速度；
允話用戶在 HPA 層面控制擴(kuò)縮容速度（每個(gè)HPA可以有個(gè)性化的控制）；
新特性設(shè)計(jì)
既然要對(duì)每個(gè) HPA 單獨(dú)控制，那就需要在 HPA 資源API中增加相應(yīng)的參數(shù)，所以將會(huì)引入下面4個(gè)參數(shù)：
periodSeconds（擴(kuò)縮容的周期）
我們知道在kube-controller-manager有個(gè)參數(shù)（--horizontal-pod-autoscaler-sync-period）控制的是 HPA controller 處理周期，每個(gè)周期中處理所有的 HPA（為HPA生成擴(kuò)縮容建議，并執(zhí)行擴(kuò)縮容）。
本次計(jì)劃引入的這個(gè)周期（periodSeconds）控制每個(gè)HPA兩次擴(kuò)縮容操作的間隔，也可以叫冷卻時(shí)間。
percent （擴(kuò)縮容百分比）
顧名思義，這個(gè)是控制擴(kuò)縮容的百分比，可以簡單的理解成把硬編碼的 scaleUpLimitFactor = 2.0 改成可配置項(xiàng)。
例如，ScaleUpPercent = 150，那么每次擴(kuò)容比例為150%（10-->25）。
pods （擴(kuò)縮容個(gè)數(shù)）
這個(gè)是控制每個(gè)擴(kuò)縮容的絕對(duì)個(gè)數(shù)，可以簡單的理解成把硬編碼的 scaleUpLimitMinimum = 4.0 改成可配置項(xiàng)。
例如：ScaleUpPods = 5，那么每次擴(kuò)容的數(shù)量將是5個(gè)（10-->15）。
delay
這個(gè)參數(shù)與kube-controller-manager的horizontal-pod-autoscaler-downscale-stabilization含義一樣， 就是在計(jì)算擴(kuò)縮容時(shí)，我們需要回頭看多久的建議值（從中選最大），可以簡單理解成把kube-controller-manager的參數(shù)下沉到 HPA 層面
需要注意的是，這幾個(gè)參數(shù)既可以控制擴(kuò)容，也可以控制縮容，下面我們給出幾個(gè)示例來說明用法。
新特性示例
Story 1： 我希望應(yīng)用能盡快的擴(kuò)容
當(dāng)希望應(yīng)用能盡快的擴(kuò)容時(shí)，可以使用大一點(diǎn)的percent。比如：
scaleUp
percent = 900 (每次擴(kuò)容900%，即10倍速擴(kuò)容)
假如pod最開始數(shù)量為1，那么擴(kuò)容路徑如下：
1 -> 10 -> 100 -> 1000
當(dāng)然，HPA既有的maxReplicas仍然有效，最大pod數(shù)不能超過此設(shè)置。
Story 2: 我希望應(yīng)用能盡快的擴(kuò)容、逐步的縮容
當(dāng)希望應(yīng)用能盡快的擴(kuò)容，同時(shí)縮容的慢一些時(shí)，可以使用如下配置：
scaleUp
percent = 900
scaleDown
pods = 1 (每次縮容減少一個(gè)pod)
periodSeconds = 600 (每10分鐘縮容一次)
假如pod最開始數(shù)量為1，那么擴(kuò)容路徑如下：
1 -> 10 -> 100 -> 1000
同時(shí)，縮容路徑如下(每10分鐘縮容一次，每次減少一個(gè)pod)：
1000 -> 1000 -> 1000 -> … (7 more min) -> 999
Story 3: 我希望能緩慢擴(kuò)容、正常的縮容
希望緩慢的擴(kuò)容、正常的縮容，可以使用如下配置：
scaleUp
pods = 1
假如pod最開始數(shù)量為1，那么擴(kuò)容路徑如下：
1 -> 2 -> 3 -> 4
Story 4: 我希望正常的擴(kuò)容、不要自動(dòng)縮容
如果希望能正常的擴(kuò)容，但是不要自動(dòng)縮容，可以使用如下配置：
scaleDown:
percent= 0
pods = 0
把縮容的百分比和pod都置為0，那么就永遠(yuǎn)不會(huì)縮容。
Story 5: 我希望更謹(jǐn)慎的縮容
如果希望縮容時(shí)再謹(jǐn)慎些，可以使用delaySeconds(這個(gè)跟kube-controller-manager的horizontal-pod-autoscaler-downscale-stabilization非常類似），配置如下：
scaleDown：
pods = 5
delaySeconds = 600
那么，每次縮容最多減少5個(gè)pod，同時(shí)每次縮容，至少看到之前600s的推薦值，從中選擇最大的值。 這樣，縮容時(shí)就會(huì)變得非常謹(jǐn)慎。
API 變化
API的變化，主要是在HorizontalPodAutoscalerSpec中增加一個(gè)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
}感謝各位的閱讀！關(guān)于“Kubernetes有哪些新特性”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！
本文名稱：Kubernetes有哪些新特性
本文地址：http://fisionsoft.com.cn/article/ghisej.html
