<a target="_blank"></a>
目前，容器的占有率可能比想象中還要快地增長，這個是使用 docker 鏡像的受歡迎的程度，可以看到幾個排在前面的。然後平均一個公司有多少容器在跑，隻有 7 個。但是在 06 年的時候，5 個都不到，其實增長還蠻快。
我覺得這個圖挺有意思的，講的是一個容器的平均生命周期，比較的是容器和未來的生命周期，容器的平均生命周期是 2.5 天，vm 是 23 天，這 2.5 天裡面分了兩部分，一部分是用了編排，一部分沒有用編排。如果使用者沒有用 k8s 工具，平均的容器生命周期是一天，但是用了 k8s 編排，生命周期是5天，但是這個資料代表了什麼意義呢？這個資料最直覺的意義是成本，也就是說你用 docker 也好，用 vm 也好，你可能解決同樣的問題，因為 vm 的建立，或者各方面的因素，導緻你上手的代價挺大，是以懶得删除了，容器的話很容易，更容易讓你删除它。從某種角度上講，你做同樣一件事情，你用容器的成本是用 vm 的 1/9。
我覺得這個資料稍微有點誇張，實際上我們内部和使用者的資料體驗來看，用容器比 vm 成本降低 50% 一點問題都沒有。通過這麼一組資料，我想表達一個觀點，雲計算的下一個時代已經是來臨了，而不是三年前說可能是容器，這個資料告訴我們，下一個時代就是容器時代，毫無質疑。
容器時代，容器的優點是啟動快，應用友善，在虛拟化時代，它的安全是強隔離的，生态也是比較完善，因為經過十年的發展，虛拟化的網絡、存儲都是相當成熟的。
我們做一個什麼事情呢？我們做了把虛拟化和容器結合的工作。我們怎麼做？為什麼這麼做？容器最大的問題是隔離性的問題，畢竟是說它用的技術，理論上存在很多容器逃逸的可能性，曆史上發生很多，在一個實體機上起兩個容器服務的時候，服務 a 和 b，a 可能很容易逃脫主控端，拿到容器 b 的資料的權限，因為容器的權限管理很難做，權限給的少用起來不舒服，給得高，應用很容易逃脫。但是這個問題在私有雲裡面其實并不嚴重，因為我們在自己的公司裡面我們都相信自己開發者開發出的應用是比較安全的，不可能 a 部門的應用讀到 b 部門的東西，我們有自己的代碼稽核機制，安全防範機制，公司内部用傳統的容器部署方案沒有問題。
公有雲上不可能。因為我們永遠不知道來的使用者是什麼人，什麼目的，可能是搗亂的，是以我們認為公有雲上的使用者，應用是不可信的，我們要在公有雲上給我們使用者提供完整地，安全的服務，讓我們怎麼做，我們仔細分析 docker，兩部分組成：第一部分是容器部分，用來做隔離，第二部分是 docker 最創新的地方，用分層的方式存儲，可以利用檔案系統分級存儲，能夠快速啟動一個容器，其實這個才是 docker 的精華。因為我們想為什麼我們啟動虛拟機的時候會慢，慢是有原因的，因為你拉一個鏡像就慢了，或者給鏡像備份的時候。你這個應用大了，鏡像大了，可能會使整體應用慢一些，我們就改寫 kvm，讓 kvm 适配docker 的鏡像，這樣我們利用了虛拟化的安全生态和它的成熟度，同時又保留了容器的啟動、體積和應用的優勢。
可以看到其實我們做的事情，我們其實，我們的底層還是一個 hypervisor，我們的容器雲不能簡單說是容器雲，為了友善大家了解叫容器雲，我們跑 app 的空間不是 container，大家知道啟動一個虛拟機比較慢，可能要好幾分鐘，如果大家在公有雲用過雲主機的話，建立雲主機時間比較慢，為什麼慢？其實這個慢的過程，跟 kvm 關系不是特别大，關系在于，啟動一個 vm 的時候，他認為自己是一個機器，要做很多的引導程式、引導檢查這種工作，會導緻變慢，但是你在實體機裡面的虛拟機，很多工作可以不用做，是以我們在這邊啟動 vm 的工作進行了簡化，同時在，這上面是傳統的啟動 docker 的流程，下面是我們啟動自己的，叫京東容器 container 的技術。
前面介紹一下我們怎麼做容器雲服務的，我們在容器雲服務裡面怎麼跟 k8s 結合的。我們對 k8s 改造并不是那麼大，大部分用了 k8s 原生的組建和架構，我們隻是把容器的運作時換了，裡面本來有多個 container，我們換成 jcloudcontainer，其他的服務并沒有大動。
右側可以看到，我們跟公有雲綁定的，我們的多租戶驗證與授權管理自己做的。另外，網絡和存儲，網絡接自己開發的 sdn 網絡，jcloudcontainer，跟公有雲上建立的雲主機，可以放在一個裡面，我們支援vm和容器互相通性，每個 jcloud，帶來便利性，可以放在一塊，持久性的存儲，我們用的是自己的硬碟，jcloudcontainer 用的硬碟如果不用了，也可以插到雲主機上用。
是以在我們的京東雲裡面，容器和主機是對等的一個關系，他們都是一等公民，在容器和主機下面，才是我們的雲硬碟，我們的網絡，監控也是一樣，用統一的跟雲主機一樣的子產品。這個圖可以讓大家很友善看，我們現在容器雲服務，京東雲容器服務，跟一些傳統的其他家或者業界其他做法不一樣，如果我們說，如果在一年前，我們說自己用虛拟機搭一套 swarm 的話，肯定去公有雲廠商裡面啟動一系列的虛拟機，再做。
接下來介紹京東雲的實踐之路，介紹我們京東内部是怎麼做容器的，同時講講内部做容器跟我們在公有雲上提供容器服務有什麼差異點，以及我們使用者是怎麼用容器雲的，我們有世界上最大的容器叢集之一，20 萬的容器叢集，保證了京東 618，雙 11 大促，内部 99% 做了容器化。
内部的做法也是非常标準的做法，本質上并沒有跟其他廠商有什麼差別，隻是在内部的容器化的過程中，我可以講講我們經曆，因為我們最早還是做虛拟化的。然後在虛拟化的基礎上我們做了很多工具，包括我們的子化部署，統一的監控，日志收集，服務發現，整體的管理都是有，我們第一部接觸容器的時候沒有現在這麼徹底，這是最終的圖，之前我們采取的做法是，為了減少損耗和風險，我們之前幹的第一件事情是把 vm 換成一個容器，先把事情做了，那個時候就是把 vm 換容器最主要的目的是什麼呢？主要是把容器用在輕量級隔離，速度和帶來的損耗比較少。
第二，容器是隔離技術，對我們重要的一點是可以動态地調整 cpu 記憶體不影響應用，對大公司很重要，因為很多申請的時候，說 32 核，64g，整體運維沒有反抗的餘地，他說不給我那麼多，影響業務，造成我們資源浪費，資源可調整之後，就友善了。但是我們并沒有把 docker 的精髓用起來，因為 docker 不僅提供了隔離的方案，還提供了應用分發，還要把我們的自動化部署，把代碼和價包拉過來，比較費勁，1.0 過後，到 2.0 的時候，就完全變成真正的容器的k8s的叢集，應用也是達到了鏡像裡面了，不是到我們上面自動拉東西了。
然後我講講我們非常典型的應用，就是在容器雲内測的，我們已經開始内測了，非常典型的應用就是資料采集，直白一點就是爬蟲，都叫資料采集，爬蟲比較敏感。爬蟲是非常适合用容器做的場景，因為爬蟲的應用特别容易做分布式，可能每個應用都長得一樣，它的任務可能是爬一個網站，爬完之後就銷毀，對于爬蟲而言，最大的問題還是在于 ip 的問題，因為爬蟲和反爬永遠是業界的兩個熱點，很多人對網站的資訊不喜歡被爬，有反爬機制，一段時間的通路請求次數有控制，是以我們提供了很豐富的ip池，包含 100 個 c 的 ip 池，前面兩條，靈活這個我們容器解決，但是 ip 這個問題，我們要靠一個大的 ips 解決，每個使用者到我們這裡申請 ip 的時候，我們配置設定得比較均勻。有可能對方把你這個 c 封了，我們有大的 ip 池之後。
這個其實我覺得有點像雲計算分時租賃的味道，每個使用者去爬取的網站不一樣，使用者a爬新浪微網誌，但是使用者b爬的是淘寶，被新浪微網誌的ip也可以通路淘寶，我們對每個使用者有黑名單的 ip，可以打一個 tab，下次申請新ip的時候，如果帶上新浪這個我不會把黑名單的ip池配置設定給你，使用者有自己分組的黑名單，保證你的 ip 可用，保證你不會拿到被扔到 ip 池的 ip。
下面，我們内部用的微服務，這個概念，大家一定耳熟能詳了，我們也一樣，我們内部，在京東雲上提供的微服務，通過我們的容器的部署去部署上去。當然我們框裡面都是微服務，後面像資料庫、日志是用 docker 部署的，不能适用于微服務，我講講 docker 為什麼和微服務結合得很緊密，确實說微服務是 docker 非常好的應用場景，剛才說的爬蟲的例子，也是可以很好用容器解決的。很多裡面，容器剛好解決了微服務的很多痛點，包括容器共享，大家可以看到，他最少可以做到一個 c 4 兆，小對小剛好比對上了，每個容器是單獨獨立的，而且說它是跟應用綁定的。我們有一個使用者是做機器學習和基因研究的，他們團隊裡面有很多個不同部門的工程師，每個工程師用的工具鍊，工具包完全不一樣。
他們運維直接崩潰了，因為每個小組需要的語言和工具鍊不一樣，給每個應用安裝部署花很多時間，用容器化就特别容易做這個事情，直接每個小組部門容器化，做微服務的時候，不應該強制每個服務用同樣的語言去出現，因為你微服務做得夠小，有些微服務需要高效的，有些不需要，不同的微服務需要不同的語言解決反而會提高效率，開發環境和生産環境相同。然後應用是一體化的，那你以前整個微服務的，代碼和業面可以共用一套管理體系，我們做微服務的時候希望微服務快速響應，多的時候啟多一些，少的話小一些。
縱向的擴容就是記憶體調整，我們用 container 的技術。最重要的還是省錢，不管是微服務還好，容器服務也好，最終的目的是提高整個團隊開發的效率，部署的效率，我覺得給大家講一個我的了解和概念，其實用容器和用虛拟機省下來的錢可能隻有一點點。
比如你的伺服器隻有一百台，用容器後可能變成 60 台、 50 台，省下來的錢也許不多，但是在人工上省的錢非常多，我們現在都知道工程師非常貴。如果開發一個東西原先需要 10 個人，現在需要 5 個人，省下來的錢非常多。微服務也好，主要是省人工的。大家要明白容器帶來的，或者 k8s 帶來的更多的優勢不是你節省的機器成本，更多節省你的管理和人員成本。
最後一個場景是我們常見的，比較推崇的 devops，開發環境、測試環境、生産環境統一後帶來的好處，以及開發環境可以用多個 container 的時候，如果你能在自己的環境裡面，因為每個開發者都有自己的筆記本，在自己的筆記本裡面可以很輕松地搭建完整的開發環境的話，效率非常高，哪怕加自己的兩台虛拟機可以搭建起來的話，那個是非常重要的，我們在大公司開發會發現，你的工程進度不取決于你寫代碼的速度，取決于其他團隊跟你協調的速度，或者對方把這些東西寫好了，你要部署起來，這個挺費時間，如果你自己有相對比較完整的開發環境的話，你不依賴于别人的進步，對每個開發者而言是效率提高的，在這個效率提升來講，我個人認為是非常劃算的。
我們非常推崇走這個 devops 路線，保證自己有完整的開發環境，每個團隊做這樣的微服務的架構，每個子產品，可以，不是以人與人為主，是以文檔為主，可以有效提高我們的效率，是以不管是容器好還是k8s還好，微服務也好，這種理念是整個團隊所有人認可之後，才能産生應該有的效率。以上就是我的整體分享，非常感謝大家的時間。
原文釋出時間為：2017-04-28
本文來自雲栖社群合作夥伴“linux中國”