今天我將帶來一些關(guān)于滴滴彈性云的分享，內(nèi)容是從物理機(jī)到 Kubernetes 的那些坑與心得。

先簡(jiǎn)單自我介紹下，我叫譚霖，之前在 Intel 從事 OpenStack 相關(guān)的工作，也花了很大精力在開源社區(qū)這方面。

后來我來到滴滴的彈性云團(tuán)隊(duì)，主要從事基于 Kubernetes 的基礎(chǔ)平臺(tái)建設(shè)，可以說是從一個(gè)做菜的“廚師”變成了一個(gè)“食客”。

今天的分享主要分為四個(gè)部分：

• 整體架構(gòu)
• 產(chǎn)品功能
• 方案細(xì)節(jié)
• 心得展望

在我們準(zhǔn)備做彈性云時(shí)，我們問了自己三個(gè)問題：

• 為什么要做私有云
• 為什么選容器
• 為什么選 Kubernetes

為什么要做私有云？因?yàn)榈蔚蔚募阂?guī)模太大，有數(shù)萬臺(tái)物理機(jī)（這樣的規(guī)模量要求我們做一個(gè)私有云平臺(tái)），結(jié)果因?yàn)橹皼]有一個(gè)比較好的方案，造成了資源使用率特別低、資源浪費(fèi)大的問題。

另一個(gè)主要原因是滴滴的發(fā)展太快，總有新的業(yè)務(wù)，隔一段時(shí)間就聽說成立了一個(gè)新的部門，而且隨著新需求的出現(xiàn)，更新迭代異常頻繁，這些都對(duì)平臺(tái)的穩(wěn)定性提出了特別高的要求。

這個(gè)問題靠堆人是解決不了的，所以需要有一個(gè)好的平臺(tái)和機(jī)制來解決它。

為什么選容器？KVM / Xen 這樣的傳統(tǒng)虛擬化已經(jīng)出現(xiàn)多年了，很穩(wěn)定，但大家也知道其弊端，就是損耗比較大。

另外，傳統(tǒng)混部也就是滴滴現(xiàn)在在用的方案（即繼續(xù)保持原有的傳統(tǒng)混部），雖然能夠部分解決資源使用率低的問題，但因?yàn)橥耆珱]有隔離，導(dǎo)致程序之間容易互相影響。

而容器是一個(gè)相對(duì)折中的方案，具有一定的隔離性、損耗更少，這是我們選擇它的最主要原因。

同時(shí)，更重要的是容器的鏡像所帶來的新玩法，因?yàn)殓R像的環(huán)境是一致的，對(duì)運(yùn)維人員特別友好。

因此他們不用再關(guān)心那些紛繁復(fù)雜的配置文件，也不用頻繁地走初始化流程，更不用每次上線更新都提心吊膽，擔(dān)心會(huì)對(duì)新的服務(wù)造成影響。

為什么要選擇 Kubernetes？大家都知道現(xiàn)在比較著名的容器平臺(tái)有 Mesos、Kubernetes 和 Swarm。

一年前我們?cè)?Mesos 和 Kubernetes 之間猶豫過很久，后來主要覺得我們要做的是一個(gè)基于容器的平臺(tái)，相比較 Mesos，Kubernetes 更專注容器。

而 Swarm 當(dāng)時(shí)還很年輕，很多功能不夠完善，相較之下 Kubernetes 更成熟。當(dāng)然更關(guān)鍵的原因是 Kubernetes 的社區(qū)更有活力，設(shè)計(jì)架構(gòu)也更清晰，可拓展性也高。

現(xiàn)在回過頭來看一年前的選擇，非常慶幸我們做了正確的選擇，因?yàn)橹跋噍^于兩者，Kubernetes 還只是旗鼓相當(dāng)，而現(xiàn)在則有一統(tǒng)江山的趨勢(shì)。

我們目前還是基于 Kubernetes 1.6 版本做的改造，接下來 1.8 版本 release 之后，我們會(huì)盡量跟上，保持和社區(qū)同步。

整體架構(gòu)

項(xiàng)目介紹

滴滴彈性云的目標(biāo)就是基于容器技術(shù)，為滴滴提供穩(wěn)定高效、可伸縮的服務(wù)管理平臺(tái)。

先簡(jiǎn)單看看彈性云的項(xiàng)目歷程：

• 2016 年 7 月，彈性云項(xiàng)目正式啟動(dòng)，然后 10 月份出了***版。
• 2017 年 4 月，發(fā)布了第二版。在幾個(gè)月的使用體驗(yàn)中，我們根據(jù)用戶的反饋，不管是產(chǎn)品形式還是底層網(wǎng)絡(luò)方案都經(jīng)過大規(guī)模優(yōu)化。
• 目前第三版也正在開發(fā)中，這一版會(huì)更側(cè)重在用戶交互和可視化上。

截止到目前為止，我們總共有 300 多臺(tái)宿主機(jī)，2000+ 的容器實(shí)例，這不算很多，但目前有多條滴滴核心業(yè)務(wù)線跑在我們的平臺(tái)上，預(yù)見 2018 年規(guī)模會(huì)有指數(shù)型的上升。

整體目標(biāo)

為了解決先前提出的三個(gè)問題，我們的整體目標(biāo)有四點(diǎn)：

• 實(shí)現(xiàn)資源按需分配，提高資源利用率
• 實(shí)現(xiàn)資源的彈性伸縮，可以快速響應(yīng)負(fù)載變化
• 基礎(chǔ)環(huán)境保持一致，實(shí)現(xiàn)服務(wù)的快速交付
• 保證服務(wù)的容錯(cuò)性，實(shí)現(xiàn)基礎(chǔ)設(shè)施免運(yùn)維

解決方案

針對(duì)不同的產(chǎn)品線和需求，我們具體落地的產(chǎn)品解決方案主要分為兩大塊：

• 基于容器構(gòu)建的輕量級(jí)虛擬機(jī)，叫做靜態(tài)容器組。
• 更純粹的微服務(wù)類容器，我們稱之為彈性伸縮組。同時(shí)我們還整合了滴滴現(xiàn)有的部署監(jiān)控和日志收集系統(tǒng)。

如上圖，是整體架構(gòu)，中間***的一塊就是我們的 K8S 集群，它主要分成控制節(jié)點(diǎn)和工作節(jié)點(diǎn)兩部分。

上面一塊是我們的控制臺(tái)和管理員入口，左邊是滴滴的一些現(xiàn)有的權(quán)限認(rèn)證系統(tǒng)和服務(wù)樹，右邊是我們的網(wǎng)絡(luò)方案。

所以按照流程我們主要做的操作是用戶先通過權(quán)限系統(tǒng)認(rèn)證后，創(chuàng)建服務(wù)（也就是 K8S 的實(shí)例），實(shí)現(xiàn)容器的擴(kuò)容縮容和部署更新。

之后我們平臺(tái)就會(huì)進(jìn)行實(shí)時(shí)監(jiān)控和日志收集，完成監(jiān)控?cái)?shù)據(jù)的上報(bào)和鏡像拉取。

剛才說的主要是管理員相關(guān)的工作流程，現(xiàn)在看看用戶流量。首先我們這邊實(shí)現(xiàn)了每個(gè)容器通過 IPAM 組件，都能獲取一個(gè)獨(dú)立的 IP，這個(gè) IP 可以和物理機(jī)雙向互通，所以允許用戶的流量可以直接通過容器 IP 訪問實(shí)例。

同時(shí)我們也提供了一個(gè) 4 層的 LB，允許用戶可以通過只訪問一個(gè) VIP，自動(dòng)把流量打到后面的容器里。

產(chǎn)品功能

接下來詳細(xì)講講滴滴彈性云具體的產(chǎn)品功能。

功能類型

正如之前所說，我們主要提供靜態(tài)容器和動(dòng)態(tài)伸縮兩大產(chǎn)品，同時(shí)伸縮組方面又細(xì)分為有狀態(tài)和無狀態(tài)伸縮組。

其實(shí)在剛開始時(shí)，我們只想提供 K8S 支持得***的 Deployment，也就是無狀態(tài)伸縮，這也是***容器使用習(xí)慣的產(chǎn)品形式。但在實(shí)際落地的過程中，我們發(fā)現(xiàn)完全不是那么一回事。

首先，不是所有程序都能比較輕易地改造成 Cloud-Native 的服務(wù)，所以針對(duì)這樣的傳統(tǒng)服務(wù)，我們還是需要提供一個(gè)比較貼近物理機(jī)的用戶體驗(yàn)的產(chǎn)品，它的問題就是不能彈性伸縮，但好處是可以掛載本地存儲(chǔ)，IP 是恒定的。

同時(shí)為了支持有狀態(tài)的服務(wù)，我們也提高了有狀態(tài)伸縮組。既支持彈性伸縮又支持掛載網(wǎng)絡(luò)存儲(chǔ)。

不過比較出人意料的是，用戶選擇有狀態(tài)伸縮組的很大一部分原因并不是因?yàn)閽燧d Ceph，而是因?yàn)橛袪顟B(tài)伸縮組的容器 IP/HostName 是不變的，這樣不管是從監(jiān)控和日志上，都是更友好的。

而無狀態(tài)伸縮我們這個(gè)當(dāng)初最想推動(dòng)的服務(wù)，也就只有在一些對(duì)彈性伸縮速度有特別高的要求的場(chǎng)景下才會(huì)用到。

功能特性

具體到產(chǎn)品功能的特性上，我們主要有三大塊：

• 復(fù)雜配置簡(jiǎn)單化
• 上線流程標(biāo)準(zhǔn)化
• 服務(wù)管理

復(fù)雜配置簡(jiǎn)單化

了解過 K8S 的朋友們都清楚，它上手很難，有特別多的配置，有時(shí)候反而給用戶帶來了困擾。

所以我們做了減法，簡(jiǎn)化了很多配置，只留給用戶一些接口，避免不必要的困擾。

比如我們支持多種接入方式，既可以一鍵完成從 Git 代碼倉(cāng)庫(kù)到上線鏡像的轉(zhuǎn)換過程，也支持直接通過自定義鏡像。

同時(shí)我們也對(duì)鏡像做了分層（基礎(chǔ)鏡像→環(huán)境鏡像→服務(wù)鏡像），實(shí)現(xiàn) RD 和 SRE 每個(gè)角色負(fù)責(zé)不同的鏡像制作，這樣分工更合理、層次更清晰，做到比較好的權(quán)責(zé)分明、高效有序。

監(jiān)控日志自動(dòng)配置關(guān)聯(lián)也是做了減法，希望用戶較少關(guān)注這一點(diǎn)，從而得到更好的體驗(yàn)。

上線流程標(biāo)準(zhǔn)化

相對(duì)于減法來說，我們也做了很多的加法，因?yàn)槲覀兪且粋€(gè)嚴(yán)肅的運(yùn)維平臺(tái)，之所以強(qiáng)調(diào)嚴(yán)肅，是因?yàn)橹灰腥藚⑴c的地方就容易犯錯(cuò)。

一方面我們要盡量減少人工參與的地方；另一方面又要盡量通過各種規(guī)范來減少人犯錯(cuò)的機(jī)會(huì)。

比如變更審批系統(tǒng)，每一次上線變更都需要開發(fā) leader 的審核；同時(shí)也對(duì)它進(jìn)行了改造，使其每次分組小流量灰度。

每次發(fā)布更新的過程中都有強(qiáng)制的觀察時(shí)間，如果在觀察過程中，比如說你發(fā)布了第二組后，發(fā)現(xiàn)你的更新過程中代碼出了 Bug，我們還支持了一鍵回滾。

服務(wù)管理

在服務(wù)管理方面，我們實(shí)現(xiàn)了服務(wù)不可用自動(dòng)重啟、一鍵擴(kuò)容和負(fù)載均衡等，最為重要的就是對(duì)用戶強(qiáng)制異地多活，必須在我們的兩個(gè)機(jī)房都有實(shí)例。

方案細(xì)節(jié)

現(xiàn)在介紹我們的方案細(xì)節(jié)，主要包括：

• 網(wǎng)絡(luò)監(jiān)控
• 日志
• 鏡像市場(chǎng)

網(wǎng)絡(luò)介紹

SDN

我們的網(wǎng)絡(luò)方案主要是基于 Onos+OVS 的 SDN 網(wǎng)絡(luò)方案，每個(gè)容器都有一個(gè)區(qū)別于機(jī)房實(shí)體機(jī)的 Overlay IP，容器與容器之間實(shí)現(xiàn)“大二層”互通，與機(jī)房網(wǎng)絡(luò)之間通過交換機(jī)打通。

物理機(jī)可以直接通過容器 Overlay IP 訪問容器，反之亦然。

IP

在 IP 上，靜態(tài)容器和伸縮容器都可以進(jìn)行 Hostname 綁定，通過容器不變的 Hostname 保證容器在漂移到其他宿主后 IP 依舊保持不變，當(dāng)容器發(fā)布更新時(shí)，它永遠(yuǎn)保持穩(wěn)定。

對(duì)于 IP 隨機(jī)分配的情況，我們還提供了 IP 池，保證 IP 只會(huì)從 IP 池里出現(xiàn)。

負(fù)載均衡

我們使用彈性云獨(dú)立的 4 層、7 層負(fù)載均衡器，實(shí)現(xiàn)動(dòng)態(tài)的負(fù)載均衡及故障自動(dòng)剔除。

網(wǎng)絡(luò)打通

架構(gòu)

當(dāng)前彈性云容器網(wǎng)絡(luò)大體上分為三種類型：同宿主間的容器通信、跨主機(jī)間的容器通信，以及容器與物理機(jī)間的通信。

每一個(gè)部署容器的宿主機(jī)，都會(huì)部署一套 Ovs 網(wǎng)絡(luò)組建，其中關(guān)鍵的就是兩個(gè) Ovs Bridge，一個(gè)負(fù)責(zé)建立隧道與外界通信，叫 Ovs-tunnel 橋。

一個(gè)負(fù)責(zé)整合本機(jī)上的容器通信，叫 Ovs-int 橋。所有的 Ovs-tunnel 都會(huì)與 Onos 的 Controller 建立連接，負(fù)責(zé)查詢流表并建立流表和其他宿主機(jī)間的隧道。

因此三種通信類型就可以解釋為：

• 同宿主間的容器通信：直接通過 Ovs-int 橋通信，因此也不依賴 Ovs-tunnel 與外界的隧道。
• 跨主機(jī)間的容器通信：***次通信時(shí)，Ovs-tunnel 也會(huì)查詢 Onos，Onos 返回目標(biāo)容器的主機(jī)信息，Ovs-tunnel 通過主機(jī)間的隧道，將容器數(shù)據(jù)發(fā)送到目的容器的宿主機(jī)，目的容器宿主機(jī)上的 Ovs-tunnel 則會(huì)將數(shù)據(jù)繼續(xù)向上一層傳遞，經(jīng) Ovs-int 傳遞給容器。
• 容器與物理機(jī)間的通信：容器發(fā)送物理機(jī)的數(shù)據(jù)包，會(huì)被 Ovs-tunnel 經(jīng)隧道發(fā)送給 Overlay 網(wǎng)關(guān)，Overlay 網(wǎng)關(guān)進(jìn)行 Vxlan 解包的操作，將數(shù)據(jù)傳遞到物理網(wǎng)絡(luò)。

相反地，物理機(jī)發(fā)送給容器的數(shù)據(jù)包，經(jīng) Overlay 網(wǎng)關(guān)把數(shù)據(jù)封包成 Vxlan 數(shù)據(jù)包，再通過隧道發(fā)往容器宿主，再由宿主傳遞給上一層的容器。

網(wǎng)絡(luò) IP 分配

具體到產(chǎn)品上，每個(gè) IP 分配方案如下：

• 靜態(tài)容器組：IP 和 Hostname 恒定。
• 有狀態(tài)伸縮組：IP 和 Hostname 恒定，支持 IP 池。
• 無狀態(tài)伸縮組：支持 IP 池，IP 隨機(jī)分配，靈活度更高。

創(chuàng)建過程

這個(gè)是容器網(wǎng)絡(luò)創(chuàng)建的過程。一旦用戶有創(chuàng)建容器需求時(shí)，控制節(jié)點(diǎn)會(huì)對(duì)整個(gè)集群做一個(gè)調(diào)度，選擇一個(gè)合適的工作節(jié)點(diǎn)，而作為節(jié)點(diǎn)最重要核心的 Kubelet 就負(fù)責(zé)創(chuàng)建容器，控制節(jié)點(diǎn)會(huì)把需求發(fā)給它。

具體創(chuàng)建步驟如下：

• 當(dāng) Kubelet 收到調(diào)度到本 Node 的 Pod 信息后，會(huì)先創(chuàng)建一個(gè)無網(wǎng)絡(luò)配置的 Infrastructure 的基礎(chǔ)容器，此容器用于承載 Pod 中所有容器的網(wǎng)絡(luò) Namespace。
• Kubelet Exec 啟動(dòng) CNIPlugin，并將***步中創(chuàng)建的網(wǎng)絡(luò) Namespace 及 Pod 名稱、容器 ID 等作為標(biāo)準(zhǔn)輸入，傳給新啟動(dòng)的 Plugin 進(jìn)程。
• CNIPlugin 根據(jù)收到的參數(shù)，去 IP Controller 中申請(qǐng)容器的網(wǎng)絡(luò) IP。
• IP Controller 會(huì)判斷該容器屬于哪一個(gè)子網(wǎng)，子網(wǎng)中是否有可用的 IP，及是否有綁定的 IP 地址等，在根據(jù)計(jì)算出的 IP 地址及子網(wǎng)信息等，去 SDN IPAM 端申請(qǐng)?zhí)摂M Port（Overlay IP）。
• IPAM 會(huì)將創(chuàng)建好的虛擬 Port 返回 API 調(diào)用者 IP Controller，并同時(shí)將信息同步給 SDN Onos。
• IP Controller 會(huì)將返回的 Port 保存在自己的存儲(chǔ)庫(kù)中。如果是綁定 IP 類型的 Pod，它還會(huì)將該 Pod 與該虛擬 Port（Overlay IP）進(jìn)行綁定，則下一次該 Pod 再一次進(jìn)行申請(qǐng)時(shí)，仍會(huì)申請(qǐng)到該 Port（Overlay IP）。數(shù)據(jù)保存后，它會(huì)把 Port 信息再返回給 CNIPlugin。
• CNIPlugin 收到 Port 信息后，會(huì)根據(jù)其中的 Overlay IP、Gateway、Vlan Tag 等信息創(chuàng)建 Veth Pair、配置 Veth 信息、配置路由、添加 Ovs-brdge 等操作。
• 至此，本來沒有任何網(wǎng)絡(luò)的基礎(chǔ)容器，就有了網(wǎng)絡(luò)配置（除了與外部通信的 Ovs 網(wǎng)絡(luò)外，同時(shí)也會(huì)添加 Lo 網(wǎng)絡(luò)）。
• CNIPlugin 在成功配置完網(wǎng)絡(luò)后，會(huì)將結(jié)果返回給 Kubelet。
• Kubelet 會(huì)使用配置成功的基礎(chǔ)容器的網(wǎng)絡(luò) Namespace 繼續(xù)去創(chuàng)建其他的業(yè)務(wù)容器，如果配置失敗了，會(huì)繼續(xù)從***步開始，繼續(xù)創(chuàng)建基礎(chǔ)容器，直到網(wǎng)絡(luò)配置成功。

監(jiān)控需求

監(jiān)控主要有兩方面需求：

• 基礎(chǔ)監(jiān)控：基礎(chǔ)監(jiān)控使用了 Google 開源容器監(jiān)控軟件 Cadvisor/Cgroup 作為監(jiān)控?cái)?shù)據(jù)來源，數(shù)據(jù)上報(bào)至 Odin，同時(shí)可在 Odin 和彈性云頁(yè)面上展開監(jiān)控?cái)?shù)據(jù)。

物理機(jī)監(jiān)控 Agent 無法采集到容器有效監(jiān)控?cái)?shù)據(jù)，Cadvisor、Proc、Cgroup 容器基礎(chǔ)監(jiān)控項(xiàng)同物理機(jī)有明顯差異，但用戶的需求沒變。

• 業(yè)務(wù)監(jiān)控：業(yè)務(wù)監(jiān)控同物理機(jī)需求完全一致，復(fù)用物理機(jī)監(jiān)控方式。

這張圖就是彈性云配置監(jiān)控和查看監(jiān)控的示意圖，我們?cè)诿總€(gè)物理機(jī)上有獲取容器的基礎(chǔ)監(jiān)控指標(biāo)，容器里面也會(huì)有獲取業(yè)務(wù)指標(biāo)。

日志需求

日志主要有三個(gè)方面考慮：

• 日志時(shí)效性：在線日志采集延遲 2min，滿足大多數(shù)場(chǎng)景，緊急情況下可以登錄到容器內(nèi)查看日志。
• 日志持久性：生成的容器直接拉到遠(yuǎn)端存儲(chǔ)一份，選擇分布式存儲(chǔ)日志在 Ceph 存儲(chǔ)一份。
• 日志展示：事后追溯有多種豐富的日志展示、分析系統(tǒng)。

這是我們?cè)趶椥栽破脚_(tái)上創(chuàng)建容器的一個(gè)操作日志，也是一個(gè)簡(jiǎn)單的示意圖。

通常用戶都打在容器里，而容器一旦發(fā)布更新，漂移之后數(shù)據(jù)都丟了，所以我們直接把日志打到 Ceph 上，用戶不喜歡用這個(gè)的話可以直接打到遠(yuǎn)端，遠(yuǎn)端采集系統(tǒng)可以使用不同的系統(tǒng)。

比如說 ES 和 HDFS，這樣就提供了更加豐富的日志展示和分析系統(tǒng)。

持久化存儲(chǔ)

存儲(chǔ)主要提供了本地卷和網(wǎng)絡(luò)卷：

本地卷 Host Path 提供給靜態(tài)容器組，我們把宿主機(jī)上的目錄掛載到容器里作為數(shù)據(jù)存儲(chǔ)卷，優(yōu)勢(shì)是穩(wěn)定和讀寫性高。

網(wǎng)絡(luò)卷 Ceph 的優(yōu)勢(shì)是多備份更可靠，支持容器遷移，缺點(diǎn)是網(wǎng)絡(luò)抖動(dòng)不可避免，所以得用 Ceph 的服務(wù)做改造，避免網(wǎng)絡(luò)抖動(dòng)影響整個(gè)服務(wù)的進(jìn)程。

Overlay FS

我們選擇 Overlay FS 作為存儲(chǔ)，一方面是因?yàn)樗男阅?穩(wěn)定性更好，當(dāng)然它也有不足。

比如 DeviceMapper 可以通過 LVM 來解決磁盤的容量限制，但 Overlay FS 單靠本身是解決不了的，需要靠 XFS 來限制。

但我們發(fā)現(xiàn)在某些場(chǎng)景中 XFS 因?yàn)闆]有開啟 ftype 功能，導(dǎo)致系統(tǒng)讀寫緩慢，因此我們建議大家如果也選用了 Overlay FS+XFS 方式，要把 ftype 設(shè)置為 1。

鏡像市場(chǎng)

如上圖所示，鏡像市場(chǎng)主要還是分層，目的是讓不同的用戶可以專注于不同的事情上：

• 基礎(chǔ)環(huán)境鏡像：彈性云管理員制作的鏡像：FROM 官方鏡像，增加了服務(wù)用到的各種 Agent、常用軟件、系統(tǒng)配置（添加 User、日志切割等）的鏡像。包攬最復(fù)雜的周邊應(yīng)用的整合，并兼顧將鏡像做得更小。
• 服務(wù)環(huán)境鏡像：SRE 同學(xué)制作和維護(hù)的鏡像：FROM 基礎(chǔ)環(huán)境鏡像，安裝了服務(wù)運(yùn)行所需的環(huán)境、配置。更加專注服務(wù)環(huán)境的保障，使鏡像滿足產(chǎn)品線的使用。
• 服務(wù)鏡像：使用 RD 代碼中 Dockerfile（一般只需要 Copy 代碼到線上所需目錄即可），F(xiàn)ROM 服務(wù)環(huán)境鏡像，通過彈性云系統(tǒng)生成的提供服務(wù)的鏡像。

心得與展望

心得體會(huì)

首先，特別想強(qiáng)調(diào)的是“云計(jì)算拼的是運(yùn)維，拼的是可靠性”。產(chǎn)品做得再好、運(yùn)維人不靠譜，出了紕漏后就沒人敢再用你的產(chǎn)品了，說得再好也沒用。

其次，“線上無小事，要對(duì)線上保持敬畏感”。我之前是做開源社區(qū)的，解決方案做得多，但現(xiàn)在做云計(jì)算方案時(shí)才發(fā)現(xiàn)實(shí)際與想象的差別特別大，可以說云計(jì)算落地更難。

也許大家看了一些網(wǎng)上的分享后都會(huì)覺得搭建一套容器環(huán)境是比較容易的，可最難的就像我們這樣已經(jīng)有現(xiàn)成的體系。

如果你要把它落地就需要做各種打通、妥協(xié)，甚至對(duì)一些功能做一些切割，有時(shí)這些不是我們想做的，但為了推進(jìn)落地不得不去做。

此外，技術(shù)挑戰(zhàn)是一方面，但用戶習(xí)慣是更加大的挑戰(zhàn)，特別是業(yè)務(wù)方，他們肯定會(huì)說為什么我要遷，現(xiàn)在用得好好的，即便你和他們說做這個(gè)是對(duì)公司省成本的，可以提高運(yùn)維的便利性，他們依然會(huì)覺得我不缺錢，怕麻煩。

再者，他們不是做運(yùn)維的，明顯感覺不到這些帶來的好處。另一方面，有些用戶覺得我上你的云可以，但你不要改變我的習(xí)慣，原來是什么樣現(xiàn)在還得保持什么樣。

但問題是原來是物理機(jī)的用法，可現(xiàn)在已經(jīng)上容器了 ，還想保持原來的方式，這是不可能的。

運(yùn)維是一個(gè)特別苦的職業(yè)，線上無小事，一點(diǎn)點(diǎn)小改動(dòng)，如果沒有考慮清楚、沒有充分驗(yàn)證過回滾方案，那分分鐘要出事，相信大家也深諳此理。

未來展望

對(duì)于彈性云的未來規(guī)劃，***是更細(xì)粒度的隔離。大家對(duì)容器比較了解的話，就會(huì)清楚現(xiàn)在 Docker 更多的是對(duì) Memory 使用量的隔離，以及對(duì) CPU 使用量的隔離。

但實(shí)際過程中我們會(huì)發(fā)現(xiàn)，比如你給用戶一個(gè) 8G 內(nèi)存，在某種極端配置下 8G 內(nèi)存會(huì)不斷地刷新讀寫，那你的 L3 Cache 很快就會(huì)被刷爆了，導(dǎo)致大量的 Cache Miss，這樣的話還是會(huì)對(duì)程序性能造成很大影響的。

第二是靜態(tài)容器的彈性伸縮。因?yàn)殪o態(tài)容器確實(shí)就像虛擬機(jī)一樣，運(yùn)維成本特別高，所以一旦物理機(jī)掛了，容器也就掛了，很多東西是找不回來的。

而且你要擴(kuò)容也只能按照傳統(tǒng)的方法，先申請(qǐng)一個(gè)容器再去上面做部署、配置等，這些都會(huì)給運(yùn)維同學(xué)帶來非常大的困擾。

第三是更智能的擴(kuò)容算法。目前我們是根據(jù)實(shí)時(shí)的使用率來進(jìn)行擴(kuò)容，但其實(shí)對(duì)于我們來說，很多業(yè)務(wù)高峰期是有規(guī)律的，如果能做到提前預(yù)測(cè)出高峰期，做適應(yīng)的擴(kuò)容，那將會(huì)極大地提高資源使用率。

最重要的一點(diǎn)是依托社區(qū)、回饋社區(qū)。我們打算騰出手來，把一些定制化需求不是那么高的解決方案來回饋到社區(qū)。

[[224427]]

譚霖，滴滴出行彈性云架構(gòu)師、云計(jì)算專家，曾任職于英特爾從事云計(jì)算方向研究。OpenStack Ironic 項(xiàng)目核心開發(fā)者，《OpenStack設(shè)計(jì)與實(shí)現(xiàn)》作者，多次在OpenStack Summit SRECon 峰會(huì)上分享 Topic。目前從事基于 Kubernetes 的私有云平臺(tái)的研發(fā)，專注提高服務(wù)的穩(wěn)定性和研發(fā)、運(yùn)維效率。