關於容器遷移、運維、查錯與監控，你想知道的都在這裏了

做者 | 邱戈川（了哥）  阿里雲智能雲原生應用平臺部高級技術專家

本文根據雲棲大會全面上雲專場演講內容整理，關注阿里巴巴雲原生公衆號，回覆「遷移」得到本文 PPT

今天上午王堅博士講了一句話我比較有感觸，你們作系統的時候，必定要想下你的系統的數據是怎麼流轉，這些系統的數據是怎麼造成閉環。咱們在設計阿里雲的 K8s 容器服務 ACK 的時候也是融入了這些思考。

容器遷雲解決方案一覽

首先是和你們先看一下整個容器上雲的解決方案。首先由於你已經作過容器，因此當你容器上雲的時候，實際上這個事情是很是簡單的，咱們只須要提供的相應的工具，幫助你們把容器鏡像遷入阿里雲同時經過工具把 K8s 的配置遷到阿里雲，以及能夠用 DTS 工具把數據庫遷入到阿里雲。這樣咱們就能夠完成一個完整的容器化上雲的過程。

因此這個過程其實很是簡單，可是上完雲以後，不是說咱們的 K8s 原來怎麼玩如今仍是怎麼玩。咱們但願你們從上雲的過程當中有些收益，因此咱們但願提供一些更高效敏捷的一些方式給到你們，包括怎麼去作 DevOps，包括咱們怎麼去作安全的軟件供應鏈，以及咱們作灰度發佈。

同時咱們但願成本更優一點，關鍵是你們上完雲以後的成本怎麼去核算，以及怎麼去節約。因此容器上雲後咱們怎麼去作更好的彈性伸縮、作自動化的運維，這個是你們須要在上雲的過程當中去考慮的問題。同時咱們須要更好的管理咱們的系統，必定要作到更好的高可用，並且要作到一個全局的管理。包括如今不少的公司已經在作混合雲管理，這個也是你們在上雲的過程當中須要考慮的問題。

阿里雲的 K8s 容器服務 ACK 到底長什麼樣，給你們一個概覽圖：

中間的 K8s 部分就跟你們去玩開源自建是一個道理，這個 K8s 沒有什麼本質上的區別。可是上了阿里雲以後，咱們但願給到你們的是一個完整的體系，而不是單單一個 K8s。因此咱們會把底下的部分跟咱們的 GPU 服務器、跟咱們彈性計算 ECS、跟咱們的網絡 VPC、跟咱們的 SLB 打通。這個在上完阿里雲 ACK 以後，咱們一鍵的方式把它所有集成好，因此你們不用再去關心阿里雲的 IaaS 層應該怎麼去作，咱們但願給你們屏蔽掉這一層複雜性。

存儲也是同樣的道理。存儲的話，就是全部的阿里雲的存儲咱們所有都已經支持完了，可是如今咱們還在作什麼事情？咱們在把阿里雲的日誌服務、阿里雲的中間件服務，包括咱們 APM 的 ARMS、咱們雲監控、以及咱們高可用服務 Ahas 等所有對接在一塊兒，讓你們有一個更高可用的環境，以及一個更安全的環境。

咱們給到你們一個 K8s 仍是個原生態的 K8s，你們可能會問咱們你的 K8s 跟我本身的 K8s 到底有什麼區別，因此仍是很簡單的回答你們這個問題。首先咱們在上雲的過程當中給到你們永遠是一個非雲廠商鎖定的 K8s。就是你在線下怎麼玩 K8s，在線上也能夠怎麼玩 K8s。若是你哪天你想下雲的時候，你同樣是能夠下去的，因此這是咱們很堅持的一個宗旨，就是咱們不作任何的鎖定。

是咱們會注重什麼事情？

• 首先咱們會去考慮怎麼作好安全，就是當你的 K8s 有問題時，咱們怎麼作快速響應，作 CVE 快速修復，而後咱們怎麼去打補丁，咱們怎麼作安全加固；
• 第二就是咱們跟阿里雲的整個生態作結合。由於阿里雲是咱們更熟悉，因此咱們跟阿里雲的底層技術設施怎麼打通，這個事情咱們本身會作得更好一點。

咱們如今也跟神龍服務器在一塊兒，咱們知道怎麼讓神龍服務器發揮更好的性能。同時咱們還有不少創新，這樣能夠幫助你們更好的作好彈性。最重要的一點其實是：咱們作了那麼久，已經積累了超過幾千家的在線客戶，這也是咱們最大的優點。因此咱們從幾千家的客戶裏面濃縮回來你們所須要的最佳實踐，咱們收集完、整理完以後要返回給你們，幫助你們去用 K8s 上生產，這也是咱們給客戶最大的一個核心價值。

容器上雲之「攻」

上完雲以後，怎麼用好 K8s？怎麼提高你的整個管理能力、提高你的系統效率？這個是咱們要講的「進攻」的部分。咱們主要分三個方面去講：

• 第一個，怎麼跟咱們阿里雲的裸金屬服務器作結合；
• 第二個，咱們會提供性能比較優化好的網絡插件 Terway；
• 第三個，怎麼作好靈活的彈性。

物理裸金屬服務器神龍

神龍裸金屬服務器已經跟咱們的容器平臺 ACK 作了無縫融合。它最大的好處是什麼？在容器化的時代，咱們不須要再去考慮虛擬化的問題。因此二者的融合基本上是一個零虛擬化的開銷的方案，容器直接使用到物理上的資源。在咱們的神龍服務器裏面，給到你們的其實是個真實的 Memory 以及真實的 CPU，但它由於使用了阿里雲專有的 MoC 卡技術，因此它能夠直接對接到阿里雲的雲盤、對接到阿里雲的 VPC 網絡。這樣的話它的體驗跟全部的 ECS 是一個道理。

這樣容器化去作資源切割的時候，咱們就不會再受虛擬化的影響。同時，它帶來了另一個好處就是它有一個 offload 的技術。這樣網卡的中斷會下沉到下面的這張卡上去，當你的流量比較大的時候，它將處理全部的網卡中斷的開銷，並不開銷你自己的 CPU，因此咱們能夠獲得一個更極致的計算性能。

同時由於它的密度比較高，它基本上是個 96 核的機器，當它加入容器集羣以後，這個集羣的容器的密度相對來講會比較高，因此它成本節約會比較好一點。另外，它是整個阿里雲彈性計算資源裏面最高規格的網絡帶寬，單獨給 30G 的網絡帶寬帶給到 VPC，同時有 20G 的網絡帶寬留給雲盤。這樣你們能夠比較好的去部署高密度的容器，同時它仍是能夠支持跟 ECS 是混搭組建集羣的。這個特色在彈性場景裏面特別高效。你平常的流量能夠用到神龍服務器去構建，當你要去作動態伸縮的時候，你能夠用 ECS。這樣兩種彈性資源一塊兒使用會幫助你們把成本作到最優。

性能優化網絡 Terway

另一個方面，就是網絡支持的狀況了。網絡的話是由阿里雲首創的 Terway 網卡的多 IP 方式。實際上咱們利用了阿里雲裏面的 ENI 的彈性網卡來構建咱們的容器的網絡，這樣的話咱們能夠用一個 ENI 來支持 10 個 IP，來構建咱們的 POD 網絡。它最大的好處就是它不會再受 VPC 路由表大小的約束。POD 跟你的 ECS 或者神龍服務器在同一個網絡平面，因此它的網絡中轉開銷是很是小的。

同時咱們還支持了 Network Policy，就是 K8s 裏面標準的 Network Policy，以及咱們擴展了帶寬限流。這樣的話也是避免你們不知道怎麼去作網絡內部的 POD 跟 POD 之間的安全管控，以及去作 POD 之間的網卡的帶寬的約束，避免一個 POD 能夠打爆整個網卡，這樣的話就會比較好的去保護你的網絡。而這個只須要添加 annotation 就能夠完成，不影響 K8s 的兼容性。

靈活彈性

最後一個就是咱們要去作靈活的彈性。作 K8s 有個說法：你不作彈性基本上就至關於沒玩 K8s。因此，咱們給你們提供了一個完整彈性的體系，除了標準的 HPA 去作伸縮 POS 以外，咱們實際上還提供了阿里雲開源的 CronHPA，就是定時的方式來支持你們去伸縮 POD。咱們還提供了額外的指標，來幫助你們按指標的方式來去作彈性伸縮。包括咱們日服務 SLS 裏面提供的 Ingress Dashboard，拿到你的 QPS 以及 Latency，或者從咱們的 Arms、Ahas 拿到你的每個 POD 流量的狀況，每一個 POD 延遲的狀況來作對應的伸縮。

由於你們知道你的程序可能開發出來以後，不必定能那麼好的完美地去適配 CPU。也就是說不是你全部的 POD 都可以按照 CPU 的方式來作伸縮，這個時候你就須要根據咱們提供的額外指標的方式來作伸縮，這是公有云裏面給你們一個比較好的彈性的方式。

另一個問題就是，當你的資源不夠的時候，你可能就須要買更多的機器來支持容量，這個時候咱們提供了 Autoscaler，它會對接阿里雲的 ESS 來幫助你們自動化的方式來夠買機器，而後再從新擴容。經過這種方式，來幫助你們作好自動化的運維。

可是這裏也有一個問題，你可能但願這個伸縮速度會更快。可是從購買臺機器到冷啓動再到加入 K8s 集羣，而後再去擴容器這個時間會比較長，若是你的業務是一個突發業務的話，可能你等不及機器伸縮。爲了適配這個場景，咱們如今又融合了阿里雲的 ECI，利用彈性容器實例來作這個事情，咱們作了一個虛擬化的 Kubelet，來對接 ECI。這個時候你們不須要再去買機器，你能夠直接用擴容的方式去作就行了。

因此它最大的好處是什麼？就是說你不須要額外買機器，你只須要根據你的業務的狀況下，直接伸縮容器，它會到 ECI 的池子裏面去找到對應的空閒容器，而後掛到你的集羣裏面去。當你不須要的時候，它更快，它直接就能夠釋放掉了。由於你們知道，若是你是普通的方式，你還要等那臺機器全部的容器全釋放才能夠釋放機器，這時還有一個時間差。


你們知道，彈性好最耗錢的地方就是時間。因此咱們用最快的方式來幫你們去節約掉這個成本。同時你們若是用這樣的方式，還能夠不去作容量規劃，由於不少時候很難去作容量規劃。若是今天有 100QPS，明天又有 1000個QPS，我不知道這個容量怎麼作，這個時候利用 ECI 的技術，你們就能夠避免這個容量規劃了。

固然我前面提到，阿里雲 ACK 制定了不少自定義的指標，因此你們只須要去配置對應的定製指標，根據 QPS 也好，平均 Latency 也好，仍是 P9九、P999 這些相應的最大延遲指標，以及你的入口流量的指標，來作相應的伸縮。因此你們只須要根據這些指標來配置對應的 HPA 的擴容伸縮就能夠了。這樣的話，你們比較容易去找到適配你業務場景的方式。特別是對於電商場景來說，若是你們比較有經驗的話，你們不少時候根據 QPS 去作是比較合理的。

另外，伸縮不是作某一個業務/應用的伸縮。你們必定要記住一點就是：伸縮必定是一個一體化的聯動性的伸縮，因此你們必定要從接入層到服務層同時考慮伸縮性。咱們利用了 Ingress Dashboard 的指標(後面監控會提到)，拿到了 QPS，能夠伸縮咱們的接入層，同時咱們能夠根據 APM 的系統，就是像阿里雲的 ARMS 這樣一個系統，拿到對應的 Latency 來伸縮咱們服務層。這樣的話，你們能夠構造一個聯動性的全局性的伸縮。否則極可能你在入口層面上作了一次伸縮，直接把流量倒了進來，最後打爆了你的服務層。

你們必定要考慮這一點，就是全部的伸縮必定是聯動性、全局性的。

容器上雲之「守」

前面講了，咱們怎麼去更好地去作管理？以及咱們有什麼好的方式來提升咱們的性能？第三部分的話給你們講一下怎麼去作防守，主要有三部分：

• 怎麼作智能化運維；
• 怎麼作安全體系；
• 怎麼去作監控體系。

智能化運維

從管理角度來說的話，你們不可或缺的點就是必定要去作灰度。從接觸的狀況來看，不少同窗實際上並無徹底作到全灰度才上線。但在阿里雲這個是強制要求，在 K8s 裏面有方便的方式，你們能夠用 Ingress 的方式來作灰度。其實比較簡單，就是你們原來有一箇舊的服務，那從新啓動一個新的服務，都掛同一個 Ingress 上。那你在 Ingress 上面配置流量分割。能夠是 90% 的流量割了舊服務，10% 的流量給到新的服務，這樣的話，Ingress 會幫你作一個分流，這是比較簡單的一個方式。

可是這裏面還有個問題：你們怎麼知道何時能不能把 90% 的流量再切割10%流量過去新服務，讓 10% 變成 20%？這個是你們目前比較痛苦的一個地方。由於不少時候發現不少同窗，他們最多見的方式是什麼？就是找了一個測試同窗過來，幫我測一下新的服務到底 OK 不 OK，若是 OK 它就直接將 90% 的流量降低到 80%，將 10% 的流量漲到 20%，但當它漲上去的時候你的系統立馬出問題。

由於什麼？由於你沒有很好的依據去作這個流量的切割，你只是去看測試結果，只是看了當時那一刻到底對仍是不對，而不是全局性的來看。因此在阿里雲的 K8s 裏面，咱們會幫助你們集成好對應的灰度監控，而後幫助你們去作好可依據的灰度。咱們會同時幫助你們去對比新的服務、舊的服務、當前的流量、平均的延遲、錯誤率、成功率、最大的延遲等等。經過這些去看新服務究竟是不是已經知足你的真實的要求，以這個對比的依據來看，你流量的是否應該再繼續切割。

就像剛纔這例子同樣，新服務 10% 要變成 20%，極可能你的延遲已經在增大、你的錯誤率已經在升高，這個時候你並不該該再去增長流量，而是要作回滾。你們必定要記住一點，就是咱們在運維的過程當中，必定要作到運維全部的動做必定要有依據。因此咱們利用 Ingress Dashboard 給你們去作相關有依據的灰度。

另外是給你們作好對應的主機上在容器層面上的對應的監測和預警。在開源體系裏面有一個組件叫 NPD，而後咱們阿里雲又開一個事件告警器叫 Eventer。咱們把這兩個東西打成了一個 Helm 包，在應用目錄裏面提供給你們。你們能夠作好相應的配置以後，當你發生 Docker 掛了、當你發現主機時間同步有問題，或者程序沒開發好形成 FD 被打爆，這個時候咱們會把相應的通知，經過釘釘的方式發給你們。

你們必定要記住在上完容器以後，你還在容器層面上的主機層的監控，跟你普通的非容器的主機監控是有區別的。因此你們接下來必定要想辦法把容器層面的主機監控再從新補回去。

另外，咱們還一直在深化去作一些智能化的運維。例如容器上雲後還必須作一些相關優化的配置。你們知道，上雲以後，K8s 應該用什麼機器？用什麼的 SLB？用什麼網絡？這些東西都須要作一個選優，根據你的業務場景去作選優，怎麼去選呢？咱們會作一些相關的優化的推薦，幫助你們去作一些相應的深度的監測，你到底有沒有改過哪些配置，哪些配置被你改錯了等等。

若是有一些錯誤的配置，智能運維會提醒你要去作一些糾錯，減小你們後期發現錯誤的糾錯高成本。這一塊，咱們還一直在深化中。

安全與信任

「防守」的第二件事情是要作安全。上雲以後，你們會以爲就主機層面上的安全不必定夠了。因此在容器管理層面上你們還須要去看看這個安全應該怎麼作。安全的話，就是你們仍是要記住一點就是安全必定要作全方位的安全，你們不要把安全認爲是一個很小的事情，特別是不少公司是沒有安全團隊的，因此這個時候運維要承擔好這個職責。

安全的話，咱們主要是分三個方面來作安全。

• 第一就是「軟性安全」，例如社區層面的合做，而後是阿里雲安全團隊來幫咱們作相應的一些「加持」，同時咱們也會給客戶作一些按期的安全的賦能。

• 另一塊的話就是 IaaS 層的安全，咱們會作一些 CVE 的修復。咱們還有阿里雲本身的 IaaS 加固，以及咱們如今還有鏡像漏洞掃描。阿里雲的鏡像倉庫已經支持了鏡像掃描，因此這裏也提醒你們：每次上業務、上生產以前，務必作一次鏡像掃描，全部的開源社區提供的鏡像均可能有漏洞。因此怎麼去作好這些漏洞的防禦，你們必定要下好功夫。同時咱們提供對應的磁盤的加密，這一塊你們能夠作好數據的加密。

• 在 K8s 運行層面的話，咱們團隊作的更多的是在 K8s 審計日誌方向，咱們過會兒講一下。包括咱們會有更嚴密的 K8s 的這種安全的配置，以及咱們會去作容器運行時的實時安全監測。你們有興趣的話，能夠看看阿里雲安全的產品，他們已經支持了安全運行態的這種實時檢測。

同時咱們還支持安全的管控，就是全部的安全配置咱們都是雙向認證。特別強調一點就是從管理層面上來說的話，咱們會作好對應的整個平臺的安全管理，這裏更多的是針對內控。你們知道，實際上真正能偷盜你數據那我的，最容易的那我的是大家公司運維裏面最有權限的那我的。因此，這裏面纔是你們平常須要重點管控的一個地方。

咱們把全部可以接觸到 K8s 的入口，都作了一層安全審計。除了安全審計落日誌的同時，咱們還提供了不少預置的安全的審計項來幫助你們作預警。這裏舉一個例子，就是假如你的 K8s 有安全性的入侵、有人進入你的容器，咱們會給你們落審期日誌，包括究竟是哪一個用戶用了什麼命令進入了哪一個容器。同時你們能夠去配一個釘釘告警，一分鐘內咱們會把這個告警給告出來，這樣你們就能夠知道有人進入你的容器環境了。

這樣確保整個 K8s 環境足夠的安全。原則上是這樣的，就是你們去用 K8s 的時候，在生產系統裏面不該該在有人可以進入容器，因此必定要提醒你們作一點防範。

另一點你們比較難作的地方就是人員的變更。人員變更以後，他這我的對系統在以前的時間內作過什麼事情，你們有沒有清楚？因此，一樣的道理，咱們會提供人員審計視圖，根據人員子帳戶進行搜索審計的信息。這樣的話，你們對內的安全管控是比較容易去作的，你只須要輸入他使用的子帳戶名字，咱們會幫助你把他全部 K8s 的操做都列出來。這樣就避免有人偷你的數據到外面去了，而不是兩三個月後你還不知道。因此這個是幫助你們去作好人員離職的管控。安全層面上的話，你們務必要把審計日製這個事情看得比較重。

一體化監控體系全鏈路分析與定位

最後給你們講一下，咱們怎麼去作整個監控體系，以及整個鏈路分析體系。整個監控體系的話，是很是的龐大。由於你們知道，不少同窗在 IDC 裏面自建 K8s 也好、仍是在雲上玩也好，只會去考慮 Prometheus 監控架構爲主。但實際上，在上完阿里雲以後，咱們會幫助你們作好整個 K8s 的監控體系以及鏈路分析。

首先是咱們從全局的角度來說，會去給你們展現一下你整個 K8S 層面上，到底有多少個網絡單元、有多少個 ECS、有多少個 SLB，而後你機器部署的狀況什麼樣子。

(Demo 演示圖)

咱們底層會依賴於阿里雲的雲監控，以及剛纔說的 NPD 的組件。中間這層仍是標準的 Prometheus 架構。可是這裏 Prometheus 架構很是耗費資源，因此咱們會把它剝離出來做爲一個託管的服務來提供，避免你們在集羣規模愈來愈大的時候，Prometheus 會把資源從新吃回去。

頂層的話，咱們會給你們提供對應的 ARMS 以及 SLS 的 Ingress Dashboard 的監控。

咱們細看一下整個流程應該如上圖所示，你們必定要把全部的監控體系，以及鏈路分析體系構建完整。包括你從前端進來，到 Ingress 入口，而後到中間的 Prometheus，再到應用層的監控 Arms，最後落到代碼層面上的執行效率仍是錯誤。你們必定要把這個鏈路鏈條構建出來，這樣可以幫助你們在出現問題的時候，立馬找到問題根源。在互聯網體系裏面，你們的每一次的問題，解決所帶來的時間開銷，就是你的成本。

前面剛纔提到了，在應用層面的話，咱們給你們預置了日誌服務 SLS 提供的 Ingress Dashboard。由於你們知道，從 Ingress 是全局的流量入口，你們一般的作法是：都去構建一個龐大的 ELK 系統作監控，這個成本是至關高的。咱們會幫助你們只須要落盤到咱們的阿里雲的 SLS 的服務，就會把所有 Ingress 監控指標構建出來，包括你當天的 PV/UV；包括你如今延遲的狀況；包括你上一週以及昨天的同時間的一個 PV/UV 的對比；包括你流量的 TOP 的省份、TOP 的城市；包括你最後錯誤的以及最高延遲的地方，有 500 錯誤發生的地方在 URL 是什麼。咱們把這些東西所有給你們作成一個大的 Dashboard，這樣你們能夠以成本最低的方式來看你的整個系統的運行狀況。同時這個 Dashboard 是支持擴展的，目前這個也是如今上阿里雲 ACK 的時候，你們很是喜歡的一個東西。

若是咱們要對服務體系作監控的話，可能你們要去考慮怎麼接入 APM 系統了。這一部分，咱們以前發現不少同窗最痛苦的地方在於：不少業務開發的同窗其實並不喜歡作接入。由於他去作接入的時候，你要給他一個 jar 包，而後他要在程序裏去引入這個 jar 包，從新打鏡像才能上線，這個是其中一個繁瑣的環節。

另一個環節就是你們其實最討厭的地方就是當你的 APM 系統升級的時候，你要求全部的業務人員所有更新換 jar 包，要從新打包鏡像、從新上線，業務開發人員就是很是惱火了。因此在容器時代的時候，咱們作了一個比較簡單以及優雅的方案：咱們提供一個應對的 helm 包給你們，作好相應的部署以後，只須要作一個事情：你在發佈容器的時候打上兩個 Annotation 咱們就自動作好 APM 系統(阿里雲 Arms)接入了。當你要作升級的時候，只須要把那個應用從新作一次發佈，它自動用最新的 jar 包把那個舊包給換掉了。

因此在運維階段，你們就能夠去決定要不要接入 APM 系統，而不須要開發的參與，甚至咱們連開發包都不須要給到開發。你們也能夠用一樣思路，在接入外部系統的時候，思考怎麼作到一個無侵入的一個方式。

剛纔提到了，咱們其實是支持了 Prometheus 的託管。原來你們在 K8s 裏面去作 Prometheus 的話，須要構建一堆的組件，而這些組件是很是耗費資源的。因此咱們如今的作法就是提供一個 Helm 包給到你們。這樣的話，你們只須要簡單的一鍵安裝，就能夠用到阿里運託管的 Prometheus 服務。而後經過託管的 Grafana 方式去看相應的數據、去作相應的告警。這些都是在後臺作了，跟你整個集羣沒有任何關係，這樣你的集羣資源是最節約的也是最穩定的。

「 阿里巴巴雲原生微信公衆號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術公衆號。」