MongoDB on Kubernetes技術(shù)解決方案

1、MongoDB on Kubernetes技術(shù)解決方案AgendaMongoDB在kubernetes中的架構(gòu)如何在kubernetes中快速部署各種規(guī)格的MongoDB實踐過程中遇到的問題為什么選擇Kubernetes？傳統(tǒng)方式：腳本 + 物理機 虛擬機方式：腳本 + 虛擬機docker方式：腳本 + docker而Kubernetes的目標是讓部署docker化的應(yīng)用簡單并且高效，Kubernetes提供了強大的API，可以出色的完成各式 各樣的調(diào)度、配置、管理、監(jiān)控。為我們MongoDB的快速部署、靈活調(diào)整、監(jiān)控管理提供了堅實的基礎(chǔ)。Kubernetes中傳統(tǒng)部署部署MongoDB準備M

2、ongoDB的docker image使用helm/k8s格式y(tǒng)aml的方式進行創(chuàng)建配置。這種部署方式是當前主流的部署方式，但是中間有著大量的腳本開發(fā)成本，而且一旦遇到復(fù)雜結(jié)構(gòu)的集群則無法靈 活調(diào)整處理，同時只負責(zé)創(chuàng)建，不會兼顧到整個生命周期。Kubernetes中Operator部署部署MongoDB準備MongoDB的docker image使用operator自定義格式y(tǒng)aml的方式進行創(chuàng)建配置。什么是Operator？Operator 是 Kubernetes 的擴展軟件，它利用定制資源管理應(yīng)用及其組件。Operator遵循Kubernetes的理念， 特別是在控制器方面。Operat

3、or將大量重復(fù)重復(fù)性的任務(wù)按照我們編寫的任務(wù)自動代碼化，同時Operator會獲得很多Kubernetes內(nèi)置 的自動化功能，優(yōu)異的Operator甚至能優(yōu)化Kubernetes自身。可以直觀的理解Operator是Kubernetes API的客戶端！什么是MongoDB Enterprise Kubernetes Opeartor？將創(chuàng)建MongoDB實例的一系列人工操作轉(zhuǎn)化為可擴展，可重復(fù)和標準化的方法。MongoDB全生命周期的管理。管理MongoDB集群規(guī)格，通過Kubernetes api完成資源配置、網(wǎng)絡(luò)配置以及存儲持久化 4.與Ops manager/cloud manager

4、一同使用，實現(xiàn)MongoDB的監(jiān)控與管理。MongoDB+ MongoDB ops + MongoDB operator + kubernetes的架構(gòu)，以及各組件的功能及關(guān)系當ops部署在kubernetes內(nèi)部的時候架構(gòu)如 左圖所示，此時ops為kubernetes中的pod 之一，這樣做的優(yōu)勢在于在進行動態(tài)擴容以 及高可用方面比較方便。同時也易于統(tǒng)一管 理，但是缺點在于Ops的穩(wěn)定性依賴于 kubernetes的穩(wěn)定性。MongoDB+ MongoDB ops + MongoDB operator + kubernetes的架構(gòu)，以及各組件的功能及關(guān)系當ops部署在kubernetes外

5、部的時候架構(gòu)如 左圖所示，此時ops跟我們平時使用的ops一 樣，沒有任何區(qū)別，只是會接受Operator的 調(diào)度，這種架構(gòu)下，優(yōu)勢在于在管理上跟我 們平時操作沒有任何差異，資源均獨立管理。 同時可以O(shè)ps部分可以使用MongoDBCloud Manager，進一步減少運維成本。MongoDB+ MongoDB ops + MongoDB operator + kubernetes的架構(gòu)，以及各組件的功能及關(guān)系Operator：根據(jù)我們提供的信息，告知kubernetes我們需要的資源，并調(diào)度kubernetes生成符合我們規(guī)格需求的pod，申請持久化存儲， 并配置好各個pod的網(wǎng)絡(luò)。Kube

6、rnetes：在接收到Operator傳輸過來的信息后，在Kubernetes集群中按照規(guī)格申請配置 對應(yīng)的pod。MongoDB Ops manager：在接收到Operator傳輸過來的信息后，向Kubernetes生成的pod中 推送automation Agent，通過Agent來配置不同 類型的MongoDB。MongoDB在kubernetes中的架構(gòu)如何在kubernetes中快速部署各種規(guī)格的MongoDB實踐過程中遇到的問題目錄在Kubernetes中創(chuàng)建MongoDB前，我們需要準備一些東西：完成operator的部署。需要一個Ops/Cloud Manager。生成Ops

7、/Cloud Manager中的用戶以及public API key，同時基于這個用戶以及public API key生成Kubernetes 中 的 secret：kubectl -n mongodb create secret generic local-cert -from-literal=user=test -from- literal=publicApiKey=xadj42c9-900d-41b3-ac00-063ff4ff0603configMap：Kubernetes中的一類資源，用于指向我們的Ops/Cloud Manager中的一個project。configMap的樣式：如

8、何創(chuàng)建Standalone,ReplicaSet,ShardedCluster?在Kubernetes中我們通過yaml文件來完成Standalone,ReplicaSet,ShardedCluster的配置。在yaml文件中，我們可以控制MongoDB的規(guī)格，cpu/內(nèi)存，存儲大小，參數(shù)配置等關(guān)鍵項。Standalone的yaml示例：space： 我們需要創(chuàng)建MongoDB在Kubernetes中的namespace。spec.version：我們需要創(chuàng)建MongoDB的版本，注意，這里必須寫入完整的版本號，如3.6.19spec.opsManager.confi

9、gMap R：我們需要創(chuàng)建MongoDB對應(yīng) 的configMapspec.type：我們需要創(chuàng)建MongoDB的類型，如Standalonespec.credentials：記錄ops/cloud manager的 public API key的secretspec.podSpec.cpu/memory/persistence.storage： 配置pod的cpu/內(nèi)存/持久化存儲大小spec.security.authentication.enabled/modes： 啟動默認鑒權(quán)以及設(shè)置鑒權(quán)模式spec.additionalMongodconfig： 配置MongoDB的初始化參數(shù)spe

10、c.additionalMongodconfig.setParmeter： 配置MongoDB動態(tài)參數(shù)ReplicaSet的yaml示例：spec.member： 副本集中的成員數(shù)spec.type：配置副本集時此參數(shù)為ReplicaSetShardedCluster的yaml示例：spec.shardCount/mo ngosCount/mongodsPerShardC ount/ configServerCount: 分片集群的數(shù)量規(guī)格spec.shard.additionalMongoDConfig：Mongos的參數(shù)設(shè)置spec.mongos. additionalMongoDConf

11、ig Mongos的參數(shù)設(shè)置spec.configSrvPodSp ec:單個config server 的規(guī)格spec.mongosPodSpe c:單個mongos的規(guī)格spec.ShardPodSpec:單個mongos的規(guī)格如何調(diào)整參數(shù)?在operator + ops/cloud manager + Kubernetes的架構(gòu)下，對MongoDB控制的優(yōu)先級為：operator ops/cloud manager 命令行。在這種情況下，如果我們在命令行級或者ops/cloud manager做的部分操作，會被operator中的配 置覆蓋！最直觀就是參數(shù)部分，operator會嚴格按照

12、yaml文件創(chuàng)建出來的StatefulSets來配置整個MongoDB， 所以如果需要修改參數(shù)，需要直接修改創(chuàng)建這個MongoDB的yaml文件，并再次apply。如何創(chuàng)建用戶?MongoDB中的用戶也是由operator來管理，所以創(chuàng)建一個MongoDB用戶需要進行下列配置： 1.數(shù)據(jù)庫開啟了密碼鑒權(quán)。準備一份secret文件，保存MongoDB用戶的密碼，可用base64加密。創(chuàng)建用戶的yaml文件，里面包含用戶持有的權(quán)限以及鑒權(quán)的DB。 例：secret：創(chuàng)建用戶的yaml：MongoDB在kubernetes中的架構(gòu)如何在kubernetes中快速部署各種規(guī)格的MongoDB實踐過程中

13、遇到的問題目錄存儲的選擇 考量在Kubernetes中支持的持久化存儲類型多達十余種，如何選擇適合自己場景的存儲呢？這需要從這 幾個方面考慮。是否需要動態(tài)申領(lǐng)(即yaml中寫需要多少存儲就分配多少)；是否需要動態(tài)擴容；是否需要極致的性能；配置是否方便；是否在生產(chǎn)中使用。存儲的選擇 類型性能：local類型的存儲為首選，因為這是本地存儲，并且是直接使用，其中沒有網(wǎng)絡(luò)等消耗，但是問 題也是非常明顯，它不能在各個節(jié)點間飄移。動態(tài)申領(lǐng)：awsElasticBlockStore，azureDisk,azureFile，cephfs，cinder，csi，fc，flexVolume， flocker，gc

14、ePersistentDisk，glusterfs，hostPath，iscsi，local，nfs，photonPersistentDisk， portworxVolume，quobyte，rbd，scaleIO，storageos，vsphereVolume動態(tài)擴容：gcePersistentDisk，awsElasticBlockStore，Cinder，glusterfs，rbd，Azure File， Azure Disk，Portworx，F(xiàn)lexVolumes，CSI這部分需要根據(jù)自身實際情況進行存儲的選型。更多存儲的相關(guān)知識參考：https:/kubernetes.io/doc

15、s/concepts/storage/persistent-volumes/ReplicaSet horizons在 完 成 副 本 集 配 置 后 ， 我 們 一 般 會 使 用 高 可 用 連 接 串 ： 例 如 ：mongo mongodb:/root:mongo81:30641,81:30879,81:32008/admin?replicaSet=test-rs&authSource=admin來進行連接。這樣的連接方法會由driver來自動選擇訪問主節(jié)點，當時這里我們需要注意的是：81:30641,81:30879,81:32008這樣的IP+端口必須是在初始化集群時就在初始化參數(shù)中

16、，如：如果連接串的IP/主機名跟配置的不一致，在連接時會出現(xiàn)driver無法正確的找到主節(jié)點的問題。 這時候我們就需要replicaSet horizons來解決這個問題。ReplicaSet horizons在完成副本集配置后，因為Kubernetes均通過自身內(nèi)網(wǎng)端口以及自身dns進行初始化的配置，所以我們需要設(shè)置horizons來映射對應(yīng)對外的dns以及端口。這樣即完成配置，然后等待Ops進行ssl狀態(tài)的update，等所有的pod/MongoDB的狀態(tài)正常后。通過mongo -host /testhorip1:30072,testhorip2:32340,testhorip3:3042

17、3 -ssl -sslAllowInvalidCertificates進行連接。參數(shù)轉(zhuǎn)化為科學(xué)技術(shù)法問題在測試過程，發(fā)現(xiàn)當修改一些最大值較大的參數(shù)時，進行最大邊界測試的情況下，會出現(xiàn)automation agent輸入 參數(shù)使用科學(xué)記數(shù)法的問題。例：參數(shù)cursorTimeoutMillis設(shè)置為10000000時候，automation agent會記錄成數(shù)字類型，最終在啟動時會 報錯：cursorTimeoutMillis: Bad digit e while parsing 1e+07解決方案，使用api去get automation agent config，再用post的方式輸入字符

18、串類型：改成：后續(xù)發(fā)現(xiàn)如果初始化為數(shù)字，后續(xù)值過大會觸發(fā)進入科學(xué)計數(shù)法，如果初始化為字符串，后續(xù)乃至最大值仍然為 字符串。同一個project中出現(xiàn)兩個cluster這是一種極端場景。絕對災(zāi)難級異常，因為operator對實例的管理是project級別的，一旦project中 出現(xiàn)多個cluster時候operator+ops的體系對該實例就去失去絕對的控制權(quán)。此時Ops會嘗試進行自己進行修復(fù)，如果成功，會重新合并到一個cluster，如果失敗，就一直處于 異常狀態(tài)(分裂成兩個集群)，無法自修復(fù)已知的觸發(fā)場景僅有一個：創(chuàng)建集群。進行壓力測試，測試過程中把磁盤壓滿。進行存儲擴容。擴容過程中遇到c

19、eph報錯，中間磁盤擴容被堵塞大概1小時。ceph恢復(fù)后，存儲擴容成功。 6.此時cluster分裂成兩個。解決方案：把備份全停止（terminate），在Kubernetes中直接刪除該MongoDB，切記不要刪除pvc， 然后在om中把project中所有的cluster移除，最后通過后臺保存的json，重新創(chuàng)建該MongoDB。MongoDB在kubernetes中的架構(gòu)如何在kubernetes中快速部署各種規(guī)格的MongoDB實踐過程中遇到的問題我們正在做的事情基于MongoDB的實時數(shù)據(jù)服務(wù)平臺產(chǎn)品ConnectorMongoDB 私有云管理平臺K8S+ Ops Manager鈦 鉑 A P I發(fā) 布APIPodbin logredo log鈦 鉑 實 時 異 構(gòu) 同 步PodPodPodPodMongoDB私有云管理平臺特點只需點擊幾下或調(diào)用 API 即可彈 性伸縮自助服務(wù) + 彈性基于Kubernetes企業(yè)級安全性 & SLAs通過一流的操作自動化按需部署、 修改和升級自動化數(shù)據(jù)庫維護數(shù)據(jù)庫和基礎(chǔ)設(shè)施可