鑒于開發(fā)人員已經(jīng)開始采用敏捷、方便的可編排技術(shù)，因此會越來越多地采用基于容器的應(yīng)用程序。但是當(dāng)這些應(yīng)用程序進(jìn)入生產(chǎn)階段時，他們的編排解決方案對操作復(fù)雜性產(chǎn)生了相當(dāng)大的影響。DevOps成功的最大障礙之一仍然是復(fù)雜性，Quali Survey進(jìn)行的調(diào)查中顯示，11%的受訪者認(rèn)為自動化相關(guān)的挑戰(zhàn)以及云計(jì)算系統(tǒng)的編排是影響DevOps成功的障礙。
這種復(fù)雜性部分來源于將應(yīng)用程序分解成“微服務(wù)”的模塊，每個微服務(wù)本身都是一個可擴(kuò)展性域，需要負(fù)載均衡和安全以及網(wǎng)絡(luò)支持。隨著容器部署越來越多，這些主要的基于軟件的解決方案需要大量的容器內(nèi)和集群內(nèi)通信，增加了東西向流量的數(shù)量和頻率。規(guī)模化應(yīng)用的傳統(tǒng)網(wǎng)絡(luò)托管解決方案（負(fù)載均衡等）必須適應(yīng)，不僅僅是通過軟件提供功能，還要通過解決相對極端的需求來跟上基于容器環(huán)境的極端動態(tài)性質(zhì)。
為此，出現(xiàn)了一種獨(dú)特的架構(gòu)模式，輕量級負(fù)載均應(yīng)用程序代理駐留在容器集群中，以便于擴(kuò)展和協(xié)助服務(wù)之間的集群內(nèi)路由。當(dāng)應(yīng)用程序分解時，其內(nèi)部通信模式轉(zhuǎn)變成外部通信模式，并且必須通過網(wǎng)絡(luò)而不是在應(yīng)用程序內(nèi)部進(jìn)行。這帶來了復(fù)雜性以及規(guī)模的需求，隨后通過納入東西向集中的負(fù)載均衡代理來解決這個問題。
架構(gòu)方面，在應(yīng)用層面上仍然存在規(guī)模化，這需要在南北向網(wǎng)絡(luò)納入能提供規(guī)模、性能和安全性的上游業(yè)務(wù)。通常由應(yīng)用交付控制器（ADC）或其他負(fù)載均衡代理（軟件或硬件）提供，并且促進(jìn)用戶、事物和集群外部的應(yīng)用程序之間的通信。
無論是Kubernetes還是Mesos或OpenShift，容器集群解決方案都適用這種模式。帶來的額外的復(fù)雜性以及對代理提供的不僅僅是傳統(tǒng)功能的需求，還支持應(yīng)用程序接口（API）調(diào)動，基于軟件的模型、容器、云和應(yīng)用程序正在不斷構(gòu)建。
云也在不斷發(fā)展，新興的計(jì)算模式是無服務(wù)器模式，或稱為功能即服務(wù)（FaaS），該模式假定比云或容器性能更加優(yōu)秀，按要求但不按需調(diào)用資源。支持網(wǎng)絡(luò)對這種環(huán)境的響應(yīng)的能力對于這些模式在實(shí)現(xiàn)其預(yù)期收益方面的成功至關(guān)重要。
為了應(yīng)對這些挑戰(zhàn)，網(wǎng)絡(luò)必須一如既往地滿足速度需求。但是，速度并不是目前唯一的關(guān)注點(diǎn)，負(fù)載均衡服務(wù)更新資源池的速度至關(guān)重要。這給負(fù)載均衡服務(wù)帶來了壓力，必須確保其API具有與其核心功能相同的可擴(kuò)展性和性能，對于服務(wù)集群內(nèi)通信的解決方案的微服務(wù)和應(yīng)用程序之間的東西向流量尤其如此。
必須從網(wǎng)絡(luò)方面整合到由Kubernetes，Mesos和OpenShift編排的集群內(nèi)容器的自動化和編排中。不再是網(wǎng)絡(luò)負(fù)責(zé)人，要求其他人配置更改。假設(shè)網(wǎng)絡(luò)將根據(jù)管理、調(diào)度和編排容器生命周期的集群主節(jié)點(diǎn)提供的信息自動調(diào)整配置和行為。為此，像負(fù)載均衡這樣的服務(wù)必須能夠監(jiān)控并了解集群活動的各種標(biāo)簽和消息，并對這些作出反應(yīng)。例如，當(dāng)Kubernetes宣布推出新的容器時，負(fù)載均衡器需要識別事件并通過調(diào)整配置進(jìn)行響應(yīng)。相反，當(dāng)Kill一個容器時，網(wǎng)絡(luò)需要通過從負(fù)載均衡資源池、路由表和安全策略中刪除相關(guān)信息來進(jìn)行響應(yīng)。這對速度提出了相當(dāng)?shù)囊螅员苊鉄o意中將請求分發(fā)到已經(jīng)不可用的資源。
這些行動必須以速度為前提，以免可用性或規(guī)模化受到損害。可擴(kuò)展、快速的管理平面是網(wǎng)絡(luò)服務(wù)的需求，希望在容器甚至基于云的環(huán)境中保持相關(guān)性和有用性。兩者都高度依賴于自動化和業(yè)務(wù)流程，因此需要專注于其應(yīng)用程序接口（API）及其核心功能。如果沒有快速、易使用的API，網(wǎng)絡(luò)解決方案將面臨淘汰的風(fēng)險，并被軟件為基礎(chǔ)的服務(wù)取締。
云計(jì)算強(qiáng)制網(wǎng)絡(luò)無論是形式和操作都需要采用軟件定義的模式，容器正在進(jìn)一步改變通信模式，以使規(guī)模、路由和安全性與這些日益增長的易失性環(huán)境協(xié)同工作。網(wǎng)絡(luò)必須適應(yīng)對應(yīng)用程序變更作出反應(yīng)的模式，更直接地與應(yīng)用程序基礎(chǔ)設(shè)施集成。最終，網(wǎng)絡(luò)必須真正意義上的應(yīng)用來支持當(dāng)今的應(yīng)用交付模式。
原文鏈接：https://www.sdxcentral.com/articles/contributed/containers-and-cloud-putting-pressure-network/2017/03/
京公網(wǎng)安備 11010502049343號