01 | 健康之路 kubernetes(k8s) 實踐之路 : 開篇及概況

近幾年容器相關的技術大行其道，容器、docker、k8s、mesos、service mesh、serverless等名詞相信你們多少都有聽過，國內互聯網公司無一不接觸和使用相關技術。

健康之路早在2016年就啓動了容器化的評估。眼觀如今容器化相關技術的穩定性和可行性也獲得了不少的驗證，在這樣的前提下咱們啓動了容器化實踐之路。

固然在實踐的過程當中咱們也不乏遇到了一些問題，咱們但願經過文字來記錄和分享咱們遇到的一些事情，也但願爲你們的容器化之路帶來幫助。

概要

目標讀者

    此係列文章不會涉及到不少的k8s技術，只涉及到咱們最終定案和使用的方案。而且文章不會從頭開始，會假設你們對k8s有必定了解有一些基礎，最佳的目標讀者是正在應用k8s初期和準備應用k8s的公司。

由於k8s的生態很是好，相關文章也特別多，入門及介紹文章、文檔很是的多，你們能夠自行的去補充相關的知識。

但有一個很重要的問題是沒有完整的生產可用的系列文章，不少是針對k8s能力的技術文章和實現剖析。

就算有大廠的應用案例文章但談及的粒度也比較粗只能提供一個大概的解決思路細的問題還要須要本身去摸索。

剛接觸k8s該如何學習？

    若是你們剛入門k8s推薦主看官方文檔（英文）不要由於英文而怯步，經過翻譯軟件基本能夠大體看懂。緣由呢很簡單：k8s發展的很是迅速，只有官方文檔纔是最可靠的，不少內容已是過期的了。

輔助的話你們能夠去搜尋一些系列文章（同樣的零散的文章由於k8s的版本不一致而容易形成困擾），本人是經過XX時間上的k8s系列課程入門的，推薦剛入門的同窗能夠先從這個系列開始。對k8s有必定的掌握力後根據系列課程的內容再去k8s官方文檔上增強學習一遍。

近期阿里雲有推出了一個系列課程：《CNCF × Alibaba 雲原生技術公開課》(XX時間上面系列的做者也在其中哦)目前還在更新中，內容也寫得很是好能夠在用來增強學習一下。

咱們目前作了什麼？

Fleet（自研，基於k8s打造的公司適用的容器運維和持續集成系統）

公司微服務框架的升級（兼容k8s引入後的原微服務調用）

生產線高可用k8s集羣搭建

服務器資源（CPU、內存）緊張時頻繁宕機的優化和避免

高可用BGP ClusterIP和PodIP及經過交換機打通現有網絡與k8s集羣內網絡的互通

全局容器hosts

Java8（JVM）在容器中的調優和優化

PHP容器化

簡單的監控和告警（Prometheus + Grafana）

技術選型

• 編排系統：kubernetes（當前版本1.14.1）
• CRI：Docker（當前版本18.09.4）
• CNI：Calico（當前版本3.7.2）
• Image Registry：Harbor（當前版本1.7.5，準備升級1.8.0）
• 負載均衡：LVS、HAProxy
• 集羣引導：kubeadm（當前版本1.14.1）
• 監控告警：Prometheus + Grafana
• Fleet
• 後端：Java8 + Spring全家桶 + fabric8io kubernetes-client
• 前端：TypeScript + React + Ant Design Pro

k8s部署方式的選擇

咱們以前有考慮過兩種方案進行k8s集羣的部署。

1. 物理機+k8s
2. 虛擬機+k8s

最終咱們選擇了虛擬機+k8s。

由於咱們以爲虛擬機帶來的損耗是咱們能夠忍受的。一些性能的損耗換來較好的維護性這是咱們想要的。

咱們的現狀

因爲早期的技術正確選型，公司在以微服務的架構方式進行開發已經經歷了很長的時間。

因此咱們的大部分應用都是無狀態的。這點爲咱們遷移k8s帶來了很是多的幫助（總所周知有狀態的應用程序是很是難遷移的，一樣在k8s中也顯得比較麻煩）。

因此若是你們如今大部分的應用仍是有狀態的，能夠先考慮進行應用重構在考慮遷移至k8s。

開發線（總體遷移進行中）

在開發線咱們基本上已經能夠遷移到k8s上，也正在逐步回收資源，將回收後的資源逐步加入k8s中，目前運行了80天左右，最後一次故障在一個月前（開發線資源緊張，由於資源緊張觸發了一個node頻繁宕機的小坑，後面會有專門的篇幅跟你們詳細分享），已穩定運行了30天左右。

目前咱們的開發線k8s集羣由於資源關係不是高可用的。

master一臺（etcd堆疊）

node五臺

harbor一臺

總計7臺虛擬機

應用狀況

服務器資源狀況

生產線（邊緣應用遷移）

在生產線咱們騰挪了一部分資源用來搭建高可用的k8s集羣環境。

同時咱們在生產線的動做也比較保守，目前遷移了小部分邊緣應用（非核心業務）到生產線。同時公司RP微服務組件使用的是TCP長鏈接也踩了一個負載均衡的小坑目前還在優化兼容中。後面會有詳細的篇幅來講明這個問題。

因爲生產線資源比較充足至搭建完成沒有發生過k8s故障（中間有由於網絡策略配置失誤致使了一小段服務不可訪問）。

目前已穩定運行53天。

master三臺

node四臺

etcd三臺

harbor兩臺

lvs兩臺

haproxy兩臺

總計17臺虛擬機

應用狀況

服務器資源狀況

咱們的不足和後續要作的事情

咱們目前沒有使用到CSI相關的內容，咱們目前也不支持有狀態的應用程序。後續咱們會考慮創建Ceph集羣來加入這塊的能力。

咱們目前也沒有使用Ingress能力（咱們目前採用Service的ClusterIP），後續根據急迫程度可能會考慮加入Ingress能力。

咱們目前沒有作日誌收集（目前是依賴程序本身的日誌傳輸邏輯自行查看或經過Fleet系統的控制檯日誌功能WebShell功能進行診斷）

咱們目前的構建系統比較固定，沒有那麼靈活，後續可能會引入Drone等第三方構建系統進行構建。

.net core的容器化

有沒有系列大綱？下一篇會分享什麼？

抱歉，我實在沒有那麼強的全局觀去梳理出所有的分享大綱。我會根據咱們遇事的大體順序進行分享。我會在每篇的結尾寫出下一篇大概會分享什麼內容。

下一篇應該會分享：高可用k8s集羣搭建的內容，不會詳細的說明搭建步驟（會分享咱們目前的拓補圖、高可用測試方案等內容），此係列的主要目標讀者仍是有必定基礎的同窗，會點到爲止。

最後

首先是感謝。感謝領導CTO和經理的鼎立支持和協調。感謝k8s社區帶來的優秀能力和文檔。

ps：分享的全部內容不必定徹底是個人成果，其中咱們的小夥伴也一直在支持這個項目。

若是你們有疑問和須要交流的能夠經過評論功能或私信我（推薦優先使用評論，評論的內容也是讀者的一筆財富）。

公司（福建福州）目前還有一些技術崗位（java、大數據工程師）缺口，有興趣的同窗能夠給我發消息，我能夠幫忙轉發。

關於Fleet

Fleet系統是咱們公司自研的一套容器運維和持續構建系統。

系統的後續出現方式未定。

Fleet系統咱們是有分期規劃的。

目前處在2期進行中（1期是基本知足公司開發人員遷移到k8s的平常運維和使用）。

下面是部分系統截圖