我在創業公司的雲原生之旅
前言
IT是一座道場！
2020年5月中旬本科畢業後，進入嚴格意義上的第一家公司。當時帶我的是阿里雲的MVP，也是公司的CTO，跟着他(石老大)學到了很多很多，帶領我經過了入道(機會，不是人人都有，請感恩，
給你機會和幫助的人）。三個月後他離職了，感謝石老大，正是他的離職給了我獨自闖道的機會。
2020年9月開始進入了闖道(孤獨，痛苦和煎熬會時常與你共舞)、修道(別忘了，給風雨中的自己一個鼓勵)、悟道(認知和思想，是拉開人與人之間的重要差距)階段。可以說自石老大走後，我的任務都是自我安排，技術都是自我驅動實現的。
2019年7月離開學校時，告訴自己：我的路是一條追逐雲原生的路。自2018年8月接觸Kubernetes時就深深愛上了這條路。
2020年6月初進入公司後，實實在在感受到了創業公司的集群環境之亂(只有前端業務Kubernetes化且測試和生產通過namespace區分、生產Kubernetes資源特別低且服務副本數只有2個、gitlab代碼倉庫是部署在Kubernetes環境上的、權限混亂等)。提出了一些自己的解決方案：//www.cnblogs.com/zisefeizhu/p/13692782.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。代碼倉庫創建規範可以參考：//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展開雲原生的涉獵，更快的參與二開和社區。
