? 最近被問到如何理解 k8s 彈性伸縮的這樣的問題库倘，而我最初的回答很簡單也很膚淺，我說：k8s 是 HPA 根據(jù)定義的 metric 閾值 （簡單的 cpu 值或者用戶自定義）來對應(yīng)用進行擴縮容的毡咏。
今天和微博的朋友也聊到了這個話題，他說在他們的場景下 k8s 的彈性擴容是不起作用的务冕，因為在某些熱點新聞的高流量下2分鐘內(nèi)就需要擴容上千臺機器血当，k8s 默認的彈性擴容是解決不了這個問題的 (因為默認的調(diào)度機制是串行的，需要做 hack 才可以)禀忆。
這讓我意識到我想簡單了，其實脫離了場景討論技術(shù)都是不靠譜的落恼。
讓我們回到這個問題的原點 “彈性伸縮”箩退， 那先看看它是如何定義的，
Elastic scaling is the ability to automatically add or remove compute or networking infrastructure based on changing application traffic patterns.
彈性伸縮是一種系統(tǒng)能力佳谦，它可以根據(jù)應(yīng)用的流量變化自動的增加或者刪減資源戴涝。
說到這里，腦海里會出現(xiàn)幾個問題：
- 這里面的一個關(guān)鍵詞是“自動的”钻蔑，那如何實現(xiàn)自動呢啥刻？
根據(jù) cpu 可以嗎？這個就區(qū)分場景了咪笑，絕大多少的線上應(yīng)用不會簡單的依賴 cpu 指標來衡量是否需要擴容可帽，因為這是一個非常復(fù)雜的決策過程，
- 彈性伸縮這種能力哪種場景需要窗怒？我們的場景需要嗎映跟？
根據(jù)定義，只有流量會有突增的場景才會有這個需求扬虚，比如幾年前微博的例子努隙，經(jīng)常幾個明顯緋聞就把系統(tǒng)搞掛了。但這種場景畢竟是很少的辜昵， 而我們自己公司內(nèi)部是用不到的荸镊。而對應(yīng)微博來說，這個功能還比較雞肋，因為它擴容的太慢了躬存，而且如何判斷更是個大難題收厨，超出了 k8s 的管理范疇。
聽完微博朋友介紹了他們的場景优构，想到了之前螞蟻的人介紹他們的雙十一架構(gòu)诵叁，可以很短的時間擴容幾千個機器，怎么做到的呢钦椭？ 把 k8s 默認的調(diào)度算法從原來的順序的調(diào)度改為了批量的調(diào)度拧额，滿足了這個大促的場景。
另外最重要的一點是如何判斷觸發(fā)擴容縮容的時機彪腔，今天從網(wǎng)上的一個 2015 年的論文里找到了一個方法論侥锦，介紹了如何用工業(yè)界的 質(zhì)量控制圖 和 區(qū)間法則找出了異常的數(shù)據(jù)波段，并進行擴容或縮容德挣。大體上微博的做法也和這個類似恭垦，因此了解下這個論文還是很有幫助的。
總之格嗅，k8s HPA 的這個功能只能處理非常簡單的場景番挺，距離真正線上應(yīng)用使用還很遙遠，而且這個功能和 k8s 平臺關(guān)系不大屯掖，應(yīng)該在非 k8s 環(huán)境下就要能夠做到甄別出應(yīng)用的異常流量玄柏。
反思：技術(shù)問題一定要優(yōu)先考慮使用場景，使用場景
論文地址：https://www.sciencedirect.com/science/article/pii/S1877050915030239
