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

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