開篇

是時候給生活來點調味劑了，我就打開 CSDN 逛逛有什么新鮮事。發(fā)現(xiàn)了這樣一個活動：騰訊云 Finops Crane 集訓營。

正好我在上一家公司負責過 Kubernetes 容器集群管理，所以抱著學(na)習(jiang)的目的報名了，想看看這個獲得 FinOps 基金會授予的全球首個認證降本增效開源的方案有何過人之處。

介紹

一直以來，云原生用戶在確保業(yè)務穩(wěn)定和優(yōu)化運營成本之間，做著兩難的選擇，為了保證業(yè)務的穩(wěn)定運行，多數(shù)用戶面臨著服務資源配置浪費、現(xiàn)有資源難以管理、計費方式不夠靈活透明等諸多問題。

基于越來越多的企業(yè)開始擁抱云上服務，騰訊云率先在國內推出了基于云原生技術的成本優(yōu)化開源項目 Crane。

Crane 遵循 FinOps 標準，依托云原生技術，結合智能預測、自動調度、業(yè)務混部等多種手段，將優(yōu)化措施應用到了云成本優(yōu)化的多個關鍵環(huán)節(jié)，以可視化的方式幫助用戶快速決策、簡化運維效率、提升系統(tǒng)穩(wěn)態(tài)、全面降本增效，從而為云原生用戶提供一站式的云成本優(yōu)化解決方案。

那么其實際效果如何呢？

眾所周知網(wǎng)易新聞的體量是非常巨大的，而以其自身的使用來看，Grane 在落地的兩個月內，管控數(shù)萬 CPU 核 ，大盤總核數(shù)縮減11%，下線30臺56C物理機，每個月節(jié)省10W費用。這樣的降本增效效果，堪稱一絕。

搭建環(huán)境

作為一個云服務管理的菜鳥，在先后經(jīng)歷了 Finops Crane 項目直播簡介、開發(fā)者集訓營實戰(zhàn)指導后，我信心滿滿的開始實操了。

第一步

首先需要安裝這幾個東西：kubectl、helm、kind、Docker

分別運行下面的命令

# install kubectl
brew install kubectl

# install helm
brew install helm
# 如果 brew 安裝不成功，試試
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
# 如果還是不能成功，需要配置下科學上網(wǎng)

如果是版本問題，helm 會告訴你，然后升級下系統(tǒng)版本就好了。我用的是個老的mac 直接在 helm 這里就卡住了，然后換了公司的電腦，還算順利。

# install kind
brew install kind
# 這里需要驗證下是否裝成功了，運行
kind create cluster --help

最后安裝下 docker
傳送門，直接點擊對應的版本，下載，安裝就可以了。

第二步

接下來，本地安裝 Crane 并成功啟動

mkdir training 
cd training
# 這一步可能需要科學上網(wǎng)
curl -sf https://raw.githubusercontent.com/gocrane/crane/main/hack/local-env-setup.sh | sh -

這一步也是有點慢，最后裝完的時候會提示你運行兩個命令來訪問 Crane Dashboard，看下圖

# 按照上圖的提示執(zhí)行這兩個命令，這一步配置 KUBECONFIG 環(huán)境變量，
export KUBECONFIG=${HOME}/.kube/config_crane
# 這一步部署運行 crane-system項目
kubectl get deploy -n crane-system

出現(xiàn)下面的截圖就算是成功

繼續(xù)運行

kubectl get pod -n crane-system

看到系統(tǒng)中的鏡像狀態(tài)，有的已經(jīng)啟動，有的則還在拉取，有的正在創(chuàng)建，這時候依然耐心等待，一直到所有的鏡像都運行

第三步

直接運行下面的命令

kubectl -n crane-system port-forward service/craned 9090:9090

這一步是把 Kubernetes 內部 service/craned 服務的端口 9090 映射到宿主機的9090，這樣可以通過本地主機訪問 Kubernetes 操作的內部集群

這樣就可以訪問 Grane 的 dashboard 了。

??：后續(xù)的所有操作都需要在一個新的終端上進行，開始一個新終端，需要再次運行export KUBECONFIG=${HOME}/.kube/config_crane

添加集群

在頁面中點擊添加集群，地址填寫： http://dashboard.gocrane.io

鏈接成功后就可以在首頁看到數(shù)據(jù)信息

成本洞察

成本洞察可以快速查看集群中的相關信息，比如 cpu 、 內存等占用信息，各個應用信息，成本，碳排放等。這里不做過多的贅述。

成本分析

成本分析模塊會自動分析集群中各種資源的運行情況并給出優(yōu)化的建議。其實現(xiàn)的流程為：

從上圖可以看出，成本分析模塊會執(zhí)行四個步驟：

1. 從監(jiān)控系統(tǒng)拉取用量數(shù)據(jù)
2. 從Kubernetes平臺拉取作業(yè)配置信息
3. 從云廠商計費API拉取資源單價
4. 通過多種算法分析成本組成并給出優(yōu)化建議

整個分析過程中的數(shù)據(jù)會首先通過可視化面板展示給用戶

那么，Grane 是通過什么東西進行的成本分呢？點開推薦規(guī)則，可以看到系統(tǒng)內置了兩條規(guī)則

Grane正是依據(jù)這兩個文件中的規(guī)則來進行成本分析的。

我們可以運行這個命令(新終端)：kubectl get RecommendationRule，來查看這兩個內置的文件。

資源推薦與副本數(shù)

通過上面的成本分析，最后會生成一個資源推薦列表，并且資源推薦會提供多種 Recommender 來實現(xiàn)針對不同資源的優(yōu)化建議。

這樣做的一個顯而易見的好處在于，我們在配置應用資源時常常是基于自己的經(jīng)驗或者網(wǎng)上的信息來設置 request 和 limit，但是這種設置是否真的適用于當前場景猶未可知。

通過成本分析的算法分析應用的真實用量，從而推斷出更有效的資源配置，可以幫助我們大大提升集群的資源利用效率。

當然，對于副本數(shù)也是一樣的。大部分用戶在創(chuàng)建應用資源時通?；谶^往經(jīng)驗來配置副本數(shù)。副本數(shù)推薦算法能夠分析應用的真實用量，因此能推薦給用戶更合適的副本配置，參考它可以大大提升集群的資源利用率。

智能預測與自動擴縮容

除了推薦的相關內容，成本分析還列出了一段時間內的閑置節(jié)點，從而讓用戶根據(jù)需要來自由的擴容或者縮容。

??：應用在監(jiān)控系統(tǒng)（比如 Prometheus）中的歷史數(shù)據(jù)越久，推薦結果就越準確，建議生產上超過兩周時間。對新建應用的預測往往不準。

EHPA

當然了，除了手動的擴容與縮容，Grane 還能自動實現(xiàn)擴縮容。Grane 基于社區(qū) HPA 做底層的彈性控制實現(xiàn)了一個名為 EffectiveHorizontalPodAutoscaler（簡稱 EHPA）的彈性伸縮產品，支持豐富的彈性觸發(fā)策略（預測，觀測，周期），例如：

• 提前擴容：算法預測未來的流量洪峰，如保證節(jié)假日的流量洪峰，避免服務器突增大量流量導致的擁堵甚至宕機。
• 減少無效縮容：預測未來可減少不必要的縮容，穩(wěn)定工作負載的資源使用率，消除突刺誤判。
• 支持 Cron 配置：支持 Cron-based 彈性配置，應對大促等異常流量洪峰。
• 兼容社區(qū)：使用社區(qū) HPA 作為彈性控制的執(zhí)行層，能力完全兼容社區(qū)。

EHPA 采用時間序列算法（FFT快速傅里葉變換算法），基于 Custom Metric，可靠性與準確性都比較高，而且完全兼容社區(qū) HPA ，支持 Dryrun 觀測，指標支持 Prometheus Metric，可以說是 Grane 的超級手指。

那么如何使用這個超級手指呢？

安裝Metrics Server

首先安裝 Metrics Server，依然是在新的那個終端上運行下面的命令：

kubectl apply -f installation/components.yaml
kubectl get pod -n kube-system

創(chuàng)建測試應用

接下來創(chuàng)建用于測試的應用：啟動一個 Deployment 用 hpa-example 鏡像運行一個容器， 然后將其暴露為一個 服務（Service）

kubectl apply -f https://raw.githubusercontent.com/gocrane/crane/main/examples/autoscaling/php-apache.yaml
kubectl apply -f https://raw.githubusercontent.com/gocrane/crane/main/examples/analytics/nginx-deployment.yaml

創(chuàng)建 EffectiveHPA

運行

kubectl apply -f https://raw.githubusercontent.com/gocrane/crane/main/examples/autoscaling/effective-hpa.yaml

# 查看 EffectiveHPA 的當前狀態(tài)：
kubectl get ehpa

可以看到這樣的數(shù)據(jù)即是成功

增加負載

# 在單獨的終端中運行它
# 如果你是新創(chuàng)建請配置環(huán)境變量 
export KUBECONFIG=${HOME}/.kube/config_crane

# 以便負載生成繼續(xù)，你可以繼續(xù)執(zhí)行其余步驟
kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
# 現(xiàn)在執(zhí)行
# 準備好后按 Ctrl+C 結束觀察
kubectl get hpa ehpa-php-apache --watch

隨著請求增多，CPU利用率會不斷提升，可以看到 EffectiveHPA 會自動擴容實例。

整體流程

其整體流程如下圖所示：

調度優(yōu)化

Kubernetes 原生調度器只能通過資源的 requests 值來調度 pod，這很容易導致負載不均的問題：

• 實際負載與資源請求相差不大，導致很大概率出現(xiàn)穩(wěn)定性問題。

• 實際負載遠小于資源請求，導致資源的巨大浪費。

基于這個問題，Grane 也交出了一份比較給力的答卷。Crane-scheduler 是一個可以實現(xiàn)負載感知調度和拓撲感知調度的調度器插件。

負載感知調度

1. 基于真實負載的調度器
2. 底層依賴 Prometheus 采集的真實負載，代替Request值
3. 引入節(jié)點歷史負載指標 (1h內最大利用率，1天內最大利用率)，感知業(yè)務波峰

如圖所示：根據(jù)預選策略（剔除高負載節(jié)點）和優(yōu)選策略（優(yōu)先低負載節(jié)點），動態(tài)地調度任務到不同的節(jié)點上，以達到負載均衡的目的，可以有效地提高系統(tǒng)的資源利用率和任務執(zhí)行效率。

拓撲感知調度

1. 優(yōu)先選擇Pod能綁定在單NUMA Node內的節(jié)點
2. 優(yōu)先選擇在同一個NUMA Socket內的NUMA Node
3. 優(yōu)先選擇空閑資源更多的NUMA Node
4. 解決原生CPU Manager導致集群負載過低的問題

Grane 拓撲感知調度基于TEG星辰算力團隊的技術支撐，通過感知網(wǎng)絡的拓撲結構，將任務分配到網(wǎng)絡拓撲結構相近的節(jié)點上，從而減小任務執(zhí)行的時延和能耗，并提高任務執(zhí)行的效率，保證系統(tǒng)的性能和可靠性。

混部

1. 業(yè)界首創(chuàng)無侵入架構
2. 聲明式節(jié)點和業(yè)務QoS規(guī)則管理
3. 多算法支持
4. 依托騰訊TencentOS的全維度資源隔離

混部內核確保高優(yōu)業(yè)務穩(wěn)定性，可參考下面的圖

以上就是關于 Grane 的一些知識整理。

清理環(huán)境

實操完成以后，可以將本地的集群清理刪除：

kind delete cluster --name=crane

關于 pr & issue

項目鼓勵所有參與者積極提交 issue 和 pr。

畢竟眾人拾柴火焰高，尤其開源項目，想要走的更遠，除了項目的參與者持之以恒的燃燒熱情和奉獻自己，社區(qū)和其他個人的關注與參與也是必不可少的一部分。

所以我也在力所能及的范疇提交了兩個 pr，從 pr 的整體流程上和與項目開發(fā)者的溝通上看，著實學到了很多東西。

小伙伴有興趣也可以看看：pr776

提交的幾個 issue 都是在使用的過程中發(fā)現(xiàn)的，有的順手做了修復，無能為力的就只能單純的提交等反饋。

Grane的開源地址在這里?? 傳送（PS：離開前請記得評論收藏點贊哦）

總結

這次活動，總體來說讓我受益匪淺。

拋開可能獲得的物質獎勵，參與活動的這些天，讓人感覺很充實，仿佛一下子回到了大學的時候。曾經(jīng)在五月的花海為社團活動四處奔走，與這種在工作之外的細碎時光里忙碌于自己的所想，何其相似呢。

作為一個技術菜鳥，我每天都忙碌于和需求與bug的相愛相殺之中，只不過日復一日，周復一周，日子總有種平平無奇的趕腳，陷落于幾個項目代碼的固定枷鎖，久而忘記作為技術人的安身立命之本，是不斷的學習和超越。

這次參與騰訊云聯(lián)合 CSDN 的【騰訊云 Finops Crane 集訓營】活動，正好是個提升的機會，讓我對之前一直不怎么趁手的 Kubernetes 有了更多的信心。

尤其是來自于項目核心團隊的老師，在直播間里從零開始的講解，每一個步驟能夠遇到的問題都有說明，每一個關鍵環(huán)節(jié)的操作都有演示，事無巨細，精益求精。

而且活動還提供了錄播，方便我這種掉隊的可以二刷三刷四刷，這哪是活動啊，這不是福利嗎！（??）

當然由于本人是一枚菜鳥，還在持續(xù)不斷的學習之中，所以內容就先到這里了，后續(xù)學習新的內容我也會隨時更新，歡迎志同道合的朋友們點贊收藏。

PS：關于騰訊云 Finops Crane 集訓營

Finops Crane集訓營主要面向廣大開發(fā)者，旨在提升開發(fā)者在容器部署、K8s層面的動手實踐能力，同時吸納Crane開源項目貢獻者，鼓勵開發(fā)者提交issue、bug反饋等，并搭載線上直播、動手實驗組隊、有獎征文等系列技術活動。既能讓開發(fā)者通過活動對 Finops Crane 開源項目有深入了解，同時也能幫助廣大開發(fā)者在云原生技能上有實質性收獲。
為獎勵開發(fā)者，我們特別設立了積分獲取任務和對應的積分兌換禮品。

??活動介紹送門：https://marketing.csdn.net/p/038ae30af2357473fc5431b63e4e1a78

??開源項目： https://github.com/gocrane/crane文章來源地址http://www.zghlxwxcb.cn/news/detail-457515.html

到了這里，關于【騰訊云 Finops Crane 集訓營】學習云原生成本優(yōu)化的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！