股份制銀行容器云平臺建設(shè)實踐經(jīng)驗

1、 某股份制銀行容器云平臺建設(shè)實踐經(jīng)驗 【作者】張立，現(xiàn)就職于某銀行信息科技部系統(tǒng)管理中心，容器云平臺技術(shù)負責(zé)人，負責(zé)行內(nèi)容器云平臺建設(shè)以及應(yīng)用容器化改造規(guī)范制定。一、容器云平臺建設(shè)行業(yè)背景當前銀行業(yè)普遍的共識之一是要以金融科技為依托，通過科技創(chuàng)新引領(lǐng)銀行的轉(zhuǎn)型升級。云計算、大數(shù)據(jù)、人工智能成為各銀行科技部門重點的投資建設(shè)領(lǐng)域。云計算領(lǐng)域的建設(shè)主要集中在IaaS和PaaS，目標是降低數(shù)據(jù)中心成本的同時，為上層應(yīng)用的創(chuàng)新、快速迭代和穩(wěn)定運行提供有效支撐。傳統(tǒng)的IaaS調(diào)度的是虛擬機或者物理機，粒度較大，相對傳統(tǒng)的虛擬化技術(shù)，在資源使用率、靈活性和彈性方面提升度并不高。依托傳統(tǒng)IaaS建設(shè)而成的Pa

2、aS，也會面臨同樣的問題。而容器技術(shù)恰好可以比較好的解決這些問題，并且在微服務(wù)、DevOps、分布式等方面天生具備優(yōu)勢，因此成為數(shù)據(jù)中心新一代云基礎(chǔ)架構(gòu)的選擇。二、建設(shè)容器云平臺的意義1.讓應(yīng)用真正意義上彈性擴縮容傳統(tǒng)方式下應(yīng)用和基礎(chǔ)環(huán)境資源（計算、網(wǎng)絡(luò)、存儲、監(jiān)控等） 是緊耦合的關(guān)系，應(yīng)用的擴容、縮容意味著基礎(chǔ)環(huán)境資源的擴容和縮容。基礎(chǔ)環(huán)境的擴、縮容耗時會非常長，因為涉及到非常多需要人工介入的環(huán)境，而且都是串行的，比如創(chuàng)建主機、分配存儲、網(wǎng)絡(luò)接入、操作系統(tǒng)安裝、網(wǎng)絡(luò)訪問關(guān)系開通、應(yīng)用部署、監(jiān)控審計部署、接入負載均衡等等。整個流程走下來通常需要數(shù)天到數(shù)周的時間。后來我們通過IaaS、虛擬化、自

3、動化工具已經(jīng)大幅度縮減了基礎(chǔ)環(huán)境資源擴容的時間，但是整個流程下來仍然需要數(shù)個小時到數(shù)天，這對于真正需要彈性的應(yīng)用來說還是不夠。容器云環(huán)境下，應(yīng)用和基礎(chǔ)環(huán)境資源是解耦的，應(yīng)用的擴縮容不需要涉及基礎(chǔ)環(huán)境資源的擴縮容，僅僅需要修改應(yīng)用部署模板文件中的副本數(shù)，然后在容器云平臺執(zhí)行即可。容器云平臺會根據(jù)副本數(shù)來自動創(chuàng)建或者刪除副本，使得最終的副本數(shù)是部署模板文件中定義的副本數(shù)。整個擴容或縮容流程可以在數(shù)秒到數(shù)十秒內(nèi)完成。這樣當應(yīng)用面臨突發(fā)業(yè)務(wù)量增長，需要緊急擴容的時候，就可以非?？斓耐瓿桑瑢崿F(xiàn)了真正意義上的彈性擴容。2.為應(yīng)用微服務(wù)化提供有力支撐應(yīng)用微服務(wù)化是當前應(yīng)用改造的一個重點方向，因為大家都看到了

4、微服務(wù)的好處，就是迭代效率高、資源使用率高(單一微服務(wù)可自行擴容)、單一微服務(wù)故障 對全局影響有限。但是傳統(tǒng)方式下的應(yīng)用微服務(wù)化開發(fā)運營是缺乏體系支撐的，成本高昂、便捷性差。比如一個應(yīng)用由20個微服務(wù)組成，每個微服務(wù)需要2個副本保持高可用，傳統(tǒng)方式下就需要申請20個負載均衡、40個虛擬機來確保隔離性，同時還要為這40個虛擬機分配相應(yīng)的網(wǎng)絡(luò)、存儲，部署配套的監(jiān)控審計等，消耗了大量的資源。傳統(tǒng)方式下的這套架構(gòu)沒有彈性擴縮容能力，也缺乏自動化的部署管理工具，對運維人員來說，管理的應(yīng)用從1個變?yōu)?0個，大大增加了工作量和復(fù)雜度，便利性會很差。從應(yīng)用開發(fā)人員的角度看，傳統(tǒng)方式下做微服務(wù)化改造，隨著微服數(shù)

5、量的增加，服務(wù)之間依賴關(guān)系的增加，開發(fā)人員會面臨很大的挑戰(zhàn)。需要部署專門的服務(wù)注冊發(fā)現(xiàn)系統(tǒng)，需要對應(yīng)用層代碼做侵入實現(xiàn)服務(wù)的注冊發(fā)現(xiàn)機制，需要對應(yīng)用代碼做修改以實現(xiàn)服務(wù)的探活和依賴性處理。這些服務(wù)治理方面的工作牽扯了開發(fā)人員很大的精力，使得應(yīng)用人員無法將精力集中在業(yè)務(wù)開發(fā)本身上，是一種低效率的做法。容器云環(huán)境提供了一套成熟的支撐體系，可以很好的支撐應(yīng)用的微服務(wù)化改造，成本低廉、便捷性好。還是以之前的應(yīng)用為例，20個微服務(wù)中，僅僅對外部提供服務(wù)的微服務(wù)需要申請負載均衡，內(nèi)部微服務(wù)之間的調(diào)用通過service機制即可實現(xiàn)。如果很多微服都需要對外提供服務(wù)，也可以通過ingress將所有服務(wù)收斂到一個

6、入口上，這樣對負載均衡的需求數(shù)量就大幅度下降。容器化的微服務(wù)都是運行在一個計算機群內(nèi)，可以共享計算節(jié)點，擴容、縮容都不需要申請?zhí)摂M機，資源的使用效率可以最高。容器云也為應(yīng)用的部署運行提供很好的編排工具，可以實現(xiàn)應(yīng)用變更的完全自動化、滾動升級、一鍵回滾。對應(yīng)用開發(fā)人員來說，容器云環(huán)境可以提供比較完善的可配置化的微服治理框架，包括服務(wù)注冊發(fā)現(xiàn)、服務(wù)探活、依賴性處理等，不需要對應(yīng)用代碼做侵入修改，這樣可以讓應(yīng)用開發(fā)人員將更多精力集中在業(yè)務(wù)開發(fā)本身。3.讓應(yīng)用實現(xiàn)自動化故障探測、隔離和恢復(fù)傳統(tǒng)方式下的應(yīng)用故障判斷、隔離和恢復(fù)完全依賴人工介入，耗時很長。比如一旦出現(xiàn)某個應(yīng)用節(jié)點的故障，需要運維人員人工判

7、斷是哪一個節(jié)點出了問題，然后人工將該節(jié)點從負載均衡摘除。隨后人工恢復(fù)故障節(jié)點，再掛到負載均衡下面。這就導(dǎo)致很長的故障窗口期，對業(yè)務(wù)連續(xù)性并不友好.容器方式下，應(yīng)用的故障判別、隔離和恢復(fù)完全自動化實現(xiàn)，無需人工干預(yù)。容器云環(huán)境提供一套應(yīng)用服務(wù)的自主探測和處理機制，同時也會檢測每一個節(jié)點，一旦發(fā)現(xiàn)某個應(yīng)用副本異常，會立即將其從service摘除，之后自動刪除故障副本，并在可用的節(jié)點上新建新的副本。當探測到新建副本已經(jīng)可以提供服務(wù)后，會自動將新建副本掛載到service下面。這種完全自動化的故障處理恢復(fù)機制為應(yīng)用提供了故障自愈能力，將故障窗口減小到最小。4.大幅度提升資源使用效率在沒有虛擬機之前，我

8、們使用裸機部署應(yīng)用，一個裸機部署一個應(yīng)用，造成了大量的 資源閑置。后來使用虛擬機后，一個裸機上可以虛擬出多個主機，可以部署多個應(yīng)用，資源使用效率得到了很大的提升。虛擬機之間可以共享CPU，但是無法共享內(nèi)存和存儲，比如一個虛擬機申請了32GB內(nèi)存和100GB存儲，這些資源只能被這個虛擬機獨占，無法和其它虛擬機共享。容器的本質(zhì)是進程，進程間是可以共享宿主機的CPU、內(nèi)存、存儲和網(wǎng)絡(luò)的，資源使用效率得到最充分的利用。當然做到這一點的前提是容器能夠確保進程運行的基本資源不被搶占，資源層面實現(xiàn)良好的隔離性。同時允許設(shè)置資源使用配額上限，避免影響其它應(yīng)用進程。三、容器云平臺架構(gòu)設(shè)計1.總體架構(gòu)設(shè)計總體架構(gòu)

9、圖如下：自服務(wù)管理平臺提供8大板塊服務(wù)，都是按照支持多租戶的目標設(shè)計實現(xiàn)。其中資源申請板塊是租戶申請容器資源的入口，包含帳號申請，K8S和鏡像庫資源申請，日志接入申請。資源變更板塊是租戶進行資源變更的入口，包括K8S資源擴容和回收，以及帳號權(quán)限的修改。集群管理板塊為云平臺管理員和租戶提供集群范圍資源的管理，鏡像庫管理板塊提供鏡像庫和鏡像的管理，應(yīng)用管理板塊主要為租戶提供K8S namespace內(nèi)資源的管理，模板管理板塊包含K8S資源模板和Helm模板，運維助手提供Pod歷史查詢以及集群健康檢查管理，帳號授權(quán)管理板塊為云平臺管理員提供租戶授權(quán)管理。自服務(wù)管理平臺南向通過K8S API和鏡像庫A

10、PI對接多個K8S集群和兩個鏡像庫，實現(xiàn)容器資源的統(tǒng)一納管。最右邊的是行內(nèi)的運營支撐工具體系，其中統(tǒng)一身份認證為自服務(wù)管理平臺提供租戶帳號的登陸鑒權(quán)服務(wù)，流程系統(tǒng)(即ITOMS)通過API和自服務(wù)管理平臺的資源申請板塊對接，提供統(tǒng)一的資源申請入口。CMDB和自服務(wù)管理平臺自身的CMDB交互，提供應(yīng)用、容器、資源之間的關(guān)系視圖；DevOps工具鏈可以從自服務(wù)平臺獲取用戶和權(quán)限，然后通過K8S API和鏡像庫API實現(xiàn)應(yīng)用的自動化流水線發(fā)布。ELK日志系統(tǒng)用于存儲容器應(yīng)用的日志，集中監(jiān)控告警系統(tǒng)接收來自K8S節(jié)點和容器應(yīng)用的監(jiān)控數(shù)據(jù)，提供告警推送、置維護、統(tǒng)一監(jiān)控視圖的能力。2.多集群管理設(shè)計根據(jù)

11、銀行內(nèi)網(wǎng)絡(luò)安全的要求，K8S集群不能通過Overlay網(wǎng)絡(luò)跨網(wǎng)絡(luò)隔離區(qū)。因此一個K8S集群只能限定在一個網(wǎng)絡(luò)隔離區(qū)內(nèi)。目前生產(chǎn)和災(zāi)備數(shù)據(jù)中心的每個網(wǎng)絡(luò)隔離區(qū)部署一套或多套K8S集群，所有集群統(tǒng)一由自服務(wù)管理平臺納管。同一網(wǎng)絡(luò)隔離區(qū)內(nèi)，生產(chǎn)和災(zāi)備數(shù)據(jù)中心各部署K8S集群，為應(yīng)用提供雙活容災(zāi)部署架構(gòu)支撐。生產(chǎn)和災(zāi)備數(shù)據(jù)中心分別部署一套鏡像庫系統(tǒng)，為各自數(shù)據(jù)中心內(nèi)的K8S集群提供鏡像服務(wù)。允許租戶跨集群管理自己的容器資源。整體示意圖如下：3.多租戶管理設(shè)計通過K8S命名空間和鏡像庫命名空間實現(xiàn)租戶資源隔離，一個租戶對應(yīng)于一個或者多個命名空間。云平臺管理員可以通過RBAC機制為租戶授予相應(yīng)命名空間的管

12、理權(quán)限。租戶對授權(quán)命名空間內(nèi)的資源具有管理員權(quán)限，但是無法訪問非授權(quán)命名空間。對于一個租戶來說，管理員可以授予他一個K8S集群內(nèi)一個或多個命名空間的管理權(quán)限，也可以授予他多個K8S集群內(nèi)命名空間的管理權(quán)限。整體示意圖如下：4.專用和共享計算節(jié)點容器云平臺為應(yīng)用提供兩種類型的K8S集群，分別是計算節(jié)點共享的K8S集群和計算節(jié)點專用的K8S集群。從資源利用率角度，首推共享計算節(jié)點的K8S集群。計算節(jié)點直接采用物理機，多個應(yīng)用共享計算節(jié)點組成的資源池，資源的彈性和使用效率最高。如應(yīng)用需要調(diào)整缺省Linux Kernel參數(shù)，或者有特殊的敏感的出網(wǎng)絡(luò)訪問關(guān)系，或者有很高的安全隔離性要求，可以考慮采用計

13、算節(jié)點專用的K8S集群。專用的計算節(jié)點考慮資源利用率，主要以虛擬機為主。特殊的應(yīng)用場景（如GPU）可以使用物理機。通過給計算節(jié)點打應(yīng)用標簽的方式，然后在應(yīng)用部署模板里指定nodeSelector的方式，實現(xiàn)計算節(jié)點的獨占。5.存儲后端實現(xiàn)使用Ceph分布式存儲作為容器云平臺的后端存儲，為應(yīng)用提供持久化的數(shù)據(jù)存儲能力。在生產(chǎn)和災(zāi)備數(shù)據(jù)中心各部署一個Ceph集群，為所屬數(shù)據(jù)中心的K8S集群提供持久化存儲后端服務(wù)。每個K8S集群創(chuàng)建2個Storage Class。rbd-class提供ReadWriteOnce類型PVC，后臺對接的是Ceph RBD；cephfs-class提供ReadWriteM

14、any類型PVC，后臺對接的是CephFS。租戶可動態(tài)申請PVC，僅有創(chuàng)建權(quán)限，沒有刪除權(quán)限。整體示意圖如下：6.應(yīng)用監(jiān)控告警每一個計算節(jié)點上會部署一個監(jiān)控Agent。應(yīng)用如需監(jiān)控，需要在應(yīng)用部署模板的環(huán)境變量里聲明監(jiān)控類型。應(yīng)用容器啟動后，監(jiān)控Agent會通過容器接口獲得容器監(jiān)控類型環(huán)境變量，并自動匹配監(jiān)控模板(腳本)。監(jiān)控Agent將監(jiān)控數(shù)據(jù)發(fā)送到監(jiān)控服務(wù)器。監(jiān)控服務(wù)器根據(jù)觸發(fā)條件判斷是否發(fā)送告警信息到集中告警平臺。在集中告警平臺上為每個應(yīng)用創(chuàng)建虛擬節(jié)點，和IP解耦。告警平臺收到告警信息后，根據(jù)告警數(shù)據(jù)包含的應(yīng)用名稱字段自動匹配到虛擬節(jié)點。虛節(jié)點上可設(shè)置維護狀態(tài)，應(yīng)用變更的時候為了避免告警

15、可以設(shè)置虛節(jié)點為維護狀態(tài)，變更完成后可以解除維護狀態(tài)。示意圖如下：目前可監(jiān)控的應(yīng)用指標如下：1.應(yīng)用容器狀態(tài)。如果容器狀態(tài)異常會觸發(fā)告警;2.應(yīng)用Deployment副本數(shù)，如果副本數(shù)和期望的不一致，會觸發(fā)告警;3.應(yīng)用Statefulset副本數(shù)， 如果副本數(shù)和期望的不一致，會觸發(fā)告警;4.應(yīng)用Pod狀態(tài)，如異常，會觸發(fā)告警;5.應(yīng)用容器內(nèi)部文件系統(tǒng)使用率，如超過80%，會觸發(fā)告警;7.應(yīng)用日志處理每個計算節(jié)點部署一個日志收集代理，該代理面向節(jié)點上所有的容器。如應(yīng)用容器需要監(jiān)控，就需要在Pod yaml里通過環(huán)境變量聲明日志路徑和kafka topic。容器啟動后，日志代理會根據(jù)容器環(huán)境變量

16、定義的日志路徑自動匹配對應(yīng)的宿主機日志文件路徑，并將日志抓取后發(fā)送到kafka topic。當前的日志代理以換行符作為分割符，如應(yīng)用的一條日志里有多行紀錄，這條日志會被切分成多個消息來處理，在Kibana上也會呈現(xiàn)多條記錄。為了適配這類一條日志有多行紀錄的應(yīng)用，我們也正在設(shè)計開發(fā)一種可定制化分隔符的日志引擎，可以允許應(yīng)用在Pod的yaml里聲明日志分隔符。8.應(yīng)用雙活容災(zāi)部署架構(gòu)生產(chǎn)、災(zāi)備中心每個網(wǎng)絡(luò)區(qū)都建設(shè)一個K8S集群，都有各自獨立的鏡像庫和后端分布式存儲。應(yīng)用雙活要求應(yīng)用同時運行在生產(chǎn)、災(zāi)備中心的兩個K8S集群上，前端可以通過負載均衡引流。任意一個數(shù)據(jù)中心的集群故障不影響應(yīng)用的可用性。示

17、意圖如下：三、應(yīng)用容器化最佳實踐總結(jié)1.鏡像和配置分離原則：制作應(yīng)用鏡像時，需要將配置分離出來，這樣做可以讓應(yīng)用鏡像在不同環(huán)境（比如測試和生產(chǎn)）都一致，變得只是配置信息。配置信息可通過環(huán)境變量或者加載卷的方式注入容器。在K8S環(huán)境下，除了環(huán)境變量注入，還可以通過ConfigMap和Serect方式注入配置。ConfigMap和Secret都支持通過卷加載的方式掛載到容器。Secret通常用于保存敏感信息（如密碼）.2.微服務(wù)原則：容器環(huán)境天生要求微服務(wù)化，一個容器只提供一種服務(wù)。每個容器原則上只對外提供一個服務(wù)監(jiān)聽端口。3.使用第三方基礎(chǔ)鏡像制作應(yīng)用鏡像的時候必須包含必要的系統(tǒng)troulesh

18、ooting工具，至少包括ps、netstat、ping、curl。否則出現(xiàn)問題的時候會妨礙排錯。4.支持通過NodePort和Ingress對外發(fā)布服務(wù)。NodePort適用于對外服務(wù)較少場景；Ingress適用于對外服務(wù)較多，需要統(tǒng)一入口場景。Ingress需要作為應(yīng)用的的一部分部署在應(yīng)用命名空間。使用Ingress只需要對外通過一個NodePort暴露服務(wù)。5.NodePort需要向容器平臺管理員申請。請僅僅使用分配給項目組的NodePort，禁止使用未經(jīng)申請的NodePort，否則容易其它項目組產(chǎn)生端口沖突 .6.如使用StatefulSet部署有狀態(tài)應(yīng)用，副本數(shù)必須大于等于2，并且在

19、驗證了單個Pod失效不影響服務(wù)的前提下，才可以生產(chǎn)上線。原因是StatefulSet的Pod在宿主機故障情況下沒有自動HA能力，需要人為干預(yù)殺死Pod才能觸發(fā)重建。7.Deployment/StatefulSet/Pod的yaml里，必須配置liveness/readiness探測，并通過測試才能生產(chǎn)上線。這對于應(yīng)用的可用性非常重要，請一定重視 。8.Deployment/StatefulSet/Pod的yaml里，必須對Container的resources做設(shè)置。因為生產(chǎn)環(huán)境出于考慮極端情況（一半節(jié)點不可用）下的應(yīng)用高可用。對于獨占計算節(jié)點的應(yīng)用，要求應(yīng)用namespace下所有Pod的r

20、equest總合不能超過分配總資源(CPU，內(nèi)存)的50%-1，單個Pod的limit不能超過單個節(jié)點資源的60%。9.對于可以和其它應(yīng)用共享計算節(jié)點(通常是物理節(jié)點)的應(yīng)用，namespace下所有Pod的request總合和limites總合不能超過分配的總資源（比如分配了16C/64G，那么request總合/limites總合不能超過16C/64G）。10.對于使用獨占宿主機節(jié)點的應(yīng)用，Deployment/StatefulSet/Pod的yaml里，必須配置NodeSelector。生產(chǎn)環(huán)境NodeSelector的value值是項目的英文名，測試環(huán)境統(tǒng)一是testapp。對于和其它

21、應(yīng)用共享宿主機節(jié)點的應(yīng)用，可以不配置NodeSelector。11.對于重要系統(tǒng)，Deployment/StatefulSet里，副本(replica)數(shù)必須大于2（包含2），禁止為1。這樣才能確保服務(wù)在單個副本故障的情況下依然可用。對于可靠性要求不高的系統(tǒng)，在資源充足的情況下盡量也保持副本數(shù)大于等于2。如資源受限，并且上線前明確說明對可靠性要求不高，可以允許副本數(shù)為1 。12.Pod產(chǎn)生的日志，推薦通過直接寫入stdout并配置Kafka Topic的方式，轉(zhuǎn)發(fā)到ELK。如果一定要持久化保存，有如下三種方案，但是都要求首先應(yīng)用層面要做好日志輪循(rotation)，控制好總量大小，因為PVC

22、和HostPath用的宿主機目錄通常是無法擴容的。目前僅寫入stdout、HostPath的日志，才可以被日志引擎處理發(fā)往ELK，HostPath需要掛載到日志目錄。HostPath方式受限使用，需要一事一議。寫入PVC或者直接寫入容器自身的日志將不能被日志引擎抓取。a)使用StatefulSet方式部署Pod，需要在yaml里聲明PVC容量和StorageClass（名字為rbd-class，提供ReadWriteOnce類型的PV），并且通過將日志同時寫入stdout，且在yaml里聲明stdout日志路徑和Kafka Topic的方式，將日志發(fā)往ELK。一旦使用PVC，Pod的可用性就會

23、和PVC的可用性關(guān)聯(lián)起來。對于可用性要求很高的系統(tǒng)（A/B類系統(tǒng)），如果使用PVC，前提條件是應(yīng)用實現(xiàn)了災(zāi)備雙活部署。b)使用Deployment方式部署Pod，需要在yaml里聲明共享型（ReadWriteMany類型）PVC的名字，并且通過將日志同時寫入stdout，且在yaml里聲明stdout日志路徑和Kafka Topic的方式，將日志發(fā)往ELK。在多副本情況下，需要應(yīng)用做好日志文件區(qū)分，避免多副本寫同一個日志文件。一旦使用PVC，Pod的可用性就會和PVC的可用性關(guān)聯(lián)起來。對于可用性要求很高的系統(tǒng)（A/B類系統(tǒng)），如果使用PVC，前提條件是應(yīng)用實現(xiàn)了災(zāi)備雙活部署。c)使用HostP

24、ath，將日志寫入宿主機的某個目錄。這需要應(yīng)用在多副本的情況下，能夠做好日志區(qū)分，將所有Pod的日志放到同一個父目錄下。如需使用此種方式，請?zhí)崆奥?lián)系容器平臺管理員創(chuàng)建目錄。即使使用HostPath存放日志，可直接通過在yaml里聲明日志文件路徑和Kafka Topic的方式，將日志發(fā)往ELK。使用HostPath存放日志主要的問題是Pod一旦遷移到新的節(jié)點，日志寫入也會遷移到新的節(jié)點，舊節(jié)點上的日志文件寫入會中斷。HostPath僅僅適用于專用計算節(jié)點場景，并且需要一事一議。13.如果兩個服務(wù)之間有依賴關(guān)系，必須在上線前解決啟動順序問題?？梢钥紤]使用K8S的initcontainer機制做探測

25、。14.對于重要系統(tǒng)，原則上要求應(yīng)用層面必須實現(xiàn)災(zāi)備雙活部署，也即應(yīng)用同時運行在生產(chǎn)、災(zāi)備的兩個K8S集群上，前端可通過負載均衡引流。任意一個集群的故障不影響應(yīng)用的可用性15.生產(chǎn)上線前，請確保在測試環(huán)境完成應(yīng)用HA測試驗證，具體的要求是：a) 殺死任意服務(wù)中的單個Pod不影響整體業(yè)務(wù)b) 殺死任意服務(wù)中的所有Pod，待Pod重啟完成后，整體業(yè)務(wù)服務(wù)不受影響c) 節(jié)點故障不影響整體業(yè)務(wù)16. 盡可能通過配置prestop或者處理SIGTERM信號，來實現(xiàn)應(yīng)用容器的優(yōu)雅停止。缺省情況下，沒有配置優(yōu)雅停止的話，K8S會在grace-period時間（缺省30秒，可在Pod Yaml里調(diào)整）到期后，

26、通過SIGKILL殺死Pod內(nèi)進程。四、應(yīng)用容器化改造案例(某支付類系統(tǒng))1.改造背景支付類系統(tǒng)作為銀行的核心系統(tǒng)之一，為了保證可用性和性能，之前都是運行在小型機上，運行成本高昂、可擴展性較差。為了解決這些問題，支付類系統(tǒng)需要進行分布式改造，把應(yīng)用程序從小型機遷移到X86 PC服務(wù)器上，導(dǎo)致服務(wù)器的規(guī)模從幾臺擴展為幾十臺，使得部署環(huán)節(jié)更加復(fù)雜、容易出錯。因此希望利用容器平臺提供的服務(wù)注冊發(fā)現(xiàn)、動態(tài)伸縮以及快速故障檢測恢復(fù)等能力，降低分布式系統(tǒng)的部署和管理難度。2.技術(shù)實現(xiàn)如下是某支付類系統(tǒng)容器化后的部署架構(gòu)，該系統(tǒng)的后端采用容器化方式部署運行。后端也根據(jù)微服務(wù)的方式，從一個大模塊拆分成幾個微服務(wù)模塊，更便于分布式的部署。行內(nèi)現(xiàn)有的支付類系統(tǒng)大多是有狀態(tài)的，因為要生成和節(jié)點相關(guān)的交易流水號。容器化改造時，為了盡可能不影響現(xiàn)有業(yè)務(wù)邏輯，也需要維持這種有狀態(tài)的方式。可以利用K8S提供的StatefulSet實現(xiàn)有狀態(tài)的部署，每個Pod會有固定的名字，比如payapp-01、payapp-02。這樣可以根據(jù)Pod名字中的索引（01、02等）自動生成交易流水號。由于現(xiàn)有前置應(yīng)用和后端應(yīng)用之間是長連接，只能采用一個Pod一個Service的方式提供服務(wù)。每一個Po