2019年新一代Serverless平臺Knative的應用實踐.pdf

《2019年新一代Serverless平臺Knative的應用實踐.pdf》由會員分享，可在線閱讀，更多相關《2019年新一代Serverless平臺Knative的應用實踐.pdf（35頁珍藏版）》請在三個皮匠報告上搜索。

1、中國軟件技術大會CHINA SOFTWARE TECHNOLOGY CONFERENCE新一代Serverless平臺 Knative的應用實踐內容內容提要提要 無服務架構的特點 Knative 的無服務架構解決方案 Knative在當當業務中的實踐 案例總結背景云原生平臺面臨的挑戰K8S+Istio已經成為微服務的主流解決方案，開發人員使用云原生平臺的技術門檻提高開發者需要一種簡單有效的服務編排標準來解決開發與運維管理復雜度問題需要進一步提高計算資源的利用率什么是Serverless無服務器架構：開發者實現的業務邏輯運行在無狀態的計算容器中，它由事件觸發，完全被第三方管理，其業務層面的狀態存

2、儲在數據庫和其他存儲資源中。無需管理基礎設施按用付費事件驅動自動化構建部署無服務器架構FaaSServerless使用場景適合使用無服務器架構的場景：1.異步，并發，易于并行化成獨立工作單元的工作負載2.低頻或有零星請求，但具有較大不可預測的擴容變化需求的工作負載3.無狀態，短期運行，對冷啟動延遲不敏感的工作負載4.業務需求變化迅速，要求快速開發實現的場景Serverless的特點Serverless架構的優點低運營成本低開發成本彈性擴展簡單的管理綠色的計算當前Serverless架構的缺點標準不統一，存在廠商鎖定問題冷啟動延遲問題FunctionsAppsContainersVirtual

3、MachinesBare MetalServerlessInfrastructure現有Serverless平臺及實現開源serverless實現KnativeApache OpenWhiskSpring Cloud FunctionsRiffOpenFaaSFissionkubeless公有云Serverless托管服務AWS Lambda（2014）Google Cloud FunctionsMicrosoft Azure FunctionsIBM Cloud FunctionsAliyun Function ComputeTencent Cloud SCFHuawei Cloud Fun

4、ctionGraphKnative是什么 Knative 是谷歌發起的基于K8S平臺的Serverless 開源項目,致力將Serverless標準化 項目地址：https:/ 當前版本：v0.10.0 當前發展情況:55+企業貢獻者 450個人貢獻者 9個工作組 6K Pull Requests/monthKnative在K8S生態中的定位Severless服務治理容器編排Container RuntimeKubernetes負載均衡、服務發現、擴縮容、運維、部署ContainersIstio動態路由、熔斷限流、調用鏈跟蹤 Knative無狀態服務編排、事件驅動、構建部署FunctionsA

5、ppsWhy KnativeKubernetes是當前最流行的容器管理平臺Resource：Container，Pod，ReplicSet，Deployment，StatefulSets，DaemonSet，Job/Cronjob，Service，Ingress，ConfigMap，Secret，PV/PVCTools&Other：Helm，Istio，CI/CD，EFK，Promethuse&GrafanaKubernetes的目標用戶事實上并不是業務開發者對于業務開發者來說，K8S平臺并不是一個好的抽象對于Devops來說，K8S是構建PaaS最好的平臺Knative是為開發者準備的Ser

6、verless平臺抽象復雜的細節讓開發者關注在業務本身（Service-based，Event-driven）解決無聊卻困難的構建，部署，服務治理步驟開放和可移植（Open&portable）云原生平臺三個最佳實踐 服務的構建和部署實現高度自動化 服務的編排要實現計算資源彈性化 事件驅動基礎設施標準化Knative的總體設計設計原則：標準化，可替代，松散組合，不綁定Knative Serving1.功能定義：Kubernetes based,scale to zero,request driven compute2.支持的工作負載FunctionMicroserviceTraditional

7、ApplicationContainer3.Knative Serving提供的基礎能力：用戶容器的快速部署 自動伸縮，支持縮容到零 服務路由和流量控制 容器和配置的版本管理Knative Serving的基礎概念基于 kubernetes 的 CRD實現Service：負責管理工作負載的整個生命周期Route：將HTTP請求路由到一個或多個revision/修訂版本Configuration：保存應用容器和配置的最新狀態，是創建Revision的模板Revision：對工作負載進行代碼和配置修改的時間點快照Knative Serving的工作流程Service 1,revision2 Dep

8、loyment 2,Scale:3Service 1,revision1 Deployment 1,Scale:1KubernetesService 1,revision1 Deployment 1,Scale:0User ContainerQueue ContainerUser ContainerQueue ContainerUser ContainerQueue ContainerUser ContainerQueue ContainerUser ContainerQueue ContainerUser ContainerQueue ContainerAutoscalerActivator

9、GatewayUser ContainerQueue ContainerService 1,revision1 Deployment 1,Scale:3Knative對用戶容器的限制必須是無狀態的HTTP服務允許掛載configmap，secret，projected，但不允許掛載持久卷pvc一個Service只能有一個用戶容器CI/CD的實現（Tekton Pipelines）Tekton Pipelines是K8S風格的CI/CD框架Kubernetes 原生靈活擴展輕量級白盒化K8S原生靈活擴展輕量級白盒化事件驅動Knative Eventing核心功能：對發布/訂閱細節進行抽象處理，幫

10、助開發人員擺脫相關負擔。聲明式地綁定event sources,triggers和services從少量事件到實時stream pipelines動態擴展采用CloudeEvents標準抽象的事件來源，解耦具體事件源類型(eg.Kafka,CronJob,Github,kubernetes )Channel的實現可插拔(eg.InMemory,Kafka,Nats,PubSub)事件驅動Knative EventingSourceEventsService(Callable)TriggerFilter=Service(Callable)TriggerFilter=SourceEventssub

11、scribesubscribeingressingressNamespaceBroker(on channel)Sources:抽象的事件來源Channel:處理事件的轉發和持久化Broker:把事件發送給訂閱者Trigger:訂閱來自特定broker的事件關于CloudEvents關于CloudEventsCloudEvents是一種以通用方式描述事件數據的規范。CloudEvents旨在簡化跨服務，平臺及其他方面的事件聲明和發送CloudEvents由CNCF Severless 工作組提出，當前已發布v1.0版CloudEvents 狀態https:/cloudevents.io/htt

12、ps:/ Knative:v0.8.0 Istio:v1.3.0 Kubernetes：v1.14.4 Docker:v18.06.3 Centos：v7.5 Promethues v2.2.1 Grafana v5.0.3 Tekton Pipelines:v0.8.0 Server:32cores/128G mem/500GB HD1.編寫用戶容器相應的dockerfile2.Tekton構建代碼打包運行時容器推送到私有鏡像倉庫3.編寫knative的service.yaml 配置文件用戶容器的構建與編排FROM reg- mkdir-p/var/www/hosts/productapiC

13、OPY./var/www/hosts/productapi/EXPOSE 80CMD/run.shapiVersion:serving.knative.dev/v1alpha1kind:Servicemetadata:labels:application:productapitier:applicationname:productapinamespace:defaultspec:template:metadata:labels:application:productapitier:applicationname:productapi-v1spec:containers:-image:reg-

14、traffic:-tag:currentrevisionName:productapi-v1percent:100-tag:candidaterevisionName:productapi-v2percent:0-tag:latestlatestRevision:truepercent:0ServiceRevision(productapi-v1)Revision(productapi-v2)100%0%性能測試評估Knative平臺對應用代碼的性能影響請求總并發：200Knative環境每個POD并發數：40Knative環境啟動POD數：6個K8s環境啟用POD數：6個問題與后續改進性能問

15、題：Queue Proxy1.負責所有用戶容器流量的轉發2.向Autoscaler報告客戶端指標 帶來的問題：調用鏈中增加了一層代理，在我們的測試場景中，QueueProxy帶來了27ms的延遲以及約120m的CPU資源消耗。未來可能的解決方案直接使用Istio的sidecar(envoy)來替換Queue Proxy，但這樣有可能會帶來對service mesh層的耦合。運維工具日志中心：EFK監控：Promethues&Grafana服務網格可視化：Istio&Kiali，Jaeger(調用鏈跟蹤)服務可視化工具服務網格的可視化工具-Kiali1.服務拓撲圖2.健康檢查3.分布式跟蹤4.指

16、標度量收集5.配置校驗監控工具性能優化（一）降低冷啟動延遲的解決方案保留服務最小副本數避免冷啟延遲autoscaling.knative.dev/minScale:“n”/n 為1或者對應業務估算的最小副本數微服務化優化服務啟動速度A.減小用戶容器鏡像的大小，方便快速分發B.減少用戶容器的啟動時間性能優化（二）對可預見的高并發場景的解決方案為服務預設預期最小所需副本數例如：autoscaling.knative.dev/minScale:“200”為服務預設最大所需副本數避免資源過度分配例如：autoscaling.knative.dev/maxScale:“500為服務的每個POD設置最大并

17、發請求數上限保障每個服務的可用性例如：autoscaling.knative.dev/target:“100”后續發展與改進支持更多彈性伸縮指標當前支持的metricsHPA：CPU使用率，不支持縮容到0KPA：并發請求數，支持縮容到0 新版本新增Metrics：KPA:RPS/QPS/OPS結論 Knative對于Serverless平臺的標準化意義重大 Knative當前正逐步成熟，大規模應用還需要進一步完善。Knative的發展前景廣闊，有望成為未來的主流無服務架構管理平臺總結 Serverless秉承請求驅動計算，計算資源按需分配原則，大幅提高了計算資源的利用率 無服務架構平臺可以顯著地減少運維工作量，使得開發者工作效能更高。業務代碼與平臺代碼的隔離帶來開發的敏捷性 計算資源脫離服務器的抽象（無服務器架構）是云計算發展的必然趨勢謝謝