云原生集成開發(fā)環(huán)境——TitanIDE
通過(guò)網(wǎng)頁(yè)在任何地方更安全、更高效地編碼2022-06-16
776
將應(yīng)用程序部署到Kubernetes的生產(chǎn)環(huán)境中,這意味著您將面向終端用戶正式公開該應(yīng)用。每個(gè)人都希望這將是一次成功的發(fā)布,并對(duì)此表示毫無(wú)疑問(wèn)。您對(duì)應(yīng)用集群的容量管理、安全態(tài)勢(shì)感知、災(zāi)難恢復(fù)等過(guò)程了如指掌……這些,現(xiàn)在,都將成為現(xiàn)實(shí)!
本文,我將為即將上線、部署應(yīng)用程序的每個(gè)人推薦“將程序部署到生產(chǎn)環(huán)境中”的最佳實(shí)踐。需要學(xué)習(xí)做什么,如何做,以及為什么要這樣做。所有這些都是為了讓您擁有可靠的操作,并能夠?qū)W⒂诟倪M(jìn)應(yīng)用程序,而不是當(dāng)問(wèn)題來(lái)臨時(shí)才緊急“救火”。
多場(chǎng)景負(fù)載測(cè)試的巨大價(jià)值
在使用應(yīng)用程序的新版本或初始版本之前,需要能夠?qū)ζ溥M(jìn)行負(fù)載測(cè)試。開發(fā)者可以使用諸如 JMeter 或 Locust 之類的合成負(fù)載生成器,也可以通過(guò) Selenium 之類的用戶交互工具重放一組記錄。
為什么要進(jìn)行負(fù)載測(cè)試?
很多原因。事實(shí)上,方便容量管理是原因之一,但肯定不是唯一的原因!
普通負(fù)載測(cè)試(容量管理測(cè)試)
為什么要做?確保為環(huán)境和應(yīng)用程序分配了足夠的容量。
如何做?設(shè)置合成工作負(fù)載生成器或重放相關(guān)工作負(fù)載。請(qǐng)平臺(tái)管理員監(jiān)控生產(chǎn)環(huán)境的容量使用情況。確保包括相關(guān)組件的性能和容量。例如,應(yīng)用程序日志和應(yīng)用程序指標(biāo)是必需的,再比如,平臺(tái)中的所有支持系統(tǒng)。
做什么?出于容量管理原因而執(zhí)行的簡(jiǎn)單的負(fù)載測(cè)試。注意響應(yīng)時(shí)間,生成平均、 中位數(shù)、 第 90 和第 95 個(gè)百分位響應(yīng)時(shí)間的統(tǒng)計(jì)數(shù)據(jù)。
期望的結(jié)果:發(fā)現(xiàn)分配的容量是足夠的。
可能的解決方案:(應(yīng)用程序開發(fā)人員)確保應(yīng)用程序具有合理的資源請(qǐng)求和限制。(平臺(tái)運(yùn)營(yíng)商)確保 Kubernetes 平臺(tái)組件和底層集群有足夠的容量。
更新應(yīng)用程序(可用性測(cè)試)
為什么要做?為確保應(yīng)用程序可以在不停機(jī)的情況下更新,提供適當(dāng)?shù)目捎眯员WC。
如何做?對(duì)應(yīng)用程序進(jìn)行一些細(xì)微的更改,例如,在某些 API 的輸出中添加“Lorem ipsum”,然后重新部署。
做什么?在應(yīng)用程序運(yùn)行并承受負(fù)載時(shí)執(zhí)行的負(fù)載測(cè)試。確保在負(fù)載測(cè)試工具中能夠記錄任何故障。
期望的結(jié)果:測(cè)量的停機(jī)時(shí)間是可以接受的(這個(gè)時(shí)間需要自己來(lái)定義)。
可能的解決方案:確保自己有正確的部署策略。在這里,個(gè)人是更喜歡滾動(dòng)更新而不是重新創(chuàng)建。另外,還需確保根據(jù)需要調(diào)整部署策略的其他參數(shù)。
更新集群(可用性、穩(wěn)定性測(cè)試)
為什么要做?節(jié)點(diǎn)故障可能導(dǎo)致應(yīng)用程序掛掉。如果意外發(fā)生在晚上,那么管理員需要半夜爬起床來(lái)才能做出響應(yīng),此時(shí)應(yīng)用程序的故障時(shí)間已經(jīng)持續(xù)很久了。此外,管理員需要一些額外的資源容量來(lái)在節(jié)點(diǎn)的基本操作系統(tǒng)上執(zhí)行關(guān)鍵的安全更新。
如何做?就像一個(gè)普通的負(fù)載測(cè)試,但現(xiàn)在要求管理員對(duì)所有 Kubernetes 集群節(jié)點(diǎn)執(zhí)行滾動(dòng)重啟。
做什么?在應(yīng)用程序運(yùn)行并承受負(fù)載時(shí)執(zhí)行負(fù)載測(cè)試。確保在負(fù)載測(cè)試時(shí)可以在工具中記錄下所有故障。理想情況下,應(yīng)該是可以實(shí)現(xiàn)的。
期望的結(jié)果:在節(jié)點(diǎn)故障或資源耗盡期間測(cè)量的停機(jī)時(shí)間(由于 Pod 遷移)是可以接受的。容量足以容納一個(gè)節(jié)點(diǎn)故障或耗盡。
可能的解決方案:
· 確保應(yīng)用程序具有適當(dāng)?shù)馁Y源請(qǐng)求和資源限制;
· 確保應(yīng)用程序至少有兩個(gè)副本,并能夠結(jié)合起來(lái);
· 確保應(yīng)用程序具有 topologySpreadConstraints 以便 Pod 不會(huì) 在同一個(gè) Node 上結(jié)束。
第2、3條措施,能夠?qū)⑹沟脩?yīng)用程序組件的兩個(gè)副本不會(huì)同時(shí)受到停機(jī)時(shí)間的影響。
關(guān)閉Cloud Region(抗災(zāi)能力測(cè)試)
為什么要做?如果需要跨多個(gè)區(qū)域進(jìn)行部署,則必須測(cè)試資源的額外彈性。否則,區(qū)域故障可能會(huì)導(dǎo)致應(yīng)用程序停機(jī)。
如何做?如上所述,但現(xiàn)在要求管理員刪除整個(gè)區(qū)域。
期望的結(jié)果:在區(qū)域故障期間測(cè)量的停機(jī)時(shí)間(由于 Pod 遷移)是可以接受的。容量足以容納一個(gè)區(qū)域的故障。
可能的解決方案:
· 確保應(yīng)用程序具有適當(dāng)?shù)馁Y源請(qǐng)求和限制。
· 確保應(yīng)用程序至少有兩個(gè)副本,并且
· 確保應(yīng)用程序具有 topologySpreadConstraints 以確保 Pod 不會(huì)最終 位于同一區(qū)域。
第2、3條措施,可以使應(yīng)用程序組件的兩個(gè)副本不會(huì)同時(shí)受到區(qū)域故障的影響。另外,根據(jù)之前的測(cè)試,還應(yīng)該確保它們不會(huì)在同一個(gè)節(jié)點(diǎn)上結(jié)束。
災(zāi)難恢復(fù):制定計(jì)劃并執(zhí)行
為什么要做?這可以確保改應(yīng)用的研發(fā)團(tuán)隊(duì)就誰(shuí)負(fù)責(zé)什么工作以及誰(shuí)支持什么工作達(dá)成一致。這比最終認(rèn)為“支持這個(gè)東西”是其他團(tuán)隊(duì)的問(wèn)題要好得多。
如何做?要求管理員破壞環(huán)境并從異地備份中恢復(fù)。檢查您的應(yīng)用程序是否已備份并且其數(shù)據(jù)是否已按預(yù)期恢復(fù)。
期望的結(jié)果:測(cè)量的恢復(fù)點(diǎn)和恢復(fù)時(shí)間是可以接受的。
可能的解決方案:確保將應(yīng)用程序數(shù)據(jù)存儲(chǔ)在 PersistentVolumes 或(托管在)數(shù)據(jù)庫(kù)中。對(duì)于 Compliant Kubernetes 用戶,您可能會(huì)注意到 PersistentVolume 在 Compliant Kubernetes 中默認(rèn)使用 Velero進(jìn)行備份。(根據(jù)服務(wù)條款, Elastisys Managed PostgreSQL 客戶默認(rèn)擁有備份和時(shí)間點(diǎn)恢復(fù) 。)
從零開始重新部署以確保能成功實(shí)現(xiàn)自動(dòng)化
為什么這么做?這可以確保不存在 tribal knowledge,確保 Git 存儲(chǔ)庫(kù)是唯一的事實(shí)來(lái)源。其中關(guān)鍵的是,如果不是所有的應(yīng)用都寫在代碼中并且完全自動(dòng)化,你就必須找到一兩個(gè)恰好知道該如何部署的工程師。在正常情況下,這樣做的難度實(shí)在是大。如果工程師恰好在休假、生病或離職了,情況可能會(huì)更糟。
如何做?要求您的管理員“重置”環(huán)境,即移除所有容器鏡像、移除所有緩存的容器鏡像、移除所有 Kubernetes 資源等,重新部署應(yīng)用程序。
期望的結(jié)果:測(cè)試出來(lái)的部署時(shí)間是可以接受的。
可能的解決方案:確保將所有代碼和 Kubernetes 清單添加到 Git 存儲(chǔ)庫(kù),并確保存在相關(guān)文檔。
概括
本文展示了負(fù)載測(cè)試在使應(yīng)用程序?yàn)樯a(chǎn)做好準(zhǔn)備、并面向終端用戶上線的諸多用途。這個(gè)過(guò)程是有效的,其提供了巨大的實(shí)用價(jià)值。
那么,應(yīng)該多久做一次負(fù)載測(cè)試呢?在微服務(wù)世界中,我們需要持續(xù)地發(fā)布應(yīng)用新版本,但同時(shí),也請(qǐng)為負(fù)載測(cè)試花點(diǎn)時(shí)間,因?yàn)楦鶕?jù)經(jīng)驗(yàn),在這個(gè)過(guò)程中你將會(huì)發(fā)現(xiàn)所需要解決的問(wèn)題。前幾次測(cè)試中更多,隨著時(shí)間的推移bug將會(huì)更少。
通過(guò)執(zhí)行這些最佳實(shí)踐措施,您將可以放心地進(jìn)行部署,做好準(zhǔn)備讓您的App席卷全球。
kaiyun開云創(chuàng)新基于Kubernetes及容器部署應(yīng)用的最佳實(shí)踐
kaiyun開云創(chuàng)新CloudOS,一站式云原生開發(fā)平臺(tái),“以應(yīng)用為核心”,為企業(yè)構(gòu)建敏捷創(chuàng)新的應(yīng)用研發(fā)環(huán)境,實(shí)現(xiàn)應(yīng)用研發(fā)可視化和敏捷化,實(shí)現(xiàn)底層技術(shù)平臺(tái)標(biāo)準(zhǔn)化,讓傳統(tǒng)應(yīng)用研發(fā)團(tuán)隊(duì)零門檻轉(zhuǎn)型為云原生研發(fā)團(tuán)隊(duì),支撐傳統(tǒng)應(yīng)用云原生化,加快企業(yè)數(shù)字化轉(zhuǎn)型。
從應(yīng)用需求發(fā)起 > 建立項(xiàng)目 > 架構(gòu)設(shè)計(jì) > 代碼研發(fā) > 程序測(cè)試 > 應(yīng)用發(fā)布 > 應(yīng)用運(yùn)維,應(yīng)用全生命周期管理一個(gè)平臺(tái)、一站搞定。
讓我們重點(diǎn)聊聊基于CloudOS的應(yīng)用發(fā)布,是什么體驗(yàn)?
提供手動(dòng)或自動(dòng)發(fā)布應(yīng)用的能力:
CloudOS,致力于為企業(yè)為應(yīng)用創(chuàng)新提供一站式平臺(tái)支撐,以數(shù)字化應(yīng)用高效創(chuàng)新和快速交付為目標(biāo),為應(yīng)用創(chuàng)新的端到端流程提供支撐,包括需求、架構(gòu)設(shè)計(jì)、編碼、測(cè)試、部署、運(yùn)維。
行云 CloudOS 打破各環(huán)節(jié)、各部門信息壁壘,提供統(tǒng)一操作頁(yè)面,讓研發(fā)資產(chǎn)(如軟件架構(gòu)資產(chǎn)、API 接口、測(cè)試用例、制品包、鏡像文件等)在各環(huán)節(jié)順暢流動(dòng)起來(lái),進(jìn)而提升各環(huán)節(jié)協(xié)作效率。CloudOS 提供云原生 DevOps 能力,實(shí)現(xiàn)應(yīng)用的 CI/CT/CD(持續(xù)集成/持續(xù)測(cè)試/持續(xù)交付)。
-----------------------------
看到這里如果你也心動(dòng)了,那就快來(lái)體驗(yàn)一下吧。
CloudOS ,SAAS版免費(fèi)體驗(yàn)環(huán)境,請(qǐng)點(diǎn)擊>
CloudOS,一站式云原生開發(fā)平臺(tái),了解詳情>