這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)Fluid的自定義彈性伸縮是怎樣的，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
創(chuàng)新互聯(lián)建站是一家集網(wǎng)站建設(shè),潞州企業(yè)網(wǎng)站建設(shè),潞州品牌網(wǎng)站建設(shè),網(wǎng)站定制,潞州網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷,網(wǎng)絡(luò)優(yōu)化,潞州網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶成長(zhǎng)自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。
**導(dǎo)讀：**彈性伸縮作為 Kubernetes 的核心能力之一，但它一直是圍繞這無(wú)狀態(tài)的應(yīng)用負(fù)載展開(kāi)。而 Fluid 提供了分布式緩存的彈性伸縮能力，可以靈活擴(kuò)充和收縮數(shù)據(jù)緩存。 它基于 Runtime 提供了緩存空間、現(xiàn)有緩存比例等性能指標(biāo), 結(jié)合自身對(duì)于 Runtime 資源的擴(kuò)縮容能力，提供數(shù)據(jù)緩存按需伸縮能力。
隨著越來(lái)越多的大數(shù)據(jù)和 AI 等數(shù)據(jù)密集應(yīng)用開(kāi)始部署和運(yùn)行在 Kubernetes 環(huán)境下，數(shù)據(jù)密集型應(yīng)用計(jì)算框架的設(shè)計(jì)理念和云原生靈活的應(yīng)用編排的分歧，導(dǎo)致了數(shù)據(jù)訪問(wèn)和計(jì)算瓶頸。云原生數(shù)據(jù)編排引擎 Fluid 通過(guò)數(shù)據(jù)集的抽象，利用分布式緩存技術(shù)，結(jié)合調(diào)度器，為應(yīng)用提供了數(shù)據(jù)訪問(wèn)加速的能力。
彈性伸縮作為 Kubernetes 的核心能力之一，但它一直是圍繞這無(wú)狀態(tài)的應(yīng)用負(fù)載展開(kāi)。而 Fluid 提供了分布式緩存的彈性伸縮能力，可以靈活擴(kuò)充和收縮數(shù)據(jù)緩存。它基于 Runtime 提供了緩存空間、現(xiàn)有緩存比例等性能指標(biāo), 結(jié)合自身對(duì)于 Runtime 資源的擴(kuò)縮容能力，提供數(shù)據(jù)緩存按需伸縮能力。
這個(gè)能力對(duì)于互聯(lián)網(wǎng)場(chǎng)景下大數(shù)據(jù)應(yīng)用非常重要，由于多數(shù)的大數(shù)據(jù)應(yīng)用都是通過(guò)端到端流水線來(lái)實(shí)現(xiàn)的。而這個(gè)流水線包含以下幾個(gè)步驟：
數(shù)據(jù)提取：利用 Spark，MapReduce 等大數(shù)據(jù)技術(shù)對(duì)于原始數(shù)據(jù)進(jìn)行預(yù)處理。
模型訓(xùn)練：利用第一階段生成特征數(shù)據(jù)進(jìn)行機(jī)器學(xué)習(xí)模型訓(xùn)練，并且生成相應(yīng)的模型。
模型評(píng)估：通過(guò)測(cè)試集或者驗(yàn)證集對(duì)于第二階段生成模型進(jìn)行評(píng)估和測(cè)試。
模型推理：第三階段驗(yàn)證后的模型最終推送到線上為業(yè)務(wù)提供推理服務(wù)。
可以看到端到端的流水線會(huì)包含多種不同類型的計(jì)算任務(wù)，針對(duì)每一個(gè)計(jì)算任務(wù)，實(shí)踐中會(huì)有合適的專業(yè)系統(tǒng)來(lái)處理（TensorFlow，PyTorch，Spark， Presto）；但是這些系統(tǒng)彼此獨(dú)立，通常要借助外部文件系統(tǒng)來(lái)實(shí)現(xiàn)把數(shù)據(jù)從一個(gè)階段傳遞到下一個(gè)階段。但是頻繁的使用文件系統(tǒng)實(shí)現(xiàn)數(shù)據(jù)交換，會(huì)帶來(lái)大量的 I/O 開(kāi)銷，經(jīng)常會(huì)成為整個(gè)工作流的瓶頸。
而 Fluid 對(duì)于這個(gè)場(chǎng)景非常適合，用戶可以創(chuàng)建一個(gè) Dataset 對(duì)象，這個(gè)對(duì)象有能力將數(shù)據(jù)分散緩存到 Kubernetes 計(jì)算節(jié)點(diǎn)中，作為數(shù)據(jù)交換的介質(zhì)，這樣避免了數(shù)據(jù)的遠(yuǎn)程寫(xiě)入和讀取，提升了數(shù)據(jù)使用的效率。但是這里的問(wèn)題是臨時(shí)數(shù)據(jù)緩存的資源預(yù)估和預(yù)留。由于在數(shù)據(jù)生產(chǎn)消費(fèi)之前，精確的數(shù)據(jù)量預(yù)估是比較難滿足，過(guò)高的預(yù)估會(huì)導(dǎo)致資源預(yù)留浪費(fèi)，過(guò)低的預(yù)估會(huì)導(dǎo)致數(shù)據(jù)寫(xiě)入失敗可能性增高。還是按需擴(kuò)縮容對(duì)于使用者更加友好。我們希望能夠達(dá)成類似 page cache 的使用效果，對(duì)于最終用戶來(lái)說(shuō)這一層是透明的但是它帶來(lái)的緩存加速效果是實(shí)實(shí)在在的。
我們通過(guò)自定義 HPA 機(jī)制，通過(guò) Fluid 引入了緩存彈性伸縮能力。彈性伸縮的條件是當(dāng)已有緩存數(shù)據(jù)量達(dá)到一定比例時(shí)，就會(huì)觸發(fā)彈性擴(kuò)容，擴(kuò)容緩存空間。例如將觸發(fā)條件設(shè)置為緩存空間占比超過(guò) 75%，此時(shí)總的緩存空間為 10G，當(dāng)數(shù)據(jù)已經(jīng)占滿到 8G 緩存空間的時(shí)候，就會(huì)觸發(fā)擴(kuò)容機(jī)制。
下面我們通過(guò)一個(gè)例子幫助您體驗(yàn) Fluid 的自動(dòng)擴(kuò)縮容能力。
推薦使用 Kubernetes 1.18 以上，因?yàn)樵?1.18 之前，HPA 是無(wú)法自定義擴(kuò)縮容策略的，都是通過(guò)硬編碼實(shí)現(xiàn)的。而在 1.18 后，用戶可以自定義擴(kuò)縮容策略的，比如可以定義一次擴(kuò)容后的冷卻時(shí)間。
yum install -y jq
git clone https://github.com/fluid-cloudnative/fluid.git cd fluid/charts kubectl create ns fluid-system helm install fluid fluid
這里通過(guò) Prometheus 對(duì)于 AlluxioRuntime 的緩存引擎暴露的 Metrics 進(jìn)行收集，如果集群內(nèi)無(wú) prometheus：
$ cd fluid $ kubectl apply -f integration/prometheus/prometheus.yaml
如集群內(nèi)有 prometheus，可將以下配置寫(xiě)到 prometheus 配置文件中：
scrape_configs: - job_name: 'alluxio runtime' metrics_path: /metrics/prometheus kubernetes_sd_configs: - role: endpoints relabel_configs: - source_labels: [__meta_kubernetes_service_label_monitor] regex: alluxio_runtime_metrics action: keep - source_labels: [__meta_kubernetes_endpoint_port_name] regex: web action: keep - source_labels: [__meta_kubernetes_namespace] target_label: namespace replacement: $1 action: replace - source_labels: [__meta_kubernetes_service_label_release] target_label: fluid_runtime replacement: $1 action: replace - source_labels: [__meta_kubernetes_endpoint_address_target_name] target_label: pod replacement: $1 action: replace
$ kubectl get ep -n kube-system prometheus-svc NAME ENDPOINTS AGE prometheus-svc 10.76.0.2:9090 6m49s $ kubectl get svc -n kube-system prometheus-svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE prometheus-svc NodePort 172.16.135.249090:32114/TCP 2m7s
如果希望可視化監(jiān)控指標(biāo)，您可以安裝 Grafana 驗(yàn)證監(jiān)控?cái)?shù)據(jù)，具體操作可以參考文檔。
檢查該集群是否包括 metrics-server，執(zhí)行kubectl top node有正確輸出可以顯示內(nèi)存和 CPU，則該集群 metrics server 配置正確。
kubectl top node NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% 192.168.1.204 93m 2% 1455Mi 10% 192.168.1.205 125m 3% 1925Mi 13% 192.168.1.206 96m 2% 1689Mi 11%
否則手動(dòng)執(zhí)行以下命令：
kubectl create -f integration/metrics-server
為了基于自定義指標(biāo)進(jìn)行擴(kuò)展，你需要擁有兩個(gè)組件：
第一個(gè)組件是從應(yīng)用程序收集指標(biāo)并將其存儲(chǔ)到 Prometheus 時(shí)間序列數(shù)據(jù)庫(kù)。
第二個(gè)組件使用收集的度量指標(biāo)來(lái)擴(kuò)展 Kubernetes 自定義 metrics API，即 k8s-prometheus-adapter。
第一個(gè)組件在第三步部署完成，下面部署第二個(gè)組件。
如果已經(jīng)配置了custom-metrics-api，在 adapter 的 configmap 配置中增加與 dataset 相關(guān)的配置：
重慶分公司
重慶分公司
apiVersion: v1
kind: ConfigMap
metadata:
name: adapter-config
namespace: monitoring
data:
config.yaml: |
rules:
- seriesQuery: '{__name__=~"Cluster_(CapacityTotal|CapacityUsed)",fluid_runtime!="",instance!="",job="alluxio runtime",namespace!="",pod!=""}'
seriesFilters:
- is: ^Cluster_(CapacityTotal|CapacityUsed)$
resources:
overrides:
namespace:
resource: namespace
pod:
resource: pods
fluid_runtime:
resource: datasets
name:
matches: "^(.*)"
as: "capacity_used_rate"
metricsQuery: ceil(Cluster_CapacityUsed{<<.LabelMatchers>>}*100/(Cluster_CapacityTotal{<<.LabelMatchers>>}))否則手動(dòng)執(zhí)行以下命令：
kubectl create -f integration/custom-metrics-api/namespace.yaml kubectl create -f integration/custom-metrics-api
注意：因?yàn)?custom-metrics-api 對(duì)接集群中的 Prometheous 的訪問(wèn)地址，請(qǐng)?zhí)鎿Q prometheous url 為你真正使用的 Prometheous 地址。
檢查自定義指標(biāo)：
$ kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq
{
"kind": "APIResourceList",
"apiVersion": "v1",
"groupVersion": "custom.metrics.k8s.io/v1beta1",
"resources": [
{
"name": "pods/capacity_used_rate",
"singularName": "",
"namespaced": true,
"kind": "MetricValueList",
"verbs": [
"get"
]
},
{
"name": "datasets.data.fluid.io/capacity_used_rate",
"singularName": "",
"namespaced": true,
"kind": "MetricValueList",
"verbs": [
"get"
]
},
{
"name": "namespaces/capacity_used_rate",
"singularName": "",
"namespaced": false,
"kind": "MetricValueList",
"verbs": [
"get"
]
}
]
}
