1.前言

AWS Well-Architected Framework 描述了用于在云中設(shè)計(jì)和運(yùn)行工作負(fù)載的關(guān)鍵概念、設(shè)計(jì)原則和架構(gòu)最佳實(shí)踐。其中可持續(xù)性支柱作為目前 Well-Architected Framework 中的最新一員側(cè)重于減少運(yùn)行的云工作負(fù)載對環(huán)境的影響。在正確的時(shí)間以正確的數(shù)量提供正確的資源，以滿足明確定義的業(yè)務(wù)需求。以Reuse，Recycle，Reduce，Rearchitect 四個(gè)方面為準(zhǔn)則構(gòu)建最佳架構(gòu)。本系列博客將以在EKS上的部署Flink作業(yè)為例，通過 Karpenter, Spot, Graviton 等技術(shù)，遵循Reuse，Recycle，Reduce，Rearchitect 四大原則，從零開始構(gòu)建最佳架構(gòu)。

在上一篇博客中，我們介紹了遵循Reuse，Recycle原則，通過容器化應(yīng)用和 Spot 實(shí)例實(shí)現(xiàn)云應(yīng)用的交付和優(yōu)化，結(jié)合 Karpenter 彈性伸縮工具最大限度地提高利用率和資源效率。在這一篇博客中，我們將：

遵循 Rearchitect 原則，引入 Graviton，實(shí)現(xiàn)從 x86 到 arm 架構(gòu)的轉(zhuǎn)變的同時(shí)，進(jìn)一步推進(jìn)成本節(jié)省和持續(xù)的基礎(chǔ)設(shè)施優(yōu)化。

亞馬遜云科技設(shè)計(jì)的 AWS Graviton 處理器為 Amazon EC2 中運(yùn)行的云工作負(fù)載提供最佳性價(jià)比。與當(dāng)前一代基于 x86 的實(shí)例相比，采用亞馬遜云科技 Graviton2 處理器的通用可突發(fā)性能型（T4g）、通用型（M6g）、計(jì)算優(yōu)化型（C6g) 和內(nèi)存優(yōu)化型（R6g、X2gd）EC2 實(shí)例，及其具有基于 NVMe 的 SSD 存儲的變體，為廣泛的工作負(fù)載（如應(yīng)用程序服務(wù)器、微服務(wù)、視頻編碼、高性能計(jì)算、電子設(shè)計(jì)自動化、壓縮、游戲、開源數(shù)據(jù)庫、內(nèi)存緩存和基于 CPU 的機(jī)器學(xué)習(xí)推理）提供高達(dá) 40% 的性價(jià)比提升。除此之外，Graviton 提供在Amazon EC2 實(shí)例家族中每瓦能源使用的最佳性能，詳細(xì)的 SPECint2017 benchmark 數(shù)據(jù)請參考下圖：

遵循 Reduce 原則，除了EKS集群層面的優(yōu)化，我們可以借助 Kubecost 工具，下沉到應(yīng)用級別，深入地監(jiān)控 Kubernetes 成本資源級別的成本。不僅提升 Kubernetes 集群的成本可見性，還提示節(jié)省成本的機(jī)會。例如幫助您定位未使用的存儲卷、過度配置的副本或廢棄的工作負(fù)載等。

實(shí)驗(yàn)架構(gòu)回顧：

架構(gòu)概要說明：

1. 創(chuàng)建 EKS 集群時(shí)，添加一個(gè)托管按需節(jié)點(diǎn)組（默認(rèn)一個(gè)節(jié)點(diǎn)），用于部署系統(tǒng)組件例如 EBS CSI 驅(qū)動程序等。

2. 借助 Karpenter 動態(tài)拉起 Flink 作業(yè)需要的計(jì)算資源，通過配置多個(gè)Provisioner，每個(gè) Provisioner 設(shè)置不同 weight，實(shí)現(xiàn)精細(xì)化協(xié)同控制。

3. ARM 節(jié)點(diǎn)主動打上 Taints，配合使用 Tolerations，以確保 Flink 作業(yè)調(diào)度到合適的節(jié)點(diǎn)上。

4. 利用 docker buildx 工具一鍵打包 Multi-Arch 鏡像并推送到鏡像倉庫。

5. Flink Job Manager (Flink JM) 利用 nodeSelector 主動調(diào)度到由按需節(jié)點(diǎn)（包括部署系統(tǒng)組件的按需節(jié)點(diǎn)組和 Karpenter拉起的節(jié)點(diǎn)）。

6. Flink Task Manager (Flink TM) 默認(rèn)不加任何限定條件（nodeSelector/ nodeAffinity），并且配置HPA（基于CPU）。當(dāng)資源不夠時(shí)，由 Provisioner 按優(yōu)先級協(xié)調(diào)拉起合適節(jié)點(diǎn)。

7. 利用 Kinesis Data Generator 生成大量模擬數(shù)據(jù)，打到 Kinesis Data Stream 數(shù)據(jù)。隨著數(shù)據(jù)的增加，配置了 HPA 的 Task Manager 自動彈出更多Pod。

8. Flink 作業(yè)啟用檢查點(diǎn)，并將作業(yè)檢查點(diǎn)數(shù)據(jù)寫入 S3，從而允許 Flink 保存狀態(tài)并具備容錯(cuò)性。

9. 使用 Fault Injection Simulator 模擬 Spot 回收事件。

10. Node Termination Handler 配合 Spot，讓應(yīng)用運(yùn)行更平穩(wěn)。

上一篇我們已經(jīng)搭建好 EKS 集群，并將 Flink 作業(yè)運(yùn)行在 x86 節(jié)點(diǎn)上。接下來首先通過切換到基于 Graviton 的實(shí)例來提高計(jì)算工作負(fù)載的能效。同時(shí)綜合運(yùn)用 Karpenter 的優(yōu)先級策略，實(shí)現(xiàn)對 Flink 作業(yè)計(jì)算資源的精細(xì)化管理。

從CPU架構(gòu)和容量類型，我們一共設(shè)置了四個(gè)Provisioner，注意為保證部署在按需節(jié)點(diǎn)上的Job Manager的高可用性，我們僅對*-spot-provisioner 啟用consolidation：

注意：不能保證 Karpenter 在特定要求下始終選擇最高優(yōu)先級的Provisioner。例如有2種場景：

1. 遵循上一篇提到的“Reuse”原則，如果現(xiàn)有容量可用，kube-scheduler 將直接調(diào)度 pod，不會觸發(fā) Karpenter 拉起新節(jié)點(diǎn)。

2. 根據(jù) Karpenter 執(zhí)行 pod 批處理和 bin 打包的方式，如果一個(gè) pod 無法使用最高優(yōu)先級的配置器進(jìn)行調(diào)度，它將強(qiáng)制使用較低優(yōu)先級的配置器創(chuàng)建一個(gè)節(jié)點(diǎn)，這可能允許該批次中的其他 pod 也可以在該節(jié)點(diǎn)上進(jìn)行調(diào)度。

如果您希望保持簡單，不要求最大化已有托管節(jié)點(diǎn)組利用率，對統(tǒng)一的 capacity 類型標(biāo)簽（eks.amazonaws.com/capacityType）也沒有要求，可以設(shè)置Flink 作業(yè)只使用 Kaprenter 節(jié)點(diǎn)。Karpenter 已經(jīng)內(nèi)置了優(yōu)先選擇 Spot 然后按需的機(jī)制，這樣初始只需配置二個(gè) Provisioner (x86/arm)。對于 Flink Job Manager 等必須使用按需實(shí)例的任務(wù)，只需利用 nodeSelector 通過原生標(biāo)簽 karpenter.sh/capacity-type 指定即可。后期如果作業(yè)容器鏡像已經(jīng)都是 multi-arch，則可以進(jìn)一步將x86和arm實(shí)例放在同一個(gè) Provisioner 中，Karpenter會分別按照spot capacity優(yōu)先、按需成本優(yōu)先的原則自動選擇x86和arm。您可以權(quán)衡考慮，如果單一 Provisioner可以滿足需求，則可以大幅簡化目前多個(gè) Provisioner的配置和選擇。

2.構(gòu)建多CPU架構(gòu)鏡像

2.1 準(zhǔn)備buildx工具

打開 Cloud9 控制臺：

https://us-east-1.console.aws.amazon.com/cloud9/home?region=us-east-1。

進(jìn)入到IDE環(huán)境，前面一篇已經(jīng)安裝好docker buildx工具，如果有問題請下載prepareCloud9IDE.sh：

wget https://raw.githubusercontent.com/BWCXME/cost-optimized-flink-on-kubernetes/main/prepareCloud9IDE.sh

然后打開查看 buildx 部分，復(fù)制到命令行手動安裝：

c9 prepareCloud9IDE.sh

2.2 配置build

創(chuàng)建并使用flink-build：

docker buildx create --name flink-build --usedocker buildx inspect --bootstrapdocker buildx ls

2.3 一鍵打包多CPU架構(gòu)鏡像

首先進(jìn)入代碼目錄：

cd ~/environment/flink-demo

登錄倉庫：

aws ecr get-login-password --region ${AWS_REGION} | docker login --username AWS --password-stdin ${ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com

借助buildx插件，一條命令同時(shí)編譯、打包、推送x86和arm架構(gòu)鏡像：

docker buildx build --platform linux/amd64,linux/arm64 --tag ${ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/flink-demo:latest --push .

查看 Dockerfile，內(nèi)容如下所示：

FROM maven:3.8.6-jdk-8-slim AS builderCOPY src/ /home/app/srcCOPY pom.xml /home/app/RUN ls -l /home/appRUN mvn -f /home/app/pom.xml clean package -Dflink.version=1.15.1
FROM flink:1.15.1RUN mkdir -p $FLINK_HOME/usrlibCOPY --from=builder /home/app/target/aws-kinesis-analytics-java-apps-1.0.jar $FLINK_HOME/usrlib/aws-kinesis-analytics-java-apps-1.0.jarRUN mkdir $FLINK_HOME/plugins/s3-fs-hadoopCOPY /lib/flink-s3-fs-hadoop-1.15.1.jar $FLINK_HOME/plugins/s3-fs-hadoop/

如果您要更改基礎(chǔ)鏡像maven 或 flink的版本，請確保指定tag下有arm的版本，不然buildx會報(bào)錯(cuò)。

推送完成后，檢查鏡像信息：

docker buildx imagetools inspect ${ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/flink-demo:latest

返回類似如下：

簡單3步，F(xiàn)link作業(yè)的ARM鏡像就打好了，即不用更改Dockerfile，也不用單獨(dú)設(shè)置Tag。

2.4 構(gòu)建自定義版本的 Flink多CPU架構(gòu)鏡像

在 Docker Hub 上 Flink 的官方鏡像倉庫中只有 1.14 及以上的版本有支持 arm64/v8 即支持 Graviton 的鏡像，如前面所說的如果鏡像不支持arm64/v8，那么通過 buildx 打包的時(shí)候會報(bào)錯(cuò)。但是在有些場景下，客戶依然想要使用 1.13 版本的 Flink, 或者希望使用除了 openjdk 以外的其他 JDK，比如針對 Graviton 優(yōu)化的 Amazon Corretto JDK,這時(shí)候就需要我們自己編譯構(gòu)建一個(gè)自定義的 Flink 多CPU架構(gòu)鏡像。

作為示例，下面我們構(gòu)建一個(gè) 1.13 版本并且基于 Amazon Corretto 11 JDK 的自定義鏡像，并且同樣構(gòu)建成多CPU架構(gòu)鏡像。

因?yàn)樯婕熬幾g arm64 架構(gòu)的 Flink, 這里推薦啟動一臺Amazon linux 2 操作系統(tǒng)的 Graviton 實(shí)例（比如 t4g.large）編譯構(gòu)建 Flink 鏡像。

在 Graviton 實(shí)例上拉取代碼：

sudo yum groupinstall "Development Tools"
git clone -b DIYflink https://github.com/BWCXME/cost-optimized-flink-on-kubernetes flink-private-demo
cd flink-private-demo

參考文檔【2】，使用腳本構(gòu)建1.13 版本的 Flink

sudo sh build_flink.sh -f 1.13 -j 11 -s 2.11

上述命令會直接構(gòu)建一個(gè)支持 Graviton 的1.13 版本的Flink 鏡像，然后需要將鏡像上傳到私有鏡像倉庫中，并且打上自定義 tag，后面會使用這個(gè)鏡像構(gòu)建多 CPU架構(gòu)鏡像。

轉(zhuǎn)到 cloud9 開發(fā)環(huán)境下，拉取代碼：

cd ~/environmentgit clone -b DIYflink https://github.com/BWCXME/cost-optimized-flink-on-kubernetes flink-private-demo
cd flink-private-demo

使用上面的私有倉庫地址和 tag代替 Dockerfile中的 和

將 Amazon Corretto 11 JDK 的壓縮文件下載到當(dāng)前目錄下

wget https://corretto.aws/downloads/latest/amazon-corretto-11-aarch64-linux-jdk.tar.gz

接下來使用 buildx 構(gòu)建多 CPU架構(gòu)鏡像

登錄倉庫：

aws ecr get-login-password --region ${AWS_REGION} | docker login --username AWS --password-stdin ${ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com

借助buildx插件，一條命令同時(shí)編譯、打包、推送x86和arm架構(gòu)鏡像：

docker buildx build --platform linux/amd64,linux/arm64 --tag ${ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/flink-demo:private --push .

在后續(xù)的部署過程中，可以用 tag 為private 的 flink-demo 鏡像代替默認(rèn)的 latest達(dá)到部署自定義 JDK 和 Flink 版本的目的，結(jié)果如下圖所示：

3.部署ARM Provisioner

當(dāng)我們有一個(gè)具有多架構(gòu) vcpus 的集群時(shí)，我們可以配合使用k8s里的 Taints 和 Tolerations，以確保 pod 調(diào)度到合適的節(jié)點(diǎn)上。

例如，默認(rèn)我們可以給 gravtion 節(jié)點(diǎn)都打上 taint，確保不會有 x86 應(yīng)用程序部署到 graviton 節(jié)點(diǎn)上。只有經(jīng)過測試，加上了 toleration 的應(yīng)用才可以調(diào)度到 gravtion 節(jié)點(diǎn)。

同樣我們?yōu)閍rm節(jié)點(diǎn)，分別設(shè)置 Spot和按需 Provisioner。一個(gè)能容忍“cpu-architectureNoSchedule”污點(diǎn)的應(yīng)用，嘗試的優(yōu)先順序依次如下：

1. arm-spot-provisioner (100)， arm 和 spot 兩大成本優(yōu)化利器的組合拳

2. x86-spot-provisioner (50)，如果arm的spot資源不足，退回到 x86 spot

3. arm-ondemand-provisioner (30)，如果spot資源總體緊張，再退到arm 按需

4. x86-ondemand-provisioner (10)，最后由x86按需兜底

3.1 篩選機(jī)型

借助ec2-instance-selector 工具快速搜索arm機(jī)型：

ec2-instance-selector --memory 16 --vcpus 4 --cpu-architecture arm64 --gpus 0

返回類似如下：

im4gn.xlargem6g.xlargem6gd.xlarget4g.xlarge

3.1 創(chuàng)建ARM Provisioner

創(chuàng)建 arm provisioner 配置文件 provisioner-arm.yaml：

cat > provisioner-arm.yaml <

	

	執(zhí)行部署：

	
k apply -f provisioner-arm.yaml

	

	檢查部署：

	
kapply-fprovisioner-arm.yaml

	

	4.部署Flink到Graviton節(jié)點(diǎn)

	4.1 清理原x86部署

	如果原x86還未刪除，請先執(zhí)行：

	
cd ~/environment/flink-demo/x86
k delete -f .
cd ..

	

	4.2 提交任務(wù)（YAML）

	您即可以通過明確定義YAML文件來部署，也可以利用命令行快捷部署。這里為了方便理解，我們主要演示基于完整的YAML文件部署，您也可以參考后面一節(jié)的命令行提交方式。

	準(zhǔn)備目錄：

	
cd ~/environment/flink-demo/mkdir armcd arm

	

	生成配置文件：

	
cat > flink-configuration-configmap.yaml <

	

	我們增加tolerations 配置，使得Job Manager能夠容忍arm64：

	

	生成jobmanager部署文件：

	
cat > jobmanager-application-ha.yaml <

	

	在上述的配置中，通過nodeSelector，強(qiáng)制往按需節(jié)點(diǎn)上調(diào)度，同時(shí)遵循“Reuse”原則，托管節(jié)點(diǎn)組或者Karpenter拉起的按需節(jié)點(diǎn)都可以。如果您希望限定到?jīng)]有自動伸縮組的節(jié)點(diǎn)（由Karpenter拉起）,請手動添加：

	
nodeSelector:        'group': 'NONE'

	

	

	生成taskmanager部署文件：

	
cat > taskmanager-job-deployment.yaml <

	

	我們遵循“Reuse”原則，上述配置中，沒有添加nodeSelector或nodeAffinity，優(yōu)先利用現(xiàn)有計(jì)算資源，不夠時(shí)再按照前面配置的provisioner優(yōu)先級，依次嘗試直到成功拉起資源。

	

	如果您需要限定托管按需節(jié)點(diǎn)組優(yōu)先部署集群管理相關(guān)組件，或者穩(wěn)定性要求高的應(yīng)用，可以參考以下配置，讓 Task Manager 優(yōu)先運(yùn)行在 Karpenter 拉起的節(jié)點(diǎn)上（如果需要，請手動添加到前面生成的 taskmanager-job-deployment.yaml）：

	
affinity:        nodeAffinity:           preferredDuringSchedulingIgnoredDuringExecution:           - weight: 50             preference:               matchExpressions:               - key: group                 operator: In                 values:                 - NONE

	

	準(zhǔn)備服務(wù)部署文件：

	
cat > jobmanager-svc.yaml <

	

	注意這里為了方便測試，使用LoadBalancer將服務(wù)暴露出來，并且綁定了安全組ExternalSecurityGroup，請確保：

	這個(gè)安全組允許您的本機(jī)IP訪問80端口。

	如果您修改了暴露端口80，例如用的8081，請相應(yīng)在安全組中放開8081端口。

	執(zhí)行部署(請先確認(rèn)在arm目錄下)：

	
k apply -f .

	

	檢查部署：

	
kgp

	

	當(dāng)Pod都拉起來以后，檢查機(jī)器,利用預(yù)設(shè)好的別名：

	
kk

	

	

	如我們的預(yù)期，分別拉起了一臺Graviton的按需和Spot實(shí)例，實(shí)現(xiàn)了非常好的性價(jià)比。

	檢查機(jī)器的taints：

	
kubectlgetnodes-ojson|jq'.items[].spec.taints'

	

	獲取服務(wù)地址：

	
kgetsvcflink-jobmanager-web

	

	拿到地址后在瀏覽器中打開：

	

	一切正常，至此我們很輕松的就將一個(gè)Flink作業(yè)從x86遷移到了arm。

	4.3 提交任務(wù)（命令行）

	您也可以使用命令行提交任務(wù)，目前flink 1.13+以上 支持pod模板，我們可以自定義JM跟TM的啟動方式。這允許直接支持 Flink Kubernetes 配置選項(xiàng)不支持的高級功能。

	定義任務(wù)名稱：

	
exportkubernetes_cluster_id=your-flink-job-name

	

	使用參數(shù) kubernetes.pod-template-file 指定包含 pod 定義的本地文件。它將用于初始化 JobManager 和 TaskManager。

	指定 job manager 運(yùn)行在按需節(jié)點(diǎn)上并且能夠容忍 arm64：

	
cat > arm-jobmanager-pod-template.yaml <

	

	配置 task manager能夠容忍 arm64：

	
cat > arm-taskmanager-pod-template.yaml <

	

	使用命令行提交任務(wù), 注意指定參數(shù) kubernetes.pod-template-file.jobmanager 和 kubernetes.pod-template-file.taskmanager：

	
flink run-application -p 2 -t kubernetes-application   -Dkubernetes.cluster-id=${kubernetes_cluster_id}   -Dkubernetes.container.image=${ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/flink-demo:latest   -Dkubernetes.container.image.pull-policy=Always   -Dkubernetes.jobmanager.service-account=flink-service-account   -Dkubernetes.pod-template-file.jobmanager=./arm-jobmanager-pod-template.yaml   -Dkubernetes.rest-service.exposed.type=LoadBalancer   -Dkubernetes.rest-service.annotations=service.beta.kubernetes.io/aws-load-balancer-security-groups:${EKS_EXTERNAL_SG}   -Dhigh-availability=org.apache.flink.kubernetes.highavailability.KubernetesHaServicesFactory  -Dhigh-availability.cluster-id=${kubernetes_cluster_id}   -Dhigh-availability.storageDir=s3://${FLINK_S3_BUCKET}/recovery   -Dstate.savepoints.dir=s3://${FLINK_S3_BUCKET}/savepoints/${kubernetes_cluster_id}   -Dkubernetes.taskmanager.service-account=flink-service-account   -Dkubernetes.taskmanager.cpu=1   -Dtaskmanager.memory.process.size=4096m   -Dtaskmanager.numberOfTaskSlots=2   -Dkubernetes.pod-template-file.taskmanager=./arm-taskmanager-pod-template.yaml   local:///opt/flink/usrlib/aws-kinesis-analytics-java-apps-1.0.jar   --inputStreamName ${FLINK_INPUT_STREAM} --region ${AWS_REGION} --s3SinkPath s3://${FLINK_S3_BUCKET}/data --checkpoint-dir s3://${FLINK_S3_BUCKET}/recovery

	

	4.4 配置HPA

	首先安裝 metrics-server：

	
kapply-fhttps://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

	

	檢查部署：

	
kgetapiservicev1beta1.metrics.k8s.io-ojson|jq'.status'

	

	Autoscaling 基于Fink的“Reactive Mode”。通過設(shè)置Horizontal Pod Autoscaler，監(jiān)控 CPU 負(fù)載并進(jìn)行相應(yīng)的縮放：

	
kautoscaledeploymentflink-taskmanager--min=1--max=25--cpu-percent=35

	

	檢查當(dāng)前 Task Manager Pod數(shù)量：

	
kgp-lcomponent=taskmanager

	

	目前只有一個(gè)：

	

	5.集成測試

	我們在上一篇中已經(jīng)設(shè)置好輸入/輸出，接下來我們模擬生成數(shù)據(jù)，測試整個(gè)端到端流程。

	

	5.1 配置數(shù)據(jù)生成器

	這里示例，我們使用Kinesis Data Generator，打https://awslabs.github.io/amazon-kinesis-data-generator/web/help.html 頁面。

	點(diǎn)擊通過 CloudFormation 配置測試用戶(跳轉(zhuǎn)后注意切換到自己所在區(qū)域)：

	

	下一步設(shè)置用戶名和密碼，其他參數(shù)保持默認(rèn)，創(chuàng)建即可。

	接著從 CloudFormation 輸出堆棧里找到 URL，跳轉(zhuǎn)到Kinesis Data Generator頁面。

	

	輸入前面創(chuàng)建堆棧時(shí)設(shè)置的用戶名和密碼完成登錄：

	

	5.2 準(zhǔn)備數(shù)據(jù)模板

	示例模板如下：

	
{"EVENT_TIME": "{{date.now("dddd, MMMM Do YYYY, hss a")}}",    "TICKER": "{{random.arrayElement(        ["ABCD", "CDEF", "IJKL", "MNOP", "QRST"]    )}}",    "PRICE": "{{random.number(        {            "min":500,            "max":1000        }    )}}",    "ID": "{{random.uuid}}"}

	

	5.3 注入測試數(shù)據(jù)

	切到所在區(qū)域，然后選擇之前準(zhǔn)備的輸入流，替換模板后，點(diǎn)擊發(fā)送數(shù)據(jù)：

	注意：請確保 Kinesis Data Generator 仍然保持在登錄狀態(tài)，開始發(fā)送后先切到 Kinesis 控制臺檢查監(jiān)控指標(biāo)，確保有數(shù)據(jù)寫入。

	

	觀察HPA變化：

	
kgethpaflink-taskmanager-w

	

	

	觀察Task Manager Pod 數(shù)量：

	
kgp -l component=taskmanager

	

	

	6.混沌測試

	您可以借助AWS Fault Injection Simulator 模擬Spot事件，例如提前5分鐘發(fā)出通知，然后觀察節(jié)點(diǎn)變化和Flink的行為。

	6.1 配置FIS模板

	打開Fault Injection Simulator控制臺https://us-east-1.console.aws.amazon.com/fis/home?region=us-east-1。

	創(chuàng)建新實(shí)驗(yàn)，參數(shù)如下：

	實(shí)驗(yàn)名稱，例如“flink-spot-experiment”

	Action 名稱：spot-interruptions

	Action 類型：awssend-spot-instance-interruptions

	提前通知時(shí)間：時(shí)間在2～15分鐘之內(nèi)，例如設(shè)置5分鐘

	Target標(biāo)簽篩選：Resource tags, filters and parameters

	Key: karpenter.sh/provisioner-name

	Value: arm-spot-provisioner

	Target 資源篩選：Resource filters

	路徑：Name

	值：running

	Target選擇模式：

	方式：Count

	數(shù)量：不超過5

	6.2 監(jiān)控Job Manager日志

	可以通過kubectl命令：

	
klogs-f

	

	或者利用預(yù)裝的k9s工具進(jìn)行跟蹤：

	
k9s

	

	然后選擇 Job Manager，按下 “l(fā)”鍵查看日志：

	6.3 啟動實(shí)驗(yàn)

	回到FIS控制臺，啟動前面創(chuàng)建的實(shí)驗(yàn)。然后詳細(xì)查看 JobManager 日志，發(fā)現(xiàn) JobManager 恢復(fù)作業(yè)的過程：

	

	如果出現(xiàn)中斷，則將使用檢查點(diǎn)數(shù)據(jù)重新啟動 Flink 應(yīng)用程序。JobManager 將恢復(fù)作業(yè)。受影響的節(jié)點(diǎn)將被自動替換。

	7.成本可見性

	前面我們主要在集群層面進(jìn)行優(yōu)化，下面我們將視角切到應(yīng)用/作業(yè)層面，遵循“Reduce”原則，將成本管理進(jìn)行到底。

	從2022年8月25號開始，Amazon EKS 客戶可以部署 EKS 優(yōu)化且免費(fèi)的 Kubecost 包，以實(shí)現(xiàn)集群成本可見性。通過 Kubecost 可以查看按 Kubernetes 資源（包括 pod、節(jié)點(diǎn)、命名空間、標(biāo)簽等）細(xì)分的成本。Kubernetes 平臺管理員和財(cái)務(wù)負(fù)責(zé)人可以使用 Kubecost 可視化其 Amazon EKS 費(fèi)用明細(xì)和分配成本等。

	Kubecost 還能根據(jù)其基礎(chǔ)設(shè)施環(huán)境和集群內(nèi)的使用模式獲得定制的成本優(yōu)化建議，例如設(shè)置合適的節(jié)點(diǎn)規(guī)模，容器資源申請建議等。

	檢查可安裝版本：

	
https://gallery.ecr.aws/kubecost/cost-analyzer

	

	準(zhǔn)備安裝參數(shù)：

	
cat > kubecost-values.yaml <

	

	這里為方便演示，使用LoadBalancer將服務(wù)暴露出來，并且綁定了安全組ExternalSecurityGroup，請確保：

	這個(gè)安全組允許您的本機(jī)IP訪問80端口。

	如果您修改了暴露端口80，例如用的9090，請相應(yīng)在安全組中放開9090端口。

	安裝kubecost(以1.96.0為例)

	
helm upgrade -i kubecost oci://public.ecr.aws/kubecost/cost-analyzer --version 1.96.0     --namespace kubecost --create-namespace     -f kubecost-values.yaml

	

	獲取服務(wù)地址：

	
k get svc kubecost-cost-analyzer -n kubecost

	

	拿到地址后在瀏覽器中打開，查看節(jié)省建議類似如下：

	如果提示還在收集數(shù)據(jù)，可以等待15分鐘左右再刷新頁面：

	
Kubecost is collecting data. Data should be ready for viewing within 15 minutes.

	

	

	總結(jié)

	在本文中，我們遵循AWS Well-Architected Framework的可持續(xù)性支柱，從Rearchitect的角度，我們介紹了通過buildx 工具，一條命令同時(shí)編譯、打包、推送x86和arm架構(gòu)鏡像，平滑的實(shí)現(xiàn)從 x86 實(shí)例遷移到 Graviton實(shí)例，同時(shí)通過自定義 Flink 鏡像讓使用者可以自由選擇 Flink, Java, Scala 等組件的版本以適應(yīng)業(yè)務(wù)需求。從Reduce 角度，通過部署 Kubecost 實(shí)現(xiàn)成本管理和持續(xù)的基礎(chǔ)設(shè)施優(yōu)化。

	

	   審核編輯：彭靜