傳統企業傳統應用遷移到容器雲需要做哪些改造？

@caikai：

大體上來說，容器網絡的改造，取決于您的運作場景對網絡的需求。網絡選擇有幾類：

- 如果是隔離的容器網絡環境，不與生産和測試環境網絡連通，隻做開發測試，技術驗證等，性能不敏感，那麼overlay方式，甚至原生的NAT就可以考慮。

- 如果是單獨的容器網絡環境，對性能有要求，不想因為overlay而浪費MTU，又需要對外提供基于容器的服務，那麼路由方式可能是選擇；對外提供服務可以配置面向外部的4/7層負載均衡。

- 如果要求容器網絡和外部統一管理，要求統一的IP位址規劃、統一的路由、防火牆、漏洞掃描、SDN能力等，需要對容器叢集的網絡方案進行深入定制，自己實作CNI/CNM接口，把容器的啟動停止過程，比如容器的子網和IP配置設定等網絡相關動作，和外部網絡管理關聯起來，讓外部感覺容器的變化，做到自動地配置到容器的路由等。

@shendb：

就談幾個必須要考慮的點供參考。

1、對生産網絡壓力的評估及安全控制。容器在規模化使用後在鏡像分發等場景下會有較大的網絡帶寬消耗這個是需要考慮到的。

2、網絡安全政策回顧。如master與slave間的網絡安全政策，是一個大的平台還是各區域分别建設再進行整個，這個和安全控制政策有較大關系。

3、負載均衡政策。是用集中式的還是分布的，是作為基礎網絡服務能力提供還是作為平台服務能力提供。dns也面臨類似情況。

網絡方面問題往往容易被忽略，處理不好将給容器平台帶來非常大的風險。

@聶奎甲：

1.評估應用上雲的必要性，可行性和風險，綜合決定是否上雲及哪些部分上雲。

2.選擇非核心,無狀态，前端應用先做試點，等遷移成功穩定後再逐漸推廣。

如果應用不做任何改造遷移到容器，或者說把容器當虛機用，基本和傳統差別不大。但如果應用做了微服務化改造，需要面對很多可能的新問題，這裡隻大緻羅列：

- 服務效率問題：解決的選項可以考慮微服務網關做服務聚合、親和性排程、緩存機制、斷路器、異步調用

- 高可用性問題：解決的選項可以考慮執行個體自動恢複、服務限流、服務降級、彈性擴容、負載均衡

- 資料一緻性及事務性問題：跨微服務的事務性和強一緻性處理代價非常高，盡量避免把這樣的場景切分到不同的微服務，就是說要盡量避免跨微服務處理事務性，對于沒有事務性一緻性要求的，或者可以接受最終一緻性的任務，才考慮微服務劃分

- 安全問題：服務間跨網絡的API調用，可能要考慮API需要有鑒權、傳輸加密、API限速、API設計上考慮避免洩露敏感資訊等，另外以容器方式運作，還可能要限制特權模式的權限

- 運維複雜度問題：可以考慮多個方面改進監控系統，包括但不限于日志集中收集、選擇适合微服務的監控粒度、微服務設計配合監控的接口提供業務名額、滾動更新和復原等。

一個應用開發到上線到你的平台首先有一個過程，容器化。如果是一個新的程式，非常好，直接可以按容器的方式來做。寫編排檔案就可以直接了。如果是老應用，要先有容器化的過程。這個過程大緻可以分為拆分、改造、合并三個階段。

@caikai： 

基本上有幾個方面都會涉及：

1.應用改造：涉及适合場景的梳理，以及應用狀态持久化，或更進一步的微服務架構拆分改造。

2.架構優化和運維：這個涉及的複雜問題很多，要應對服務效率降低（例如用服務網關聚合一組API，親和性排程、斷路器、異步調用等）、高可用性要求（例如服務限流、服務降級、彈性擴容、負載均衡、故障恢複、滾動更新和復原）、分布式系統資料一緻性（包括強一緻性和最終一緻性的分别處理）、分布式系統安全性（統一身份驗證、傳輸加密、API鑒權、API限速、租戶隔離）、監控系統改造（日志收集、集中告警燈）。

3.流程改造：CI/CD流水線工具、全生命周期管理的流程、推行類似SRE等的DevOps理念。

4.團隊組織：提倡按照業務服務邊界而不是技術職能的團隊組織和KPI設定等。

這部分對接通常要涉及的幾個方面：

- 對接底層IaaS資源池，遵從雲計算資源的統一管理和配置設定

- 對接或改造容器平台的網絡，以滿足容器平台中應用與傳統虛拟機、實體機中舊業務系統的互相通信，避免或盡可能減少對現有網絡管理模式的沖擊

- 對接統一身份驗證、和整個雲平台其它系統采用統一的租戶定義、角色定義、資源配額定義等

- 對接漏洞掃描、集中監控系統、日志分析系統等已有周邊系統

此外，考慮到對應用的統一規範管理，容器平台可能還需要對接已有的應用釋出體系、持續內建系統、應用模組化規範、高可用管理政策（例如同城雙活的部署、災備切換方案）

@bryan：

補充一點，由于IaaS平台主要為PaaS提供作業系統資源，這些資源包含存儲、網絡、計算資源等，在設計的時候要考慮資源的抽象化和統一化，将多種不同的硬體資源都可以抽象成統一的接口和概念，盡量提供統一的接口，對PaaS屏蔽異構資源的差異性，視作從資源池動态排程資源即可。

Paas平台的資源管理，防火牆；容器彈性伸縮等問題；以及實ip帶來的管理和跟蹤問題；此外還想了解鏡像和版本如何做好管理？

資源管理可以選擇事先劃分好主控端、存儲等資源給paas平台使用，這樣做比較簡單，沒有多少和底層資源池或IaaS對接的要求；如果要求資源動态申請，就需要PaaS和IaaS的對接了。

網絡如何管理是比較複雜的，也直接影響到防火牆、IP的管理。在這次交流的其它問題裡有專門關于網絡的，建議參考。

彈性伸縮，目前比較簡單的能做到的是基于資源使用情況的彈性，但這樣的彈性往往不充分，或者不準确。如果要做到基于業務的彈性，那麼理想的情況需要應用配合改造吐出業務狀态資訊才行，要麼提供接口，要麼通過日志等。個人覺得目前比較實用、代價比較低的彈性是基于時間表的彈性，因為大多數需要彈性的場景，其實是可預測的，要麼有比較固定的時間段，要麼就是在某個活動開始前的一段時間。

回答前，先假設問題中的“網絡扁平化”，是指容器網絡和容器平台之外的網絡融為一體，不僅可以直接路由互通，還可以完全利用到外部網絡已有的各類網絡服務能力、SDN能力。

要實作以上目的，在設計容器網絡時，需要考慮整個容器網絡具備和容器平台以外，例如IaaS的VM有相同的網絡層級、IP位址規劃、子網劃分規則，IP位址配置設定、根據容器的生滅動态配置防火牆政策、路由政策等。具體的做法變化比較多樣，基本上都需要修改已有容器平台的容器網絡接口實作，即CNI或CNM的實作。

文章《容器雲平台建設的需求分析與關鍵設計》中舉了一個例子，對接了IAAS的Neutron+SDN進行統一網絡管理，工作原理是：

- 當容器平台需要為新的租戶配置設定網絡資源時，通知Neutron，由Neutron對接的SDN控制器按照預先定義的規則為容器平台配置設定所需的子網和網絡位址空間

- 開發網絡驅動，實作CNI接口。當容器平台建立新的容器執行個體時，網絡驅動調用Neutron接口建立port，為容器執行個體在子網中配置設定MAC和IP，并把IP綁定到容器網卡（類似nova-compute的工作），然後通知Neutron容器IP配置成功

- 容器平台記錄容器的IP位址，作為進行服務注冊、服務發現、監控服務的基礎

- Neutron和SDN關聯，完成為容器執行個體設定相關的路由政策、防火牆政策等