摘要:大家好今天我分享的主題與游戲行業(yè)相關(guān),為大家介紹的是在騰訊游戲中的應(yīng)用實(shí)踐。隨著技術(shù)的興起,我們開始調(diào)研在游戲容器化方面的應(yīng)用。也就是說,將不同游戲業(yè)務(wù)部署到同一臺(tái)母機(jī),采用綁定核的方式。在母機(jī)上架部署時(shí),創(chuàng)建設(shè)備和設(shè)備并將它們進(jìn)行關(guān)聯(lián)。
今天小數(shù)的推送內(nèi)容來自騰訊互娛高級工程師黃惠波,讓我們一起來看看吧~~~
黃惠波,騰訊互娛高級工程師
目前主要負(fù)責(zé)游戲計(jì)算資源容器化平臺(tái)的研發(fā)工作,包括 kubernetes/docker 研究以及定制化開發(fā),主導(dǎo)騰訊游戲萬級容器資源調(diào)度平臺(tái)的建設(shè)工作。
大家好!今天我分享的主題與游戲行業(yè)相關(guān),為大家介紹的是 kubernetes 在騰訊游戲中的應(yīng)用實(shí)踐。
騰訊在線游戲的容器化應(yīng)用場景2014 年,我們開啟了容器化探索之路,先回顧一下之前遇到的一些問題。
在物理機(jī)時(shí)代,資源的交付時(shí)間較長,資源的利用率較低,也不能做到隔離。到了 xenkvm 虛擬機(jī)時(shí)代,問題得到了初步的解決,但在彈性伸縮方面仍有不足。隨著 Docker 技術(shù)的興起,我們開始調(diào)研 Docker 在游戲容器化方面的應(yīng)用。我們的目標(biāo)有兩個(gè),一是提高資源利用率,二是通過 Docker 鏡像來標(biāo)準(zhǔn)化部署流程。
選擇 Docker 技術(shù)之后,我們開始了容器調(diào)度平臺(tái)的選型。我們當(dāng)時(shí)也調(diào)研了其它的一些組件,比如 Shipyard 、 Fig 等,但這些組件無法支撐海量游戲容器調(diào)度。而自建調(diào)度平臺(tái)的話,時(shí)間成本非常的高。就在那時(shí), Google 開源了 kubernetes (當(dāng)時(shí)的版本是 kubernetes v0.4 ),我們基于這個(gè)版本進(jìn)行了定制和開發(fā),使其成為我們游戲容器的調(diào)度管理平臺(tái)。
在 2015 年初的時(shí)候, TDocker 平臺(tái)上線。之后,我們開始逐步接入業(yè)務(wù)。一開始的模式非常簡單,就是把 Docker 當(dāng)成虛擬機(jī)來使用,但這不意味著游戲全容器化的實(shí)現(xiàn)。
大家知道,對于一項(xiàng)新技術(shù)來說,大家都很謹(jǐn)慎,會(huì)通過不斷的灰度上線,由點(diǎn)到面的策略推動(dòng)。截至目前,在全國各地以及加拿大等地區(qū),都有我們的部署點(diǎn);接入容器數(shù)超過兩萬,接入的業(yè)務(wù)也有兩百多款,包括手游、端游、頁游。在這么多的業(yè)務(wù)中,主要分為兩種場景,第一種場景是輕量級虛擬機(jī)模式,這類容器承載多個(gè)服務(wù)進(jìn)程,需要一個(gè)具體的內(nèi)網(wǎng) IP ,可以通稿 SSH 登錄。另一種是微服務(wù)化模式,這種模式會(huì)拆分得非常細(xì),每一個(gè)容器對應(yīng)一個(gè)服務(wù)進(jìn)程,不需要對外可見的內(nèi)網(wǎng) IP ,可以使用虛擬 IP 。
接下來會(huì)對每一個(gè)場景做一些分享。首先來看一下傳統(tǒng)游戲下的架構(gòu)。這是非常典型的三層服務(wù)架構(gòu),包括了接入層、邏輯層、數(shù)據(jù)庫層。同時(shí),游戲又分為:全區(qū)全服、分區(qū)分服兩種類型。對于分區(qū)分服類游戲,滾服對資源的調(diào)度非常頻繁,所以我們需要一個(gè)高效的調(diào)度平臺(tái)。
容器資源的調(diào)度管理基于 kubernetes v0.4 版本,上圖是一個(gè)簡化后的調(diào)度框架。在 Master 端包括 ApiServer 和 Scheduler ,接收 Web 請求,然后做資源調(diào)度。在每個(gè) node 節(jié)點(diǎn)上,包括 agent 進(jìn)程、 Docker 進(jìn)程,還有 Lxcfs 進(jìn)程。在鏡像存儲(chǔ)方面,當(dāng)時(shí)用的是 Registry V1 版,后端用的是 ceph 存儲(chǔ)?,F(xiàn)在,我們自己維護(hù)了一個(gè)分支,功能上已滿足當(dāng)前的游戲需求,并保證運(yùn)行的穩(wěn)定。所以在虛擬機(jī)模式下,我們不會(huì)升級 kubernetes ,而是把一些好用的功能合并進(jìn)來。
基于 kubernetes 的功能定制與優(yōu)化首先講調(diào)度器,調(diào)度器為數(shù)以萬計(jì)的容器提供了一個(gè)靈活、穩(wěn)定、可靠的底層資源計(jì)算調(diào)度引擎。資源的合理分配像是一場博弈,里面有很多矛盾的地方,需要我們根據(jù)游戲的特點(diǎn)做取舍。
我們在原有的調(diào)度策略上根據(jù)游戲特點(diǎn)做了一些定制。比如在網(wǎng)絡(luò)方面,傳統(tǒng)游戲的每個(gè)容器都需要一個(gè)對外可見的實(shí)體 IP ,用戶可以通過 SSH 登錄到容器里面,因此對網(wǎng)絡(luò)資源進(jìn)行調(diào)度。部署容器的時(shí)候,會(huì)申請 network 的資源(比如 IP )然后進(jìn)行劃分,綁定到 minions 對象。這樣調(diào)度器調(diào)度的時(shí)候,就可以通過這些配置信息給容器分配好網(wǎng)絡(luò)資源。
在社區(qū)中, CPU 的分配用的是共享 CPU 的方式,游戲采用的是一種混部的模式。也就是說,將不同游戲業(yè)務(wù)部署到同一臺(tái)母機(jī),采用綁定核的方式。這樣做一方面可以防止不同游戲之間的 CPU 搶占,另一方面對游戲成本的核算也會(huì)更加精細(xì)。例如,某個(gè)游戲用了多少 CPU 這些指標(biāo)都是可以量化的。在容器分配 CPU 時(shí),結(jié)全 numa 技術(shù),對于 CPU CORE 的分配會(huì)盡量地分配到同一個(gè) numa node 上,這樣可以提升性能,因?yàn)橥瑐€(gè) numa node 的 CPU 訪問只需通過自身的 local memory ,無需通過系統(tǒng)總線。
在磁盤容量分配方面,由于游戲業(yè)務(wù)是有狀態(tài)的服務(wù),需要存儲(chǔ),所以我們把磁盤也作為一個(gè)可調(diào)度的資源分配給容器。還有非親和性的調(diào)度。我們知道,在容器的可靠性與碎片優(yōu)化之間需要一個(gè)權(quán)衡,讓用戶根據(jù)這些策略去選擇、部署自己的容器。例如在非親和性的策略中,用戶希望把容器是分散到各個(gè)母機(jī)上的,在母機(jī)宕機(jī)時(shí),可以減少對游戲的影響。
在 IDC Module 分配方面,游戲容器的部署會(huì)按地區(qū)劃分,比如按照上海、深圳或天津地區(qū)的 IDC 來劃分,所以我們提供了 IDC 部署策略。由于游戲需要考慮 IDC 的穿越流量問題,還有網(wǎng)絡(luò)延時(shí)的問題,所以同一個(gè)游戲的的不同模塊一般會(huì)部署到同一個(gè) IDC Module 下面。
海量應(yīng)用過程中遇到的問題與解決方案以上是基于游戲行業(yè)特點(diǎn)定制的調(diào)度規(guī)劃。在資源調(diào)度過程中,也遇到過一些問題,例如容器資源的重復(fù)調(diào)度。首先在調(diào)度過程中它會(huì)跟 ScheduledPod (已完全調(diào)度的容器)進(jìn)行比較,判斷現(xiàn)在是不是有足夠的資源分配給待調(diào)度容器,最后通過 Bind (異步)把 Pod 信息寫入到 ETCD 。這里就會(huì)出現(xiàn)一個(gè)問題,那就是異步寫入慢了或者 ScheduledPod 同步慢了導(dǎo)致 ScheduledPods 不能及時(shí)刷新, Scheduler 計(jì)算出錯(cuò),從而造成資源重復(fù)計(jì)算。針對這個(gè)問題,我們的解決方案是在資源調(diào)度完成后,做一個(gè)檢測的邏輯,檢測調(diào)度的容器信息是否已在 ScheduledPod Cache 這里,然后再進(jìn)入下一個(gè)容器的調(diào)度。當(dāng)然這會(huì)帶來一定的性能損耗。
解決了這個(gè)問題,又產(chǎn)生了另外一些問題,那就是性能的問題。在 0.4 版本的 pod 接口是非常低效的,在查每一個(gè) pod 狀態(tài)的時(shí)候,會(huì)通過實(shí)時(shí)查所有的 Host 來確定,設(shè)計(jì)不太合理。社區(qū)也做了一些方案,當(dāng)時(shí)我們也是參考了社區(qū)的一些方案做了一些改造,把 pod 狀態(tài)放在 Cache 里面,定時(shí)更新,從而提高查詢效率。
還有一點(diǎn)就是 RESTClient 。在 kubernetes 中, rest API 大部分是異步進(jìn)行,對于這些異步的接口的請求,并不會(huì)立刻返回結(jié)果。這里有一個(gè)輪詢檢測狀態(tài)的邏輯,在檢測輪詢的時(shí)候有幾秒的休眠,然后進(jìn)再行下一個(gè)輪詢。默認(rèn)的休眠時(shí)間是 2 秒,這個(gè)時(shí)間對大部分場景來說有點(diǎn)過長,我們通過一些功能點(diǎn)的調(diào)整,從物理機(jī)的小時(shí)級到虛擬機(jī)分鐘級的調(diào)度,再到還未調(diào)整之前的秒級調(diào)度,到現(xiàn)在達(dá)到的毫秒級調(diào)度,現(xiàn)在的調(diào)度能力已能滿足游戲的需求。
講完調(diào)度,再看一下網(wǎng)絡(luò)方面。網(wǎng)絡(luò)是非常關(guān)鍵、也是最為復(fù)雜的一環(huán)。在虛擬機(jī)模式下,結(jié)合公司網(wǎng)絡(luò)環(huán)境為游戲提供高性能、穩(wěn)定的網(wǎng)絡(luò)環(huán)境,包括 Bridge+VLANSR-IOV 兩種方案。
先來說, Docker 的網(wǎng)絡(luò)還有 kubernetes 的網(wǎng)絡(luò)。對于 Docker 的 NAT 網(wǎng)絡(luò)來說,性能是最大的瓶頸,同時(shí)它與物理機(jī)或虛擬機(jī)的通信路徑不一致也會(huì)對業(yè)務(wù)帶來一些未知的影響。比如,外界不能看到容器真實(shí)的 IP(必須要使用主機(jī) IP+port 方式,端口本身就是稀缺資源,并且 ip+port 的方式,無疑增加了復(fù)雜度), TGW 仍然可以為業(yè)務(wù)程序服務(wù)。 Host 模式?jīng)]有隔離,也不符合需求。在 kubernetes 中, pod 作為最小調(diào)度單元,每個(gè) pod 有兩個(gè)容器,一個(gè)就是網(wǎng)絡(luò)容器,接管 pod 的網(wǎng)絡(luò),提供網(wǎng)絡(luò)服務(wù),并與其它容器共享 netIPC 。另一個(gè)是 App Container ,也就是業(yè)務(wù)容器,使用第一個(gè)網(wǎng)絡(luò)容器的網(wǎng)絡(luò)。在這種模式下,容器之間的通訊是非常簡單的。對于 pod 到 pod 、 pod 到物理機(jī)、物理機(jī)到 pod 的通訊,我們?yōu)槊總€(gè) pod 分配一個(gè)內(nèi)網(wǎng) IP ,對外可見,也可以互相通訊。
接下來,通過兩個(gè)方案給大家分析。首先是 Bridge+Vlan 的方案,母機(jī)都是部署在虛擬化區(qū)上,通過 Vlan 做網(wǎng)絡(luò)的隔離。在母機(jī)上架部署時(shí),創(chuàng)建 Bridge 設(shè)備和 VLAN 設(shè)備并將它們進(jìn)行關(guān)聯(lián)。創(chuàng)建容器的時(shí)候,使用 pipework 腳本創(chuàng)建容器所需要的虛擬網(wǎng)卡設(shè)備,并把它們綁定到容器和 Bridge 上,同時(shí)會(huì)設(shè)置容器內(nèi)的 IP 、 MAC 地址以及路由等信息。從而打通容器到外界的網(wǎng)絡(luò)通信。這里也做了一些優(yōu)化以提高性能,這里可以看到一個(gè)性能的對比,其中 Bridge 相對 NAT 網(wǎng)絡(luò)有相當(dāng)大的提升。這種方式可以滿足一部分游戲的需求,而有一些業(yè)務(wù),像 FPS 、 Moba 游戲等大流量,對網(wǎng)絡(luò)要求非常高的業(yè)務(wù),還有類似 MySQL-Proxy 這種組件,在 Bridge 場景下是無法滿足需求的。
所以我們探索了另一種網(wǎng)絡(luò)方式,就是 SR-IOV 模式,這種模式在 zenkvm 虛擬化上用的比較多,游戲也需要這種網(wǎng)絡(luò)方案,因此我們把這種網(wǎng)絡(luò)方案也結(jié)合到 Docker 容器里面。
這里需要硬件的支持,結(jié)合 SR-IOV 技術(shù)的網(wǎng)卡,在 Docker 容器內(nèi)就可以直接通過驅(qū)動(dòng)來加載虛擬的網(wǎng)卡并使用。使用的方式就如同在一臺(tái)物理機(jī)上使用一個(gè)真實(shí)的物理網(wǎng)卡一樣,這個(gè)虛擬網(wǎng)卡也擁有驅(qū)動(dòng)程序,也擁有 PCI BUSID ,因此所有的虛擬機(jī)網(wǎng)絡(luò)操作都如同操作普通網(wǎng)卡一般,從而在性能上得到提升。為了進(jìn)一步發(fā)揮 SR-IOV 的網(wǎng)絡(luò)性能,還需要對容器的相關(guān)網(wǎng)絡(luò)參數(shù)進(jìn)行配置,主要包括以下幾個(gè)方面: VF 中斷 CPU 綁定;關(guān)閉物理機(jī)的 irqbalance ;容器內(nèi)設(shè)置 RPS (軟中斷均衡)網(wǎng)卡不能中斷均衡,對高性能的網(wǎng)絡(luò)形成了阻礙。為了解決這個(gè)問題,需要設(shè)置容器內(nèi)的軟中斷均衡。通過上述的調(diào)整,性能得到了大幅度提升。
這是我們測試的一個(gè)結(jié)果,這邊是物理機(jī)的,這是 Bridge ,這是 SR-IOV , SR-IOV 在網(wǎng)絡(luò)性能方面基本上已經(jīng)接近了物理機(jī),所以這個(gè)對于游戲大包量、大流量的應(yīng)用是非常適合的,現(xiàn)在我們把 SR-IOV 網(wǎng)絡(luò)作為傳統(tǒng)游戲里默認(rèn)的網(wǎng)絡(luò)模式。
在游戲容器化過程中,我們希望資源的使用是明確的、合理的、可量化的。所以我們會(huì)為每個(gè)容器分配固定的資源,比如多少 CPU 、多少內(nèi)存,還有需要多大磁盤、 IO 帶寬。在啟動(dòng)容器的時(shí)候,比如 CPU/Memory ,通過 Cgroup 去做一個(gè)限制, disk 通過 xfs quota 去做配額的限制。還有 Buffered-IO 帶寬的限制。
在資源分配方面,我們開始做的是限定的 CPU 、內(nèi)存的分配。在容器的整個(gè)生命周期,這個(gè)配置并非一沉不變,比如在業(yè)務(wù)運(yùn)行過程中都會(huì)有一些起伏和動(dòng)態(tài)調(diào)整,這是游戲的一張生命周期圖像,生命周期比較短,可能是一年半載的時(shí)間,而且這里在線人數(shù)起伏也會(huì)比較大,需要?jiǎng)討B(tài)調(diào)整。而動(dòng)態(tài)調(diào)整就會(huì)涉及兩個(gè)方面,一是橫向的水平擴(kuò)展,二是垂直伸縮。
每個(gè)游戲都會(huì)有一個(gè) IP ,因此橫向拓展比較困難,因而更傾向于穩(wěn)定的垂直擴(kuò)縮。在虛擬化時(shí)代,擴(kuò)縮容是有損的,需要重啟機(jī)器來實(shí)現(xiàn),而 Docker 可以做到無損的擴(kuò)縮容。我們對這個(gè)需求做了一些定制開發(fā),比如 CPU 或者內(nèi)存,通過修改 Cgroup 的配額去把它提升上去或是削減下來。
當(dāng)在線人數(shù)上來的時(shí)候,我們可以給業(yè)務(wù)做到無損擴(kuò)容,不影響業(yè)務(wù)服務(wù)。過了一段時(shí)間,當(dāng)人數(shù)降下來時(shí),資源會(huì)閑置,我們會(huì)對空閑的資源做一些重復(fù)利用,將其回收。這個(gè)時(shí)候做一些縮容,針對縮容我們做一個(gè)常態(tài)的動(dòng)作,檢測這些容器的 CPU 、內(nèi)存,結(jié)合業(yè)務(wù)的負(fù)載、活動(dòng)、定時(shí)驅(qū)動(dòng)。
Buffered IO Throttle 需要內(nèi)核支持,我們與內(nèi)核團(tuán)隊(duì)進(jìn)地了緊密的合作,提供了支持 Buffered IO Throttle 功能的內(nèi)核版本。根據(jù)容器在母機(jī)資源的占比分配一定比例的 IO 帶寬。這在某種程序上解決了游戲之間互相影響的問題。
監(jiān)控、告警是整個(gè)游戲運(yùn)營過程中最為核心的功能之一。容器上的監(jiān)控有別于物理機(jī), cAdvisor 和 kubenetes 結(jié)合得比較緊密,是個(gè)不錯(cuò)的方案。但它也會(huì)帶來問題,那就是需要自建監(jiān)控平臺(tái),而且它與周邊各系統(tǒng)的兼容性也有待考驗(yàn),同時(shí)改變運(yùn)維的使用習(xí)慣也需要時(shí)間。綜合考慮各種因素后,我們放棄了 cAdvisor ,重新調(diào)研其它方案,希望可以沿用公司成熟的監(jiān)控平臺(tái),而且兼容周邊系統(tǒng)。最終我們選用的是 lxcfs + 公司 agent 的方案,通過 lxcfs 去實(shí)現(xiàn) Docker 容器內(nèi)的虛擬 proc 文件系統(tǒng),增強(qiáng)容器的隔離性。
我們這里以 meminfo 內(nèi)存統(tǒng)計(jì)信息為例,為大家講解如何通過 lxcfs 用戶態(tài)文件系統(tǒng)實(shí)現(xiàn) Docker 容器內(nèi)的虛擬 proc 文件系。掛載虛擬 proc 文件系統(tǒng)到 Docker 容器,通過 Docker 的 volume 功能,將母機(jī)上的 /var/lib/dockerfs/docker-xxx/proc 掛載到 Docker 容器內(nèi)部的虛擬 proc 文件系統(tǒng)目錄下 /proc/。此時(shí)在容器內(nèi)部 /proc/目錄下可以看到一些列 proc 文件,其中包括 meminfo 。用戶在容器內(nèi)讀取 /proc/meminfo 時(shí),實(shí)際上是讀取宿主機(jī)上的 /var/lib/dockerfs/docker-xxx/proc/meminfo 掛載到容器內(nèi)部的 meminfo 文件。內(nèi)核 VFS 將用戶請求轉(zhuǎn)發(fā)到具體文件系統(tǒng)—— fuse , fuse 文件系統(tǒng)封裝 VFS 請求,將請求轉(zhuǎn)發(fā)給 Fuse 設(shè)備(/dev/fuse)。如果設(shè)備上有已經(jīng)處理完成的請求(例如 Cache ),文件系統(tǒng)獲取處理結(jié)果并返回給 VFS , VFS 再反饋給用戶。用戶庫(fuse daemon)直接訪問 Fuse 設(shè)備,讀取文件系統(tǒng)轉(zhuǎn)發(fā)到設(shè)備上的請求,分析請求類型,調(diào)用用戶接口處理請求,處理完成后將處理結(jié)果返回給設(shè)備,再由設(shè)備返回給 VFS , VFS 再反饋給用戶,從而實(shí)現(xiàn)容器內(nèi)的隔離。公司 agent 可以通過讀取 memory 等信息,上報(bào)到監(jiān)控平臺(tái)做分析與報(bào)警。同時(shí)運(yùn)維通過 SSH 登錄到這個(gè)容器,通過 free 、 top 等命令查看性能,維持了運(yùn)維原來的使用習(xí)慣。
在傳統(tǒng)游戲里,更多的是有狀態(tài)的服務(wù)會(huì)涉及到數(shù)據(jù)的存儲(chǔ),我們通過 Docker 的 volume 提供持久化存儲(chǔ)。最開始我們采用 HostPath 方式,把 host 上的目錄掛載到容器里(例如 /data )作為數(shù)據(jù)存儲(chǔ)。這種做法非常方便、簡單,無需額外的支持,但數(shù)據(jù)的安全性、可靠性方面比較差。所以我們采用了另外一種方案,即 Ceph 。改造 kubenetes 支持 ceph ,通過 volume 掛載,提供更安全、更可靠的數(shù)據(jù)存儲(chǔ)方案。解決在 host 故障時(shí),數(shù)據(jù)丟失的問題,應(yīng)用場景也變得更加廣泛,包括數(shù)據(jù)庫存儲(chǔ),鏡像存儲(chǔ),容器遷移等。
今年,我們開始支撐第一款微服務(wù)化游戲(極品飛車 online),源于之前對 kubernetes 的使用經(jīng)驗(yàn)。在微服化容器的調(diào)度中我們沿用了 kubernetes ,但在版本上重新做了選擇,跟隨著社區(qū)的發(fā)展,選用了 v1.2 版。在微服務(wù)化模式下,游戲的架構(gòu)產(chǎn)生了很大的變化。按功能細(xì)分到各個(gè)小模塊,通過鏡像交付、分發(fā),最后以容器來部署服務(wù)。每個(gè)模塊相對獨(dú)立,之間信息流交互通過消息組件(例如 RabbitMQ)來實(shí)現(xiàn)。同時(shí)每個(gè)容器無須配置內(nèi)網(wǎng) IP ,可以通過域名來訪問。所以在網(wǎng)絡(luò)方面也有所調(diào)整,我們也評估了 docker overlay 、 flannel 、 vxlan 、 maxvlan 、 SR-IOV 等,結(jié)合其中的優(yōu)缺點(diǎn),最后我們選定的方案如下:
1 、集群內(nèi) pod 與 pod 的之間的通信,由于不需要內(nèi)網(wǎng) IP (可以用虛擬 IP )所以采用 overlay 網(wǎng)絡(luò),由 flannel 組件實(shí)現(xiàn)。
2 、公司內(nèi)網(wǎng)到集群內(nèi) pod 通信,例如 HAProxy ,游戲某些模塊,采用 SR-IOV 網(wǎng)絡(luò),由自己定制的 sriov-cni 組件實(shí)現(xiàn)。這類 pod 具備雙重網(wǎng)絡(luò), eth0 對應(yīng) overlay 網(wǎng)絡(luò), eth1 對應(yīng) SR-IOV 網(wǎng)絡(luò)。
3 、 pod 到公司內(nèi)網(wǎng)之間的通信。在微服務(wù)場景下,游戲的數(shù)據(jù)存儲(chǔ),周邊系統(tǒng)等,部署在物理機(jī)或者虛擬機(jī)上,因此 pod 到這些模塊、系統(tǒng)的訪問,走的是 NAT 網(wǎng)絡(luò)。
4 、公網(wǎng)(Internet)接入,采用公司的 TGW 方案。
在整個(gè)微服化平臺(tái)上,涉及到的關(guān)健技術(shù)點(diǎn)會(huì)更多:
1 、網(wǎng)絡(luò)方案:即上述講到了 overlay + SR-IOV + TGW + NAT 方案
2 、日志,監(jiān)控:對于微服務(wù)化架構(gòu)的游戲,版本的交付都是通過鏡像,不會(huì)把公司的 agent 打到鏡像,所以原來的 lxcfs + agent 監(jiān)控就不適應(yīng)了,所以這里我們重新打造了一個(gè)新的日志、監(jiān)控平臺(tái),與藍(lán)鯨團(tuán)隊(duì)合作,實(shí)現(xiàn)了游戲業(yè)務(wù)日志采集;容器健康狀態(tài)、性能的監(jiān)控
3 、高可用方案:在資源的部署方面,我們采用了 replication controller 方式,通過 kubernetes 的 controller manager 模塊來監(jiān)測 pod 的狀態(tài),在發(fā)生故障的時(shí)候,實(shí)現(xiàn)快速的遷移、恢復(fù)服務(wù)。另一方面,在 load balance 場景下,我們采用了 HAProxy 來實(shí)現(xiàn)
4 、安全方面: kubernetes 集群承載著整個(gè)游戲容器資源的調(diào)度、管理。不管是人為誤操作,還是黑客入侵,造成的影響將是非常之大。所以安全是我們需要考慮的重點(diǎn),結(jié)合 kubernetes ,我們目前做了以幾方面,后面會(huì)有更加的安全策略提供。
4.1 Authentication 和 Authorization 。使用 https 來加密流量,同時(shí)在用戶權(quán)限驗(yàn)證上,提供了 token 驗(yàn)證方式、 ABAC 權(quán)限認(rèn)證方式
4.2 Admission Controllers :配置具體的準(zhǔn)入規(guī)則
4.3 ServiceAccount :主要解決運(yùn)行在 pod 里的進(jìn)程需要調(diào)用 kubernetes API 以及非 kubernetes API 的其它服務(wù)問題
5 、配置管理:通過 configmapsecret 為游戲提供簡易的配置管理
6 、服務(wù)發(fā)現(xiàn): kubernetes 會(huì)為每個(gè) pod 分配一個(gè)虛擬的 IP ,但這個(gè) IP 是非固定的,例如 pod 發(fā)生故障遷移后,那么 IP 就會(huì)發(fā)生變化。所以在微服務(wù)化游戲架構(gòu)下,業(yè)務(wù) pod 之間的訪問更多地采用域名方式進(jìn)行訪問。在 kubernetes 生態(tài)鏈中,提供了 skydns 作為 DNS 服務(wù)器,結(jié)合 kubernetes 的 server 可以很好的解決域名訪問問題
開始講游戲容器化的時(shí)候談到用鏡像來標(biāo)準(zhǔn)化部署,所以我們花了很多時(shí)間打造企業(yè)級的鏡像倉庫。目前支持 registry v1v2 兩個(gè)版本,如右圖所示,在 client 端(docker)與 registry 之間采用 nginx 作為代理,實(shí)現(xiàn) v1v2 不同請求的轉(zhuǎn)發(fā),這樣一來,用戶無需關(guān)心到底請求的是 v1 還是 v2 。在安全方面,不同類型用戶不同的權(quán)限驗(yàn)證方案。公司內(nèi)部用戶接入 OA 認(rèn)證,與公司平臺(tái)打通。外部用戶需要申請?jiān)L問權(quán)限,由管理員分配帳號,然后通過分配的帳號來請求。在大批量拉取鏡像的時(shí)候,鏡像中心的性能、效率是我們需要考慮的問題。前期我們通過 mirror 方案來實(shí)現(xiàn),在主要城市部署 mirror registry ,通過就近原則來拉取鏡像,解決性能瓶頸。后續(xù)我們還會(huì)采用 P2P 方案來提升鏡像拉取性能。同時(shí)我們定制了 Notification Server ,用于鏡像 pullpush 日志記錄,便于后續(xù)分析與審計(jì)。在鏡像后端存儲(chǔ)方面,采用 ceph 集群方案,從而提供穩(wěn)定、強(qiáng)大的數(shù)據(jù)存儲(chǔ)。
微服務(wù)化之路我們剛剛起航,在面臨挑戰(zhàn)的同時(shí)也帶來了機(jī)遇。不僅僅是在線業(yè)務(wù)的探索,我們也會(huì)探索離線計(jì)算、深度學(xué)習(xí)等系統(tǒng)的支持。
來源于社區(qū),回饋于社區(qū)。后續(xù)我們還會(huì)更多地參與社區(qū)互動(dòng),為社區(qū)做貢獻(xiàn)。這也是我們想去做的一點(diǎn)。目前有個(gè)開源的項(xiàng)目, sriov kubernetes 的網(wǎng)絡(luò)插件( https://github.com/hustcat/sr... ),集中了騰訊游戲兩種模式下容器的高性能網(wǎng)絡(luò)經(jīng)驗(yàn),大家感興趣的可以關(guān)注下。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/32534.html
摘要:正在走遠(yuǎn),新年之初,小數(shù)精選過去一年閱讀量居高的技術(shù)干貨,從容器到微服務(wù)云原生,匯集成篇精華集錦,充分反映了這一年的技術(shù)熱點(diǎn)走向。此文值得收藏,方便隨時(shí)搜索和查看。,小數(shù)將繼續(xù)陪伴大家,為朋友們奉獻(xiàn)更有逼格的技術(shù)內(nèi)容。 2017正在走遠(yuǎn),新年之初,小數(shù)精選過去一年閱讀量居高的技術(shù)干貨,從容器、K8S 到微服務(wù)、云原生、Service Mesh,匯集成52篇精華集錦,充分反映了這一年的技...
摘要:本文內(nèi)容節(jié)選自由主辦的第七屆,架構(gòu)師高欣分享的的實(shí)踐實(shí)錄。當(dāng)然,在部署完成后,我們要做一個(gè)監(jiān)測以便掌握它的運(yùn)行狀況。規(guī)劃配置運(yùn)行環(huán)境在正式部署前,還要考慮如何規(guī)劃并配置好運(yùn)行環(huán)境。在使用部署時(shí),可以利用這些命令做驗(yàn)證,檢驗(yàn)部署是否正常。 showImg(https://segmentfault.com/img/bVblRHj?w=2880&h=1920); 本文內(nèi)容節(jié)選自由msup主辦...
摘要:今天小數(shù)給大家?guī)硪黄夹g(shù)正能量滿滿的分享來自社區(qū)線上群分享的實(shí)錄,分享嘉賓是數(shù)人云肖德時(shí)。第二級調(diào)度由被稱作的組件組成。它們是最小的部署單元,由統(tǒng)一創(chuàng)建調(diào)度管理。 今天小數(shù)給大家?guī)硪黄夹g(shù)正能量滿滿的分享——來自KVM社區(qū)線上群分享的實(shí)錄,分享嘉賓是數(shù)人云CTO肖德時(shí)。 嘉賓介紹: 肖德時(shí),數(shù)人云CTO 十五年計(jì)算機(jī)行業(yè)從業(yè)經(jīng)驗(yàn),曾為紅帽 Engineering Service ...
摘要:數(shù)人云容器助力產(chǎn)品迭代力沙龍干貨分享實(shí)錄持續(xù)上新,今天是來自人人貸高級運(yùn)維工程師杜天鵬的分享,與我們細(xì)數(shù)了人人貸容器化實(shí)踐過程中遇到的問題以及解決方法。 數(shù)人云容器助力產(chǎn)品迭代力MAX沙龍干貨分享實(shí)錄持續(xù)上新,今天是來自人人貸高級運(yùn)維工程師杜天鵬的分享,與我們細(xì)數(shù)了人人貸容器化實(shí)踐過程中遇到的問題以及解決方法。 很高興站在這里和大家一起交流容器技術(shù),我叫杜天鵬,是人人貸的運(yùn)維工程師。人...
閱讀 1002·2021-09-30 09:58
閱讀 2829·2021-09-09 11:55
閱讀 2001·2021-09-01 11:41
閱讀 991·2019-08-30 15:55
閱讀 3350·2019-08-30 12:50
閱讀 3495·2019-08-29 18:37
閱讀 3295·2019-08-29 16:37
閱讀 2011·2019-08-29 13:00