Kubernetes是Google開源的一個(gè)容器編排引擎，它支持自動(dòng)化部署、大規(guī)?？缮炜s、應(yīng)用容器化管理。伴隨著云原生技術(shù)的迅速崛起，如今Kubernetes 事實(shí)上已經(jīng)成為應(yīng)用容器化平臺(tái)的標(biāo)準(zhǔn)，越來越受到企業(yè)的青睞，在生產(chǎn)中也應(yīng)用的也越來越廣泛。
我們的容器平臺(tái)建設(shè)從2016年開始，大致經(jīng)歷了探索預(yù)研、體系建設(shè)和平臺(tái)落地這樣三個(gè)階段。

下面就從Kubernetes的網(wǎng)絡(luò)、存儲(chǔ)、集群管理和監(jiān)控與運(yùn)維幾個(gè)方面來分享下我們?nèi)萜髟破脚_(tái)建設(shè)走過的歷程，希望給大家一些思考和啟發(fā)。
一、 kubernetes網(wǎng)絡(luò)
容器網(wǎng)絡(luò)發(fā)展到現(xiàn)在，已經(jīng)是雙雄會(huì)的格局。雙雄會(huì)其實(shí)指的就是Docker的CNM和Google、CoreOS、Kuberenetes主導(dǎo)的CNI。首先明確一點(diǎn)，CNM和CNI并不是網(wǎng)絡(luò)實(shí)現(xiàn)，他們是網(wǎng)絡(luò)規(guī)范和網(wǎng)絡(luò)體系，從研發(fā)的角度他們就是一堆接口，你底層是用Flannel也好、用Calico也好，他們并不關(guān)心，CNM和CNI關(guān)心的是網(wǎng)絡(luò)管理的問題。
網(wǎng)絡(luò)需求調(diào)研發(fā)現(xiàn)，業(yè)務(wù)部門主要關(guān)注以下幾點(diǎn)：1、容器網(wǎng)絡(luò)與物理網(wǎng)絡(luò)打通2、速度越快越好3、改動(dòng)越少越好4、盡可能少的風(fēng)險(xiǎn)點(diǎn)。
容器的網(wǎng)絡(luò)方案大體可分為協(xié)議棧層級(jí)、穿越形態(tài)、隔離方式這三種形式

協(xié)議棧層級(jí)：二層比較好理解，在以前傳統(tǒng)的機(jī)房或虛擬化場景中比較常見，就是基于橋接的 ARP+MAC 學(xué)習(xí)，它最大的缺陷是廣播。因?yàn)槎拥膹V播，會(huì)限制節(jié)點(diǎn)的量級(jí)；三層（純路由轉(zhuǎn)發(fā)），協(xié)議棧三層一般基于 BGP，自主學(xué)習(xí)整個(gè)機(jī)房的路由狀態(tài)。它最大的優(yōu)點(diǎn)是它的 IP 穿透性，也就是說只要是基于這個(gè) IP 的網(wǎng)絡(luò)，那此網(wǎng)絡(luò)就可以去穿越。顯而易見，它的規(guī)模是非常有優(yōu)勢，且具有良好的量級(jí)擴(kuò)展性。但在實(shí)際部署過程中，因?yàn)槠髽I(yè)的網(wǎng)絡(luò)大多受控。比如，有的企業(yè)網(wǎng)絡(luò)的 BGP 是基于安全考慮不給開發(fā)者用或者說企業(yè)網(wǎng)絡(luò)本身不是 BGP，那這種情況下你就受限了；協(xié)議棧二層加三層，它的優(yōu)點(diǎn)是能夠解決純二層的規(guī)模性擴(kuò)展問題，又能解決純?nèi)龑拥母鞣N限制問題，特別是在云化 VPC 場景下，可以利用 VPC 的跨節(jié)點(diǎn)三層轉(zhuǎn)發(fā)能力。
穿越形態(tài)：
這個(gè)與實(shí)際部署環(huán)境十分相關(guān)。穿越形態(tài)分為兩種：Underlay、Overlay。
Underlay：在一個(gè)較好的可控的網(wǎng)絡(luò)場景下，我們一般利用 Underlay?？梢赃@樣通俗的理解，無論下面是裸機(jī)還是虛擬機(jī)，只要整個(gè)網(wǎng)絡(luò)可控，容器的網(wǎng)絡(luò)便可直接穿過去 ，這就是 Underlay。
Overlay：Overlay 在云化場景比較常見。Overlay 下面是受控的 VPC 網(wǎng)絡(luò)，當(dāng)出現(xiàn)不屬于 VPC 管轄范圍中的 IP 或者 MAC，VPC 將不允許此 IP/MAC 穿越。出現(xiàn)這種情況時(shí)，我們可利用 Overlay 方式來做。
Overlay網(wǎng)絡(luò)使物理網(wǎng)絡(luò)虛擬化、資源池化，是實(shí)現(xiàn)云網(wǎng)融合的關(guān)鍵。把Overlay網(wǎng)絡(luò)和SDN技術(shù)結(jié)合使用，把SDN控制器作為Overlay網(wǎng)絡(luò)控制平面的控制器，這種方式更容易使網(wǎng)絡(luò)與計(jì)算組件整合，是網(wǎng)絡(luò)向云平臺(tái)服務(wù)轉(zhuǎn)變的理想選擇。
隔離方式：
隔離方式通常分為VLAN和VXLAN 兩種：
VLAN：VLAN 機(jī)房中使用偏多，但實(shí)際上存在一個(gè)問題。就是它總的租戶數(shù)量受限。眾所周知，VLAN 具有數(shù)量限制。
VXLAN：VXLAN 是現(xiàn)今較為主流的一種隔離方式。因?yàn)樗囊?guī)模性較好較大，且它基于 IP 穿越方式較好。
我們從協(xié)議層級(jí)、穿越形態(tài)和隔離方式對(duì)kubernetes幾個(gè)常見的網(wǎng)絡(luò)組件（calico、contiv、flannel、Openshift SDN、自定義路由）在傳統(tǒng)機(jī)房網(wǎng)絡(luò)以及云化VPC網(wǎng)絡(luò)應(yīng)用場景下做一個(gè)分析，用連線圖來表述它們之前的關(guān)系。

首先無論是傳統(tǒng)機(jī)房網(wǎng)絡(luò)還是云化 VPC 網(wǎng)絡(luò)，我們可以看到 Overlay 方案是通用的，它在云化場景里可能用的更多一些，因?yàn)樗泻芎玫拇┰叫浴?br/>在上圖中，紅線實(shí)線指向傳統(tǒng)機(jī)房網(wǎng)絡(luò)，這里重點(diǎn)說明下。Underlay + 三層的方案，是傳統(tǒng)機(jī)房網(wǎng)絡(luò)非常流行的方案，同時(shí)它的性能非?？捎^，場景應(yīng)用比較偏多。
綠色虛線指向云化VPC網(wǎng)絡(luò)， Underlay+三層網(wǎng)絡(luò)在云化 VPC 場景下，也是可以受限使用。受限使用顧名思義，可以使用但不是每個(gè)供應(yīng)商都讓你用，因?yàn)槊恳粋€(gè)云廠商對(duì)他自己網(wǎng)絡(luò)保護(hù)的定義不一樣。比如像 Calico 方案，它的 BGP 在 AWS 中就容易做，但在 Azure 中就不允許，因?yàn)?Azure 的 VPC 本身是不允許不受它管控范圍的 IP 通過。
黃顏色的實(shí)線指向云化VPC網(wǎng)絡(luò)，Overlay+二層或三層在云化場景中比較常見。Overlay 下面是受控的 VPC 網(wǎng)絡(luò)，管控會(huì)比較方便。
當(dāng)然云化VPC場景下也存在一些問題，如下圖所示。

接下來說一下多租戶之間的網(wǎng)絡(luò)隔離問題

K8s從1.3版引入網(wǎng)絡(luò)策略機(jī)制，通過網(wǎng)絡(luò)策略可實(shí)現(xiàn)POD之間的入站和出站訪問策略。
網(wǎng)絡(luò)策略可應(yīng)用于通過常用標(biāo)簽標(biāo)識(shí)的pod組，然后使用標(biāo)簽來模擬傳統(tǒng)的分段網(wǎng)絡(luò)，可以通過特定的“段”標(biāo)簽來標(biāo)識(shí)前端和后端pod。策略控制這些段之間的流量，甚至控制來自外部源的流量。但并非所有的網(wǎng)絡(luò)后端都支持策略，比如 flannel?，F(xiàn)在很多廠商在這方面加強(qiáng)了研究，也有很多新的解決方案，就不一一列舉了。
還有就是集群邊界Ingress的管理

Ingress 是在kubernetes 1.2版本才出現(xiàn)的，容器應(yīng)用默認(rèn)以Service的形式提供服務(wù)，但Service僅作用于集群內(nèi)部，通過Ingress將Service暴露出去才能為集群外的客戶端提供服務(wù)。
下面對(duì)常見的Ingress Controller做一個(gè)對(duì)比，見下表

我們看到Nginx在性能和功能適用面上，還有社區(qū)活躍度上都較好，實(shí)用中也較多。
二、 kubernetes的存儲(chǔ)
k8s最初用于管理無狀態(tài)的服務(wù)，但隨著越來越多的應(yīng)用遷移到k8s平臺(tái)，管理存儲(chǔ)資源成為一個(gè)非常重要的功能。
Kubernetes中對(duì)于存儲(chǔ)的使用主要集中在以下幾個(gè)方面：
服務(wù)的基本配置文件讀取、密碼密鑰管理等；服務(wù)的存儲(chǔ)狀態(tài)、數(shù)據(jù)存取等；不同服務(wù)或應(yīng)用程序間共享數(shù)據(jù)。大致有以下幾個(gè)場景，如圖：

Kubernete存儲(chǔ)在設(shè)計(jì)的時(shí)候遵循著Kubernetes的一貫哲學(xué)，即聲明式（Declarative）架構(gòu)。同時(shí)為了盡可能多地兼容各種存儲(chǔ)平臺(tái)，Kubernetes以in-tree plugin的形式來對(duì)接不同的存儲(chǔ)系統(tǒng)，滿足用戶可以根據(jù)自己業(yè)務(wù)的需要使用這些插件給容器提供存儲(chǔ)服務(wù)。同時(shí)兼容用戶使用FlexVolume和CSI定制化插件。相比較于Docker Volume，支持的存儲(chǔ)功能更加豐富和多樣。
Kubernete存儲(chǔ)插件解析：
1、in-tree plugin：存儲(chǔ)代碼與K8S緊密集成，耦合性太強(qiáng)
2、FlexVolume：存儲(chǔ)插件安裝在宿主機(jī)上，需要宿主機(jī)的root權(quán)限
3、CSI規(guī)范：將存儲(chǔ)代碼與K8S完全解耦（1.10版本及以上，使用CSI attacher使用0.2.0版本）

csi規(guī)范極大地方便了插件的開發(fā)、維護(hù)和集成，具有很好的發(fā)展前景。
Kubernetes使用兩種資源管理存儲(chǔ)：
PersistentVolume（簡稱PV）：由管理員添加的的一個(gè)存儲(chǔ)的描述，是一個(gè)全局資源，包含存儲(chǔ)的類型，存儲(chǔ)的大小和訪問模式等。它的生命周期獨(dú)立于Pod，例如當(dāng)使用它的Pod銷毀時(shí)對(duì)PV沒有影響。
PersistentVolumeClaim（簡稱PVC）：是Namespace里的資源，描述對(duì)PV的一個(gè)請(qǐng)求。請(qǐng)求信息包含存儲(chǔ)大小，訪問模式等。
PV可以看作可用的存儲(chǔ)資源，PVC則是對(duì)存儲(chǔ)資源的需求，PVC會(huì)根據(jù)Pod的要求去自動(dòng)綁定合適的PV給Pod使用。PV和PVC的相互關(guān)系遵循下圖所示的生命周期。

PV模式有靜態(tài)和動(dòng)態(tài)，靜態(tài)PV模式管理NFS、FC、ISCSI，動(dòng)態(tài)PV模式管理glusterfs、Cinder、Ceph RBD、Vsphere、ScaleIO、AWS、Azure等。靜態(tài)的需要管理員創(chuàng)建和管理PV，而動(dòng)態(tài)的則由系統(tǒng)自動(dòng)生成PV并綁定PVC.
下面再簡單補(bǔ)充下kubernetes中的鏡像管理，生產(chǎn)中都會(huì)有很多不同版本不同應(yīng)用的鏡像，對(duì)鏡像的管理也是比較重要的環(huán)節(jié)。

鏡像的多租戶權(quán)限管理：
1、不同租戶的鏡像應(yīng)相互隔離
2、不同的租戶對(duì)鏡像擁有不同的權(quán)限，例如讀寫、只讀、上傳、下載權(quán)限
3、鏡像庫提供鏡像的查詢、更新和刪除等功能

創(chuàng)新互聯(lián)專注于大石橋網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠為您提供大石橋營銷型網(wǎng)站建設(shè)，大石橋網(wǎng)站制作、大石橋網(wǎng)頁設(shè)計(jì)、大石橋網(wǎng)站官網(wǎng)定制、微信小程序定制開發(fā)服務(wù)，打造大石橋網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供大石橋網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。

對(duì)于跨地域多數(shù)據(jù)中心的鏡像管理，鏡像庫的遠(yuǎn)程復(fù)制管理需要注意：
1、在多數(shù)據(jù)中心或跨地域多站點(diǎn)的環(huán)境下，為了提高多地區(qū)鏡像的下載效率，至少需要兩級(jí)鏡像庫的設(shè)置：總鏡像庫和子鏡像庫
2、鏡像庫之間的準(zhǔn)實(shí)時(shí)增量同步

三、 Kubernetes集群管理
在生產(chǎn)系統(tǒng)中，kubernetes多集群的管理主要涉及：
1、服務(wù)運(yùn)維
2、集中配置
3、擴(kuò)容升級(jí)
4、資源配額
首先說說多集群的調(diào)度管理
1、Kubernetes中的調(diào)度策略可以大致分為兩種，一種是全局的調(diào)度策略，另一種是運(yùn)行時(shí)調(diào)度策略
2、NODE的隔離與恢復(fù)；NODE的擴(kuò)容；Pod動(dòng)態(tài)擴(kuò)容和縮放
3、親和性可以實(shí)現(xiàn)就近部署，增強(qiáng)網(wǎng)絡(luò)能力實(shí)現(xiàn)通信上的就近路由，減少網(wǎng)絡(luò)的損耗。反親和性主要是出于高可靠性考慮，盡量分散實(shí)例。
4、 微服務(wù)依賴，定義啟動(dòng)順序
5、跨部門應(yīng)用不混部
6、api網(wǎng)關(guān)以及GPU節(jié)點(diǎn)應(yīng)用獨(dú)占

多集群管理中的應(yīng)用彈性伸縮管理：
1、手工擴(kuò)縮容：預(yù)先知道業(yè)務(wù)量的變化情況
2、基于CPU使用率的自動(dòng)擴(kuò)縮容：v1.1版引入控制器HPA，POD必須設(shè)置CPU資源使用率請(qǐng)求
3、基于自定義業(yè)務(wù)指標(biāo)的自動(dòng)擴(kuò)縮容：v1.7版對(duì)HPA重新設(shè)計(jì)，增加了組件，被稱為HPA v2
在實(shí)際應(yīng)用中，HPA還有很多不完善的地方，很多廠商都用自己的監(jiān)控體系來實(shí)現(xiàn)對(duì)業(yè)務(wù)指標(biāo)的監(jiān)控并實(shí)現(xiàn)自動(dòng)擴(kuò)容
Kubernetes多集群的調(diào)優(yōu)：
主要有三個(gè)難點(diǎn)：
第一是如何分配資源，當(dāng)用戶選擇多集群部署后，系統(tǒng)根據(jù)每個(gè)集群的資源用量，決定每個(gè)集群分配的容器數(shù)量，并且保證每個(gè)集群至少有一個(gè)容器。集群自動(dòng)伸縮時(shí)，也會(huì)按照此比例創(chuàng)建和回收容器。
第二是故障遷移，集群控制器主要是為了解決多集群的自動(dòng)伸縮和集群故障時(shí)的容器遷移，控制器定時(shí)檢測集群的多個(gè)節(jié)點(diǎn)，如果多次失敗后將觸發(fā)集群容器遷移的操作，保障服務(wù)可靠運(yùn)行。
第三是網(wǎng)絡(luò)和存儲(chǔ)的互連，由于跨機(jī)房的網(wǎng)絡(luò)需要互連，我們采用vxlan的網(wǎng)絡(luò)方案實(shí)現(xiàn)，存儲(chǔ)也是通過專線互連。容器的鏡像倉庫采用Harbor，多集群之間設(shè)置同步策略，并且在每個(gè)集群都設(shè)置各自的域名解析，分別解析到不同的鏡像倉庫。

接下來說說K8S集群的Master節(jié)點(diǎn)高可用實(shí)現(xiàn)，我們知道Kubernetes集群的核心是其master node，但目前默認(rèn)情況下master node只有一個(gè)，一旦master node出現(xiàn)問題，Kubernetes集群將陷入“癱瘓”，對(duì)集群的管理、Pod的調(diào)度等均將無法實(shí)施。所以后面出現(xiàn)了一主多從的架構(gòu)，包括master node、etcd等都可設(shè)計(jì)高可用的架構(gòu)。

還有了解下Federation 集群聯(lián)邦架構(gòu)
在云計(jì)算環(huán)境中，服務(wù)的作用距離范圍從近到遠(yuǎn)一般可以有：同主機(jī)（Host，Node）、跨主機(jī)同可用區(qū)（Available Zone）、跨可用區(qū)同地區(qū)（Region）、跨地區(qū)同服務(wù)商（Cloud Service Provider）、跨云平臺(tái)。K8s的設(shè)計(jì)定位是單一集群在同一個(gè)地域內(nèi)，因?yàn)橥粋€(gè)地區(qū)的網(wǎng)絡(luò)性能才能滿足K8s的調(diào)度和計(jì)算存儲(chǔ)連接要求。而集群聯(lián)邦（Federation）就是為提供跨Region跨服務(wù)商K8s集群服務(wù)而設(shè)計(jì)的，實(shí)現(xiàn)業(yè)務(wù)高可用。
Federation 在1.3版引入，集群聯(lián)邦federation/v1beta1 API擴(kuò)展基于DNS服務(wù)發(fā)現(xiàn)的功能。利用DNS，讓POD可以跨集群、透明的解析服務(wù)。
1.6版支持級(jí)聯(lián)刪除聯(lián)邦資源,1.8版宣稱支持5000節(jié)點(diǎn)集群，集群聯(lián)邦V2

目前存在的問題：
1、網(wǎng)絡(luò)帶寬和成本的增加
2、削弱了多集群之間的隔離性
3、成熟度不足，在生產(chǎn)中還沒有正式的應(yīng)用
四、kubernetes的監(jiān)控與運(yùn)維
對(duì)于一個(gè)監(jiān)控系統(tǒng)而言，常見的監(jiān)控維度包括：資源監(jiān)控和應(yīng)用監(jiān)控。資源監(jiān)控是指節(jié)點(diǎn)、應(yīng)用的資源使用情況，在容器場景中就延伸為節(jié)點(diǎn)的資源利用率、集群的資源利用率、Pod的資源利用率等。應(yīng)用監(jiān)控指的是應(yīng)用內(nèi)部指標(biāo)的監(jiān)控，例如我們會(huì)將應(yīng)用在線人數(shù)進(jìn)行實(shí)時(shí)統(tǒng)計(jì)，并通過端口進(jìn)行暴露來實(shí)現(xiàn)應(yīng)用業(yè)務(wù)級(jí)別的監(jiān)控與告警。那么在Kubernetes中，監(jiān)控對(duì)象會(huì)細(xì)化為哪些實(shí)體呢？
系統(tǒng)組件
kubernetes集群中內(nèi)置的組件，包括apiserver、controller-manager、etcd等等。
靜態(tài)資源實(shí)體
主要指節(jié)點(diǎn)的資源狀態(tài)、內(nèi)核事件等等
動(dòng)態(tài)資源實(shí)體
主要指Kubernetes中抽象工作負(fù)載的實(shí)體，例如Deployment、DaemonSet、Pod等等。
自定義應(yīng)用
主要指需要應(yīng)用內(nèi)部需要定制化的監(jiān)控?cái)?shù)據(jù)以及監(jiān)控指標(biāo)。
不同容器云監(jiān)控方案的對(duì)比：

關(guān)于Prometheus監(jiān)控：
主要注意兩點(diǎn)：
? 查詢api的封裝
? 配置文件的下發(fā)
有了prometheus這個(gè)強(qiáng)大的監(jiān)控開源系統(tǒng)之后，我們所需要投入的工作就是查詢api的封裝和配置文件的下發(fā)。查詢api的封裝沒什么好說的，無非就是前端調(diào)用我們自己的server，我們的server呢通過http協(xié)議去調(diào)用prometheus的api接口查詢到原始數(shù)據(jù)，然后進(jìn)行組裝，最后返回給前端。 配置文件的話包含三部分吧，警報(bào)的定義，alertmanager的配置，以及prometheus的配置，這里也不好展開講，有興趣的可以去官網(wǎng)看看。當(dāng)然也可以使用Prometheus+Grafana來搭建監(jiān)控系統(tǒng)，這樣可視化會(huì)更豐富些，展現(xiàn)也比較快。
運(yùn)維的思考---開發(fā)與運(yùn)維的一體化

運(yùn)維的思考---高可用問題
? Ocp平臺(tái):
1、負(fù)載均衡Router高可用集群: 2個(gè)節(jié)點(diǎn)
2、EFK高可用集群: 3個(gè)ES節(jié)點(diǎn)+n個(gè)F節(jié)點(diǎn)
3、鏡像倉庫高可用集群: 2個(gè)鏡像倉庫
? 微服務(wù)架構(gòu):
1、注冊(cè)中心高可用集群(Eureka): 3個(gè)
2、配置中心高可用集群: 3個(gè)
3、網(wǎng)關(guān)高可用集群: 2個(gè)
4、關(guān)鍵微服務(wù)均是高可用集群
運(yùn)維的思考---高并發(fā)問題
? Ocp平臺(tái):
1、對(duì)后端微服務(wù)(Pod)配置彈性擴(kuò)容, K8的彈性伸縮擴(kuò)容以及Docker容器的秒級(jí)啟動(dòng)可以支撐用戶量的持續(xù)增長;
2、提前預(yù)留20%的資源, 當(dāng)高并發(fā)情況發(fā)生時(shí), 可以緊急擴(kuò)充資源。
? 微服務(wù)架構(gòu):

1. 調(diào)大關(guān)鍵鏈路微服務(wù)的熔斷線程數(shù): 提升主要業(yè)務(wù)的并發(fā)響應(yīng)能力。
2. 對(duì)非關(guān)鍵鏈路微服務(wù)通過熔斷限流進(jìn)行降級(jí)處理甚至關(guān)閉非關(guān)鍵鏈路的微服務(wù)。
3. 熔斷機(jī)制：提升容器云高并發(fā)場景下的容錯(cuò)能力，防止故障級(jí)聯(lián)以及微服務(wù)的雪崩效應(yīng)，提升系統(tǒng)的可用性。
   ? 中間件:
   1、除了正在使用的集群外, 提前增加冷備的集群。
   2、當(dāng)高并發(fā)場景即將發(fā)生時(shí), 可以緊急水平擴(kuò)展。
   還有就是性能壓測與優(yōu)化問題，限于時(shí)間關(guān)系，這里就不展開講了。
   最后，容器云之路總結(jié)
   1.業(yè)務(wù)層面：因大型企業(yè)對(duì)業(yè)務(wù)的穩(wěn)定性和連續(xù)性有比較高的要求，故容器化的演進(jìn)路徑必然是從邊緣業(yè)務(wù)到核心業(yè)務(wù)，從簡單應(yīng)用到復(fù)雜應(yīng)用，具體到業(yè)務(wù)，首先可以考慮在Web前端進(jìn)行容器化遷移，最后動(dòng)后端業(yè)務(wù)。 ?
   2.技術(shù)層面：目前原生Docker在服務(wù)發(fā)現(xiàn)、負(fù)載均衡、容器生命周期管理、容器間網(wǎng)絡(luò)、存儲(chǔ)等方面還存在諸多的不足，許多第三方廠家提供的開源解決方案和商業(yè)化版本，各具特色，難分高下。用戶無論選擇何種產(chǎn)品，可靠性、靈活性是需要慎重考慮的2個(gè)重要因素。
   3.兼顧成本效益：綜合考慮容器化付出的成本代價(jià)與未來收益之間的平衡。
   4.考慮現(xiàn)有硬件的負(fù)載能力，容器化并非包治百病的良藥，某些對(duì)并發(fā)吞吐量要求更高的業(yè)務(wù)，直接運(yùn)行在裸機(jī)上，通過系統(tǒng)調(diào)優(yōu)提高性能，容器化未必是最好的選擇。
   5、持續(xù)更新，時(shí)刻提醒自己持續(xù)學(xué)習(xí)，擁抱變化，這樣才能看到平臺(tái)的不足，不斷迭代出更好的產(chǎn)品。
   在生產(chǎn)實(shí)踐中，只有夯實(shí)基礎(chǔ)不斷去完善基于容器云平臺(tái)的產(chǎn)品和建設(shè)生態(tài)體系，才能掌控未來決勝千里！

網(wǎng)頁題目：Kubernetes容器云平臺(tái)實(shí)踐
分享路徑：http://jinyejixie.com/article36/ggegsg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站維護(hù)、企業(yè)建站、網(wǎng)站策劃、自適應(yīng)網(wǎng)站、網(wǎng)站設(shè)計(jì)、定制網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)