容器的運行無法簡單參考虛擬機的實踐經(jīng)驗。例如，幾乎任何工作負載都可以立即虛擬化，但是有些工作負載適合容器化部署，有的則不適合。

本文回答企業(yè)在使用容器時最常見的10個問題，幫助大家更好地理解容器部署、工作負載容器化等問題。

1. 最適合容器的使用場景是什么?

在生產(chǎn)環(huán)境中，最適合容器化部署的理想應用類型應該是微服務。微服務是一個聚焦的任務，它只代表整個應用程序中很小部分。因為微服務專注于單個任務，所以它可以獨立于應用程序的其它部分進行伸縮擴展。此外，由于微服務是高內(nèi)聚和松散耦合的，因此可以彼此獨立部署和發(fā)布。

此外，使用容器基礎設施構建微服務可以更快、更好地實現(xiàn)其優(yōu)勢。只要面向外部的API不破壞應用兼容性，軟件開發(fā)人員就可以快速迭代并改進整個微服務，且不會影響其它開發(fā)人員的微服務。但是，大多數(shù)傳統(tǒng)的企業(yè)應用程序并不符合微服務體系結構，所以也不是所有企業(yè)都適合使用微服務。

2. 容器部署時需要考慮的關鍵因素都有哪些?

(1)UI界面管理和API

管理用戶界面UI，包括那些基于API的圖形化UI(即外部系統(tǒng)直接使用API訪問系統(tǒng))。

(2)鏡像倉庫

公共鏡像倉庫，例如Docker Hub提供公共管理的容器鏡像倉庫。許多容器管理系統(tǒng)都提供私有鏡像倉庫，企業(yè)組織可以在其中管理自己的鏡像。

(3)編排和調度

編排層能夠使容器以所需的狀態(tài)運行，并提供滾動更新和回滾的功能。當然，Kubernetes已經(jīng)成為容器編排的實際標準。

(4)容器運行時

容器運行時，可以讓集群節(jié)點在鏡像倉庫中獲取容器鏡像，還可生成正確的文件結構在主機上運行容器，也可與網(wǎng)絡和存儲插件交互，也能創(chuàng)建、啟停容器。

(5)安全管控

通過安全組件執(zhí)行安全策略，包括秘鑰管理、安全掃描、圖像簽名、網(wǎng)絡隔離和加密、以及基于角色的訪問控制(RBAC)等。

(6)持續(xù)監(jiān)控

監(jiān)控程序能夠提供集群節(jié)點、容器和微服務級別的可視化能力。

(7)DevOps工作流

DevOps對于容器部署并不重要，但是它們通常一起使用，例如，DevOps工具、CI/CD管道工具和容器鏡像生成器等工具需要協(xié)同工作。

3. 是否可以在Windows、VMware環(huán)境運行容器?

Windows容器生態(tài)系統(tǒng)還不夠成熟，無法廣泛應用于生產(chǎn)環(huán)境中。Windows容器缺乏容器編排工具的支持。例如，最新的Kubernetes軟件版本只提供了對Windows容器的beta支持。此外，容器支持的Windows應用程序非常少。Windows服務器對身份驗證、安全和網(wǎng)絡的支持也非常有限的。現(xiàn)有的幾個組件要么處于“beta”版本，要么處于“預覽”版本。當然，盡管有這些限制，針對特定場景也是可以使用Windows容器，例如內(nèi)部開發(fā)等場景，通過容器可以獲得敏捷性、可移植性和成本優(yōu)勢。

VMware的vSphere可將Docker引擎與vSphere集成，為容器在輕量級VM中運行提供了途徑。此外VMware還提供了用于安全存儲鏡像的容器管理門戶和私有倉庫。

4. 應該選擇CaaS、Kubernetes還是BYO容器管理解決方案

市場上有多種產(chǎn)品允許企業(yè)大規(guī)模部署容器。這些產(chǎn)品為應用程序開發(fā)人員提供的抽象程度不同。最抽象的產(chǎn)品是容器即服務產(chǎn)品(CaaS)，這類產(chǎn)品以前大多是PaaS產(chǎn)品，比如Cloud Foundry和OpenShift。這些CaaS產(chǎn)品從開發(fā)人員那里抽象出基礎設施的細節(jié)，并以結構化方式提供應用程序工具。而BYO容器管理方案，則提供了最少的抽象和最大的靈活性，但是增加了復雜性。

• BYO：盡量避免使用BYO，除非在極少數(shù)情況下。因為很少有組織有能力實現(xiàn)它。對于想要BYO的組織，可以選擇集成一些快速移動的開源產(chǎn)品。
• Kubernetes：至少在概念上了解基礎設施并且能夠動手實踐，那么選擇一個相對靈活K8S發(fā)行版是一個可行方案。有些CaaS產(chǎn)品提供了一些開發(fā)人員工具的選項，同時也為開發(fā)人員提供了更直接地使用容器編排、調度組件的選項。
• PaaS：如果剛剛進入微服務開發(fā)，那么就使用PaaS提供的服務。

5. 容器技術會比虛擬機技術(VM)更不安全嗎?

容器技術本身并非不安全。事實上，以防止由于其它容器的破壞而遭受攻擊, 容器中每個應用程序和用戶是相互隔離的。所以確保共享主機OS內(nèi)核的完整性是至關重要的，并確保在主機上容器的相互隔離。此外，需要監(jiān)控和保護容器間通信，而傳統(tǒng)的安全工具在這方面大多是無效的。

采用容器技術時候，建議考慮以下3點：

• 使用一個經(jīng)過加固的操作系統(tǒng)，通常是一個“瘦客戶機操作系統(tǒng)”，它可以限制攻擊面，并通過一個嚴格的和自動化的補丁管理系統(tǒng)對其進行補充。
• 在容器的構建和運行階段采取控制手段，例如在軟件開發(fā)生命周期過程中對軟件進行掃描，及早發(fā)現(xiàn)漏洞。
• 通過使用細粒度容器安全工具主動檢測和監(jiān)控異常行為，例如青藤蜂巢等容器安全產(chǎn)品可以提供容器和服務器級別的安全可視化圖，并有助于防止惡意應用程序流量。

6. 容器是否可以處理敏感數(shù)據(jù)和應用程序?

通過聚焦于容器安全的方法進行容器部署，同時結合現(xiàn)有加密等安全工具，那么容器就可用于處理敏感數(shù)據(jù)和應用程序。此外，還可以使用一些容器安全廠商的方案確保容器的安全，例如青藤云安全的容器解決方案等。當然，要使此方法成功，安全團隊必須盡早參與為敏感數(shù)據(jù)部署容器的過程。

7. 容器是否適合COTS應用?

現(xiàn)在越來越多的軟件供應商將容器化部署作為產(chǎn)品一個選項。有的供應商采用敏捷開發(fā)模式滿足容器化部署方式，將其納入他們編寫、測試和交付軟件的一部分。這些應用都被重構為天然適配容器的微服務。但也有供應商，是因為害怕不提供容器化部署功能將失去市場，故而勉強提供容器部署，這種情況下COTS多數(shù)不適合容器，因為這些應用程序本質上可能仍然是整體的，或者應用程序沒有獨立可擴展屬性。此外，如果企業(yè)本身沒有現(xiàn)有的容器基礎設施來管理，那么COTS應用程序的容器部署可能不適合企業(yè)。

在絕大多數(shù)情況下，應該避免在沒有供應商明確支持的情況下封裝COTS應用程序，避免出差錯。

8. Foundry、OpenShift等產(chǎn)品和容器之間有什么關系

Cloud Foundry是一個應用程序PaaS平臺，它支持多種框架、語言、運行時環(huán)境、云平臺及應用服務，使開發(fā)人員能夠在幾秒鐘內(nèi)進行應用程序的部署和擴展，無需擔心任何基礎架構的問題。因此，也是一個相對固定的容器框架。之所以這樣描述，是因為它是預先配置的，以便于安裝和維護。

OpenShift是紅帽的云開發(fā)平臺即服務(PaaS)，能使開發(fā)人員創(chuàng)建、測試和運行他們的應用程序，并且可以把它們部署到云中。OpenShift廣泛支持多種編程語言和框架，如Java、Ruby和PHP等。另外它還提供了多種集成開發(fā)工具如Eclipse integration，JBoss Developer Studio和 Jenkins等。

企業(yè)在評估面向容器場景的PaaS產(chǎn)品時，重需要重點注意其提供服務范圍，區(qū)分它們自身是否支持容器場景，還是需要自定義配置或者需要通過第三方組件服務才能支持容器場景。

9. 是否應該重構應用程序，以更好地支持容器?

在生產(chǎn)中，如果通過部署容器來支持微服務的彈性工作負載時，容器將會帶來最大的幫助。因此是否要重構應用程序以支持容器化部署，這取決于企業(yè)組織是否計劃在開發(fā)測試、生產(chǎn)等階段中使用容器。

另外，企業(yè)在決定重構應用程序以更好支持容器，應該首先重構無狀態(tài)部分應用程序，例如web應用程序前端部分，將其重構為微服務，以便能夠支持使用容器。此外，企業(yè)可以通過微服務體系結構來構建新的應用程序，避免以后重構。

10. 在公有云中部署容器服務效果如何?

云IaaS服務提供商提供完全托管服務，而不需要處理虛擬機或底層基礎設施，這種趨勢現(xiàn)在也被應用到容器中，例如，AWS Fargate提供了抽象底層基礎設施的托管容器服務，以便開發(fā)人員關注需要執(zhí)行的任務，而不是Kubernetes集群中的實例數(shù)量。