本發(fā)明涉及計算機領域，特別涉及一種容器管理平臺。
背景技術：
在一個平臺即服務(paas)平臺中，可能需要管理數(shù)量巨大的容器，而這些容器無規(guī)律的分布在不同的虛擬機中，同時還會根據(jù)外部命令或內(nèi)部資源的改變而遷移到其他的虛擬機上，而應用編排、服務發(fā)現(xiàn)等功能的實現(xiàn)需要快速的定位一個服務的位置。同時，一個容器管理平臺，需要保持高效率的利用集群資源，并且需要監(jiān)控系統(tǒng)可以對容器的性能指標和應用的健康狀態(tài)進行有效靈活的監(jiān)控，并在出現(xiàn)問題時，可以提供更全面的日志信息以方便查看分析。
目前的容器管理平臺，存在當容器數(shù)量增多，在大規(guī)模集群的情況下，定位速度較慢的缺點。且對多租戶管理時，目前的容器管理平臺對集群資源的利用率不高，同時傳統(tǒng)的監(jiān)控報警系統(tǒng)靈活度不高，需要較復雜的配置，復雜的配置導致了可靠性不高的風險，且傳統(tǒng)的日志檢索不直接提供關聯(lián)背景下的日志信息，使得日志分析不夠方便。
由此需要提出一種容器管理平臺，既可以非?？焖俚亩ㄎ灰粋€服務的位置，又能高效利用集群資源下的多租戶管理，還可以靈活的設置監(jiān)控報警系統(tǒng)，并提供關聯(lián)背景下的日志查看。
技術實現(xiàn)要素：
本發(fā)明提供了一種容器管理平臺，可以非?？焖俚亩ㄎ灰粋€服務的位置，又能高效利用集群資源下的多租戶管理，還可以靈活的設置監(jiān)控報警系統(tǒng)，并提供關聯(lián)背景下的日志查看。
根據(jù)本發(fā)明提供的一種容器管理平臺，包括：
調(diào)度器，為基于mesosrestfulapi編寫的應用調(diào)度框架，用于容器應用的生命周期管理；
監(jiān)控報警系統(tǒng)，用于監(jiān)控容器的性能指標和應用的健康狀態(tài)；
日志處理系統(tǒng)，用于日志檢索和日志統(tǒng)計；
發(fā)布系統(tǒng)，用于實現(xiàn)應用的發(fā)布和回滾。
優(yōu)選的，所述調(diào)度器：
調(diào)度器的ui為固定的格式。
優(yōu)選的，所述調(diào)度器：
調(diào)度器啟動時指定所在集群id，如果沒有指定則使用默認的集群id；
調(diào)度器發(fā)應用時需指定用戶id，如果沒有指定則使用默認的用戶id，發(fā)應用的api里包含有user字段；
調(diào)度器發(fā)應用時允許指定所發(fā)應用運行時的用戶名，用于發(fā)應用的api里包含有runas字段；
使用borg把uid和gid同步到每臺borgslave，用戶的應用實例在borgslave上運行在真實的uid下，uid和gid的對應關系維護由外層維護。
優(yōu)選的，所述調(diào)度器：
調(diào)度器還用于給實例打標簽，所述標簽為docker的label，所述標簽包括：
task_id；
app_id；
user_id，當有runas字段時，該label為runas字段的內(nèi)容；
cluster_id；
log_path，當該應用有文件日志時，該label為應用在容器內(nèi)輸出的日志文件路徑，為一條或多條路徑。
調(diào)度器還按照task_id.app_id.user_id.cluster_id的方式來唯一標識每個應用的每個實例；
調(diào)度器命名task_id時按照整數(shù)從0開始連續(xù)分配；
調(diào)度器允許實例暴露多個端口，每個端口對應一個port_id，由調(diào)度器來命名port_id，port_id按照整數(shù)從0開始連續(xù)分配；
實例的名稱在實例容錯恢復后保持不變；
mesos上的實例名字也命名為task_id.app_id.user_id.cluster_id；
mesos調(diào)度起來的docker容器的名字或標簽命名為cluster_id.user_id.app_id.task_id。
優(yōu)選的，所述調(diào)度器：
調(diào)度器用于容器應用全生命周期管理，包括：
發(fā)布應用：強制pull鏡像；privileges權限；支持uri機制；停止信號指定；容器中增加marathon對應增加的環(huán)境變量，包括宿主機ip；
刪除應用，分為兩種種情況，一次性刪除應用所有的實例，或應用實例收縮：
當應用實例個數(shù)收縮減少時，從task_id最大的實例開始刪除；
支持優(yōu)雅終止，每殺掉一個實例的時候，先發(fā)送sigterm信號給實例，在等待預設的時長后，檢查實例是否結(jié)束，如果實例還未結(jié)束則殺掉實例；
更新應用，每個實例被更新后，要由健康檢查機制來保證實例啟動成功，如果更新后的實例健康檢查不通過則對其進行重啟，重啟3次健康檢查仍然失敗則認為實例更新失敗，進行回滾，包括三種情況:應用實例擴縮、全量更新和滾動更新：
實例擴縮：當應用實例個數(shù)擴張增加時，新增實例的task_id從已有實例最大task_id開始依次遞增；
全量更新：老版本先全部刪掉，再發(fā)布新版本；
滾動更新：老版本的實例依次更新為新版本，保證應用不停服；
滾動更新從第0個實例開始，滾動更新分批次進行；
每次滾動更新操作，需要調(diào)度器記錄被更新的實例和未被更新的實例；
每次滾動更新完畢之前，無法對應用有其他滾動更新操作；
滾動更新開始之后，設置應用的狀態(tài)為更新狀態(tài)，當應用的實例沒有全部更新完或全部回滾完時，無法對應用進行擴縮操作，而且調(diào)度器最多維護應用的兩個版本，老版本和新版本，應用的所有實例更新完畢后結(jié)束應用的更新狀態(tài)；
滾動更新的回滾，分為自動回滾和手動回滾：
自動回滾：滾動更新開始之后，只要有任意一個更新后的實例健康檢查不成功，并重新調(diào)度超過3次，則回滾所有更新的實例到老版本，并結(jié)束應用的更新狀態(tài)；
手動回滾：滾動更新開始之后，手動觸發(fā)撤銷滾動更新，所有更新的實例回滾到老版本；
滾動更新和實例擴縮時，對應用進行標記，標記出當前應用正在滾動更新和實例擴縮，除取消操作外，禁止用戶對該應用任何操作；
查詢應用；
容錯恢復，調(diào)度器在發(fā)現(xiàn)某一應用的某一實例失效的時候，自動恢復失效的實例：
當應用的實例為可遷移的，自動恢復時允許把實例遷移到其他節(jié)點上重新運行；
當應用的實例綁定特定節(jié)點不可遷移時，自動恢復時必須先確認實例綁定的節(jié)點可用后再恢復實例。
優(yōu)選的，所述調(diào)度器：
調(diào)度器還用于操作審計，記錄下所有手動觸發(fā)的操作的操作人：
調(diào)度器的編排文件里有user字段，用于記錄應用的變動時實施該操作的user的id。
優(yōu)選的，所述調(diào)度器：
調(diào)度器還用于服務發(fā)現(xiàn)與負載均衡：
調(diào)度器將所有應用的所有實例的ip以及暴露的端口都寫入consul，并通過consul的dns功能查詢到每個應用的每個實例的srv記錄，當實例有任何變化時，所述變化包括增加一個實例、刪除一個實例、容錯恢復或遷移一個實例，調(diào)度器把實例的ip和端口的變化同步到consul，用以保證consul里每個實例的srv記錄都是可訪問的；
七層服務發(fā)現(xiàn)，通過http://task_id.app_id.user_id.cluster_id.dataman.io:80/來訪問某個實例的port0暴露的服務，http://task_id.app_id.user_id.cluster_id.dataman.io:80/進行http重定向到http://task_id.app_id.user_id.cluster_id.dataman.io:port0/；
七層負載均衡，有三種方式對外提供七層負載均衡：
域名的方式，通過http://app_id.user_id.cluster_id.dataman.io:80/訪問某個應用暴露的七層服務，app_id.user_id.cluster_id.dataman.io是域名解析到負載均衡器的ip地址，負載均衡器根據(jù)app_id.user_id.cluster_id區(qū)分不同的應用服務并把請求分發(fā)給應用服務的后臺實例，如果應用的實例暴露多個端口，默認只支持port0對應的服務，該方式支持https實現(xiàn)；
端口的方式，通過http://loadbalancer_ip:app_port/訪問某個應用暴露的七層服務，不同的應用通過在負載均衡器上占不同的端口來區(qū)分不同的服務，如果應用的實例暴露多個端口，則在負載均衡器上占多個端口；
事件機制加api的方式，調(diào)度器通過事件機制觸發(fā)額外的模塊調(diào)用f5的api來更新應用在f5上的后臺實例；
四層服務發(fā)現(xiàn)，對于需要暴露四層服務的應用，該應用的每個實例保持固定ip，每個實例暴露的服務通過tcp://task_id.app_id.user_id.cluster_id.dataman.io:port_number訪問，其中task_id.app_id.user_id.cluster_id.dataman.io為解析到該應用的某個實例的固定ip，port_number是該應用所暴露的端口，每個實例暴露一個或多個端口，通過task_id.app_id.user_id.cluster_id.dataman.io加上實例暴露的特定端口進行訪問；
四層負載均衡，當四層應用實例擴縮之后，通過調(diào)度器的事件機制觸發(fā)額外的模塊調(diào)用f5的api來更新應用在f5上的后臺實例；
負載均衡支持訪問請求速率限制，包括每秒請求次數(shù)上限。
優(yōu)選的，所述調(diào)度器：
調(diào)度器通過負載均衡器與健康檢查機制實現(xiàn)應用實例的優(yōu)雅啟動和優(yōu)雅終止，包括：
優(yōu)雅啟動，當應用做實例擴展、滾動更新時，負載均衡器不對未通過健康檢查的實例分配流量；
優(yōu)雅終止，當應用做實例收縮、滾動更新時，當一個實例要被關閉時，那負載均衡器暫停給該實例分配新請求，并等待該實例將已有的請求處理完畢，當負載均衡器確定該實例完全沒有流量之后，調(diào)度器利用mesos的優(yōu)雅終止機制來關閉該實例。
優(yōu)選的，所述的容器管理平臺：
每一個容器具有獨立的ip，實施為：
dockerdeamon層面以macvlan為driver創(chuàng)建出子網(wǎng)，并且保證dockerrun--ip之后的網(wǎng)絡能夠到達互通要求；
調(diào)度器下發(fā)4層應用時，通過api提供與實例數(shù)數(shù)量相等的ip數(shù)量；
調(diào)度器維護ip地址和taskid之間關系，保證task異常重啟之后使用之前ip；
對4層應用不進行擴展和收縮操作；
調(diào)度器將應用劃分為兩類：replicates類型和fixed類型；其中，fixed類型不能擴縮和滾動升級；replicates類型面向七層應用，通過調(diào)度器實現(xiàn)負載服務發(fā)現(xiàn)和服務代理，負載均衡，調(diào)度器還提供此類應用的task地址元組{ip：port}，用于客戶自有代理和負載均衡場景，服務之間和對外使用調(diào)度器提供的dns服務器。
優(yōu)選的，所述容器管理平臺：
所述調(diào)度器，還用于在單集群模式下虛擬多租戶；
所述監(jiān)控報警系統(tǒng)，為基于表達式的監(jiān)控報警系統(tǒng)；
所述日志處理系統(tǒng)，還用于在全文檢索日志時進行單個日志行的上下文關聯(lián)查看。
本發(fā)明提供的容器管理平臺，可以非常快速的定位一個服務的位置，又能高效利用集群資源下的多租戶管理，還可以靈活的設置監(jiān)控報警系統(tǒng)，并提供關聯(lián)背景下的日志查看。
本發(fā)明的其它特征和優(yōu)點將在隨后的說明書中闡述，并且，部分地從說明書中變得顯而易見，或者通過實施本發(fā)明而了解。本發(fā)明的目的和其他優(yōu)點可通過在所寫的說明書、權利要求書、以及附圖中所特別指出的結(jié)構(gòu)來實現(xiàn)和獲得。
下面通過附圖和實施例，對本發(fā)明的技術方案做進一步的詳細描述。
附圖說明
附圖用來提供對本發(fā)明的進一步理解，并且構(gòu)成說明書的一部分，與本發(fā)明的實施例一起用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的限制。在附圖中：
圖1為本發(fā)明實施例中一種容器管理平臺的示意圖。
具體實施方式
以下結(jié)合附圖對本發(fā)明的優(yōu)選實施例進行說明，應當理解，此處所描述的優(yōu)選實施例僅用于說明和解釋本發(fā)明，并不用于限定本發(fā)明。
在本發(fā)明的一個實施例中，如圖1所示，一種容器管理平臺，包括：
調(diào)度器，為基于mesosrestfulapi編寫的應用調(diào)度框架，用于容器應用的生命周期管理；
監(jiān)控報警系統(tǒng)，用于監(jiān)控容器的性能指標和應用的健康狀態(tài)；
日志處理系統(tǒng)，用于日志檢索和日志統(tǒng)計；
發(fā)布系統(tǒng)，用于實現(xiàn)應用的發(fā)布和回滾。
依據(jù)本發(fā)明提供的容器管理平臺，通過對容器應用的生命周期管理和監(jiān)控，實現(xiàn)了對容器應用的管理。
在本發(fā)明的一個實施例中，調(diào)度器：
調(diào)度器的ui為固定的格式。
依據(jù)本發(fā)明提供的容器管理平臺，調(diào)度器的ui為固定的格式，這樣應用即使尚未發(fā)布，也可以通過應用或?qū)嵗拿Q，拼出url用以訪問調(diào)度器ui來查詢詳情，比如通過
http://swan_ui/？task_id＝1,3,5&app_id＝2048&user_id＝xxxxx&cluster_id＝beijing查詢某個應用的某一個或幾個實例；通過
http://swan_ui/？task_id＝0-4&app_id＝2048&user_id＝xxxxx&cluster_id＝beijing查詢某個應用的某范圍內(nèi)的實例；通過
http://swan_ui/？app_id＝2048&user_id＝xxxxx&cluster_id＝beijing查詢某個應用；通過http://swan_ui/？user_id＝xxxxx&cluster_id＝beijing查詢某個用戶在某個集群下的所有應用；通過http://swan_ui/？cluster_id＝beijing查詢某個集群下的所有應用。
在本發(fā)明的一個實施例中，調(diào)度器：
調(diào)度器啟動時指定所在集群id，如果沒有指定則使用默認的集群id；
調(diào)度器發(fā)應用時需指定用戶id，如果沒有指定則使用默認的用戶id，發(fā)應用的api里包含有user字段；
調(diào)度器發(fā)應用時允許指定所發(fā)應用運行時的用戶名，用于發(fā)應用的api里包含有runas字段；
使用borg把uid和gid同步到每臺borgslave，用戶的應用實例在borgslave上運行在真實的uid下，uid和gid的對應關系維護由外層維護。
依據(jù)本發(fā)明提供的容器管理平臺，可以實現(xiàn)對集群id和用戶用戶id的同步維護，且在發(fā)應用時更加靈活。
在本發(fā)明的一個實施例中，調(diào)度器：
調(diào)度器還用于給實例打標簽，所述標簽為docker的label，所述標簽包括：
task_id；
app_id；
user_id，當有runas字段時，該label為runas字段的內(nèi)容；
cluster_id；
log_path，當該應用有文件日志時，該label為應用在容器內(nèi)輸出的日志文件路徑，為一條或多條路徑。
調(diào)度器還按照task_id.app_id.user_id.cluster_id的方式來唯一標識每個應用的每個實例；
調(diào)度器命名task_id時按照整數(shù)從0開始連續(xù)分配；
調(diào)度器允許實例暴露多個端口，每個端口對應一個port_id，由調(diào)度器來命名port_id，port_id按照整數(shù)從0開始連續(xù)分配；
實例的名稱在實例容錯恢復后保持不變；
mesos上的實例名字也命名為task_id.app_id.user_id.cluster_id；
mesos調(diào)度起來的docker容器的名字或標簽命名為cluster_id.user_id.app_id.task_id。
依據(jù)本發(fā)明提供的容器管理平臺，通過給實例打標簽，可以方便快速的對實例進行管理，在大規(guī)模集群下，可以非?？焖俚亩ㄎ灰粋€應用和實例的位置。
在本發(fā)明的一個實施例中，調(diào)度器：
調(diào)度器用于容器應用全生命周期管理，包括：
發(fā)布應用：強制pull鏡像；privileges權限；支持uri機制；停止信號指定；容器中增加marathon對應增加的環(huán)境變量，包括宿主機ip；
刪除應用，分為兩種種情況，一次性刪除應用所有的實例，或應用實例收縮：
當應用實例個數(shù)收縮減少時，從task_id最大的實例開始刪除。某個應用有5個實例，task_id為0、1、2、3、4，當實例個數(shù)要收縮為3個時，要把task_id是4和3的兩個實例刪除掉，不能任意刪除實例，而是通過實例收縮來刪除應用實例；
支持優(yōu)雅終止，每殺掉一個實例的時候，先發(fā)送sigterm信號給實例，在等待預設的時長后，檢查實例是否結(jié)束，如果實例還未結(jié)束則殺掉實例；
更新應用，每個實例被更新后，要由健康檢查機制來保證實例啟動成功，如果更新后的實例健康檢查不通過則對其進行重啟，重啟3次健康檢查仍然失敗則認為實例更新失敗，進行回滾，包括三種情況:應用實例擴縮、全量更新和滾動更新：
實例擴縮：當應用實例個數(shù)擴張增加時，新增實例的task_id從已有實例最大task_id開始依次遞增，某個應用有3個實例，task_id為0、1、2，當實例個數(shù)要擴張為5個時，新增的兩個實例的task_id分別為3和4；
全量更新：老版本先全部刪掉，再發(fā)布新版本；
滾動更新：老版本的實例依次更新為新版本，保證應用不停服；
滾動更新從第0個實例開始，滾動更新分批次進行，每次選擇要更新幾個實例，某應用有5個實例，先更新一個，把第0個實例更新，再更新兩個，把第1個和第2個實例更新，最后再更新兩個，把第3個和第4個實例更新；
每次滾動更新操作，需要調(diào)度器記錄被更新的實例和未被更新的實例；
滾動更新，更新某應用的3個實例(該應用至少有3個以上實例)，只有當3個更新實例的健康檢查成功之后，并保持健康至少一分鐘(該等待時間可配置)以上，才算這3個實例更新完畢，而且每次滾動更新完畢之前，無法對應用有其他滾動更新操作；
滾動更新開始之后，設置應用的狀態(tài)為更新狀態(tài)，當應用的實例沒有全部更新完或全部回滾完時，無法對應用進行擴縮操作，而且調(diào)度器最多維護應用的兩個版本，老版本和新版本，應用的所有實例更新完畢后結(jié)束應用的更新狀態(tài)；
滾動更新的回滾，分為自動回滾和手動回滾：
自動回滾：滾動更新開始之后，只要有任意一個更新后的實例健康檢查不成功，并重新調(diào)度超過3次，則回滾所有更新的實例到老版本，并結(jié)束應用的更新狀態(tài)；
手動回滾：滾動更新開始之后，手動觸發(fā)撤銷滾動更新，所有更新的實例回滾到老版本；
滾動更新和實例擴縮時，對應用進行標記，標記出當前應用正在滾動更新和實例擴縮，除取消操作外，禁止用戶對該應用任何操作；
查詢應用；
容錯恢復，調(diào)度器在發(fā)現(xiàn)某一應用的某一實例失效的時候，自動恢復失效的實例：
當應用的實例為可遷移的，自動恢復時允許把實例遷移到其他節(jié)點上重新運行；
當應用的實例綁定特定節(jié)點不可遷移時，如mysql等長時間有狀態(tài)的應用，自動恢復時必須先確認實例綁定的節(jié)點可用后再恢復實例。
依據(jù)本發(fā)明提供的容器管理平臺，可以實現(xiàn)對容器應用的全生命周期的管理，能夠更安全和穩(wěn)定的運行應用。
在本發(fā)明的一個實施例中，調(diào)度器：
調(diào)度器還用于操作審計，記錄下所有手動觸發(fā)的操作的操作人：
調(diào)度器的編排文件里有user字段，用于記錄應用的變動時實施該操作的user的id。
依據(jù)本發(fā)明提供的容器管理平臺，可以實現(xiàn)對操作的審計，實現(xiàn)對整個平臺的更好的管理。
在本發(fā)明的一個實施例中，調(diào)度器：
調(diào)度器還用于服務發(fā)現(xiàn)與負載均衡：
調(diào)度器將所有應用的所有實例的ip以及暴露的端口都寫入consul，并通過consul的dns功能查詢到每個應用的每個實例的srv記錄，當實例有任何變化時，所述變化包括增加一個實例、刪除一個實例、容錯恢復或遷移一個實例，調(diào)度器把實例的ip和端口的變化同步到consul，用以保證consul里每個實例的srv記錄都是可訪問的；
七層服務發(fā)現(xiàn)，通過http://task_id.app_id.user_id.cluster_id.dataman.io:80/來訪問某個實例的port0暴露的服務，http://task_id.app_id.user_id.cluster_id.dataman.io:80/進行http重定向到http://task_id.app_id.user_id.cluster_id.dataman.io:port0/；
七層負載均衡，有三種方式對外提供七層負載均衡：
域名的方式，通過http://app_id.user_id.cluster_id.dataman.io:80/訪問某個應用暴露的七層服務，app_id.user_id.cluster_id.dataman.io是域名解析到負載均衡器的ip地址，負載均衡器根據(jù)app_id.user_id.cluster_id區(qū)分不同的應用服務并把請求分發(fā)給應用服務的后臺實例，如果應用的實例暴露多個端口，默認只支持port0對應的服務，該方式支持https實現(xiàn)；
端口的方式，通過http://loadbalancer_ip:app_port/訪問某個應用暴露的七層服務，不同的應用通過在負載均衡器上占不同的端口來區(qū)分不同的服務，如果應用的實例暴露多個端口，則在負載均衡器上占多個端口；
事件機制加api的方式，調(diào)度器通過事件機制觸發(fā)額外的模塊調(diào)用f5的api來更新應用在f5上的后臺實例；
四層服務發(fā)現(xiàn)，對于需要暴露四層服務的應用，該應用的每個實例保持固定ip，每個實例暴露的服務通過tcp://task_id.app_id.user_id.cluster_id.dataman.io:port_number訪問，其中task_id.app_id.user_id.cluster_id.dataman.io為解析到該應用的某個實例的固定ip，port_number是該應用所暴露的端口，每個實例暴露一個或多個端口，通過task_id.app_id.user_id.cluster_id.dataman.io加上實例暴露的特定端口進行訪問；
四層負載均衡，當四層應用實例擴縮之后，通過調(diào)度器的事件機制觸發(fā)額外的模塊調(diào)用f5的api來更新應用在f5上的后臺實例；
負載均衡支持訪問請求速率限制，包括每秒請求次數(shù)上限。
依據(jù)本發(fā)明提供的容器管理平臺，可以實現(xiàn)服務的發(fā)現(xiàn)和負載的均衡，能夠更高效的利用硬件資源。
在本發(fā)明的一個實施例中，調(diào)度器：
調(diào)度器通過負載均衡器與健康檢查機制實現(xiàn)應用實例的優(yōu)雅啟動和優(yōu)雅終止，包括：
優(yōu)雅啟動，當應用做實例擴展、滾動更新時，負載均衡器不對未通過健康檢查的實例分配流量；
優(yōu)雅終止，當應用做實例收縮、滾動更新時，當一個實例要被關閉時，那負載均衡器暫停給該實例分配新請求，并等待該實例將已有的請求處理完畢，當負載均衡器確定該實例完全沒有流量之后，調(diào)度器利用mesos的優(yōu)雅終止機制來關閉該實例。
依據(jù)本發(fā)明提供的容器管理平臺，通過優(yōu)雅啟動和優(yōu)雅終止，能夠更穩(wěn)定的實現(xiàn)應用的擴展、收縮和更新。
在本發(fā)明的一個實施例中，容器管理平臺：
每一個容器具有獨立的ip，實施為：
dockerdeamon層面以macvlan為driver創(chuàng)建出子網(wǎng)，并且保證dockerrun--ip之后的網(wǎng)絡能夠到達互通要求；
調(diào)度器下發(fā)4層應用時，通過api提供與實例數(shù)數(shù)量相等的ip數(shù)量；
調(diào)度器維護ip地址和taskid之間關系，保證task異常重啟之后使用之前ip；
對4層應用不進行擴展和收縮操作；
調(diào)度器將應用劃分為兩類：replicates類型和fixed類型；其中，fixed類型不能擴縮和滾動升級；replicates類型面向七層應用，通過調(diào)度器實現(xiàn)負載服務發(fā)現(xiàn)和服務代理，負載均衡，調(diào)度器還提供此類應用的task地址元組{ip：port}，用于客戶自有代理和負載均衡場景，服務之間和對外使用調(diào)度器提供的dns服務器。
依據(jù)本發(fā)明提供的容器管理平臺，通過一容器一ip的方式，能夠非?？焖俚亩ㄎ灰粋€服務的位置，方便對容器和服務的管理。
在本發(fā)明的一個實施例中，的容器管理平臺：
調(diào)度器，還用于在單集群模式下虛擬多租戶；
監(jiān)控報警系統(tǒng)，為基于表達式的監(jiān)控報警系統(tǒng)；
日志處理系統(tǒng)，調(diào)度器通過httpget鏈接訪問日志處理系統(tǒng)，參數(shù)通過uri傳遞，日志處理系統(tǒng)在全文檢索日志時進行單個日志行的上下文關聯(lián)查看。
依據(jù)本發(fā)明提供的容器管理平臺，通過使用在單集群模式下的虛擬多租戶的管理模式，實現(xiàn)了高效利用集群資源下的多租戶管理；通過使用基于表達式的監(jiān)控報警系統(tǒng)，實現(xiàn)了對監(jiān)控報警系統(tǒng)的靈活的設置，降低了設置監(jiān)控報警系統(tǒng)的難度，進而降低了監(jiān)控報警系統(tǒng)的可靠性不高的潛在風險；通過在全文檢索日志時進行單個日志行的上下文關聯(lián)查看，可以方便的在關聯(lián)背景下查看分析日志信息。
顯然，本領域的技術人員可以對本發(fā)明進行各種改動和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權利要求及其等同技術的范圍之內(nèi)，則本發(fā)明也意圖包含這些改動和變型在內(nèi)。