在线观看国产一区二区_免费一级A爱片久久毛片_VA在线观看免费国产_色污无遮挡在线看WWW_国产麻豆福利在线观看_国产日韩高清三级精品人成_99久久人妻无码精品系列ai_天堂av免费在线

1.前言

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

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

遵循 Rearchitect 原則，引入 Graviton，實現從 x86 到 arm 架構的轉變的同時，進一步推進成本節省和持續的基礎設施優化。

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

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

實驗架構回顧：

架構概要說明：

1. 創建 EKS 集群時，添加一個托管按需節點組（默認一個節點），用于部署系統組件例如 EBS CSI 驅動程序等。

2. 借助 Karpenter 動態拉起 Flink 作業需要的計算資源，通過配置多個Provisioner，每個 Provisioner 設置不同 weight，實現精細化協同控制。

3. ARM 節點主動打上 Taints，配合使用 Tolerations，以確保 Flink 作業調度到合適的節點上。

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

5. Flink Job Manager (Flink JM) 利用 nodeSelector 主動調度到由按需節點（包括部署系統組件的按需節點組和 Karpenter拉起的節點）。

6. Flink Task Manager (Flink TM) 默認不加任何限定條件（nodeSelector/ nodeAffinity），并且配置HPA（基于CPU）。當資源不夠時，由 Provisioner 按優先級協調拉起合適節點。

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

8. Flink 作業啟用檢查點，并將作業檢查點數據寫入 S3，從而允許 Flink 保存狀態并具備容錯性。

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

10. Node Termination Handler 配合 Spot，讓應用運行更平穩。

上一篇我們已經搭建好 EKS 集群，并將 Flink 作業運行在 x86 節點上。接下來首先通過切換到基于 Graviton 的實例來提高計算工作負載的能效。同時綜合運用 Karpenter 的優先級策略，實現對 Flink 作業計算資源的精細化管理。

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

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

1. 遵循上一篇提到的“Reuse”原則，如果現有容量可用，kube-scheduler 將直接調度 pod，不會觸發 Karpenter 拉起新節點。

2. 根據 Karpenter 執行 pod 批處理和 bin 打包的方式，如果一個 pod 無法使用最高優先級的配置器進行調度，它將強制使用較低優先級的配置器創建一個節點，這可能允許該批次中的其他 pod 也可以在該節點上進行調度。

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

2.構建多CPU架構鏡像

2.1 準備buildx工具

打開 Cloud9 控制臺：

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

進入到IDE環境，前面一篇已經安裝好docker buildx工具，如果有問題請下載prepareCloud9IDE.sh：

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

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

c9 prepareCloud9IDE.sh

2.2 配置build

創建并使用flink-build：

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

2.3 一鍵打包多CPU架構鏡像

首先進入代碼目錄：

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插件，一條命令同時編譯、打包、推送x86和arm架構鏡像：

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

查看 Dockerfile，內容如下所示：

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/

如果您要更改基礎鏡像maven 或 flink的版本，請確保指定tag下有arm的版本，不然buildx會報錯。

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

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

返回類似如下：

簡單3步，Flink作業的ARM鏡像就打好了，即不用更改Dockerfile，也不用單獨設置Tag。

2.4 構建自定義版本的 Flink多CPU架構鏡像

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

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

因為涉及編譯 arm64 架構的 Flink, 這里推薦啟動一臺Amazon linux 2 操作系統的 Graviton 實例（比如 t4g.large）編譯構建 Flink 鏡像。

在 Graviton 實例上拉取代碼：

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】，使用腳本構建1.13 版本的 Flink

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

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

轉到 cloud9 開發環境下，拉取代碼：

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 的壓縮文件下載到當前目錄下

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

接下來使用 buildx 構建多 CPU架構鏡像

登錄倉庫：

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

借助buildx插件，一條命令同時編譯、打包、推送x86和arm架構鏡像：

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

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

3.部署ARM Provisioner

當我們有一個具有多架構 vcpus 的集群時，我們可以配合使用k8s里的 Taints 和 Tolerations，以確保 pod 調度到合適的節點上。

例如，默認我們可以給 gravtion 節點都打上 taint，確保不會有 x86 應用程序部署到 graviton 節點上。只有經過測試，加上了 toleration 的應用才可以調度到 gravtion 節點。

同樣我們為arm節點，分別設置 Spot和按需 Provisioner。一個能容忍“cpu-architectureNoSchedule”污點的應用，嘗試的優先順序依次如下：

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

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

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

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

3.1 篩選機型

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

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

返回類似如下：

im4gn.xlargem6g.xlargem6gd.xlarget4g.xlarge

3.1 創建ARM Provisioner

創建 arm provisioner 配置文件 provisioner-arm.yaml：

cat > provisioner-arm.yaml <

	

	執行部署：

	
k apply -f provisioner-arm.yaml

	

	檢查部署：

	
kapply-fprovisioner-arm.yaml

	

	4.部署Flink到Graviton節點

	4.1 清理原x86部署

	如果原x86還未刪除，請先執行：

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

	

	4.2 提交任務（YAML）

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

	準備目錄：

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

	

	生成配置文件：

	
cat > flink-configuration-configmap.yaml <

	

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

	

	生成jobmanager部署文件：

	
cat > jobmanager-application-ha.yaml <

	

	在上述的配置中，通過nodeSelector，強制往按需節點上調度，同時遵循“Reuse”原則，托管節點組或者Karpenter拉起的按需節點都可以。如果您希望限定到沒有自動伸縮組的節點（由Karpenter拉起）,請手動添加：

	
nodeSelector:        'group': 'NONE'

	

	

	生成taskmanager部署文件：

	
cat > taskmanager-job-deployment.yaml <

	

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

	

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

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

	

	準備服務部署文件：

	
cat > jobmanager-svc.yaml <

	

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

	這個安全組允許您的本機IP訪問80端口。

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

	執行部署(請先確認在arm目錄下)：

	
k apply -f .

	

	檢查部署：

	
kgp

	

	當Pod都拉起來以后，檢查機器,利用預設好的別名：

	
kk

	

	

	如我們的預期，分別拉起了一臺Graviton的按需和Spot實例，實現了非常好的性價比。

	檢查機器的taints：

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

	

	獲取服務地址：

	
kgetsvcflink-jobmanager-web

	

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

	

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

	4.3 提交任務（命令行）

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

	定義任務名稱：

	
exportkubernetes_cluster_id=your-flink-job-name

	

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

	指定 job manager 運行在按需節點上并且能夠容忍 arm64：

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

	

	配置 task manager能夠容忍 arm64：

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

	

	使用命令行提交任務, 注意指定參數 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”。通過設置Horizontal Pod Autoscaler，監控 CPU 負載并進行相應的縮放：

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

	

	檢查當前 Task Manager Pod數量：

	
kgp-lcomponent=taskmanager

	

	目前只有一個：

	

	5.集成測試

	我們在上一篇中已經設置好輸入/輸出，接下來我們模擬生成數據，測試整個端到端流程。

	

	5.1 配置數據生成器

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

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

	

	下一步設置用戶名和密碼，其他參數保持默認，創建即可。

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

	

	輸入前面創建堆棧時設置的用戶名和密碼完成登錄：

	

	5.2 準備數據模板

	示例模板如下：

	
{"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 注入測試數據

	切到所在區域，然后選擇之前準備的輸入流，替換模板后，點擊發送數據：

	注意：請確保 Kinesis Data Generator 仍然保持在登錄狀態，開始發送后先切到 Kinesis 控制臺檢查監控指標，確保有數據寫入。

	

	觀察HPA變化：

	
kgethpaflink-taskmanager-w

	

	

	觀察Task Manager Pod 數量：

	
kgp -l component=taskmanager

	

	

	6.混沌測試

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

	6.1 配置FIS模板

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

	創建新實驗，參數如下：

	實驗名稱，例如“flink-spot-experiment”

	Action 名稱：spot-interruptions

	Action 類型：awssend-spot-instance-interruptions

	提前通知時間：時間在2～15分鐘之內，例如設置5分鐘

	Target標簽篩選：Resource tags, filters and parameters

	Key: karpenter.sh/provisioner-name

	Value: arm-spot-provisioner

	Target 資源篩選：Resource filters

	路徑：Name

	值：running

	Target選擇模式：

	方式：Count

	數量：不超過5

	6.2 監控Job Manager日志

	可以通過kubectl命令：

	
klogs-f

	

	或者利用預裝的k9s工具進行跟蹤：

	
k9s

	

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

	6.3 啟動實驗

	回到FIS控制臺，啟動前面創建的實驗。然后詳細查看 JobManager 日志，發現 JobManager 恢復作業的過程：

	

	如果出現中斷，則將使用檢查點數據重新啟動 Flink 應用程序。JobManager 將恢復作業。受影響的節點將被自動替換。

	7.成本可見性

	前面我們主要在集群層面進行優化，下面我們將視角切到應用/作業層面，遵循“Reduce”原則，將成本管理進行到底。

	從2022年8月25號開始，Amazon EKS 客戶可以部署 EKS 優化且免費的 Kubecost 包，以實現集群成本可見性。通過 Kubecost 可以查看按 Kubernetes 資源（包括 pod、節點、命名空間、標簽等）細分的成本。Kubernetes 平臺管理員和財務負責人可以使用 Kubecost 可視化其 Amazon EKS 費用明細和分配成本等。

	Kubecost 還能根據其基礎設施環境和集群內的使用模式獲得定制的成本優化建議，例如設置合適的節點規模，容器資源申請建議等。

	檢查可安裝版本：

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

	

	準備安裝參數：

	
cat > kubecost-values.yaml <

	

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

	這個安全組允許您的本機IP訪問80端口。

	如果您修改了暴露端口80，例如用的9090，請相應在安全組中放開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

	

	獲取服務地址：

	
k get svc kubecost-cost-analyzer -n kubecost

	

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

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

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

	

	

	總結

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

	

	   審核編輯：彭靜