金融行業(yè)容器平臺建設方案

金融行業(yè)容器平臺建設方案

【導讀】數(shù)字經(jīng)濟時代金融行業(yè)面臨數(shù)字化轉(zhuǎn)型挑戰(zhàn)，利用容器云原生技術作為支撐數(shù)字經(jīng)濟的數(shù)字底座，與公有云云原生采用相同的技術和架構，統(tǒng)一的生態(tài)體系，在保障金融機構數(shù)據(jù)權益和行業(yè)監(jiān)管的同時，能夠快速獲取大數(shù)據(jù)、人工智能、數(shù)據(jù)庫等新型云服務能力，滿足“安全可靠+應用創(chuàng)新”雙重訴求，以快速應對市場變化。本文是2021容器云職業(yè)技能大賽團隊賽的亞軍作品。

目錄1.背景概述2.現(xiàn)狀及分析2.1IT研發(fā)轉(zhuǎn)型2.2IT架構轉(zhuǎn)型2.3IT運維轉(zhuǎn)型2.4IT組織轉(zhuǎn)型3.建設方案3.1容器平臺建設3.1.1容器可編排性3.1.2容器平臺可擴展性3.1.3安全合規(guī)性對接3.2統(tǒng)一知識庫3.2.1建設目標3.2.2建設方案3.2.3知識分類3.3統(tǒng)一制品發(fā)布3.3.1方案架構3.3.2代碼版本管理3.3.3自動化測試3.3.4打包構建3.3.5運行環(huán)境3.3.6持續(xù)部署3.3.7制品交付3.3.8合規(guī)性檢查3.4統(tǒng)一資源申請平臺3.4.1自助資源申請服務3.4.2在線審批流程3.4.3自動化部署3.4.4自助運維3.4.5自助監(jiān)控告警3.4.6租期回收3.5容器統(tǒng)一規(guī)范3.5.1容器內(nèi)應用的健康檢測3.5.2應用容器的DNS配置3.5.3應用容器的應用配置管理3.5.4應用容器的日志配置3.5.5集群資源管理規(guī)范3.5.6投產(chǎn)審核3.5.7自動化運維3.6高可用架構體系3.6.1方案概述3.6.2高可用部署方案3.6.3總體設計3.6.4災備實現(xiàn)4.方案價值4.1IT交付新能力4.2IT架構新能力4.3IT運維新能力

1背景概述“十四五”期間的核心任務之一是科技創(chuàng)新，科技創(chuàng)新是引領發(fā)展的第一動力，是推動高質(zhì)量發(fā)展、建設現(xiàn)代化經(jīng)濟體系的戰(zhàn)略支撐。傳統(tǒng)企業(yè)在今天都面臨著新興業(yè)務模式的劇烈沖擊，同質(zhì)化的競爭手段已無法讓企業(yè)在愈演愈烈的競爭中脫穎而出，包括銀行、證券、保險以及政府金融機構在內(nèi)的傳統(tǒng)企業(yè)，紛紛致力于數(shù)字化轉(zhuǎn)型。在數(shù)字經(jīng)濟時代，以大數(shù)據(jù)、人工智能、數(shù)據(jù)庫為支撐的數(shù)字高速路，成為數(shù)字世界的基礎。且科技創(chuàng)新需要建立在數(shù)字化轉(zhuǎn)型成功的基石和底座之上。數(shù)字經(jīng)濟時代金融行業(yè)面臨數(shù)字化轉(zhuǎn)型挑戰(zhàn)，利用容器云原生技術作為支撐數(shù)字經(jīng)濟的數(shù)字底座，與公有云云原生采用相同的技術和架構，統(tǒng)一的生態(tài)體系，在保障金融機構數(shù)據(jù)權益和行業(yè)監(jiān)管的同時，能夠快速獲取大數(shù)據(jù)、人工智能、數(shù)據(jù)庫等新型云服務能力，滿足“安全可靠+應用創(chuàng)新”雙重訴求，以快速應對市場變化?？梢岳萌萜髟圃系臄?shù)據(jù)治理能力，實現(xiàn)數(shù)據(jù)統(tǒng)一管理，挖掘數(shù)據(jù)價值；可以利用容器云原生上的人工智能開發(fā)平臺和開發(fā)框架，持續(xù)積累訓練數(shù)據(jù)、算法模型和知識圖譜，儲備人才，探索前沿科技；可以利用容器云原生上的應用管理、微服務和DevOps技術，落地人工智能、金融級的應用，并且能夠提升開發(fā)生產(chǎn)效率。倡導各金融機構結(jié)合自身實際情況，積極推進混合云的部署和建設，引入業(yè)界先進的云服務，支撐金融機構基于容器云原生靈活創(chuàng)新。2.現(xiàn)狀及分析銀行的業(yè)務應用目前以多種形態(tài)運行在不同的技術棧上，包括互聯(lián)網(wǎng)技術棧和商業(yè)技術棧。大多數(shù)系統(tǒng)已經(jīng)完成新一代的升級，但是隨著容器的發(fā)展很多銀行開始試水分布式架構體系改造。由于銀行交易往往比較重要，有哪些系統(tǒng)最適合云原生容器化改造，應用在進行改造后如何符合銀行現(xiàn)有規(guī)范等問題也顯露出來。1.對容器技術沒接觸或接觸少的研發(fā)部門會面臨新技術的學習成本高，改造難度大等問題；2.互聯(lián)網(wǎng)技術棧產(chǎn)品直接進入不符合銀行的高可用及安全要求等；3.容器改造期間可能涉及到除容器以外的其他平臺或云產(chǎn)品；4.開發(fā)測試環(huán)節(jié)中生成的制品、編排文件需要經(jīng)過安全審核再投產(chǎn)；5.測試資源申請面臨不同云平臺產(chǎn)品的統(tǒng)一供給問題；6.運維部門需要在現(xiàn)有運維框架下如何更快上手，并減少運維難度問題。在互聯(lián)網(wǎng)+金融和自主可控兩大趨勢的影響下，中國金融IT領域掀起了一場規(guī)?？涨暗霓D(zhuǎn)型大潮。傳統(tǒng)的IT流程、基礎架構和運維模式已經(jīng)無法滿足業(yè)務發(fā)展的需求和競爭形態(tài)的轉(zhuǎn)變，傳統(tǒng)金融機構都在考慮未來的IT開發(fā)機制、IT架構等如何變革。2.1

IT研發(fā)轉(zhuǎn)型IT研發(fā)轉(zhuǎn)型-如何快速響應用戶需求？互聯(lián)網(wǎng)思維的根本就是快，只有快速響應用戶需求才能在激烈的市場競爭中占據(jù)優(yōu)勢。在互聯(lián)網(wǎng)+轉(zhuǎn)型的過程中，金融行業(yè)信息化建設的關鍵是及時響應業(yè)務需求、適應多變的商業(yè)環(huán)境的靈活的IT架構，以滿足不同部門、客戶和合作伙伴的各種需求。然而，傳統(tǒng)的研發(fā)模型已經(jīng)成為應用交付和迭代速度的瓶頸，IT研發(fā)流程和亟待轉(zhuǎn)型。2.2

IT架構轉(zhuǎn)型IT架構轉(zhuǎn)型-煙囪式架構如何向分布式架構無痛轉(zhuǎn)型？在IT基礎架構層面，很多金融企業(yè)都是煙囪式架構，煙囪式架構帶來的最大問題是能力孤島，不同的應用系統(tǒng)之間的資源無法實現(xiàn)共享。并且，在金融走向普惠、擁抱長尾市場的過程中，傳統(tǒng)金融IT架構無法支撐巨量涌入的長尾客戶。隨著互聯(lián)網(wǎng)+轉(zhuǎn)型的深入，IT基礎架構需要獲得更多的彈性，從而滿足互聯(lián)網(wǎng)業(yè)務對彈性伸縮的需求。因此，IT系統(tǒng)的云化勢在必行。大部分金融企業(yè)已經(jīng)意識到從煙囪式向分布式架構轉(zhuǎn)型的重要性。然而，當前許多架構轉(zhuǎn)型的方案需要經(jīng)歷推倒重來的陣痛，這讓他們對云化IT基礎架構裹足不前。他們需要一套能夠?qū)崿F(xiàn)無痛、漸進式向云計算遷移的方案。2.3

IT運維轉(zhuǎn)型IT運維轉(zhuǎn)型-高復雜環(huán)境下如何確保系統(tǒng)的高可用性？金融IT運維人員的壓力之大眾所周知，這源于金融行業(yè)對業(yè)務連續(xù)性和可用性的嚴苛要求。然而，隨著金融信息化的不斷發(fā)展，金融IT環(huán)境正在變得越來越復雜：應用紛繁復雜、IT架構異構、IT規(guī)模日益增大，這些都導致運維的難度越來越大，運維部門需要全新的思路來應對復雜環(huán)境下IT系統(tǒng)運維的壓力。2.4

IT組織轉(zhuǎn)型IT組織轉(zhuǎn)型-如何平衡唯快不破和安全第一互聯(lián)網(wǎng)的業(yè)務拓展和產(chǎn)品研發(fā)，講究唯快不破。業(yè)務的交付速度、快速迭代和幾乎實時的用戶響應，是互聯(lián)網(wǎng)公司所追求的目標；其研發(fā)、運營等組織結(jié)構的設計，內(nèi)部流程審批等權力的分配，也都充分考慮了這樣的業(yè)務特征和目標。金融行業(yè)追求安全第一，但在互聯(lián)網(wǎng)的節(jié)奏下，如何平衡唯快不破與安全第一？如何優(yōu)化組織結(jié)構，在使用技術手段保障安全的同時，在運營環(huán)節(jié)提高效率、精簡流程？這是很多金融決策者需要思考的問題，也是對金融企業(yè)管理層提出的新挑戰(zhàn)。3

建設方案3.1容器平臺建設容器技術在金融行業(yè)的應用場景非常廣泛，從開發(fā)測試環(huán)境到生產(chǎn)環(huán)境，都可以采用容器技術。以Docker為代表的容器技術，為金融IT和業(yè)務轉(zhuǎn)型帶來了近乎顛覆性的思路。從容器技術的使用場景來看，非常適合使用容器技術的應用主要包括幾個類型：需要經(jīng)常更新和快速迭代的應用、需要在云中運行的應用，以及需要從DevOps和微服務中受益的應用等。下面總結(jié)了幾個適合采用Docker容器技術的場景，包括CI/CD持續(xù)交付、大規(guī)模集群管理、混合云、數(shù)據(jù)分析應用、微服務化應用、以及云原生應用（CloudNativeApplication）等。3.1.1容器可編排性容器云平臺技術架構，需要符合云原生技術的發(fā)展方向，能支持分布式應用，故而選擇合適的容器的管理和編排（Orchestration）工具尤為重要。初級的編排，是資源的編排，即針對物理機或者虛擬機；但更高層次的是服務的編排，需要對架構層次在整體上有一個完整的定義。Docker技術所解決問題的對象是面向“一個應用”。而在真實的云環(huán)境中，工程師需要面對的是將數(shù)十類應用構成的“綜合系統(tǒng)”，部署為成百上千個具體實例。這樣龐大的工作依靠人工來進行實施顯然是難度巨大且風險和成本均極高的。因此就需要有對應于容器運行時的編排技術來解決海量容器的生命周期管理工作，Kubernetes就是原生技術生態(tài)中已成為事實行業(yè)標準的一種容器編排技術。Kubernetes這個名字起源于古希臘，譯為“舵手”。如果Docker把自己定位為馱著集裝箱在大海上遨游的鯨魚，那么Kubernetes就是掌舵大航海時代話語權的舵手，指揮著這條鯨魚按照舵手設定的路線巡游。Kubernetes是Google開源的容器集群管理系統(tǒng)，由Google多年大規(guī)模容器管理技術Borg演化而來，并贈給云原生計算基金會（CNCF），其主要功能包括：基于容器的應用部署、維護和滾動升級；負載均衡和服務發(fā)現(xiàn)；跨機器和跨地區(qū)的集群調(diào)度；容器負載自動伸縮；無狀態(tài)服務和有狀態(tài)服務；開放API以獲得擴展性支持。圖-Kubernetes定義容器狀態(tài)的機制如上圖所示，Kubernetes通過符合YAML標準的聲明式語言定義Kubernetes內(nèi)所有允許的資源類型，包括如Pod、Deployment、Service等等。作為基礎調(diào)度單元，容器組（Pod）通過組織一組緊密關聯(lián)的容器（Container），他們共享網(wǎng)絡和文件系統(tǒng)的特性，而對外提供某一項應用服務能力，并接受Kubernetes對于其生命周期和接口能力的管理。通過這樣的機制，Kubernetes可以為應用提供以下解決方案：解決了大規(guī)模應用運維的規(guī)模性問題，自動化支持海量應用的編排及生命周期管理；通過簡單的聲明式語言（YAML）描述了應用的拓撲結(jié)構和生命周期，解決了Dockerfile無法描述應用自身之外的環(huán)境問題，將“從代碼到應用”演進到“從代碼到服務”；應用負載實時彈性擴容，無需經(jīng)過冗長的申請資源、安裝操作系統(tǒng)、部署應用、測試、負載上線的繁瑣過程，輕松面對流量波峰，完整釋放Docker的生產(chǎn)力；流量切分和發(fā)布策略配合，實現(xiàn)持續(xù)交付，整合精益管理，支持DevOps實踐落地；開放API，實現(xiàn)對各種第三方網(wǎng)絡、存儲解決方案的支持能力，滿足企業(yè)用戶的生產(chǎn)需求；抽象底層環(huán)境，標準化鏡像、標準化編排，大規(guī)模應用亦可隨時遷移，不用擔心被廠商綁定。除功能支持外，對于企業(yè)生產(chǎn)級支撐平臺的選型考慮，編排引擎作為調(diào)度核心能力的實現(xiàn)技術，應考慮其未來長期可持續(xù)擴展的能力是否能夠滿足企業(yè)業(yè)務增長需求。Kubernetes單一集群內(nèi)最大可支持5000個節(jié)點部署，支持包含150000個容器組或300000個容器。再加上多集群擴展的能力，從生產(chǎn)規(guī)模支持上完全可滿足企業(yè)未來長期的業(yè)務增長需求。Kubernetes自身提供的是對由一組容器定義的對象Pod提供了運維能力、彈性能力、調(diào)度能力、及服務訪問能力等幾個方面的功能，其對容器運行時、存儲、網(wǎng)絡等等所有會差異化的外圍服務均在以接口驅(qū)動的形式來提供支持，即ContainerRuntimeInterface（CRI）、ContainerStorageInterface（CSI）、ContainerNetworkInterface（CNI）。如下圖所示：圖-Kubernetes的Interface設計模式對于極特殊情況，當原生內(nèi)部定義的資源對象如存儲類型等無法滿足企業(yè)需求時，也可以通過CustomResourceDefinition（CRD）來實現(xiàn)新的資源定義擴展API，使得Kubernetes的開放性可以進一步被無限放大。如下圖所示CRD原理：圖-CRD原理通過以上設計，使得Kubernetes面對不同的容器運行時、網(wǎng)絡、存儲實現(xiàn)甚至是特殊的資源形態(tài)要求時，均可通過擴展驅(qū)動實現(xiàn)有效兼容，而不用更改其核心功能實現(xiàn)，換言之Kubernetes的兼容性設計很大程度上取決于它的設計邊界即是操作這些資源驅(qū)動程序，而不是操作某個資源實體本身，是一個高度通用的抽象?；谶@樣的架構設計，使得Kubernetes具備了與生俱來的可兼容性，原理上可以認為，只要下游部署實現(xiàn)不修改上游原有的代碼，即使各類部署均具備了對Kubernetes的一致兼容性。Kubernetes已經(jīng)成為事實上的容器管理的標準，世界上大多數(shù)公司都使用它作為容器管理和編排，其有以下幾大優(yōu)勢：開源的力量在不斷擴大的容器應用領域，Kubernetes已發(fā)展成為事實上的行業(yè)標準。因此，您可以選擇多種服務提供商來幫助您在組織的IT基礎架構中實施它。如果出現(xiàn)任何問題，Kubernetes開發(fā)者的開放社區(qū)可以指望做正確的事情。更重要的是，Kubernetes并不是一個開源了就不再活躍的項目，而是一個全年四次大版本更新的項目。成本效益容器的復雜性和占用空間都很輕，而且設置它們比設置VM要簡單得多。這使得Kubernetes成為管理容器化應用程序的非常靈活的平臺。Kubernetes配置可減少錯誤的CPU周期和GB的RAM，從而縮短響應時間，最終提高系統(tǒng)性能。并且由于Kubernetes的負載平衡引擎，它可以在需要時啟動，停止和優(yōu)先處理給定的容器-所有這些都可以保持性能一致?？梢浦残杂捎谄涠喙δ苄?，Kubernetes可以在您的組織內(nèi)本地設置和運行在大量底層操作系統(tǒng)上。此外，如果您決定在整個生命周期的部署過程中遷移到備用操作系統(tǒng)，您可以隨身攜帶現(xiàn)有工作負載，而無需重新設計應用程序或廢品并重新構建基礎架構。Kubernetes避免了供應商鎖定，您的設置將繼續(xù)標準化并隨著時間的推移而簡化?？蓴U展性Kubernetes從頭開始設計為模塊化容器管理工具（CM），您可以自由選擇混合和匹配組件，實現(xiàn)真正的交鑰匙和定制實施。使用Kubernetes，您可以決定要運行的操作系統(tǒng)，應用運行時（Libs/Bins），文件系統(tǒng)，處理器架構甚至云平臺。應用程序開發(fā)人員還可以直接調(diào)用KubernetesAPI（應用程序編程接口），并加強應用程序的集成，以提高性能和可管理性。自愈軟件將不時遭受奇怪的故障，導致功能癱瘓和系統(tǒng)失敗。然而，這些陷阱將使您成為可靠性困境的犧牲品。但不要害怕：Kubernetes能夠定期監(jiān)控您的完整基礎設施（容器，節(jié)點，Pod，網(wǎng)絡，硬件，操作系統(tǒng)）。如果軟件錯誤導致系統(tǒng)的某些部分崩潰，Kubernetes將立即重啟應用程序。如果錯誤是由于硬件故障引起的，Kubernetes將檢測到它并將應用程序分布在多個pod中。在這兩種情況下，應用程序停機時間都減少到最低限度。云服務因為Kubernetes很受歡迎，用戶不需要自己處理內(nèi)部實現(xiàn)，也不需要在硬件上花錢。事實上，用戶可以通過注冊托管的Kubernetes解決方案來外包流程：PaaS（平臺即服務）或IaaS（基礎架構即服務）。用戶的角色是專注于通過用戶的應用提供最佳體驗，將負載平衡和云服務留給Kubernetes。綜上所述，容器管理和編排技術建議選擇Kubernetes，根據(jù)開源社區(qū)版本迭代計劃，融合業(yè)內(nèi)實踐，推薦版本為Kubernetes1.16及以上穩(wěn)定版本。容器平臺提供應用可視化編排部署的相關管理功能，包括拓撲可視化、組件可視化、配置可視化等核心功能。在此基礎之上，容器平臺還提供了F5、數(shù)據(jù)庫、DNS、軟件負載均衡等常見平臺組件及服務的封裝功能，實現(xiàn)組件的配置管理、可視化編排支持等功能。容器平臺支持的編排功能如下:應用模板管理與認證:應用模板管理功能支持應用模板新建、刪除、修改等操作。同時容器平臺提供豐富的應用模板管理能力，比如批量上傳應用模板、添加/修改模板變量、展示和修改應用模板描述信息、展示模板與相關應用的關聯(lián)情況、提供從模板部署應用的向?qū)?、支持模板分類和搜索。模板功能還支持驗證公有/私有模板，并且支持模板權限配置，設定訪問權限。應用編排管理:容器平臺的應用編排管理功能較為豐富。不僅支持與數(shù)據(jù)庫、F5等周邊系統(tǒng)混編，還支持更為完善的應用編排管理能力，比如支持KubernetesYAML編排標準、支持圖形化展示編排、同時編排基礎設施資源、支持編排時指定日志策略/調(diào)度策略、支持圖形化修改和維護編排。應用配置管理:容器平臺可以為應用編排設置應用程序日志、應用端口等配置信息。容器信息查詢:容器平臺支持用戶以應用系統(tǒng)為維度，查看應用中容器名稱、軟件版本、配置信息、所屬應用、所屬宿主機、運行狀態(tài)等信息。同時容器平臺根據(jù)企業(yè)級用戶的需求，展示更多可用信息，包括鏡像層級信息、鏡像改動記錄、容器內(nèi)進程信息、容器網(wǎng)絡信息、容器存儲信息、應用/容器操作審計日志信息、應用可視化拓撲以及編排信息等。容器操作功能:在編排功能下，容器平臺提供了常用的應用容器操作功能，包括啟動、停止、創(chuàng)建、刪除等。并且容器平臺為了方便企業(yè)級用戶的操作，額外提供了更為豐富的容器操作功能，包括從容器內(nèi)下載文件、向容器上傳文件、支持打開容器內(nèi)部Shell控制臺、支持從容器一鍵制作新鏡像、重啟容器、暫停以及恢復容器、在不中斷容器內(nèi)業(yè)務服務的情況下修改容器資源配額。負載均衡展示:容器平臺提供內(nèi)置負載均衡，并能夠展示應用整體負載情況，同時容器平臺可對接F5等外部負載均衡系統(tǒng)或設備，并且支持提供應用級別的負載均衡，應對微服務架構。服務到容器的自動負載分發(fā):容器平臺負載均衡默認采用Linux內(nèi)核中的LVS技術，相對于其他軟件負載性能較高，并且負載均衡可以配置SSL證書，當服務的容器擴展后，負載均衡可以自動發(fā)現(xiàn)后端服務變化并自動適配，負載均衡可提供多種負載策略，可以通過環(huán)境變量進行配置，具備會話保持的功能。版本管理/灰度發(fā)布:針對企業(yè)級發(fā)布應用的場景，容器平臺支持應用版本升級時對各集群進行灰度升級，保證業(yè)務的不間斷運行，同時容器平臺還支持更高級的灰度發(fā)布選項，比如設定并行發(fā)布實例數(shù)、設置發(fā)布失敗后的錯誤處理機制、配置發(fā)布時舊版本實例優(yōu)雅下線策略。

多模式應用編排.1應用容器編排云原生技術平臺管理系統(tǒng)提供了應用可視化編排部署的相關管理功能，包括拓撲可視化、組件可視化、配置可視化等核心功能。在此基礎之上，云原生技術平臺管理系統(tǒng)還提供了F5、數(shù)據(jù)庫、DNS、軟件負載均衡等常見平臺組件及服務的封裝功能，實現(xiàn)組件的配置管理、可視化編排支持等功能。云原生技術平臺管理系統(tǒng)支持的編排功能有:應用模板管理與認證:應用模板管理功能支持應用模板新建、刪除、修改等操作。同時云原生技術平臺管理系統(tǒng)提供了更為豐富的應用模板管理能力，比如批量上傳應用模板、添加/修改模板變量、展示和修改應用模板描述信息、展示模板與相關應用的關聯(lián)情況、提供從模板部署應用的向?qū)?、支持模板分類和搜索。模板功能還支持驗證公有/私有模板，并且支持模板權限配置，設定訪問權限。應用編排管理:云原生技術平臺管理系統(tǒng)的應用編排管理功能較為豐富。不僅支持與數(shù)據(jù)庫、F5等周邊系統(tǒng)混編，還支持更為完善的應用編排管理能力，比如支持KubernetesYAML編排標準、支持圖形化展示編排、同時編排基礎設施資源、支持編排時指定日志策略/調(diào)度策略、支持圖形化修改和維護編排。應用配置管理:云原生技術平臺管理系統(tǒng)可以為應用編排設置應用程序日志、應用端口等配置信息。容器信息查詢:云原生技術平臺管理系統(tǒng)支持用戶以應用系統(tǒng)為維度，查看應用中容器名稱、軟件版本、配置信息、所屬應用、所屬宿主機、運行狀態(tài)等信息。同時云原生技術平臺管理系統(tǒng)根據(jù)企業(yè)級用戶的需求，展示更多可用信息，包括鏡像層級信息、鏡像改動記錄、容器內(nèi)進程信息、容器網(wǎng)絡信息、容器存儲信息、應用/容器操作審計日志信息、應用可視化拓撲以及編排信息等。容器操作功能:在編排功能下，云原生技術平臺管理系統(tǒng)提供了常用的應用容器操作功能，包括啟動、停止、創(chuàng)建、刪除等。并且云原生技術平臺管理系統(tǒng)為了方便企業(yè)級用戶的操作，額外提供了更為豐富的容器操作功能，包括從容器內(nèi)下載文件、向容器上傳文件、支持打開容器內(nèi)部Shell控制臺、支持從容器一鍵制作新鏡像、重啟容器、暫停以及恢復容器、在不中斷容器內(nèi)業(yè)務服務的情況下修改容器資源配額。負載均衡展示:云原生技術平臺管理系統(tǒng)提供內(nèi)置負載均衡，并能夠展示應用整體負載情況，同時云原生技術平臺管理系統(tǒng)可對接F5等外部負載均衡系統(tǒng)或設備，并且支持提供應用級別的負載均衡，應對微服務架構。服務到容器的自動負載分發(fā):云原生技術平臺管理系統(tǒng)負載均衡默認采用Linux內(nèi)核中的LVS技術，相對于其他軟件負載性能較高，并且負載均衡可以配置SSL證書，當服務的容器擴展后，負載均衡可以自動發(fā)現(xiàn)后端服務變化并自動適配，負載均衡可提供多種負載策略，可以通過環(huán)境變量進行配置，具備會話保持的功能。版本管理/灰度發(fā)布:針對企業(yè)級發(fā)布應用的場景，云原生技術平臺管理系統(tǒng)支持應用版本升級時對各集群進行灰度升級，保證業(yè)務的不間斷運行，同事云原生技術平臺管理系統(tǒng)還支持更高級的灰度發(fā)布選項，比如設定并行發(fā)布實例數(shù)、設置發(fā)布失敗后的錯誤處理機制、配置發(fā)布時舊版本實例優(yōu)雅下線策略。.2應用混合編排現(xiàn)有的應用開發(fā)流程中，為了提高研發(fā)效率，相關部門會預先配置好一部分數(shù)據(jù)庫服務用于研發(fā)測試。根據(jù)研發(fā)業(yè)務的不同，數(shù)據(jù)庫服務包括:Oracle服務，MSSQL服務以及DB2服務。隨著業(yè)務量的增長，相應的研發(fā)生產(chǎn)線也呈多樣化發(fā)展，向研發(fā)測試提供數(shù)據(jù)庫服務部門的壓力也越來越大?，F(xiàn)有的情況下，研發(fā)測試面臨著申請數(shù)據(jù)庫服務流程周期長，服務部門向不同研發(fā)生產(chǎn)線交付相應的數(shù)據(jù)庫服務的壓力也越來越大。云原生技術平臺管理系統(tǒng)的數(shù)據(jù)庫混合編排借鑒了公有云的數(shù)據(jù)庫編排服務，經(jīng)過了大規(guī)模使用的驗證。云原生技術平臺管理系統(tǒng)的數(shù)據(jù)庫混合編排主要有以下幾點特征:服務注冊:當服務部門配置好相關數(shù)據(jù)庫服務后，可通過WEB頁面向服務注冊模塊注冊該數(shù)據(jù)庫服務，供研發(fā)測試部門使用?？赏ㄟ^選擇不同的數(shù)據(jù)庫服務類型來注冊數(shù)據(jù)庫服務，包括:Oracle數(shù)據(jù)庫服務、MSSQL數(shù)據(jù)庫服務、DB2數(shù)據(jù)庫服務等。服務管理:可通過WEB頁面對已注冊的數(shù)據(jù)庫服務進行管理，管理操作包括:增加新數(shù)據(jù)庫服務，刪除已有數(shù)據(jù)庫服務，更新已有數(shù)據(jù)庫服務配置，刪除數(shù)據(jù)庫服務。服務綁定:可通過應用的頁面將數(shù)據(jù)庫服務綁定到應用容器內(nèi)，服務綁定將數(shù)據(jù)庫的信息設置到應用容器的環(huán)境變量內(nèi)，供應用容器取用。服務發(fā)現(xiàn):該方案依托客戶端服務發(fā)現(xiàn)的場景，“數(shù)據(jù)庫服務發(fā)現(xiàn)應用”提供了一系列RESTAPI供客戶端調(diào)用，并可將數(shù)據(jù)庫配置信息以結(jié)構化數(shù)據(jù)的形式返回供客戶端使用。云原生技術平臺管理系統(tǒng)的混合編排方案架構圖如下所示:圖-混合編排架構圖云原生技術平臺管理系統(tǒng)數(shù)據(jù)庫混合編排服務將云原生技術平臺管理系統(tǒng)與數(shù)據(jù)庫資源池深度集成?！皵?shù)據(jù)庫服務編排應用”以插件的形式部署在云原生技術平臺管理系統(tǒng)平臺上。該應用將提供對接云原生技術平臺管理系統(tǒng)用戶權限控制模塊的功能。通過對API進行授權訪問，可控制特定用戶訪問特定的數(shù)據(jù)庫服務資源?！皵?shù)據(jù)庫服務發(fā)現(xiàn)應用”將對接云原生技術平臺管理系統(tǒng)的用戶權限控制，避免二次配置用戶權限。負載均衡云原生技術平臺管理系統(tǒng)支持兩種負載均衡方案:7層負載均衡和4層負載均衡，需要在不同的應用場景下選用不同的負載均衡方案。云原生技術平臺管理系統(tǒng)負載均衡方案整體架構圖如下所示:圖-負載均衡.1內(nèi)置4層負載均衡解決方案云原生技術平臺管理系統(tǒng)的4層負載均衡IPVS解決方案主要用于彈性伸縮的場景，通過端口轉(zhuǎn)發(fā)將請求轉(zhuǎn)發(fā)至多個容器內(nèi)，應用場景如下圖所示:針對該場景，云原生技術平臺管理系統(tǒng)內(nèi)置了一套IPVS負載均衡的解決方案。LVS是一個高性能的負載均衡，并能夠支持自動的服務發(fā)現(xiàn)功能。云原生技術平臺管理系統(tǒng)的4層負載均衡解決方案架構圖如下所示:使用IPVS作為負載均衡解決方案的優(yōu)勢:Docker內(nèi)置機制基于內(nèi)核LVS技術，高效轉(zhuǎn)發(fā)高性能請求轉(zhuǎn)發(fā)高可用架構(如果云原生技術平臺管理系統(tǒng)有多個節(jié)點)自動適配后端應用變化自動檢測后端狀態(tài)，并實現(xiàn)容錯熱更新，無中斷的配置更新.2內(nèi)置7層負載均衡解決方案云原生技術平臺管理系統(tǒng)內(nèi)置的IPVS能力之上提供了一套7層負載均衡組件如Nginx、HAProxy和Traefik等，該組件通過自動獲得集群中服務的域名配置(目前通過服務label實現(xiàn))，自動更新負載均衡轉(zhuǎn)發(fā)策略。下圖表示以Traefik為例的解決方案整體架構圖:使用七層負載均衡解決方案的優(yōu)勢:友好的圖形界面管理能力支持用戶/租戶級別的LB，適應微服務場景高性能請求轉(zhuǎn)發(fā)高可用架構(如果云原生技術平臺管理系統(tǒng)有多個控制器)自動適配后端應用變化優(yōu)雅的中斷HTTP連接自動后端健康檢查，并實現(xiàn)容錯熱更新，無中斷的配置更新提供簡單的性能監(jiān)控報表HTTP2支持Websocket支持HTTPS/SSL支持存儲管理.1數(shù)據(jù)持久化容器運行期間產(chǎn)生的數(shù)據(jù)是不會在寫鏡像里面的，重新用此鏡像啟動新的容器就會初始化鏡像，會加一個全新的讀寫入層來保存數(shù)據(jù)。如果想做到數(shù)據(jù)持久化，就必須尋求其他解決方案來保存數(shù)據(jù)。云原生技術平臺管理系統(tǒng)通過存儲卷(volume)用于持久化存儲Docker容器的數(shù)據(jù)，存儲卷分為本地卷和遠程卷和快照，其中本地卷是對本機磁盤的映射，遠程卷和和快照需要在集成中心集成第三方存儲服務(比如ScaleIO)才可以使用:本地存儲卷:本地卷沒有容量或讀寫性能的限制(上限由磁盤的規(guī)格和性能決定)。本地卷亦不可創(chuàng)建快照。一般地，在創(chuàng)建應用時，可以通ComposeYAML指定。遠程存儲卷:遠程卷的創(chuàng)建以及使用過程同本地卷類似。云原生技術平臺管理系統(tǒng)遠程存儲卷包括NFS存儲卷和其他遠程存儲卷。NFS遠程卷的創(chuàng)建需要增加設備、讀寫權限、設備目錄的信息。其他遠程存儲卷主要包括支持ScaleIO等存儲軟件的REXRAY驅(qū)動存儲卷，以及VMDK存儲卷。.2數(shù)據(jù)持久化保護與恢復云原生技術平臺管理系統(tǒng)通過對存儲卷創(chuàng)建快照，來保護數(shù)據(jù)。以ScaleIO為例，查看ScaleIO詳情，可以看到云原生技術平臺管理系統(tǒng)提供的創(chuàng)建快照按鈕:點擊創(chuàng)建快照，填入快照名稱，點擊創(chuàng)建快照。云原生技術平臺管理系統(tǒng)提供了UI界面供恢復快照用，進入快照詳情頁面，點擊恢復即可:網(wǎng)絡方案云原生技術平臺管理系統(tǒng)完全支持Kubernetes多種網(wǎng)絡方案。只要符合CNM模型的網(wǎng)絡插件都可以被云原生技術平臺管理系統(tǒng)接入用于管理容器間網(wǎng)絡通信。云原生技術平臺管理系統(tǒng)目前產(chǎn)品內(nèi)置支持的網(wǎng)絡技術包括:Flannel、Calico，同時可以通過插件支持Macvlan網(wǎng)絡。下圖為基于云原生技術平臺管理系統(tǒng)的網(wǎng)絡方案整體架構圖:.1CalicoCalico是一個純?nèi)龑拥臄?shù)據(jù)中心網(wǎng)絡方案(不需要Overlay)，并且與OpenStack、Kubernetes、AWS、GCE等IaaS和容器平臺都有良好的集成。Calico在每一個計算節(jié)點利用LinuxKernel實現(xiàn)了一個高效的vRouter來負責數(shù)據(jù)轉(zhuǎn)發(fā)，而每個vRouter通過BGP協(xié)議負責把自己上運行的workload的路由信息像整個Calico網(wǎng)絡內(nèi)傳播——小規(guī)模部署可以直接互聯(lián)，大規(guī)模下可通過指定的BGProutereflector來完成。這樣保證最終所有的workload之間的數(shù)據(jù)流量都是通過IP路由的方式完成互聯(lián)的。Calico節(jié)點組網(wǎng)可以直接利用數(shù)據(jù)中心的網(wǎng)絡結(jié)構(無論是L2或者L3)，不需要額外的NAT，隧道或者OverlayNetwork。此外，Calico基于iptables還提供了豐富而靈活的網(wǎng)絡Policy，保證通過各個節(jié)點上的ACLs來提供Workload的多租戶隔離、安全組以及其他可達性限制等功能。Calico主要由Felix、etcd、BGPclient以及BGPRouteReflector組成：Felix，CalicoAgent，跑在每臺需要運行Workload的節(jié)點上，主要負責配置路由及ACLs等信息來確保Endpoint的連通狀態(tài);etcd，分布式鍵值存儲，主要負責網(wǎng)絡元數(shù)據(jù)一致性，確保Calico網(wǎng)絡狀態(tài)的準確性;BGPClient(BIRD),主要負責把Felix寫入Kernel的路由信息分發(fā)到當前Calico網(wǎng)絡，確保Workload間的通信的有效性;BGPRouteReflector(BIRD)，大規(guī)模部署時使用，摒棄所有節(jié)點互聯(lián)的mesh模式，通過一個或者多個BGPRouteReflector來完成集中式的路由分發(fā)。.2FlannelFlannel通過給每臺宿主機分配一個子網(wǎng)的方式為容器提供虛擬網(wǎng)絡，它基于LinuxTUN/TAP，使用UDP封裝IP包來創(chuàng)建overlay網(wǎng)絡，并借助etcd維護網(wǎng)絡的分配情況?？刂破矫嫔蟞ost本地的flanneld負責從遠端的ETCD集群同步本地和其它host上的subnet信息，并為POD分配IP地址。數(shù)據(jù)平面flannel通過Backend(比如UDP封裝)來實現(xiàn)L3Overlay，既可以選擇一般的TUN設備又可以選擇VxLAN設備。除了UDP，F(xiàn)lannel還支持很多其他的Backend:udp:使用用戶態(tài)udp封裝，默認使用8285端口。由于是在用戶態(tài)封裝和解包，性能上有較大的損失;vxlan:vxlan封裝，需要配置VNI，Port(默認8472)和GBP;host-gw:直接路由的方式，將容器網(wǎng)絡的路由信息直接更新到主機的路由表中，僅適用于二層直接可達的網(wǎng)絡。彈性伸縮.1彈性伸縮策略簡介彈性伸縮(AutoScaling)是根據(jù)不同的業(yè)務需求與策略，自動調(diào)整應用的彈性計算資源，最終達到優(yōu)化資源組合的服務能力。通過自動伸縮和手動伸縮這兩種工作模式，應用便能在無運維人員介入的情況下實現(xiàn)自動調(diào)整計算資源，當訪問量上漲時增加計算能力，而當訪問量下降時減小計算能力，既保障了系統(tǒng)的穩(wěn)定性與高可用性，又節(jié)約了計算資源成本。彈性伸縮在業(yè)界有兩個方向，一個是垂直化的擴展(Scaleup)，一個水平化的擴展(Scaleout)。從業(yè)務發(fā)展的角度來看應該是水平擴展的能力，這要求業(yè)務都是無狀態(tài)的，通過負載均衡技術將訪問請求分配到集群每一臺機器上，不管是增加還是減少機器，業(yè)務的連續(xù)性都不應受到影響。.2云原生技術平臺管理系統(tǒng)的彈性伸縮策略云原生技術平臺管理系統(tǒng)同時支持自動伸縮和手動伸縮兩種策略。自動伸縮方面，對于不同的應用，云原生技術平臺管理系統(tǒng)通過平臺內(nèi)置的彈性伸縮引擎來靈活地提供彈性伸縮功能。目前，云原生技術平臺管理系統(tǒng)的彈性伸縮策略支持從內(nèi)存、CPU負載、線程池剩余線程數(shù)、會話數(shù)等維度來進行彈性擴縮容。自動伸縮的架構如下圖所示:相比較其他平臺的彈性伸縮功能，云原生技術平臺管理系統(tǒng)平臺的彈性伸縮具備如下特點:?容器化部署，最高程度提高部署的靈活度。彈性伸縮作為云原生技術平臺管理系統(tǒng)的一個模塊，通過應用模板的方式容器化部署，可以做到針對每個服務提供不同的彈性伸縮策略而不會相互影響。?伸縮策略靈活且可定制化。彈性伸縮和應用緊密耦合，根據(jù)不同應用的特點和表現(xiàn)需要設定不同的彈性策略，云原生技術平臺管理系統(tǒng)的彈性伸縮內(nèi)置根據(jù)容器資源(CPU和內(nèi)存使用情況)和中間件資源(Tomcat的線程數(shù)和會話數(shù))，除此之外，用戶可靈活設置應用特定的彈性策略如MySQL數(shù)據(jù)庫并發(fā)量、應用的網(wǎng)絡連接數(shù)等。?開放接口，方便二次開發(fā)。云原生技術平臺管理系統(tǒng)完全兼容Docker原生API，同時還提供平臺相應的二次開發(fā)API，云原生技術平臺管理系統(tǒng)自動伸縮模塊也是根據(jù)云原生技術平臺管理系統(tǒng)的API進行開發(fā)而成。如用戶需要根據(jù)平臺進行深度二次定制開發(fā)，云原生技術平臺管理系統(tǒng)彈性伸縮模塊可以很好支持和對接。?伸縮資源廣泛，粒度可調(diào)。云原生技術平臺管理系統(tǒng)應用平臺提供南向北向的集成，除容器管理功能外，云原生技術平臺管理系統(tǒng)可以很好集成Vmware和Openstack實現(xiàn)對虛機的動態(tài)創(chuàng)建和管理。除自動伸縮功能，平臺也支持方便的手動伸縮功能。手動伸縮在應用測試、不方便設定容器閾值和容器縮容等場景下具有較強的需求，通過在云原生技術平臺管理系統(tǒng)應用的服務頁面選擇服務擴展和縮小后的容器數(shù)量，便可快速實現(xiàn)手動的容器彈性擴縮。應用管理功能.1

應用生命周期管理圖形化界面針對應用的整個生命周期進行管理，提供多種部署方式一鍵部署、通過鏡像部署、YAML編排、基礎鏡像部署四種方式，同時提供包括應用的啟動、停止、下線、重新啟動、版本更新等功能及可手動調(diào)整CPU、內(nèi)存、實、應用制作鏡像、上傳文件、下載文件、重命名、更新應用鏡像等操作。實現(xiàn)功能如下:部署方式提供多種部署方式一鍵部署、通過鏡像部署、YAML編排、基礎鏡像部署四種方式圖-部署方式應用基礎功能同時提供包括應用的啟動、停止、下線、重新啟動基礎維護功能。圖-應用基礎功能版本更新提供應用鏡像版本更新功能，可進行新版本更新亦可進行歷史版本回滾。圖-應用鏡像版本更新彈性伸縮平臺自帶彈性伸縮功能，提供CPU、內(nèi)存等閾值規(guī)則設置，通過閾值進行自動擴展或收縮實例，已擴展實例通過標簽自動接入平臺負載均衡能力，支持通過拓撲關系展示當前應用于其他應用、服務等資源的關系。圖-彈性伸縮配置圖-應用拓撲.2應用資源資源平臺提供可視化界面管理應用資源管理，針對應用初始化發(fā)布提供缺省資源配置，對已經(jīng)發(fā)布運行的應用可進行資源調(diào)整包括應用實例數(shù)、內(nèi)存、磁盤、路由、服務、容器發(fā)布、容器調(diào)度策略等信息。實現(xiàn)效果如下:圖-應用鏡像版本更新圖-應用負載路由配置圖-自動配置路由信息圖-手動配置負載路由.3應用狀態(tài)查詢平臺支持簡單方式，供租戶查詢其發(fā)布的所有應用及每個應用的運行狀態(tài)，包括應用運行狀態(tài)、實例數(shù)量、資源使用情況、服務使用情況等?？刹樵儜冒l(fā)布日志、運行日志以及應用中定義的各種日志輸出。平臺管理員可以通過統(tǒng)一的web界面查看所有應用上述的運行狀態(tài)及日志。實現(xiàn)效果如下:圖-運行應用信息圖-停止應用信息圖-日志信息圖-資源使用信息.4配置文件平臺提供配置參數(shù)管理基于配置文件實現(xiàn)對應用配置信息的集中管理，提供基礎配置文件與加密配置文件兩種方式。圖-創(chuàng)建配置-命令圖-創(chuàng)建配置-上傳文件圖-加密配置文件.5鏡像工廠平臺提供鏡像工廠，鏡像工廠可管理設置過個鏡像倉庫，集成的docker鏡像(dockerregistry)服務，提供便捷公有、私有鏡像的自由切換功能，提供日常鏡像空間維護功能，空間可細化授權為個人及團隊管理，針對不同的鏡像空間可以通過統(tǒng)籌進行控制空間可存放鏡像的數(shù)量，支持鏡像同步功能支持根據(jù)規(guī)則實現(xiàn)鏡像遠程復制，也支持鏡像掃描服務。且提供標準運行環(huán)境支持Java、PHP、Node.js、Ruby、Go、Python等語言，可定制提供更多語言類型及版本?？赏ㄟ^提供鏡像模板以及自定義鏡像方式支持更多的應用類型和語言實現(xiàn)效果如下:圖-空間鏡像詳情及創(chuàng)建空間圖-鏡像空間設置圖-空間授權圖-鏡像復制圖-基礎鏡像.6部署管理平臺提供統(tǒng)一鏡像標準交付部署，對于日常的迭代變更上線，系統(tǒng)以鏡像為管理顆粒度，所有進行統(tǒng)一通過鏡像工廠進行管理，實現(xiàn)對基礎部署、部署策略、容器管理等功能實現(xiàn)效果如下:圖-應用部署圖-容器管理圖-灰度部署.7應用商店模塊商店模塊中心包含模塊商店與模塊管理兩個部分，模塊商店由兩個部分構成內(nèi)置模塊與定制服務模塊兩個部分，內(nèi)置模塊即是自主開發(fā)通用模塊，定制服務模塊根據(jù)客戶實際需求定制的服務應用。模塊按照類型劃分，每個模塊提供對應的概述、截圖描述、資源說明、安裝說明及技術支持內(nèi)容。選擇需要進行安裝的模塊進行安裝，針對已經(jīng)安裝的模塊提供管理功能，設置模塊的啟動與卸載。實現(xiàn)效果如下:圖-模塊管理圖-模塊管理-安裝圖-模塊管理-安裝圖-模塊管理-模塊截圖說明模塊管理模塊管理是針對已經(jīng)安裝的模塊進行管理，同時可以提供手動安裝模塊及構建新模塊，手動安裝模塊是通過鏡像工程或互聯(lián)網(wǎng)鏡像安裝。構建新模塊是基于平臺提供的開發(fā)者平臺結(jié)合我們開發(fā)的API進行應用的開發(fā)，開發(fā)完成后通過鏡像的方式存儲到鏡像工程，然后進行手動安裝，已經(jīng)安裝的模塊可以進行更新與卸載。圖-模塊管理容器組提供容器組下容器的運行狀態(tài)，包含容器名稱、應用、宿主機、鏡像、運行中、狀態(tài)、重啟次數(shù)、創(chuàng)建時間的信息查詢及調(diào)試訪問與刪除功能。圖-容器組信息.8基于模板部署平臺內(nèi)置種類豐富的應用模板，模板管理頁面提供名稱及應用分類組合定位檢索功能，用戶可通過管理模塊進行模板功能的創(chuàng)建、分類、修改、刪除等日常維護，不同應用之間在部署方面也有一定的相似性，通過模板可以進行快速的構建部署任務。圖-新增模板圖-模板詳情服務管理.1服務管理提供可視化界面管理服務，提供服務名稱、應用、鏡像、狀態(tài)、創(chuàng)建時間等基礎信息查詢及日常維護快速入口，可創(chuàng)建和綁定新服務，并對已創(chuàng)建的服務進行監(jiān)控和生命周期管理。圖-服務查詢及日常維護.2服務發(fā)現(xiàn)平臺提供基于etcd的原生服務發(fā)現(xiàn)，同時也支持通過dns及微服務erueka的服務發(fā)現(xiàn)機制。.3數(shù)據(jù)庫服務平臺內(nèi)置支持Mysql、PostgreSQL、MongoDB、Redis、Memcached、Casandra服務組件作為基礎服務模板，同時亦可提供消息隊列、大數(shù)據(jù)服務、容器服務等組件，支持對數(shù)據(jù)庫服務的搜索、啟動、停止、重啟、刪除等操作，可以對數(shù)據(jù)庫的基本信息、實例信息、配置信息、日志信息進行管理，可以監(jiān)控cpu、內(nèi)存、磁盤、下行速度等信息，并提供備份管理功能。圖-數(shù)據(jù)庫模板圖-大數(shù)據(jù)模板圖-日志信息圖-操作日志圖-CPU、內(nèi)存.4存儲平臺提供存儲卷管理，提供存儲卷基礎維護功能，新增、刪除及YAML的高級安裝編排功能。圖-存儲3.1.2容器平臺可擴展性集群規(guī)模擴展能力容器平臺軟件底層遵循Kubernetes核心架構設計，從集群節(jié)點和容器支撐的規(guī)模上，核心因素取決于主機性能。集群每增加一個節(jié)點，kube-controller計算開銷分別增加0.1CPU/80MB內(nèi)存；而創(chuàng)建namespace則是kb級內(nèi)存開銷，幾乎可以忽視其資源占用。集群內(nèi)置的用戶中心采用OpenLDAP實現(xiàn)，OpenLDAP支持集群技術，可通過持續(xù)的橫向節(jié)點擴展提升用戶表規(guī)模，支持近乎無限的用戶創(chuàng)建。用戶中心亦支持用戶自行選擇AD等不同第三方實現(xiàn)標準化接入。隨著集群訪問用戶的增加，平臺控制器單個前端實例默認狀態(tài)下支持150左右用戶并發(fā)訪問達到預設資源峰值，當用戶并發(fā)大于此數(shù)值時，可通過增加前端服務CPU/內(nèi)存提供更高的并發(fā)支撐能力，也可以通過增加前端控制器服務的容器實例數(shù)量實現(xiàn)橫向的性能擴展。插件擴展能力由于云原生社區(qū)正處于一個快速發(fā)展豐富的擴張階段，而在整個社區(qū)范圍中，Kubernetes僅承載其中很少一部分計算編排的角色，在真實的使用場景中，用戶所使用的功能大量來自于其他社區(qū)圍繞Kubernetes擴展的能力，典型例如Ingress，CoreDNS等都不是Kubernetes的自身能力卻又不可或缺。因此，平臺從設計架構上，采取插件的模式實現(xiàn)系統(tǒng)在架構保持穩(wěn)定的基礎上提供對新功能組件的擴充。當前集群所使用Ingress、CoreDNS、HPA、Istio等均屬于在這一體系下持續(xù)添加的功能。插件結(jié)合平臺API/SDK集成開發(fā)，以一組獨立的鏡像打包模塊后發(fā)布到平臺，通過插件管理中心進行安裝。安裝后的插件根據(jù)規(guī)范一般是在獨立的namespace中運行的一系列容器，其生命周期由平臺進行統(tǒng)一管理。OpenAPI接口擴展能力容器平臺基于OpenAPI標準開放接口，兼容使用Kubernetes原生API調(diào)用。進行二次開發(fā)時配置接口地址、請求參數(shù)和響應參數(shù)與使用Kubernetes官方API完全一致。通過接口創(chuàng)建的對象和通過平臺頁面操作創(chuàng)建的對象保持一致。3.1.3安全合規(guī)性對接統(tǒng)一身份認證容器平臺作為IT信息化系統(tǒng)，在安全和權限管理上也遵從統(tǒng)一的身份認證和管理方式。采用統(tǒng)一身份系統(tǒng)來實現(xiàn)和企業(yè)內(nèi)部的認證系統(tǒng)的對接，從而獲取用戶身份驗證信息，及獲取和更新配置信息。統(tǒng)一身份認證系統(tǒng)可以對接多種身份管理系統(tǒng)，比如LDAP,CA以及還是現(xiàn)有AD域安全系統(tǒng)。整個身份對接系統(tǒng)的內(nèi)部結(jié)構如下圖:圖-統(tǒng)一身份認證如上圖所示，統(tǒng)一身份認證系統(tǒng)通過一套安全和認證管理的模塊，可以完成下述功能:?身份認證中心:存儲企業(yè)用戶目錄，完成對用戶身份、角色等信息的統(tǒng)一管理。?授權和訪問管理系統(tǒng):用戶的授權、角色分配;訪問策略的定制和管理;用戶授權信息的自動同步;用戶訪問的實時監(jiān)控、安全審計。?身份認證服務:身份認證前置為應用系統(tǒng)提供安全認證服務接口，中轉(zhuǎn)認證和訪問請求;身份認證服務完成對用戶身份的認證和角色的轉(zhuǎn)換。?訪問控制服務:應用系統(tǒng)插件從應用系統(tǒng)獲取單點登錄所需的用戶信息;用戶單點登錄過程中，生成訪問業(yè)務系統(tǒng)的請求，對敏感信息加密簽名。?AD域管控中心及數(shù)字證書受理系統(tǒng):用戶身份認證和單點登錄過程中所需證書的簽發(fā);用戶身份認證憑證(USB智能密鑰)的制作。與現(xiàn)有監(jiān)控體系對接當前，在銀行為所提供的各類金融服務中，有很大的比例需要依托IT系統(tǒng)實現(xiàn)，因此銀行數(shù)據(jù)中心的穩(wěn)定可靠運行，是銀行能否為提供優(yōu)質(zhì)服務的基礎保障。對于新增的容器平臺，需要納入到數(shù)據(jù)中心的整個集中監(jiān)控體系，對各類設備/應用的運行參數(shù)和狀態(tài)進行監(jiān)控和管理；對設備/應用的故障狀態(tài)進行報警輸出。目前，銀行數(shù)據(jù)中心已經(jīng)實現(xiàn)了系統(tǒng)監(jiān)控、應用監(jiān)控、日志監(jiān)控和交易監(jiān)控，同時，監(jiān)控系統(tǒng)內(nèi)置HUB，支持收集第三方監(jiān)控。銀行監(jiān)控系統(tǒng)與CMDB實現(xiàn)對接，可通過固定IP獲取資產(chǎn)系統(tǒng)的映射關系，實現(xiàn)集中告警。圖-監(jiān)控體系對接與集中日志系統(tǒng)對接目前，銀行不少應用系統(tǒng)的日志單獨存放，并通過ITM進行日志監(jiān)控，但單一系統(tǒng)的日志信息量有限，出現(xiàn)故障、告警時，往往需要查詢多個關聯(lián)應用系統(tǒng)的日志信息才能準確定位，故障定位難，效率低。為此，為了更好的進行日志收集、日志存儲、日志分析及管理，銀行數(shù)據(jù)中心建設統(tǒng)一的日志中心，中心化的日志處理方案有效地解決了在完整生命周期內(nèi)對日志的消費需求。容器平臺除了需將平臺日志上報給集中的日志中心外，容器平臺上運行的容器日志、應用/服務日志也要集中上報的日志中心。圖-日志對接容器平臺與日志中心集成，需滿足如下需求：?針對動態(tài)增減的容器實例，保證日志收集對象的完整?涵蓋平臺日志和應用日志?收集容器的標準輸出日志和內(nèi)部應用的多個文件日志?容器平臺上的應用日志需通過Kafka消息隊列分發(fā)給集中式日志中心?上傳的數(shù)據(jù)應至少包含收集時間、集群、應用、服務、容器等關鍵標識?對接的行內(nèi)日志中心如出現(xiàn)異常，不能出現(xiàn)日志丟失或不完整的情況?支持大規(guī)模的日志上傳，且不丟失數(shù)據(jù)?平臺日志中心需要對具有“容器感知”能力，建立多級索引，支持復雜條件的查詢，支持各種業(yè)務監(jiān)控告警，如基于應用的日志查詢，基于容器的查詢等。與堡壘機對接圖-堡壘機對接為了保障網(wǎng)絡和數(shù)據(jù)不受來自外部和內(nèi)部用戶的入侵和破壞，堡壘機綜合了運維管理和安全性的融合，切斷了終端計算機對網(wǎng)絡和服務器資源的直接訪問，而是采用協(xié)議代理的方式，接管了終端計算機對網(wǎng)絡和服務器的訪問，從而具備如下特點：?運維人員通過堡壘機登錄系統(tǒng)，所有操作行為被記錄和審批；?堡壘機保全了全部的生產(chǎn)用戶信息；?應用系統(tǒng)之前相互隔離，運維人員分別登錄自己有權訪問的系統(tǒng)；由于容器平臺的應用集中管理，帶來用戶的集中和潛在的操作風險，為了強化容器平臺的接入安全，要求各用戶接入容器平臺進行應用管理時，必須經(jīng)由堡壘機進行安全接入控制。另一方面，容器平臺也擁有用戶管理及權限控制功能，為便于用戶管理及權限控制（需支持不同的角色權限，如高級用戶具有高權限，普通用戶只具有只讀或查看權限），以及強化用戶單點登錄體驗，容器平臺經(jīng)由服務流程平臺中轉(zhuǎn)，實現(xiàn)用戶信息、權限信息的同步。?容器平臺對接到堡壘機中，其中堡壘機中保存用戶信息，容器平臺中保留資源信息，授權信息。堡壘機的用戶按照組織架構分組管理，在容器平臺中建立這些組對接的用戶。?用戶在日常維護時，使用容器平臺的低權用戶。用戶先登錄到堡壘機，堡壘機根據(jù)用戶的映射關系，使用該用戶對應的組用戶登錄容器平臺。?用戶在變更時，使用容器平臺的高權用戶。用戶在服務流程平臺提交申請，申請獲批后，登錄到堡壘機，堡壘機根據(jù)用戶的映射關系，使用該用戶對應的組的高權登錄容器平臺。?容器平臺提供項目注冊以及配額信息的管理，管理員控制項目數(shù)量以及各個項目的資源上限。?容器平臺可以維護用戶的注冊添加，對于本地賬號，支持設置強制的密碼強度要求。?容器平臺用戶的登錄，支持本地賬戶，LDAP賬戶以及SSO對接賬戶的身份驗證，對于成功登錄的用戶，發(fā)放token用于后續(xù)的身份驗證。對于連續(xù)多次登陸失敗的賬號，會進行短時間封禁；對于長時間未修改密碼或者密碼強度不夠的賬號，會根據(jù)配置，推薦或強制其修改密碼。?容器平臺的用戶安全模塊在架構還充當APIgateway的職責。用戶在外部調(diào)用容器平臺API的時候，請求都會優(yōu)先轉(zhuǎn)發(fā)給用戶安全管理組件以便驗證Token，確認用戶身份和角色信息，并根據(jù)用戶訪問的RestfulAPI的方法和路徑解析當前用戶是否有相應權限，只有有權限的請求會被轉(zhuǎn)發(fā)給內(nèi)部組件處理。3.2統(tǒng)一知識庫在企業(yè)內(nèi)部，對知識并沒有一個明確的、清晰的定義。企業(yè)一經(jīng)創(chuàng)建，總是會源源不斷建設和產(chǎn)生實物資源，這些實物資源的自然利用是企業(yè)應用知識的最初級形式。在應用實物資源的過程中，有些資源可以被改造加工，進而提升了資源的共享化和智能化程度，促進了可用性，使得資源具備了知識的特征。知識與資源的關系是相對的，資源與知識之間是相互轉(zhuǎn)化的。對特定層次來說，高層次的對象就是知識，低層次的對象就是資源。因此，對企業(yè)而言，知識和資源是同一種對象，只不過是層次高低不同罷了。知識工程建設和資源建設之間沒有絕對界限，在工程實踐中也不需要明確這個界限。從實用的角度講，凡是對工作有幫助的資源都是知識。因此，在產(chǎn)品研發(fā)設計中有用的資源，都可作為知識工程的建設范圍。3.2.1建設目標知識應用要實現(xiàn)以下幾方面的建設目標：?實現(xiàn)各類知識的體系化管理與基礎性功能應用；?實現(xiàn)各類知識與應用開發(fā)流程的融合，形成對應用開發(fā)流程的知識化支撐；?實現(xiàn)各類知識與開發(fā)、運維行為的關聯(lián)，形成基于個人形成的個人知識空間；?實現(xiàn)對各類知識應用效果的分析統(tǒng)計；?實現(xiàn)各類知識的多渠道應用；?實現(xiàn)各類知識與工程師工作場景的融合，達到知識“隨需而現(xiàn)”的效果。3.2.2建設方案為了實現(xiàn)上述幾方面的知識應用建設目標，將從兩方面考慮知識應用方案的建設，第一方面是構建知識應用的基礎功能；第二方面是為應用基礎功能構建多種應用途徑。(一)

知識應用的基礎功能(二)

知識應用的多途徑知識應用的途徑有三種，分別是知識的門戶應用、知識的客戶端應用、知識的嵌入業(yè)務系統(tǒng)應用。?知識的門戶應用：通過構建基于瀏覽器的知識門戶系統(tǒng)，實現(xiàn)對各類知識的體系管理與應用，實現(xiàn)各類知識與應用開發(fā)流程的融合等。如：知識搜索、知識地圖、知識面向研發(fā)流程的知識推送、基于檢索頻率的知識推送、個性化定制知識推送等。?知識的客戶端應用：通過客戶端，將各科室中與每個研制任務相關的知識結(jié)構化的組織在一起，結(jié)構化的維度包括：輸入、輸出、流程、質(zhì)量、模板組件、關聯(lián)任務、關聯(lián)知識等。實現(xiàn)以研制任務為主體的知識地圖，以及知識與應用開發(fā)流程的融合。?知識的嵌入容器平臺系統(tǒng)應用：將知識推送到工程師的工作界面，在容器平臺相關界面，嵌入知識鏈接。實現(xiàn)知識與工程師工作場景的融合。3.2.3知識分類容器平臺的知識包括平臺自身相關的內(nèi)容，同時包括與平臺相關的外圍系統(tǒng)的知識，我們?nèi)萜髌脚_知識劃分為九類。每類資源可以根據(jù)需要進一步細化，形成更小的資源類別。如下表所示。3.3統(tǒng)一制品發(fā)布金融IT采用容器技術的一個非常大的驅(qū)動力就是加速應用交付和迭代，尤其是那些直接面向客戶和內(nèi)部流程的IT系統(tǒng)。以Docker為代表的容器技術，為企業(yè)的應用交付平臺和開發(fā)運維聯(lián)動帶來了近乎顛覆性的進步。過去，開發(fā)、測試、運維被分割成獨立的階段，每個階段交付不同的內(nèi)容，開發(fā)人員交付代碼，測試人員交付測試包，運維人員搭建環(huán)境。這樣的模式下，應用交付的速度已經(jīng)無法滿足業(yè)務對速度的需求。Docker的出現(xiàn)，為持續(xù)集成、持續(xù)交付（CI/CD）和開發(fā)運維聯(lián)動帶來了新的思路。如下圖所示，Docker將應用的交付件統(tǒng)一為Docker鏡像（圖中類似樂高積木的模塊），使得開發(fā)人員、測試人員和運維人員的交付內(nèi)容都是標準化容器鏡像，鏡像中已經(jīng)包括了應用對環(huán)境的所有需求，包括操作系統(tǒng)、中間件和應用代碼。他們基于鏡像進行協(xié)作，實現(xiàn)了應用以及其依賴環(huán)境的整體交付，從而極大地提升了效率，也降低了安全隱患。3.3.1方案架構圖-方案架構完整的CI/CD持續(xù)交付解決方案實現(xiàn)CodetoCloud全流程自動化,開發(fā)者只需要關注最核心的代碼層面，接下來的測試、構建、集成、部署等過程，都可以由CI/CD平臺自動化完成。CI/CD平臺通過鏡像進行版本的識別和控制，實現(xiàn)灰度發(fā)布和回滾。開發(fā)運維一體化場景中，非常值得一提的是，當前很多金融行業(yè)的應用是由外包開發(fā)商開發(fā)，金融企業(yè)內(nèi)部IT人員缺乏對應用的控制能力。通過容器化的應用交付模式，開發(fā)商的應用交付形式被標準化了，極大的降低了對開發(fā)商的依賴，提高了運維效率。?全功能產(chǎn)品團隊，開發(fā)／測試／運維在一個組織架構下?應用有持續(xù)迭代要求，版本的每次更新都需要通過開發(fā)、測試、發(fā)布全過程?測試環(huán)境和生產(chǎn)環(huán)境部署主要靠人工操作，環(huán)境的差異性導致部署效率低，大量溝通成本?應用技術棧趨向于多元化，應用配置／運維／管理差異性大，管理成本高。通過CI/CD平臺支撐企業(yè)持續(xù)交付流程，打造跨環(huán)境無差異軟件交付過程，實現(xiàn)軟件資產(chǎn)高效和自動的交付。圖-交付流程3.3.2代碼版本管理代碼版本管理是企業(yè)軟件資產(chǎn)的重要組成部分，維護了企業(yè)開發(fā)過程的代碼成果。甚至，在很多現(xiàn)代化企業(yè)軟件開發(fā)方法論中，團隊的協(xié)作流程也是依據(jù)代碼版本管理規(guī)范展開的，CI/CD需要支持對接企業(yè)常用的代碼版本管理系統(tǒng)，包括Git/SVN/GitHub/GitLab，通過可靈活定制的觸發(fā)策略，實現(xiàn)由代碼驅(qū)動的軟件持續(xù)交付自動化。3.3.3自動化測試通常我們把自動化測試前置到提測前，以此作為是否達到提測要求的快速驗證。因此在定義流水線時,我們應該將自動化測試階段定義的整個流水線的前半部分,下面將以RobotFramework測試框架來說明。有很多理由使得RobotFramework非常受歡迎，比如：?支持簡單易用的表格型語法，使得可以用統(tǒng)一方式創(chuàng)建測試用例?提供可以復用既存的關鍵字的功能?提供HTML的簡單易讀的報表和日志結(jié)果文件?平臺和應用相互獨立?提供簡單的LibaryAPI，可以使用Ptyhon或者java進行實現(xiàn)?提供命令行接口也XML格式的輸出文件，非常容易進行持續(xù)集成?支持Selenium，JavaGUI測試，Telnet，SSH等?支持創(chuàng)建數(shù)據(jù)驅(qū)動的測試用例?變量的內(nèi)建支持，尤其是不同測試環(huán)境下的測試?提供testcase和testsuite級別的setup和teardown?通過平臺的內(nèi)置模塊可以很方便的集成RobotFramework3.3.4打包構建打包構建負責把軟件代碼轉(zhuǎn)變?yōu)閼媒桓都舜a獲取、編譯構建、版本標示三個部分。?CI/CD可以根據(jù)預先定義好的觸發(fā)規(guī)則自動啟動打包構建過程，實現(xiàn)當代碼端進行了指定的變更時，自動從代碼版本管理系統(tǒng)中拉取特定的代碼版本。?代碼拉取以后，CI/CD會根據(jù)代碼中的編譯構建描述文件，即Dockerfile文件，進行鏡像構建。整個構建過程都是可追溯的，實現(xiàn)了軟件資產(chǎn)和代碼資產(chǎn)的關聯(lián)。?鏡像構建完成后，CI/CD根據(jù)預先定義的策略標示鏡像版本，并推送至CI/CD內(nèi)置的企業(yè)鏡像倉庫。同時，編譯打包的過程往往對計算和內(nèi)存資源消耗很大，為了不影響集群已有應用的正常運行，需要把編譯打包環(huán)境和應用運行環(huán)境進行隔離。CI/CD可以指定集群中的某些節(jié)點為專屬構建主機，實現(xiàn)計算任務的合理調(diào)度。3.3.5運行環(huán)境在持續(xù)交付流程中，需要提供一個開發(fā)、測試、生產(chǎn)環(huán)境無差異的應用運行環(huán)境，同時對運行環(huán)境的訪問需要進行權限控制和資源隔離。?在CI/CD之上為不同的環(huán)境創(chuàng)建對應的租戶空間，并把相應的團隊加入到可訪問的租戶空間中，實現(xiàn)不同租戶空間的應用可見性權限控制。?把不同環(huán)境對應的主機添加到租戶空間作為租戶的專享資源，從而實現(xiàn)資源隔離。?CI/CD提供完善的應用部署和運維能力支持，可以讓團隊快速看到應用運行效果。3.3.6持續(xù)部署自動化是持續(xù)交付流程的關鍵，也是提升軟件交付速度和迭代頻率的重要能力。通過在CI/CD上定義軟件持續(xù)部署策略，能夠?qū)崿F(xiàn)應用更新和代碼更新的聯(lián)動，可以極大的減少開發(fā)、測試人員頻繁更新環(huán)境的繁瑣操作，提升工作效率，鼓勵團隊持續(xù)迭代、穩(wěn)步提升。3.3.7制品交付針對金融行業(yè)的應用交付的特點，一部分是企業(yè)開發(fā)團隊自研應用，一部分是由外包開發(fā)商開發(fā)。所以需要針對這兩種交付模式設計交付流程。企業(yè)自研應用交付流程：通過代碼交付的DevOps流程圖-制品交付流程?開發(fā)團隊提交代碼到代碼倉庫?CICD自動進行編譯打包，并提交到鏡像倉庫?CICD根據(jù)發(fā)布規(guī)則，自動將鏡像發(fā)布到預生產(chǎn)環(huán)境中?在預生產(chǎn)環(huán)境中通過驗證以后，進行版本標記，將鏡像發(fā)布到生產(chǎn)環(huán)境的鏡像倉庫。?手動將待發(fā)布的鏡像，發(fā)布到生產(chǎn)環(huán)境。應用開發(fā)商通過制品交付流程：圖-應用開發(fā)商制品交付流程?應用開發(fā)商直接提交代碼到代碼倉庫?應用開發(fā)商提供應用安裝包到代碼倉庫?應用開發(fā)商提供應用安裝包到制品庫，更新代碼倉庫的對應腳本文件?

構建鏡像，自動推送預生產(chǎn)環(huán)境?

標記鏡像，手動更新生產(chǎn)環(huán)境3.3.8合規(guī)性檢查容器平臺及服務具體包括了身份鑒別、訪問控制、安全審計、通信完整性、通信保密性、軟件容錯、資源控制和其他安全設計等。身份鑒別?在身份識別上，實現(xiàn)了與統(tǒng)一身份認證平臺打通，實現(xiàn)唯一識別身份的信息。?可以通過用戶所在的組織、角色、姓名來人工識別該用戶?系統(tǒng)提供了重復身份校驗功能，新錄入的用戶、修改的用戶都會判斷是否存在重復編號。?在系統(tǒng)中，用戶的會話保持在服務端，當用戶登錄成功時創(chuàng)建會話、登出時注銷會話、當用戶15分鐘沒有操作時，會話被自動注銷。?系統(tǒng)設定了允許用戶登錄錯誤的次數(shù)(默認5次)，一旦用戶連續(xù)輸錯密碼導致登錄失敗，用戶賬號將被鎖定30分鐘無法登錄。?用戶登錄時，在日志中會記載登錄用戶賬號、登錄端的ip地址，登錄時間、以遍安全審計時追蹤使用人。?用戶密碼根據(jù)統(tǒng)一認證平臺設定，系統(tǒng)默認不少于8位，規(guī)則由數(shù)字和字母混合構成，帳戶超過3個月不使用會被系統(tǒng)自動鎖定，使用找回密碼功能重新設定密碼。?重新設置的密碼不能與前3次設定的原密碼相同?用戶設定保存在服務端的密碼采用AES對稱加密算法安全加密?通過審查系統(tǒng)設計，并進行差距分析項后能夠達到?為用戶提供專用的登錄控制模塊對登錄用戶進行身份標識和鑒別;?為用戶提供對同一用戶采用兩種或兩種以上組合的鑒別技術實現(xiàn)用戶身份鑒別;?為用戶提供用戶身份標識唯一和鑒別信息復雜度檢查功能，保證應用系統(tǒng)中不存在重復用戶身份標識，身份鑒別信息不易被冒用;?為用戶提供登錄失敗處理功能，可采取結(jié)束會話、限制非法登錄次數(shù)和自動退出等措施;?

為用戶提供啟用身份鑒別、用戶身份標識唯一性檢查、用戶身份鑒別信息復雜度檢查以及登錄失敗處理功能，并根據(jù)安全策略配置相關參數(shù)。進而通過以上安全機制設計我們能夠?qū)崿F(xiàn):?提供專用的登錄控制模塊對登錄用戶進行身份標識和鑒別;?提供用戶身份標識唯一和鑒別信息復雜度檢查功能，保證應用系統(tǒng)中不存在重復用戶身份標識，身份鑒別信息不易被冒用;?提供登錄失敗處理功能，可采取結(jié)束會話、限制非法登錄次數(shù)和自動退出等措施;?啟用身份鑒別、用戶身份標識唯一性檢查、用戶身份鑒別信息復雜度檢查以及登錄失敗處理功能，并根據(jù)安全策略配置相關參數(shù);?對口令長度、復雜度和定期修改進行設定要求，必須使用唯一一套帳號標識。安全審計容器平臺以及服務安全審計設計如下:?系統(tǒng)保存用戶訪問日志，會記錄用戶的任何操作軌跡?日志有格式，會記錄用戶在某時候使用何種方式、使用那個ip地址登錄和注銷，日志會記錄登錄用戶在何時執(zhí)行了什么操作，做到了操作100%覆蓋。?系統(tǒng)所有日志定義了訪問人員、一般用戶無法觸及，只用特定運營人員可以下載、但無法修改，具有不可抵賴性。?系統(tǒng)提供對審計記錄數(shù)據(jù)進行統(tǒng)計、查詢、分析及生成審計報表的功能通過對審核系統(tǒng)設計和審核系統(tǒng)日志設計，并進行差距分析項后能夠達到:?應提供覆蓋到每個用戶的安全審計功能，對應用系統(tǒng)重要安全事件進行審計;?應保證無法單獨中斷審計進程，無法刪除、修改或覆蓋審計記錄;?審計記錄的內(nèi)容至少應包括事件的日期、時間、發(fā)起者信息、類型、描述和結(jié)果等;?應提供對審計記錄數(shù)據(jù)進行統(tǒng)計、查詢、分析及生成審計報表的功能。進而通過以上安全機制設計能夠?qū)崿F(xiàn):?應提供覆蓋到每個用戶的安全審計功能，對應用系統(tǒng)重要安全事件進行審計;?應保證無法刪除、修改或覆蓋審計記錄;?審計記錄的內(nèi)容至少應包括事件日期、時間、發(fā)起者信息、類型、描述和結(jié)果等;?系統(tǒng)具備獨立審計員角色，審計員可按時段導出審計記錄，其他角色不能查看、導出審計記錄。通信完整性容器平臺以及服務通信完整性設計如下:?為保證通訊完整性，數(shù)據(jù)在通訊前，系統(tǒng)對通訊報文、數(shù)據(jù)進行長度記錄當數(shù)據(jù)抵達接受端時，接受端程序會對數(shù)據(jù)進行長度校驗。?端和服務端程序會對必須數(shù)據(jù)字段進行非空校驗。通過對審核系統(tǒng)設計和審核系統(tǒng)安裝部署設計，并進行差距分析項后能夠達到:采用密碼技術保證通信過程中數(shù)據(jù)的完整性進而通過以上安全機制設計能夠?qū)崿F(xiàn):應采用校驗碼技術保證通信過程中數(shù)據(jù)的完整性;通信保密性容器平臺以及服務通信保密性設計如下:?通訊采用HTTPS安全協(xié)議，以保證數(shù)據(jù)在網(wǎng)絡傳輸過程中即使被截取也不會被破解。?敏感數(shù)據(jù)在傳輸前會被首先加密(AES對稱加密)，數(shù)據(jù)到達目的地之后才被解密使用。通過審核系統(tǒng)設計和審核系統(tǒng)安裝部署設計，并進行差距分析項后能夠達到:?在通信雙方建立連接之前，應用系統(tǒng)應利用密碼技術進行會話初始化驗證;?應對通信過程中的整個報文或會話過程進行加密。進而通過以上安全機制設計能夠?qū)崿F(xiàn)：?在通信雙方建立連接之前，應用系統(tǒng)應利用密碼技術進行會話初始化驗證；?應對通信過程中的敏感信息字段進行加密。其他其他安全設計包括了安全手段、提供產(chǎn)品、安全隱患、備份與恢復、部署及備份工作、系統(tǒng)管理建議等，其中系統(tǒng)管理建議又包括了數(shù)據(jù)存儲安全設計、信息使用安全設計、接口調(diào)用安全設計、應用安全措施設計、其他安全措施設計等。通過以上安全機制設計能夠?qū)崿F(xiàn):?系統(tǒng)提供安全手段防止非授權用戶的非法侵入、攻擊?提供的產(chǎn)品(包括中間件)不能包含已被發(fā)現(xiàn)的漏洞?能夠備份和恢復系統(tǒng)及數(shù)據(jù)，備份策略粒度可細化，并提供恢復驗證的測試環(huán)境?提供本地用戶登錄時首次強制修改密碼功能，登錄失敗后的解鎖時間能進行定制?提供的所有系統(tǒng)日志能要求兼容syslog格式，在本地記錄的同時可推送至

syslog日志服務器3.4統(tǒng)一資源申請平臺平臺提供用戶全生命周期的自助服務功能，包括資源自助申請、審批狀態(tài)自助查詢，可視化部署過程自助查看、日常運維自助操作、資源變更自助申請、監(jiān)控信息自助查詢、自助續(xù)租或回收資源等。將用戶自助服務從資源自動化交付延伸到資源的增刪改查全生命周期，讓用戶真正體驗全面的云服務，并減少管理員簡單重復勞動。3.4.1自助資源申請服務租戶通過統(tǒng)一云服務目錄申請各種多樣化的測試資源，包括：?申請標準IaaS服務，至少包括：VM虛擬機、云主機、安全組、彈性IP、負載均衡、對象存儲等；?申請自營PaaS軟件服務，至少包括：Oracle、JDK、Tomcat等；?申請容器應用部署服務，申請表單中選擇容器鏡像、容器規(guī)格、容器編排文件HelmChart，由云管理平臺進行容器應用的自動化部署；?云資源使用過程中遇到問題，可提交事件、問題、變更等工單服務。3.4.2在線審批流程提供云服務申請的在線審批流程?通過服務目錄申請資源時，可租戶和云管理員可遵循不同的審批流程。簡單的云資源服務對管理員可以免審；?租戶可以查看自己的審批進度和詳情；?審批人可以修改申請參數(shù)，可駁回申請到上一級審批者或直接駁回給申請者；?當一個云服務包含跨技術服務團隊的資源時，需進行多級審批，且不同技術團隊可審批、可修改的內(nèi)容根據(jù)其技術專業(yè)而有所不同。3.4.3自動化部署通過服務目錄申請的云資源服務，可由云管平臺自動化部署：?提供可視化的自動化交付過程可，顯示自動化交付進度，顯示自動化交付過程詳細日志；?當一個自動化執(zhí)行過程包含多個云資源時，云管平臺應支持獲取運行態(tài)狀態(tài)，自行決定多個資源執(zhí)行的先后順序和并行度，支持獲取運行態(tài)數(shù)據(jù)進行多個資源間配置傳參；?自動化交付過程出現(xiàn)異常時，云管理平臺應以明顯圖標警示，并通知管理員。支持管理員解決問題后選擇重新執(zhí)行或從失敗處繼續(xù)執(zhí)行；?支持自動化交付完成后將必要的配置信息、訪問信息通過郵箱和短信通知申請者；?云資源自動化交付服務支持靈活的擴展，提供可視化的服務編排、配置服務申請表單、對自動化參數(shù)設置默認值或開放給租戶填寫?？芍С址盏陌l(fā)布、取消、復制服務。3.4.4自助運維提供自助云資源運維功能，租戶可在云資源運維界面對自己所有的資源進行自助運維，包括：?云主機，支持啟停、CPU內(nèi)存磁盤擴容、安裝軟件、堡壘機登錄?彈性IP，支持彈性IP支持綁定、解綁虛擬機?安全組，支持安全策略的添加、刪除?負載均衡，支持增加節(jié)點、刪除節(jié)點、修改輪詢和健康檢查策略?對象存儲，支持創(chuàng)建文件夾、上傳文件、刪除文件?Container容器鏡像，支持更新副本、增加副本、調(diào)整規(guī)格?部分涉及資源變更的運維操作，需要遵循審批流程3.4.5自助監(jiān)控告警提供自助監(jiān)控告警功能，包括：?將租戶自己的IaaS、PaaS資源的監(jiān)控展現(xiàn)給用戶，包括VM、SLB、OSS、容器Pod等；?將租戶自己的IaaS、PaaS資源的告警信息展現(xiàn)給用戶。3.4.6租期回收提供租期回收功能，包括：?云資源租期到期后將停止云資源服務，并放入回收站；?在保留期內(nèi)（如一個月），租戶可申請云管理員將云資源從回收站恢復；?回收站內(nèi)資源過了保留期后，將被卸除（同時從云平臺中刪除）；?即將到期的資源應發(fā)送郵件或站內(nèi)信息給租戶；?租戶可進行資源續(xù)租。3.5容器統(tǒng)一規(guī)范3.5.1容器內(nèi)應用的健康檢測在集群中，可以通過健康檢查探針來檢查容器的就緒或存活狀態(tài)，以在集群層面保證業(yè)務容器的可用性，集群的健康檢查探針的類型：?存活檢查(livenessprobe，存活探針)：使用此探針確認何時重啟容器，當程序處于運行狀態(tài)但無法正常提供對外服務時，可以通過此探針捕獲到這種異常，重啟該狀態(tài)下的容器?就緒檢查（readinessprobe，就緒探針）：使用此探針來確認容器是否已經(jīng)啟動完成，已經(jīng)可以正常對外提供服務，如果Pod處于非就緒狀態(tài)，Pod不會被添加到Service的iptables轉(zhuǎn)發(fā)規(guī)則中，流量不會轉(zhuǎn)發(fā)到未就緒狀態(tài)的Pod；只有當Pod已經(jīng)就緒，相應Pod才會被添加到Service的iptables轉(zhuǎn)發(fā)規(guī)則中3.5.2應用容器的DNS配置可以在Pod級別來設置DNS，主要涉及到兩個配置項“dnsPolicy”和“dnsConfig”，其中：dnsPolicy的類型有:?Default：Pod中DNS的配置會使用宿主機上/etc/resolv.conf中的配置?ClusterFirst（如果Pod沒有明確指定dnsPolicy的配置，默認為此種類型）：Pod中的DNS配置會使用，即Kube-DNS/Core-DNS的配置，對于集群domain前綴會進行解析，非集群domain前綴轉(zhuǎn)發(fā)給Kube-DNSPod所在的宿主機/etc/resolv.conf中配置的nameserver進行解析查詢?ClusterFir