我在創業公司的雲原生之旅

前言

IT是一座道場！

2020年5月中旬本科畢業後，進入嚴格意義上的第一家公司。當時帶個人是阿里雲的MVP，也是公司的CTO，跟着他(石老大)學到了不少不少，帶領我通過了入道(機會，不是人人都有，請感恩，
給你機會和幫助的人）。三個月後他離職了，感謝石老大，正是他的離職給了我獨自闖道的機會。

2020年9月開始進入了闖道(孤獨，痛苦和煎熬會時常與你共舞)、修道(別忘了，給風雨中的本身一個鼓勵)、悟道(認知和思想，是拉開人與人之間的重要差距)階段。能夠說自石老大走後，個人任務都是自我安排，技術都是自我驅動實現的。

2019年7月離開學校時，告訴本身：個人路是一條追逐雲原生的路。自2018年8月接觸Kubernetes時就深深愛上了這條路。

2020年6月初進入公司後，實實在在感覺到了創業公司的集羣環境之亂(只有前端業務Kubernetes化且測試和生產經過namespace區分、生產Kubernetes資源特別低且服務副本數只有2個、gitlab代碼倉庫是部署在Kubernetes環境上的、權限混亂等)。提出了一些本身的解決方案：http://www.javashuo.com/article/p-fgwvrlwb-no.html

2020年6月構建以ELFK爲技術核心的日誌系統(只收集網關日誌即nginx-ingress日誌爲惟一收集源)。

2020年7月圍繞業務全面Kubernetes化展開，主導了業務從一到零再到一的過程。

2020年8月和9月忙於集羣和CI|CD重構。新增了測試環境、預發環境，將網關由nginx-ingress改成kong-ingress，將gitlab從Kubernetes環境中剝離出來，藉助cert-manager實現證書的自動申請和續簽，增長堡壘機更正權限混亂問題，使用gitlab-runner實現多Kubernetes集羣的自動化部署等。

2020年10月專攻於"監控預警系統"，實現三個緯度的監控，期間第一次參與並主導私有化項目的部署。

2020年11月以"ISTIO服務治理"爲重心，在測試環境驗證了鏈接、安全、流控、可視，期間開發了envoyfilter插件對接鑑權服務。

2020年12月和1月圍繞"kubernetes下微服務的日誌系統"展開，實現了多Kubernetes集羣服務和裸機服務的日誌統一到一個管理平臺。

2021年1月和2月實現了將預發環境的kong-ingress過分到istio。並對接了證書服務、監控預警系統和日誌系統。

2021年3月忙於私有化部署和istio準備上生產環境的驗證。

在公司近1年中建立了13個代碼倉庫，寫了130餘篇技術文檔，

2020年6月初通過規劃了一張"基於KUBERNETES的企業級集羣架構"，通過和CTO及向有關人員的闡述，準備實施此架構

此架構規劃了三個集羣環境：生產環境、預發環境、測試環境

此架構除業務和項目外還增長了邊界服務：統一日誌管理平臺、監控預警系統、鏈路追蹤、統一管理平臺、證書自動續簽、流控等，下面將重點圍繞此展開

基於KUBERNETES的企業級集羣架構重點部分淺解

重構集羣架構、業務全面容器化

這是一個從一到零再到一的過程，剛畢業即接觸此類項目，實屬幸運

大體重構步驟以下：

• 根據原有業務設計容器化架構方案；
• 新增堡壘機Jumpserver；
• 製做先後端業務鏡像；
• 新增測試環境Kubernetes集羣、預發環境Kubernetes集羣、改造原生產環境Kubernetes集羣；
• 藉助Gitlab-Runner、Gitlab、Kustomize等實現多集羣的CI|CD；
• 和有關同事一塊兒定義先後端日誌字段和輸出形式；
• 協助後端團隊微調原裸機業務源碼；
• 藉助Rancher實現對多Kubernetes集羣的統一管理；
• 用Cert-Manager實現域名證書的自動申請和續期；
• 寫Shell腳本對Gitlab備份進行檢查、裸機服務備份進行檢查、對域名有效期進行檢查。

統一日誌管理平臺

此項目應是我近一年的最大收穫了，思想上。

大體實現思路：多kubernetes集羣的namespace絕對不能重複，elasticsearch、kibana、logstash、kafka獨立於集羣環境外且共用一套，filebeat、metricbeat、kube-state-metrics須要在每一個kubernetes集羣中都存在一套、metricbeat和tag須要標準清晰明瞭、日誌以json格式輸出且不容許多行日誌出現

一提之舉在：

• 實現了多集羣、多環境日誌的統一化管理

CI|CD

基於我司目前的研發現狀，選擇的自動化部署工具爲gitlab-runner。代碼倉庫建立規範能夠參考：https://www.cnblogs.com/zisefeizhu/p/13621797.html。

大體實現思路：研發提交代碼代碼到特定分支(分支區分環境，生產分支須要項目總監merge) --> 鏡像打包(由預發Kubernetes集羣的一臺特定節點執行) --> 根據.gitlab-ci.yml 規則進行業務pod化。

一提之舉在：

• 經過分支區分環境
• 鏡像打包只在一臺預發環境的特定節點執行，減小因打包鏡像而對生產環境帶來的波動，且能夠存在鏡像利用
• 大量藉助內置變量經過提早寫的腳本提升Kubernetes 部署部分的資源清單的重複可用性

監控預警系統

實現三個緯度(業務監控、應用監控、操做系統)的監控預警系統。

其中業務監控主要是研發提供一些業務指標、業務數據。對其增上率、錯誤率等進行告警或展現，須要提早定義規範甚至埋點。

應用程序的監控主要有探針和內省。其中探針主要是從外部探測應用程序的特徵，好比監聽端口是否有響應。內省主要是查看應用程序內部的內容，應用程序經過檢測並返回其內部的狀態、內部的組件，事務和性能等度量，它能夠直接將事件、日誌和指標直接發送給監控工具。

操做系統主要是監控主要組件的使用率、飽和度以及錯誤，好比CPU的使用率、CPU的負載等。

一提之舉在：

• 三個緯度
• 裸機也進行監控
• windows也進行監控

服務治理

隨着業務的不斷微服務化、對於服務的運行的失控感愈來愈強、且對東西向流量的管理成爲了急需解決的痛點、而Kong網關的ab test是付費版的開箱即用功能，而我司偏偏開始須要此功能。基於上服務治理開始進行視野。

我司對於服務治理的使用應算中度依賴，主要使用到以下點：

• 負載均衡：基礎服務使用最少鏈接策略，業務層服務使用一致性哈希負載均衡。
• 健康檢測：輸出健康檢測具體配置方案。（如：基礎移出時間30秒，10秒內出現3次錯誤移出，檢測時間間隔爲10秒…）
• 鏈接池：建立鏈接池，每一個實例最大處理請求數爲10，每一個鏈接處理2個請求後關閉，重試次數爲3次，鏈接超時時間爲500ms。
• 熔斷策略：根據健康檢測和鏈接池策略實現熔斷策略
• 重試策略：最多重試3次，每次調用超時爲2秒。
• 限流策略：後期用戶數提升後再實行。
• 鏈路追蹤

一提之舉在：

• 基於envoyfilter 和lua開發對接鑑權服務和istio

總結

始終認爲IT是一座道場，修道，修道，修一座本身的道場。在畢業的近1年中，經歷了入道、闖道、修道階段，到目前的悟道階段。

須要提高和掌握的知識還有不少，技術沒有止境，依然在路上。雲原生是一條充滿機遇的路，堅持與不斷追求才能翻過一座又一座高山。

展望

悟道(認知和思想，是拉開人與人之間的重要差距)

試道(出道下山、世界這麼大)

圍繞Kubernetes展開雲原生的涉獵，更快的參與二開和社區。