隨著云原生技術(shù)的發(fā)展，越來越多的公司正在選擇將應(yīng)用運行在云上或者自建的 Kubernetes 集群上，但是許多機構(gòu)的調(diào)研發(fā)現(xiàn)，絕大多數(shù)的用戶集群資源利用率并不高，浪費嚴重。本文就帶大家來了解Crane，以及通過實踐，體驗它的魅力。
Crane是什么
Crane 是由騰訊云主導開源的國內(nèi)第一個基于云原生技術(shù)的成本優(yōu)化項目，同時遵循 FinOps 標準，它的愿景是在保證客戶應(yīng)用運行質(zhì)量的前提下實現(xiàn)極致的降本。目前已經(jīng)獲得FinOps基金會授予的全球首個認證降本增效開源方案。它為使用 Kubernetes 集群的企業(yè)提供了一種簡單、可靠且強大的自動化部署工具。
如何在 Crane 中開啟成本優(yōu)化之旅？
- 成本展示: Kubernetes 資源( Deployments, StatefulSets )的多維度聚合與展示。
- 成本分析: 周期性的分析集群資源的狀態(tài)并提供優(yōu)化建議。
- 成本優(yōu)化: 通過豐富的優(yōu)化工具更新配置達成降本的目標。
Crane整體架構(gòu)
Crane 的整體架構(gòu)如下：
由Craned整體架構(gòu)可知Craned 是 Crane 的最核心組件，它管理了 CRDs 的生命周期以及API。Craned 通過 Deployment 方式部署且由兩個容器組成：
- Craned: 運行了 Operators 用來管理 CRDs，向 Dashboard 提供了 WebApi，Predictors 提供了 TimeSeries API
- Dashboard: 基于 TDesign’s Starter 腳手架研發(fā)的前端項目，提供了易于上手的產(chǎn)品功能
Fadvisor
Fadvisor 提供一組 Exporter 計算集群云資源的計費和賬單數(shù)據(jù)并存儲到你的監(jiān)控系統(tǒng)，比如 Prometheus。Fadvisor 通過 Cloud Provider 支持了多云計費的 API。
Metric Adapter
Metric Adapter 實現(xiàn)了一個 Custom Metric Apiserver. Metric Adapter 讀取 CRDs 信息并提供基于 Custom/External Metric API 的 HPA Metric 的數(shù)據(jù)。
Crane Agent
Crane Agent 通過 DaemonSet 部署在集群的節(jié)點上。
Crane安裝
因為我的是mac電腦，所以我只對mac電腦下的安裝，進行演示。
安裝 kind
請參考官方文檔https://kind.sigs.k8s.io/docs/user/quick-start/#installation，這里我用的命令是
brew install kind
安裝 Helm
請參考官方文檔：https://helm.sh/zh/docs/intro/install/，這里我用的是
brew install helm
安裝 kubectl
請參考官方文檔https://kubernetes.io/zh-cn/docs/tasks/tools/，這里我用的是
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
安裝 Docker
請參考官方文檔安裝 docker：https://docs.docker.com/get-docker/，這里我用的是
然后
以下命令將安裝 Crane 以及其依賴 (Prometheus/Grafana).
curl -sf https://raw.githubusercontent.com/gocrane/crane/main/hack/local-env-setup.sh | sh -
如果網(wǎng)絡(luò)有問題，可以直接用我提供的資料，進行本地安裝
bash installation/local-env-setup.sh
確保所有 Pod 都正常運行:
$ export KUBECONFIG=${HOME}/.kube/config_crane
$ kubectl get pod -n crane-system
NAME READY STATUS RESTARTS AGE
craned-6dcc5c569f-vnfsf 2/2 Running 0 4m41s
fadvisor-5b685f4cd6-xpxzq 1/1 Running 0 4m37s
grafana-64656f6d54-6l24j 1/1 Running 0 4m46s
metric-adapter-967c6d57f-swhfv 1/1 Running 0 4m41s
prometheus-kube-state-metrics-7f9d78cffc-p8l7c 1/1 Running 0 4m46s
prometheus-server-fb944f4b7-4qqlv 2/2 Running 0 4m46s
訪問 Crane Dashboard
kubectl -n crane-system port-forward service/craned 9090:9090
# 后續(xù)的終端操作請在新窗口操作，每一個新窗口操作前請把配置環(huán)境變量加上(不然會出現(xiàn)8080端口被拒絕的提示)
export KUBECONFIG=${HOME}/.kube/config_crane
注意：后續(xù)的終端操作請在新窗口操作，每一個新窗口操作前請把配置環(huán)境變量加上(不然會出現(xiàn)8080端口被拒絕的提示)
export KUBECONFIG=${HOME}/.kube/config_crane
點擊 這里 訪問 Crane Dashboard
成本展示
Crane Dashboard 提供了各式各樣的圖表展示了集群的成本和資源用量，
- 當月總成本：過去一個月集群總成本。從安裝Crane時間開始，按小時累加集群成本
- 預(yù)估每月成本：以最近一小時成本估算未來一個月的成本。每小時成本 * 24 * 30
- 預(yù)估CPU總成本：以最近一小時CPU成本估算未來一個月的CPU成本。每小時CPU成本 * 24 * 30
- 預(yù)估Memory總成本：以最近一小時Memory成本估算未來一個月的Memory成本。每小時Memory成本 * 24 * 30
成本洞察->集群總覽
成本洞察->集群總覽
- Workload Spec CPU Slack: Workload 的 CPU 規(guī)格 - 推薦的 CPU 規(guī)格
- Workload Total CPU Slack: （Workload 的 CPU 規(guī)格 - 推薦的 CPU 規(guī)格）* Pod 數(shù)量
更多的成本分析圖表可以通過登陸 Grafana 的頁面或者分析源碼研究。
登陸 Grafana 的方式可以通過以下命令建立一個 port-mapping：
優(yōu)化應(yīng)用配置
在 dashboard 中開箱后就可以看到相關(guān)的成本數(shù)據(jù)，是因為在添加集群的時候我們安裝了推薦的規(guī)則。
推薦框架會自動分析集群的各種資源的運行情況并給出優(yōu)化建議。Crane 的推薦模塊會定期檢測發(fā)現(xiàn)集群資源配置的問題，并給出優(yōu)化建議。智能推薦提供了多種 Recommender 來實現(xiàn)面向不同資源的優(yōu)化推薦。
在成本分析>推薦規(guī)則頁面可以看到我們安裝的兩個推薦規(guī)則。
計算成本
成本計算功能是由組件 Fadvisor 實現(xiàn)，在安裝 Crane 時會一起安裝，一起提供了成本展示和成本分析功能：
- Server：收集集群 Metric 數(shù)據(jù)并計算成本
- Exporter：將成本 Metric 暴露出來
原理
Fadvisor 成本模型提供了一個方法來估計和分析每個容器,pod 或其他資源在 Kubernetes 中的資源價格。
請注意,成本模型只是預(yù)估成本,而不是替代云訂單,因為實際的計費數(shù)據(jù)取決于更多原因，比如各類計費邏輯。以下是計算理論：
- 最簡單的成本模型是以相同的價格估算所有節(jié)點或 pod 的資源價格。例如,在計算成本時,您可以假設(shè)所有容器的 CPU 和 RAM 單位價格相同,2 / 小時核心 , 0.3 /小時核心,0.3 /小時核心,0.3/小時 Gib
- 高級成本模型是通過成本分攤來估計資源價格。 這一理論的基礎(chǔ)是不同實例類型和計費類型的每個云機器實例的價格不同，不過 CPU 和 RAM 的價格比率是相對固定的，可以通過這個價格比率來計算資源成本。
成本分攤模型下的具體的計算公式如下：
- 集群整體成本：cvm 成本之和
- CPU/mem 價格比率相對固定
- cvm 的成本 = CPU 成本 * CPU 數(shù)量 + mem 成本 * mem 數(shù)量
- CPU 申請成本：整體成本 * （CPU 占 cvm 成本的比例）得到整體 CPU 成本，再按申請的 CPU 總覽占整體 CPU 總量的比例計算出 CPU 申請的成本
- namespace 下的 CPU 申請成本： CPU 申請成本按 namespace 聚合
Crane主要特點以及應(yīng)用場景
成本可視化和優(yōu)化評估
- 提供一組 Exporter 計算集群云資源的計費和賬單數(shù)據(jù)并存儲到你的監(jiān)控系統(tǒng)，比如 Prometheus。
- 多維度的成本洞察，優(yōu)化評估。通過
Cloud Provider支持多云計費。
推薦框架
推薦框架是指自動分析集群的各種資源的運行情況并給出優(yōu)化建議。
Crane 的推薦模塊定期的檢測發(fā)現(xiàn)集群資源配置的問題，并給出優(yōu)化建議。智能推薦提供了多種 Recommender 來實現(xiàn)面向不同資源的優(yōu)化推薦。
目前支持的Recommender：
智能推薦的典型用例
創(chuàng)建 RecommendationRule 配置
下面是一個 RecommendationRule 示例： workload-rule.yaml。
apiVersion: analysis.crane.io/v1alpha1
kind: RecommendationRule
metadata:
name: workloads-rule
spec:
runInterval: 6h # 每6h運行一次
resourceSelectors: # 資源的信息
- kind: Deployment
apiVersion: apps/v1
- kind: StatefulSet
apiVersion: apps/v1
namespaceSelector:
any: true # 掃描所有namespace
recommenders: # 使用 Workload 的副本和資源推薦器
- name: Replicas
- name: Resource
在該示例中：
- 每隔24小時運行一次分析推薦，
runInterval格式為時間間隔，比如: 1h，1m，設(shè)置為空表示只運行一次。 - 待分析的資源通過配置
resourceSelectors數(shù)組設(shè)置，每個resourceSelector通過 kind，apiVersion，name 選擇 k8s 中的資源，當不指定 name 時表示在namespaceSelector基礎(chǔ)上的所有資源 -
namespaceSelector定義了待分析資源的 namespace，any: true表示選擇所有 namespace -
recommenders定義了待分析的資源需要通過哪些 Recommender 進行分析。 - 資源類型和
recommenders需要可以匹配，比如 Resource 推薦默認只支持 Deployments 和 StatefulSets
1.通過以下命令創(chuàng)建 RecommendationRule，剛創(chuàng)建時會立刻開始一次推薦。
kubectl apply -f workload-rules.yaml
這個時候，就會對所有 namespace 中的 Deployments 和 StatefulSets 做資源推薦和副本數(shù)推薦。
基于預(yù)測的水平彈性器
EffectiveHorizontalPodAutoscaler 支持了預(yù)測驅(qū)動的彈性。它基于社區(qū) HPA 做底層的彈性控制，支持更豐富的彈性觸發(fā)策略（預(yù)測，觀測，周期），讓彈性更加高效，并保障了服務(wù)的質(zhì)量。
特點是：
- 提前擴容，保證服務(wù)質(zhì)量：通過算法預(yù)測未來的流量洪峰提前擴容，避免擴容不及時導致的雪崩和服務(wù)穩(wěn)定性故障。
- 減少無效縮容：通過預(yù)測未來可減少不必要的縮容，穩(wěn)定工作負載的資源使用率，消除突刺誤判。
- 支持 Cron 配置：支持 Cron-based 彈性配置，應(yīng)對大促等異常流量洪峰。
- 兼容社區(qū)：使用社區(qū) HPA 作為彈性控制的執(zhí)行層，能力完全兼容社區(qū)。
它的功能我們可以根據(jù)通過一個簡單的 EHPA yaml 文件進行了解：
apiVersion: autoscaling.crane.io/v1alpha1
kind: EffectiveHorizontalPodAutoscaler
metadata:
name: php-apache
spec:
scaleTargetRef: #(1)
apiVersion: apps/v1
kind: Deployment
name: php-apache
minReplicas: 1 #(2)
maxReplicas: 10 #(3)
scaleStrategy: Auto #(4)
metrics: #(5)
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
prediction: #(6)
predictionWindowSeconds: 3600 #(7)
predictionAlgorithm:
algorithmType: dsp
dsp:
sampleInterval: "60s"
historyLength: "3d"
- ScaleTargetRef 配置你希望彈性的工作負載。
- MinReplicas 指定了自動縮容的最小值。
- MaxReplicas 指定了自動擴容的最大值。
- ScaleStrategy 定義了彈性的策略，值可以是 “Auto” and “Preview”.
- Metrics 定義了彈性閾值配置。
- Prediction 定義了預(yù)測算法配置。
- PredictionWindowSeconds 指定往后預(yù)測多久的數(shù)據(jù)。
負載感知的調(diào)度器
kubernetes 的原生調(diào)度器只能通過資源請求來調(diào)度 pod，這很容易造成一系列負載不均的問題：
- 對于某些節(jié)點，實際負載與資源請求相差不大，這會導致很大概率出現(xiàn)穩(wěn)定性問題。
- 對于其他節(jié)點來說，實際負載遠小于資源請求，這將導致資源的巨大浪費。
為了解決這些問題，動態(tài)調(diào)度器根據(jù)實際的節(jié)點利用率構(gòu)建了一個簡單但高效的模型，并過濾掉那些負載高的節(jié)點來平衡集群。
這里主要用到的就是Crane-scheduler ，Crane-scheduler是一組基于scheduler framework的調(diào)度插件， 包含：Dynamic scheduler：負載感知調(diào)度器插件
拓撲感知的調(diào)度器
現(xiàn)代多核服務(wù)器大多采用非統(tǒng)一內(nèi)存訪問架構(gòu)（來提高硬件的可伸縮性），由于在 Kubernetes 中，調(diào)度是指將 Pod 放置到合適的節(jié)點上，一個節(jié)點會運行多個Pod。所以在某些延遲敏感的場景下，可能希望Kubernetes為Pod分配拓撲最優(yōu)的節(jié)點和硬件，以提升硬件利用率和程序性能。為了解決這一類問題，資源拓撲感知調(diào)度給予了精細調(diào)度的能力，將調(diào)度的粒度擴展到設(shè)備級別。下圖是它的設(shè)計結(jié)構(gòu)。
Crane-Scheduler和Crane-Agent配合工作，支持更為精細化的資源拓撲感知調(diào)度和多種綁核策略，可解決復(fù)雜場景下“吵鬧的鄰居問題"，使得資源得到更合理高效的利用。完成拓撲感知調(diào)度與資源分配的工作。
Crane-Agent從節(jié)點采集資源拓撲，包括NUMA、Socket、設(shè)備等信息，匯總到NodeResourceTopology這個自定義資源對象中。
Crane-Scheduler在調(diào)度時會參考節(jié)點的NodeResourceTopology對象獲取到節(jié)點詳細的資源拓撲結(jié)構(gòu)，在調(diào)度到節(jié)點的同時還會為Pod分配拓撲資源，并將結(jié)果寫到Pod的annotations中。
Crane-Agent在節(jié)點上Watch到Pod被調(diào)度后，從Pod的annotations中獲取到拓撲分配結(jié)果，并按照用戶給定的CPU綁定策略進行CPUSet的細粒度分配。
基于 QOS 的混部
QOS相關(guān)能力保證了運行在 Kubernetes 上的 Pod 的穩(wěn)定性。具有多維指標條件下的干擾檢測和主動回避能力，支持精確操作和自定義指標接入；具有預(yù)測算法增強的彈性資源超賣能力，復(fù)用和限制集群內(nèi)的空閑資源；具備增強的旁路cpuset管理能力，在綁核的同時提升資源利用效率。同時，crane支持自定義指標適配整個干擾檢測框架，只需要完成排序定義等一些操作，即可復(fù)用包含精確操作在內(nèi)的干擾檢測和回避流程。
參考文檔
快速開始
https://github.com/gocrane/crane
總結(jié)
通過本文的學習，知道了Crane是什么、以及它的愿景，同時我們也了解了Crane的整體架構(gòu)和主要特點，還在本地安裝體驗了Crane，理清了他的應(yīng)用場景。也感受到了它的魅力。確實在落地方面，保證客戶應(yīng)用運行質(zhì)量的前提下實現(xiàn)了極致的降本。對于目前的大環(huán)境和行業(yè)來說，有著十足的誠意。最后想說的是你的公司涉及到的相關(guān)業(yè)務(wù)無論是否需要資源優(yōu)化，當你希望實踐 FinOps 時，Crane 都可以作為嘗試對象。你可以首先通過集群的成本展示了解當前的 Kubernetes 集群的現(xiàn)狀，并根據(jù)問題所在選擇優(yōu)化的方式。
就拿降本來說，可以提前通過預(yù)測算法提前擴容，利用預(yù)測數(shù)據(jù)做降級，利用平滑的預(yù)測指標緩解抖動，比如我們可以先在 CI/CD 環(huán)境驗證配置的準確性再更新生產(chǎn)環(huán)境。 然后先優(yōu)化浪費嚴重的業(yè)務(wù)，再優(yōu)化已經(jīng)比較低配置的業(yè)務(wù) ，根據(jù)業(yè)務(wù)特征配置推薦參數(shù)。發(fā)布平臺通過提示用戶建議的配置，讓用戶確認后再更新以防止意料之外的線上變更。以實現(xiàn)更高的利用率。
關(guān)于騰訊云 Finops Crane 集訓營：
Finops Crane集訓營主要面向廣大開發(fā)者，旨在提升開發(fā)者在容器部署、K8s層面的動手實踐能力，同時吸納Crane開源項目貢獻者，鼓勵開發(fā)者提交issue、bug反饋等，并搭載線上直播、動手實驗組隊、有獎?wù)魑牡认盗屑夹g(shù)活動。既能讓開發(fā)者通過活動對 Finops Crane 開源項目有深入了解，同時也能幫助廣大開發(fā)者在云原生技能上有實質(zhì)性收獲。
為獎勵開發(fā)者，我們特別設(shè)立了積分獲取任務(wù)和對應(yīng)的積分兌換禮品。
??活動介紹送門：https://marketing.csdn.net/p/038ae30af2357473fc5431b63e4e1a78文章來源：http://www.zghlxwxcb.cn/news/detail-454780.html
??開源項目： https://github.com/gocrane/crane文章來源地址http://www.zghlxwxcb.cn/news/detail-454780.html
到了這里，關(guān)于【騰訊云 Finops Crane 集訓營】降本增效？學會 Crane，就夠了的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
