摘要：本文內容節選自由主辦的第七屆，架構師高欣分享的的實踐實錄。當然，在部署完成后，我們要做一個監測以便掌握它的運行狀況。規劃配置運行環境在正式部署前，還要考慮如何規劃并配置好運行環境。在使用部署時，可以利用這些命令做驗證，檢驗部署是否正常。

本文內容節選自由msup主辦的第七屆TOP100summit，JFrog架構師高欣分享的《Kubernetes is hard!JFrog的Kubernetes實踐》實錄。

本文為JFrog架構師高欣在TOP100summit上的演講實錄。分享者高欣專注DevOps解決方案，以及企業DevOps 轉型，曾在IBM服務近十年，帶領團隊致力于DevOps領域產品，及公有云服務的研發、運維、服務及推廣等，在軟件產品和云服務的開發與運維、持續集成及交付、DevOps 等領域具備豐富的技術積累和實踐經驗。

編者按：2018年11月30日-12月3日，第七屆全球軟件案例研究峰會在北京國家會議中盛大召開，現場解讀2018年「壹佰案例榜單」。本文為JFrog架構師高欣老師分享的《Kubernetes is hard!JFrog的Kubernetes實踐》案例實錄。

在Kubernetes中部署和運行應用，真不是印象中那么輕松簡單。JFrog目前可以做到每周自動化部署100+的不同產品線、任意版本組合的測試環境，而每個環境都要部署50+的微服務。而在達到這樣的部署規模的過程中，我們遇到了足夠多的問題，也積累了很多的經驗和教訓。在這次案例分享當中，我們將基于JFrog自身落地實踐的總結，介紹JFrog是如何從準備開始，一步一步實現應用在Kubernetes環境中的成功部署的。

希望大家不要在這個領域選擇做一個孤膽英雄，我們要學會善用團隊的力量、別人的成果、專家的輔助把企業內部的Kubernetes實踐做好。

背景回顧

最早我們發布一些應用都是直接發布在服務器上，但這會導致成本過高和服務的擴展、遷移非常困難；接著慢慢的發展到虛機上部署，相比原來在維護性、可遷移性上得到了提高，但因為每個虛機都要維護一個獨立的虛擬操作系統，還是有些不方便；接著，容器技術的誕生和使用，使得應用的部署和遷移更加方便快捷；再后來，應用逐步微服務化，應用的部署也就從一個大的容器，變成了多個容器一起提供服務的模式，也就是容器的集群。而容器集群的部署相對復雜，我們需要相應的編排工具、系統支持，Kubernetes就是當前這一領域大家使用比較多的環境，來幫助我們做容器集群化的部署。但是真正把Kubernetes用到生產環境中很難，我們在內部做了Kubernetes的實踐，主要目標是把已經做好的應用（包括現在新的開發應用），部署到Kubernetes環境中。今天我分享的實在這個過程中碰到的一些問題以及積累下的實踐經驗，希望能給大家帶來更多的啟示。

我先簡單解釋一下如何真正去做Kubernetes實踐。當我們準備應用的時候，并不是簡單地把現有應用裝到幾個docker就好，在部署之前，我們一定要把Kubernetes環境當中運行環境、運行參數，部署方式等問題做一個詳細的計劃。當我們真正執行的時候，要借助一些工具使整個部署環境更加的方便、可控。當然，在部署完成后，我們要做一個監測以便掌握它的運行狀況。整個運行流程需要能夠復用，按需自動運轉（以流水線的方式）。

JFrog內部的Kubernetes實踐

JFrog內部要解決什么樣的問題？

?如何能夠快速搭建JFrog產品的全功能測試環境（無論規模大?。?？

?當開發上百個分支時，我們如何為每一個分支提供獨立的CI/CD流水線支撐？

?如何利用我們現有的硬件資源？

?如何為JFrog產品提供新的交付方式？

下面我們來看看JFrog如何一步步解決以上的這些問題：

1
起步：小處入手

從一個很小的Kubernetes環境入手，先熟悉Kubernetes所有的特性（命令、組件，以及如何工作等）。這些不止可以從生產環境中獲得，我們可能會做一些破壞性的實驗。我們有很多的資源可以獲得一個能夠學習、實驗的環境，例如，公有服務、私有化部署以及自己探索。

當有了一個真正的Kubernetes環境后，我們要從一個很小的示例應用開始部署。如Nginx，而每次我們可以試驗和考察某個具體的特性，如它如何擴容、如何重啟，或者對外開放一個API等。這個過程中可以充分利用現有的各種教程和演示材料。

2

準備：調整應用

把應用裝進docker是遠遠不夠的，你的應用要做相應的設置和改進去適應Kubernetes部署的特性。首先，要考慮如何處理足夠多的日志文件，再分析哪些數據需要持久化存儲，然后合理的處理sigterm信號，最后，要保障在上一次運行的遺留數據。

除了應用本身之外，Kubernetes的一個應用部署—高可用是新的標準配置。我們要做到應用改造后，在高負載情況下，讓它保持良好的持久性和可用性；在負載均衡下，支持多個實例同時運轉，根據實際應用的負載情況，能夠非常順暢地做擴容、縮容；多個應用實例進行滾動升級的過程中，新舊兩個版本同時運行不會造成應用的誤解或中斷，等等。除了應用本身，我們還要考慮Kubernetes環境可能出現的問題。例如，Node正常維護的時間段，應用如何保持高可用，提供持續的服務；Node意外中斷了，應用如何處理這些計劃外的問題，繼續提供服務，這都是我們額外要準備的。

3

規劃：配置運行環境

在正式部署前，還要考慮如何規劃并配置好運行環境。而運行環境最重要的一個問題就是運行環境的資源，所有的限制都要考慮清楚。一定要限制Pod本身的資源，防止一個Pod占用了整個Node的資源。同時，應用本身也需要資源限制。之前的服務器、虛機、多帶帶的docker部署，大家可以注意到，我需要控制應用部署和限制資源。現在在Kubernetes環境中，應用部署在Pod，Pod部署到Node，如果不做資源限制，當真正運行時就會影響到同一Node上其他的Pod中的應用。此外，應用的運行狀態必須有可信的健康數據。在配置應用的時候，我們要通過各種各樣的方式，判斷應用的運行狀態是否正常。因此，我們要安裝一個探針，類型根據我們應用的特點，腳本正常反饋是0，說明腳本運行正常，這個探針反饋就是正常，我們也可以用HTTP，回復給我一個正常的return，說明是正常的服務。同時，還可以開放一些特定的端口，連接這個端口，是不是能夠很好的連上，能夠得到特定的回應，這些都是大家去規劃整個Kubernetes部署環境的時候，要去充分考慮的。

4

部署：編排部署

真正部署的時候，要利用yaml文件編排應用，多個組件、模塊，對應多個yaml文件；這時候考慮應用的版本化該如何管理？這里給大家推薦一個工具—Helm，

它原來是Kubernetes內部的子項目，現在已升級成為CNCF基金會的專門項目，專門負責協助容器集群化的部署。

上圖中左邊的餅狀圖是JFrog和客戶做的一個統計，從左圖可以看出只有5%的客戶在他的生產環境中用的Kubernetes。右邊的餅狀圖是一個關于有多少人用Helm去做Kubernetes部署的統計，也是5%。

這兩個數據絕對不是巧合，這是因為Helm大大方便了Kubernetes的部署。

那么，Helm是什么樣的呢？

圖中可看出，在templates中包含了所有yam，下次部署一個應用到底部署多少yaml，不會多也不會少。剛才講到版本化專門會有Chart.yaml去描述，整套是哪一個版本，包含哪些東西，當其中一些組件發生了新的變化時，會生成一個新的版本，這樣再去部署一個應用的時候，就會非常清晰的知道所有的變化記錄。

剛才講到的配置數據，我們目標環境配置的數據怎么辦呢？在部署yaml里，每一個環境都有對應的values.yaml，部署時就可以指定用哪個Values，這樣保證了所有應用的yaml，只考慮我的應用該如何去部署，不用考慮特定的目標環境，真正跟目標環境集成是在values.yaml，也就是說一次開發可以做多次部署。

Helm Charts有很多公共的數據庫，這樣一些公共應用的Kubernetes部署，都有很多成熟的Chart這里，不需要從頭拷貝或重寫，直接引用就可以了。大家開發編程的時候已經很熟悉外部依賴了，利用Helm，容器化部署的編排也可以作為代碼處理，我們有版本、有依賴，可以很方便的應用別人已經成熟做好的Charts，不需要重復這些工作了。

Helm專門有一個倉庫，存儲公共的Charts。使用這個公共倉庫，就可以把已經成熟的Charts直接做部署或引用到你的Helm Chart中。如果想建立一個私有化的Helm倉庫也可以，JFrog本身有一個全語言的制品倉庫——Artifactory，各種開發語言的交付包、依賴包，包括Helm Charts，都可以存儲在本地的Artifactory當中。有了這個本地倉庫之后，我們就可以把這些公共的Helm Chart帶回本地，下次使用的時候，你的代碼、依賴、編排都可以直接在一個倉庫當中拉取。

Helm也提供了很多很好地客戶端命令，以方便我們使用。

上圖中列出了一些命令。這些命令其實不是真正部署環境時使用的Helm命令，而是輔助大家做一些檢查的命令。在使用Helm Charts部署時，可以利用這些命令做驗證，檢驗部署是否正常。

5

監測：跟蹤部署

部署應用就要像放風箏一樣，雖然飛的很高、很遠，甚至可能看不見了，但我手中還是有根線，我能夠知道現在的狀態和位置，當有問題時，我能夠收回并處理。Kubernetes應用部署也是一樣。在Kubernetes環境中，很多情況都是自動處理的，如擴容、重啟、遷移等，所以監控是非常重要的，要能正確地掌握應用的運行狀態。大家可能會說，應用監控誰不會啊，我做了這么多年應用部署。但在Kubernetes環境中，有一個重要的問題，就是很多原有的監測手段不適用了。如傳統的運維手段是直接ssh到有問題的服務器上去查看，但是在Kubernetes環境里ssh已經無法使用了，因為IP是動態分布的，根本不知道機器布在哪里，無法跟蹤到具體的哪一個pod，哪一個docker上。所以，在Kubernetes環境下，我們要用一些新的監控手段，我們要讓開發、運維能夠隨時訪問到應用的運行數據和狀態信息，以便更好地看到目前的運行態、時序化的數據，同時可以看到日志，出問題時可以記錄下來。

另外，還要注意的是，我們盡可能要提供一個Out-of-Band這樣的工具幫助檢測。讓應用只是做應用相關的東西，監測的工具是用其他的方式來提供給開發和運維。

監視是給大家提供應用運行態的時序化數據（一些具體的參數）。最基本的是運行狀態、內存、存儲、性能等數據。這個很直觀，但是，我們應用要去考慮如何把狀態傳遞出去。我們有很多探針，很多日志文件，包括我們一些狀態，也應該提供一些時序化的方式，隨時把運行狀態信息傳遞出來。不僅僅是周邊環境的狀態、應用自身的狀態，也應該提供這種時序化的方式，比如當前流量進來的多少，應用自身性能的高低等。這就對應到我們前面設計的探針，才能把時序化的數據拿出來。

如何傳遞數據？放在pod或docker都不合適，因為它們很可能會自動銷毀或遷移。那么，我們輔助的方式要如何跟監測系統連接起來呢？首先，把需要的數據取出來。時序化監測用的比較多的是Prometheus、Grafana，提供時序化的數據和進行可視化的展示。這是我們監視的方式之一，能夠隨時隨地了解應用運行的狀態，包括整個運行環境中的關鍵數據。

除了運行態的時序數據外，我們講了日志也是非常重要的，但這個地方日志就能再放在原來的docker或pod中，我們要把它傳出來放在一個集中的系統中展示，這也回應到剛才應用改造的部分。我們在最開始改造應用的時候，我們規劃部署環境時就要考慮日志如何記錄、

擴/縮容后如何記錄等問題。這并不是記錄幾個文件的問題，而是要考慮哪些內容需要記錄下來，如何展示給開發、運維使用。

EFK是比較主流的方式，Fluented做數據的收集，Elastic Search做數據的存儲和索引，Kibana做日志的顯示；另一個更傳統的方式是，日志收集比較多時，我們在EFK之前放一些Kafka，提供數據的緩存。

這些架構有很多成熟的案例，大家可以詳細參考。不管時序化數據還是日志，都要從應用的改造，到規劃環境，再到這個監視的系統，結合Kubernetes各種環境，做好充分的規劃與考慮。

我們應用的目標是建立測試環境，所以采用了上述的監測方案。而在最終的生產環境中，我們可能還要監測微服務，即對應用最終的服務狀態進行監測。這里我們要注意的一些問題，大家可以參考一下：

第一點，做監測，不僅僅是監測Kubernetes環境，容器內部運行的應用同樣去監測。剛才講到的探針，監測的時序化數據、日志等都在監測范圍之內。

第二點，業務自身的性能。這些性能要從數據中體現，Kubernetes開發環境、pod系統只是一個參考，不代表應用自身的性能，我們要考慮應用自身性能如何監測。

第三點，監測具有彈性，以及多地部署的服務。這樣的服務該如何設計監測，需要充分考慮。

第四點，服務之間通過API溝通和連接的。API的狀況如何監測，使用情況、性能情況、有沒有不可達等問題，都是需要關注的。

第五點，微服務的監測體系要匹配組織架構。真正把微服務提供給客戶時，我們要做監測。如何呈現所有的監測數據，這是跟整個組織架構的管理方式、管理原則緊密相關的。大家應該都聽過康威定律，所有的研發工作最后呈現出的內容都是和組織架構相關的。這不是說一種方式所有的企業都要適用，而是要根據自身的需求和管理要求去調整。

6

流程：復用、自動

這一步要考慮的是讓流程能夠復用，而且一定要讓整個流程自動地運轉起來。我們做了一個Kubernetes流水線，剛才講的所有相關這些規劃、環境的設置以及我們的應用（用Helm Charts去描述），如何部署環境和應用配置，集成所有的內容，我們都把它們串聯成一個流水線。這樣，包括每一個分支開發后，都可以自動生成CI/CD流水線。而有了測試需求之后，也能夠快速部署相應的測試環境。

整個流水線的搭建，核心是自動化流程和編排驅動的工具，包括了JFrog的全語言制品倉庫Artifactory，和安全漏洞掃描工具Xray。JFrog的這些產品本身就是為CI/CD流水線服務的，其能力在我們的實踐中也得到了考驗和驗證。

使用全語言制品倉庫Artifactory，所有涉及的代碼包、依賴包以及編排的Helm Charts都放在一個倉庫里處理，從運維、管理、使用方面來講非常簡便。而且，Artifactory倉庫本身是支持企業級高可用的，高可用、高并發、異地復制同步、容災備份等都有成熟、可靠的方案，能夠保證流水線正常、可靠、持續地運轉，對整個后臺的測試和開發非常有益。

目前，我們能夠為JFrog每個產品、每個分支，按需提供完全獨立的測試環境；每周部署100+不同產品線、任意版本組合的測試環境，每次部署超過50種微服務。

7

協作：善用社區

現在的開發是一個協作的時代，不可能一個人把所有事情搞定。所以，要善于用社區的力量。

①在社區里你遇到的問題，很多人早就碰到并解決了。你不需要重復的從頭解決了，要多和他人溝通，了解他們是如何解決難題的。

②在社區里有非常多的專家和高手。善用社區就能充分借助高手的力量幫你解決問題。

結語

大家既然選擇了IT這個行業，就要做好一切的準備。Kubernetes既是趨勢也是挑戰，目前為止還沒有出現像插頭插上去就有電這樣方便快捷的應用。我希望能通過JFrog的案例實踐，帶給大家更多的思考！

以上內容來自高欣老師的分享。

聲明：本文是由msup原創，轉載請聯系 meixu.feng@msup.com.cn