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

本文根據云棲大會全面上云專場演講內容整理，關注阿里巴巴云原生公眾號，回復“遷移”獲得本文 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 也好，還是 P99、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等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的技術公眾號?！?/strong>

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的关于容器迁移、运维、查错与监控，你想知道的都在这里了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。