212
京東大規模容器集群之 kubernetes 實踐
01 容器時代已經到來
當前，容器的占有率可能比想象中還要快地增長，這個是使用 Docker 鏡像的受歡迎的程度，可以看到幾個排在前麵的。然後平均一個公司有多少容器在跑，隻有 7 個。但是在 06 年的時候，5 個都不到，其實增長還蠻快。
我覺得這個圖挺有意思的，講的是一個容器的平均生命周期，比較的是容器和未來的生命周期，容器的平均生命周期是 2.5 天，VM 是 23 天，這 2.5 天裏麵分了兩部分，一部分是用了編排，一部分沒有用編排。如果用戶沒有用 K8S 工具，平均的容器生命周期是一天，但是用了 K8S 編排，生命周期是5天，但是這個數據代表了什麼意義呢？這個數據最直觀的意義是成本，也就是說你用 Docker 也好，用 VM 也好，你可能解決同樣的問題，因為 VM 的創建，或者各方麵的因素，導致你上手的代價挺大，所以懶得刪除了，容器的話很容易，更容易讓你刪除它。從某種角度上講，你做同樣一件事情，你用容器的成本是用 VM 的 1/9。
我覺得這個數據稍微有點誇張，實際上我們內部和用戶的數據體驗來看，用容器比 VM 成本降低 50% 一點問題都沒有。通過這麼一組數據，我想表達一個觀點，雲計算的下一個時代已經是來臨了，而不是三年前說可能是容器，這個數據告訴我們，下一個時代就是容器時代，毫無質疑。
0 2 京東雲：將虛擬化和容器結合
容器時代，容器的優點是啟動快，應用方便，在虛擬化時代，它的安全是強隔離的，生態也是比較完善，因為經過十年的發展，虛擬化的網絡、存儲都是相當成熟的。
我們做一個什麼事情呢？我們做了把虛擬化和容器結合的工作。我們怎麼做？為什麼這麼做？容器最大的問題是隔離性的問題，畢竟是說它用的技術，理論上存在很多容器逃逸的可能性，曆史上發生很多，在一個物理機上起兩個容器服務的時候，服務 A 和 B，A 可能很容易逃脫宿主機，拿到容器 B 的數據的權限，因為容器的權限管理很難做，權限給的少用起來不舒服，給得高，應用很容易逃脫。但是這個問題在私有雲裏麵其實並不嚴重，因為我們在自己的公司裏麵我們都相信自己開發者開發出的應用是比較安全的，不可能 A 部門的應用讀到 B 部門的東西，我們有自己的代碼審核機製，安全防範機製，公司內部用傳統的容器部署方案沒有問題。
公有雲上不可能。因為我們永遠不知道來的用戶是什麼人，什麼目的，可能是搗亂的，所以我們認為公有雲上的用戶，應用是不可信的，我們要在公有雲上給我們用戶提供完整地，安全的服務，讓我們怎麼做，我們仔細分析 Docker，兩部分組成：第一部分是容器部分，用來做隔離，第二部分是 Docker 最創新的地方，用分層的方式存儲，可以利用文件係統分級存儲，能夠快速啟動一個容器，其實這個才是 Docker 的精華。因為我們想為什麼我們啟動虛擬機的時候會慢，慢是有原因的，因為你拉一個鏡像就慢了，或者給鏡像備份的時候。你這個應用大了，鏡像大了，可能會使整體應用慢一些，我們就改寫 KVM，讓 KVM 適配Docker 的鏡像，這樣我們利用了虛擬化的安全生態和它的成熟度，同時又保留了容器的啟動、體積和應用的優勢。
可以看到其實我們做的事情，我們其實，我們的底層還是一個 hypervisor，我們的容器雲不能簡單說是容器雲，為了方便大家理解叫容器雲，我們跑 APP 的空間不是 Container，大家知道啟動一個虛擬機比較慢，可能要好幾分鍾，如果大家在公有雲用過雲主機的話，創建雲主機時間比較慢，為什麼慢？其實這個慢的過程，跟 KVM 關係不是特別大，關係在於，啟動一個 VM 的時候，他認為自己是一個機器，要做很多的引導程序、引導檢查這種工作，會導致變慢，但是你在物理機裏麵的虛擬機，很多工作可以不用做，所以我們在這邊啟動 VM 的工作進行了簡化，同時在，這上麵是傳統的啟動 Docker 的流程，下麵是我們啟動自己的，叫京東容器 Container 的技術。
03 京東容器雲中的 K8S 實踐
前麵介紹一下我們怎麼做容器雲服務的，我們在容器雲服務裏麵怎麼跟 K8S 結合的。我們對 K8S 改造並不是那麼大，大部分用了 K8S 原生的組建和架構，我們隻是把容器的運行時換了，裏麵本來有多個 Container，我們換成 JCLOUDContainer，其他的服務並沒有大動。
右側可以看到，我們跟公有雲綁定的，我們的多租戶驗證與授權管理自己做的。另外，網絡和存儲，網絡接自己開發的 SDN 網絡，JCLOUDContainer，跟公有雲上創建的雲主機，可以放在一個裏麵，我們支持VM和容器相互通性，每個 JCLOUD，帶來便利性，可以放在一塊，持久性的存儲，我們用的是自己的硬盤，JCLOUDContainer 用的硬盤如果不用了，也可以插到雲主機上用。
所以在我們的京東雲裏麵，容器和主機是對等的一個關係，他們都是一等公民，在容器和主機下麵，才是我們的雲硬盤，我們的網絡，監控也是一樣，用統一的跟雲主機一樣的模塊。這個圖可以讓大家很方便看，我們現在容器雲服務，京東雲容器服務，跟一些傳統的其他家或者業界其他做法不一樣，如果我們說，如果在一年前，我們說自己用虛擬機搭一套 Swarm 的話，肯定去公有雲廠商裏麵啟動一係列的虛擬機，再做。
04 京東容器雲的典型應用
接下來介紹京東雲的實踐之路，介紹我們京東內部是怎麼做容器的，同時講講內部做容器跟我們在公有雲上提供容器服務有什麼差異點，以及我們用戶是怎麼用容器雲的，我們有世界上最大的容器集群之一，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中國”
最後更新：2017-05-22 14:02:33