TOP100summit分享實錄 | JFrog高欣：Kubernetes is hard!JFrog的Kubernetes實踐

本文內容節選自由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