PPT下載 | KubeCon歐洲大會熱點議題總彙

4月22日，由K8S技術社區、Linux中國聯合主辦的K8S GeekGathering 2017吸引了國內容器領域關注者100+人到場參與，如下是EasyStack 容器架構師王后明的演講實錄整理：

EasyStack 容器架構師王后明

你們下午好，開場以前，我作一個簡單的現場調查，有哪位朋友在生產環境上或者使用K8S平臺的，你們能夠舉手。生產環境或者在運維，或者在生產上使用的，開發和測試環境上用的多一些。

今天的話題，我主要是對KubeCon2017歐洲峯會的熱門話題的總結和社區關注的的分享和回顧，說到現場的，對我印象最深的是其中某個話題的時候，現場調查的時候，問有誰，哪位同事在生產環境上運維K8S平臺，在現場能夠看到超過80%的人舉手，我感受在K8S平臺，在國外的使用程度，可能比國內走得更前一步，已經有很是很是多的生產案例在跑。

1

CNCF最新動態

首先分享第一個問題是CNCF的最新動態，在兩天的會議上，CNCF宣佈了社區發展的最新狀況，就是在加入黃金和會員後，CN已經增長到85家的會員的數量，生態發展速度很是快，託管項目，目前從峯會上，3月25日，DOcker把容器運營時捐贈給了容器的基金會，進入基金會之後，CNCF託管的項目目前一共有9個，包括K8S、等等，目前一共9個託管的項目，但同時，由於在這個圖裏面，CNCF進行了維護，至關於整個企業在雲裏面作運用改造，可能涉及到很是多的項目，包括整個技術架構，項目的安裝部署，容器的編排，應用的開發和部署的流程，整個其實涉及到很是很是多的開源的項目，來支撐雲應用層的生態，目前CNCF基金會管理9個項目，更多項目進入基金會的視野，未來會有更多項目進入CNCF下託管，這是CNCF社區的狀況。

峯會上一個比較重要的消息就是說DOcker把本身的容器運營時捐贈給了CNCF和基金會。咱們知道在K8S1.5版本的時候，他已經脫離多個運行的CII容器，Container的接口，有這個接口以後，K8S能夠繞過DOcker使用基金會的實現，作容器的編排，在1.5發佈以後，Docker的話，多少也可以感受到一些壓力，由於若是K8S一個CII+OCI標準運行成爲事實之後，Docker的市場佔有率會有所降低，今年峯會的時候，Docker選擇把ContainerD捐贈給基金會，這是本身的容器運營時，主要解決下面幾個問題，好比說他怎麼樣，第一個部分是進行容器競相的格式的管理，怎麼樣把分層的鏡像，進行運行時，同時會管理底層的存儲和網絡，怎麼樣去分配，就是容器運行時要作的事情，容器ContainerD的話，主要是結合Docker的產品，結合微軟的共同開發了開源的容器運行時的平臺，這是ContainerD要解決的問題。

說到OCI和這些標準，咱們能夠簡單看一下，目前這個容器的生態裏面所存的幾個，標準化的一個組織，首先從鏡像運行時和網絡方面都有不一樣的標準化組織來規範容器的生態，CoreOS是APPC和OCI和CNI，谷歌是OCI和CNI，DOcker本身推的Liwork，1.5版本里面，怎麼調動不一樣的容器運行時的接口，1.5開始是這個狀態，避免直接使用，直接調用下面的，好比DOcker和這樣的容器的實現，就是造成統一的容器運行時的接口，底下不一樣的實現是經過不一樣的接口調度容器，若是一個公司企業裏面來選擇一個容器的編排的工具，選擇K8S是底層的容器引擎沒有硬性的要求，這樣能夠更好地避免底層技術廠商鎖定的問題。

其實在峯會上，分享了他爲何選擇把ContainerD捐贈給基金會，主要是兩個大的方面，一個是你們也是立志於造成整個容器生態的統一的規範，避免說你們各自玩本身的一套規範。這樣也是給整個生態的開發者和廠商都會帶來一些兼容性的問題，選擇CNCF基金會，是由於二者目標一致，造成統一的容器生態的規範，而後技術實現方面的話，ContainerD是直接使用GRPC的調動的關係，監控數據也是使用普羅米修斯的方式發佈，這樣能夠更好地跟K8S更好地融合。其實ContainerD進入CNCF之後，代替DOcker的地位，在社區已經有針對ContainerD和CNCF接口的實現，直接調用CII的調用Containerd的技術實現也跟CNCF其餘項目保持一致，作下面容器的盛行週期的管理，這個就是Containerd的爲何捐贈給CNCF基金會的說明。

2

峯會上的技術熱點總彙

接下來咱們能夠看一下整個峯會上所講述的一些比較重要的和比較新的技術話題，咱們看到第一點是KubeVirt，咱們目前用得比較多的是，IaaS層裏面，open stack比較多，容器的話K8S比較大，KubeVirt的實現方法有兩種，對Open Stack平臺裏面，從Open Stack平臺上，完成對虛擬化和容器技術的統一調度，KubeVirt目的是作容器和虛擬機的統一調度，實現方式是把K8S做爲容器的控制平面，評比容器的差別，讓整個K8S調度數據中心的虛擬化和容器的技術。

現場的話，工程師也給你們作了說明，怎麼樣實時建立虛擬機，同時怎麼管理虛擬機的生命週期，KubeVirt的實現的話，實現方式，和K8S目前三方的，若是咱們要新增功能，在K8S裏面新增一些功能加一些資源，是相似的方案在K8S裏面，是不會直接改這個sever，會擴展一套新的，會有一套新的管理者響應新的資源，由於整個平臺是在K8S框架下，因此這兩個下面的統一資源管理是經過TBR統一管理、調度三方資源，把三方的服務定義爲統一的實現，具體的他們新加了一個APIsever，經過新的資源的描述類型，來定義這個虛擬機的資源，咱們響應虛擬機類型的資源，把資源真正的請求分發到底層運行在每一個節點上的資源，這樣的話，來完成整個用K8S平臺對虛擬機和容器作統一的調度。

這是KubeVirt的大概介紹。這個項目的話，目前它尚未到特別成熟的階段，目前是至關於原型的階段，來證實這種方式，若是咱們想用K8S做爲統一的虛擬機和容器的管理平臺也是可行的。這是關於容器和虛擬化，它倆統一管理，做爲統一的控制平面的實現方式之一，除了KubeVirt以外，其實整個當前K8S生態上面，其實也有另一些實現容器和虛擬機調度管理的思路，第一種是virtlet，讓虛擬機和容器統一管理，和KubeVirt類似，Virtlet沿用現有的資源和框架，作二者統一的資源的調度，如今已經進入統一項目下面，你們能夠本身作一些嘗試。

另一種是Frakti也是一個項目，跟郭理靖分享的京東雲的類似，底層其實用來真正跑容器運行時，其實仍是虛擬化的技術，只是把虛擬化和容器進行了深度的融合，底層的容器運行時仍是虛擬化的技術。主要是用的hypervisor控制的。Open Stack這邊其實也是另一種實現思路，就是在Open Stack和虛擬機統一管理，這是另外的話題，這邊咱們就不說這部分了，這是容器和虛擬機統一管理的方案。接下來咱們能夠看一下對Open sevice API以及K8S Service Catalog。

咱們若是用某一個平臺以外的服務，咱們要作的事情很是簡單，第一步要獲取這個服務提供商能夠提供哪些服務，好比從這上面能夠提供服務，有這個服務能力以後，咱們第二步直接向服務提供商提供具體的數據出來。把建立出來的數據庫和底層的某個應用進行綁定，綁定好以後，咱們應用能夠更方便用，往數據庫裏寫入數據存儲數據，這樣的話，咱們使用這些服務的時候，並不須要關注具體的細節，這是提供給咱們的橋樑，讓整個生態應用之間，使用、分發更方便。這個就是Open sevice Broke API作的事情，對應的，相似於KubeVirt，是插件格式加入整個平臺裏面，至關於整個的實現，讓K8S裏面的服務更好地使用數據庫提供的原理，這個也是和剛纔相似，也是經過三方的資源來實現，目前也是孵化項目，能夠作一些使用。

在目前的審計，在生產的系統裏面是很是重要的組成部分，按照時間順序記錄用戶，管理員或者其餘組建，跟安全相關的行爲，審計的話，能夠給系統管理員提供，對安全行爲的審計，過程當中須要回答的幾個問題，好比這個用戶作了什麼操做，操做是何時發生，由誰發起，對誰發起，它發起的目標是什麼，它在哪裏被觀察到，哪裏被髮起，會影響哪些地方。這是整個審計過程當中須要的信息，其實在整個審計的系統裏面都應該能囊括到，主要是用來發現系統的安全違規行爲，作性能分析、軟件BUG的分析，調試的工具，這是審計系統要完成的功能，審計系統，並不會給系統帶來額外的安全性，主要是以K8S審計爲例，Virtlet在Open sevice以後的行爲，是已認證用戶的行爲的記錄。這是審計系統的定位，只能說做爲咱們感應系統安全的一個參數信息的來源，這是審計系統。

那審計系統在K8S裏面，目前功能比較簡單，你在審計的時候，加幾個選項就能把審計系統打開，打開以後，咱們能夠從日誌裏面看到，咱們系統的用戶和管理員作的認證的操做，當前的日誌的記錄，目前是比較簡單的狀態，剛開始有這麼一個系統，能夠來做爲系統K8S審計的信息的輸出，這是審計的在K8S的狀態，而後另一個就是別的工程師分享了，K8S裏面無服務框架的項目，其實跟容器也是至關於目前像公有云裏面，AWS，谷歌、微軟，都有本身的無服務框架的產品，在K8S裏面，也有很多的嘗試的實現，K8S的話，也是跟KubeVirt相似，也是用TBR做爲函數，操做的具體的展示的對象，同時也是新加了一個響應函數的請求，最底層的話，無服務器請求，並非沒有最後的服務器的門第，是經過最底層的K8S的基礎資源來響應函數後面的資源的運算的請求，同時相關的一些配置，是經過map作的。這是K8S的實現，同時經過插件化的方式加入整個K8S的平臺裏面來的。

除了K8S以外，也有這樣的框架。底層也是利用Kubeless是兼容谷歌的API。另外還有分享的容器初始化系統的，由於linux內核啓動的時候會先啓動一個init進程，這個進程的PID開始hypervisor於特殊的使命，須要作好的父進程的角色，好比傳遞信號，容器使用PID隔離不一樣容器裏面進程的，帶到這個問題就是每一個容器裏面都能看到這麼一個進程，這個進程由於linux設立的是惟一的進程有使命，處理這個子進程的關係，在init爲1的進程就變得重要了，早期若是運維過生產環境，Docker或多或少遇到，容器某個進程怎麼樣，其實這種狀況下，就是跟容器初始化進程關係比較大，由於PID爲一的進程比較關鍵。

因此對應實現的話，有三種實現的方式，第一種是dumb init，系統起來的時候，若是咱們在某個容器件裏面使用這個的話，咱們首先要啓動真正的應用，這個dumb init是完成了容器初始化的工做，真正的是做爲dumb init的子進程，不會由於沒有處理進程化，致使進程上不掉的狀況，因此dumb init是比較輕量級的實現方式。另外從Docker1.13版本以後，DockerD已經加了這種標記，DOckerD會自動會用戶的應用程序處理初始化的工做，因此重新版本的話，咱們遇到這種進程相對少一些了。這是DOcker這邊的實現。第三種方式是能夠經過Systemd，同時咱們在容器裏面的話，也能夠選擇用Systemd充當內部的初始化的進程，這個好處是除了作容器初始化系統以外，還能更多處理日誌，服務之間的啓動順序，這是它帶來的好處，這是容器初始化系統，你們作應用容器的時候，若是遇到相似的問題，能夠選擇三種不一樣的方式，用哪一種方式解決可能存在的問題。

3

與生產實踐相關的技術話題

最後一部分跟你們分享一下，我所聽到的這些裏面跟生產應用關係比較大的，對我印象深入的幾個話題，其中之一是houm，我大概普及一下，簡單理解能夠理解成應用系統裏的一個，其實就是，目的是讓K8S裏面的一個應用，它使用和維護升級更加方便。咱們知道。若是咱們單跑一個容器其實很是方便，咱們直接進行單個容器的使用、啓動、刪除就能夠。若是真正的一個系統作完微服務化，整個大系統不多是單個的容器，容器之間或多或少存在跟其餘系統之間微服務的交互關係，這個時候，把各個大系統裏面子系統的依賴關係交代清楚，這個是很是重要的。houm的出現是爲了解決大系統進行容器應用化以後，在線上運維的所作的事情，至關於咱們把每一個小的服務定義好以後，以houm裏面的定義好，一個應用的話，能夠包括多個微服務，一個helm能夠理解爲一個ITE，至關於一個大應用之間，它的依賴關係能夠經過一個管理起來，這是helm作的事情。

K8S生態裏面的一個應用包的管理工具。helm的內部組成相對簡單，helm本身是一個客戶端，你本身執行的樣本、app這些，你能夠本身設定對應的應用，運營的名字是，客戶端發起請求之後，響應完之後，服務器上把這個應用的描述先描述的壓縮文件下載到K8S集羣裏面，度曲這些信息，部署組件，helm的話，在整個企業裏面，其實它的重要性愈來愈重要，其中第一點是CTO分享了，第一個K8S裏面的，咱們目前只有Docker，這只是單個容器的，有了helm以後，咱們能夠把標準的應用，不只僅是咱們能夠用容器生態來管理好一個容器，更方便的是咱們把標準應用經過應用的方式管理和發佈，quay集成helm，相似於應用商店，quay和容器的倉庫融合得比較緊密，在整個微服務過程當中，除了能把整個image以外，同時能夠推送到應用的裏面去，這樣能達到整個應用方面的運維和管理。這是這個產品。

第二部分，其實helm能夠做爲整個流程的重要部分，其實整個企業作應用容器化的時候，少不了代碼提交、觸發、流程以後，把對應的應用推送到容器裏面去，有了helm以後，咱們能夠作的事情還有不少，一個大的服務分爲三個應用，若是咱們三個應用事先定義好應用的組織關係，這個時候，若是咱們每次應用的代碼提交，其實都會帶動整個線上的大系統作總體的更新和測試，這樣不只是對某個服務自己作一個測試，其實能夠對多個服務大系統作大的過程，這是helm在企業裏面應用更豐富，重要性，後面會愈來愈重要。包括國內國外，愈來愈多的平臺和產品已經支持用helm做應用商店的方式。最後一個部分就是分享一下華爲工程師的分享，如何讓K8S支持5萬+個服務。在1.6發佈的時候，官方宣稱，K8S能夠支持5千個物理節點，若是真正開始規模化地使用這麼一些應用的時候。

若是規模上去以後，會遇到一些問題，由於服務的話，都是經過IP 作流量的負載，對整個副本，決定你這個應用最後到哪一個訪問的時候，它流量在那個pot上面，是經過ip tab的規則，能夠看到整個系統規則裏面一些IP tabs規則的增長，你的數量上來以後，會成倍的增長，ip table達到必定程度會形成反應延遲很是大，這個時候對IPTables作一些刪除修改的話，整個延遲很是大，爲何慢，是由於ip tables不是增量作規則的增長，若是當前有服務出來，後面要新建立一個服務，這些規則是要把當前全部規則拷貝出來作修改，再把這個規則save回去，把整個規則作一個更新，這個過程會致使ip table鎖住，若是規則很是大，會很是耗時，有個具體的數據是若是有5千個serves的時候，ip table有四萬條，添加一條規則耗時11分鐘才能把這條規則在系統上生效，這是絕大的耗時，有16萬條規則，須要耗時5小時。在生產裏面能夠理解爲不可用的狀態了。ip table做爲內部使用，存在的問題。這是服務延遲的問題，就是你請求到節點以後，分發到哪一步了的延遲，第一個服務和最後一個服務之間，到哪一個之間的間隔，這是比較顯著的變化了。面對IP table存在的問題，社區有方案，用IPVS代替當前kube proxy，基於Netfilter之上的協議。

目前經過NAT負載均衡模式，支持更高級的，直接路由的方式，目前K8S使用NAT的實現，這種實現的話，目前代碼仍是在，若是五千規則須要耗11分鐘，如今降到2秒，以前須要5小時，也只須要2秒，這樣的話，能夠解決這樣的問題。這是如何用IPVS支持5萬級別的service，這是性能數據的對比，在5千個數據的時候，以前須要11分鐘，若是2萬個服務的話，須要5小時，用IPVS，能夠很小，這樣的話可以很好地支撐整個大的應用的，大規模的應用的分發，大規模應用的運行。以上就是我在峯會上聽到的比較多的熱門的技術話題的簡單分享，涉及到的問題比較多，你們有問題的話，這只是影子，告訴你們有這個東西，後面要用的話，能夠從社區上，或者網絡上找到更豐富的資源和介紹，個人分享就到這兒，謝謝你們。