如何讓一個創(chuàng)業(yè)公司開啟云原生之旅？
IT是一座道場！
2020年5月中旬本科畢業(yè)后，進入嚴格意義上的第一家公司。當時帶我的是阿里云的MVP，也是公司的CTO，跟著他(石老大)學到了很多很多，帶領(lǐng)我經(jīng)過了入道(機會，不是人人都有，請感恩，給你機會和幫助的人）。三個月后他離職了，感謝石老大，正是他的離職給了我獨自闖道的機會。
2020年9月開始進入了闖道(孤獨，痛苦和煎熬會時常與你共舞)、修道(別忘了，給風雨中的自己一個鼓勵)、悟道(認知和思想，是拉開人與人之間的重要差距)階段。可以說自石老大走后，我的任務都是自我安排，技術(shù)都是自我驅(qū)動實現(xiàn)的。
2019年7月離開學校時，告訴自己：我的路是一條追逐云原生的路。自2018年8月接觸Kubernetes時就深深愛上了這條路。
2020年6月初進入公司后，實實在在感受到了創(chuàng)業(yè)公司的集群環(huán)境之亂(只有前端業(yè)務Kubernetes化且測試和生產(chǎn)通過namespace區(qū)分、生產(chǎn)Kubernetes資源特別低且服務副本數(shù)只有2個、gitlab代碼倉庫是部署在Kubernetes環(huán)境上的、權(quán)限混亂等)。提出了一些自己的解決方案：https://www.cnblogs.com/zisefeizhu/p/13692782.html
2020年6月構(gòu)建以ELFK為技術(shù)核心的日志系統(tǒng)(只收集網(wǎng)關(guān)日志即nginx-ingress日志為唯一收集源)。
2020年7月圍繞業(yè)務全面Kubernetes化展開，主導了業(yè)務從一到零再到一的過程。
2020年8月和9月忙于集群和CI|CD重構(gòu)。新增了測試環(huán)境、預發(fā)環(huán)境，將網(wǎng)關(guān)由nginx-ingress改為kong-ingress，將gitlab從Kubernetes環(huán)境中剝離出來，借助cert-manager實現(xiàn)證書的自動申請和續(xù)簽，增加堡壘機更正權(quán)限混亂問題，使用gitlab-runner實現(xiàn)多Kubernetes集群的自動化部署等。
2020年10月專攻于"監(jiān)控預警系統(tǒng)"，實現(xiàn)三個緯度的監(jiān)控，期間第一次參與并主導私有化項目的部署。
2020年11月以"ISTIO服務治理"為重心，在測試環(huán)境驗證了連接、安全、流控、可視，期間開發(fā)了envoyfilter插件對接鑒權(quán)服務。
2020年12月和1月圍繞"kubernetes下微服務的日志系統(tǒng)"展開，實現(xiàn)了多Kubernetes集群服務和裸機服務的日志統(tǒng)一到一個管理平臺。
2021年1月和2月實現(xiàn)了將預發(fā)環(huán)境的kong-ingress過度到istio。并對接了證書服務、監(jiān)控預警系統(tǒng)和日志系統(tǒng)。
2021年3月忙于私有化部署和istio準備上生產(chǎn)環(huán)境的驗證。
2021年4月忙于舊服務器治理、私有化部署、聚石塔方面的有關(guān)工作。
2021年5月忙于istio生產(chǎn)啟用、聚石塔和私有化部署的工作。
在公司近1年中創(chuàng)建了13個代碼倉庫，寫了130余篇技術(shù)文檔，
2020年6月初經(jīng)過規(guī)劃了一張"基于KUBERNETES的企業(yè)級集群架構(gòu)"，經(jīng)過和CTO及向有關(guān)人員的闡述，準備實施此架構(gòu)
此架構(gòu)規(guī)劃了三個集群環(huán)境：生產(chǎn)環(huán)境、預發(fā)環(huán)境、測試環(huán)境
此架構(gòu)除業(yè)務和項目外還增加了邊界服務：統(tǒng)一日志管理平臺、監(jiān)控預警系統(tǒng)、鏈路追蹤、統(tǒng)一管理平臺、證書自動續(xù)簽、流控等，下面將重點圍繞此展開
基于 KUBERNETES 的企業(yè)級集群架構(gòu)重點部分淺解
重構(gòu)集群架構(gòu)、業(yè)務全面容器化
這是一個從一到零再到一的過程，剛畢業(yè)即接觸此類項目，實屬幸運
大致重構(gòu)步驟如下：
根據(jù)原有業(yè)務設(shè)計容器化架構(gòu)方案； 新增堡壘機Jumpserver； 制作前后端業(yè)務鏡像； 新增測試環(huán)境Kubernetes集群、預發(fā)環(huán)境Kubernetes集群、改造原生產(chǎn)環(huán)境Kubernetes集群； 借助Gitlab-Runner、Gitlab、Kustomize等實現(xiàn)多集群的CI|CD； 和有關(guān)同事一起定義前后端日志字段和輸出形式； 協(xié)助后端團隊微調(diào)原裸機業(yè)務源碼； 借助Rancher實現(xiàn)對多Kubernetes集群的統(tǒng)一管理； 用Cert-Manager實現(xiàn)域名證書的自動申請和續(xù)期； 寫Shell腳本對Gitlab備份進行檢查、裸機服務備份進行檢查、對域名有效期進行檢查。
統(tǒng)一日志管理平臺
此項目應是我近一年的最大收獲了，思想上。
大致實現(xiàn)思路：多kubernetes集群的namespace絕對不能重復，elasticsearch、kibana、logstash、kafka獨立于集群環(huán)境外且共用一套，filebeat、metricbeat、kube-state-metrics需要在每個kubernetes集群中都存在一套、metricbeat和tag需要標準清晰明了、日志以json格式輸出且不允許多行日志出現(xiàn)
一提之舉在：
實現(xiàn)了多集群、多環(huán)境日志的統(tǒng)一化管理
CI|CD
基于我司目前的研發(fā)現(xiàn)狀，選擇的自動化部署工具為gitlab-runner。代碼倉庫創(chuàng)建規(guī)范可以參考：https://www.cnblogs.com/zisefeizhu/p/13621797.html。
大致實現(xiàn)思路：研發(fā)提交代碼代碼到特定分支(分支區(qū)分環(huán)境，生產(chǎn)分支需要項目總監(jiān)merge) --> 鏡像打包(由預發(fā)Kubernetes集群的一臺特定節(jié)點執(zhí)行) --> 根據(jù).gitlab-ci.yml 規(guī)則進行業(yè)務pod化。
一提之舉在：
通過分支區(qū)分環(huán)境 鏡像打包只在一臺預發(fā)環(huán)境的特定節(jié)點執(zhí)行，減少因打包鏡像而對生產(chǎn)環(huán)境帶來的波動，且可以存在鏡像利用 大量借助內(nèi)置變量通過提前寫的腳本提高Kubernetes 部署部分的資源清單的重復可用性
監(jiān)控預警系統(tǒng)
實現(xiàn)三個緯度(業(yè)務監(jiān)控、應用監(jiān)控、操作系統(tǒng))的監(jiān)控預警系統(tǒng)。
其中業(yè)務監(jiān)控主要是研發(fā)提供一些業(yè)務指標、業(yè)務數(shù)據(jù)。對其增上率、錯誤率等進行告警或展示，需要提前定義規(guī)范甚至埋點。
應用程序的監(jiān)控主要有探針和內(nèi)省。其中探針主要是從外部探測應用程序的特征，比如監(jiān)聽端口是否有響應。內(nèi)省主要是查看應用程序內(nèi)部的內(nèi)容，應用程序通過檢測并返回其內(nèi)部的狀態(tài)、內(nèi)部的組件，事務和性能等度量，它可以直接將事件、日志和指標直接發(fā)送給監(jiān)控工具。
操作系統(tǒng)主要是監(jiān)控主要組件的使用率、飽和度以及錯誤，比如CPU的使用率、CPU的負載等。
一提之舉在：
三個緯度 裸機也進行監(jiān)控 windows也進行監(jiān)控
服務治理
隨著業(yè)務的不斷微服務化、對于服務的運行的失控感越來越強、且對東西向流量的管理成為了急需解決的痛點、而Kong網(wǎng)關(guān)的ab test是付費版的開箱即用功能，而我司恰恰開始需要此功能。基于上服務治理開始進行視野。
我司對于服務治理的使用應算中度依賴，主要使用到如下點：
負載均衡：基礎(chǔ)服務使用最少連接策略，業(yè)務層服務使用一致性哈希負載均衡。 健康檢測：輸出健康檢測具體配置方案。（如：基礎(chǔ)移出時間30秒，10秒內(nèi)出現(xiàn)3次錯誤移出，檢測時間間隔為10秒…） 連接池：創(chuàng)建連接池，每個實例最大處理請求數(shù)為10，每個連接處理2個請求后關(guān)閉，重試次數(shù)為3次，連接超時時間為500ms。 熔斷策略：根據(jù)健康檢測和連接池策略實現(xiàn)熔斷策略 重試策略：最多重試3次，每次調(diào)用超時為2秒。 限流策略：后期用戶數(shù)提高后再實行。 鏈路追蹤
一提之舉在：
基于envoyfilter 和lua開發(fā)對接鑒權(quán)服務和istio
私有化部署
因我司主打產(chǎn)品為3D編輯器，數(shù)據(jù)保密性要求極高，大型企業(yè)更在意數(shù)據(jù)由自己掌握，所以在這近一年中做了好幾個私有化部署項目。
在做私有化部署項目中學到了很多：
業(yè)務：需要知道客戶需求牽扯到的服務有哪些，作出路由規(guī)劃表。 集群：根據(jù)客戶的需求，估算出資源需求。 溝通：需要和客戶(基本是非技術(shù)類)、我司運營等人員啊進行技術(shù)上的溝通，需要將繁瑣的技術(shù)通俗化。 時間：根據(jù)客戶的規(guī)定時間和我司的實際現(xiàn)狀規(guī)劃出準備、部署、測試、交付的時間段，考驗項目時間把握度。 協(xié)調(diào)：在項目部署中難免會出現(xiàn)一些配置類的問題，需要后端人員介入。
一提之舉在：
私有化部署嚴重考驗對業(yè)務、集群的熟悉度，是考驗一個運維人員的技能修養(yǎng)的。
總結(jié)
始終認為IT是一座道場，修道，修道，修一座自己的道場。在畢業(yè)的近1年中，經(jīng)歷了入道、闖道、修道階段，到目前的悟道階段。
需要提升和掌握的知識還有很多，技術(shù)沒有止境，依然在路上。云原生是一條充滿機遇的路，堅持與不斷追求才能翻過一座又一座高山。
展望
悟道(認知和思想，是拉開人與人之間的重要差距)
試道(出道下山、世界這么大)
圍繞 Kubernetes 展開云原生的涉獵，更快的參與二開和社區(qū)。
過手如登山，一步一重天
- END -
?推薦閱讀? Kubernetes 生態(tài)架構(gòu)圖 基于Nginx實現(xiàn)灰度發(fā)布與AB測試 Linux 系統(tǒng)日常巡檢腳本 K8s kubectl 常用命令總結(jié)（建議收藏） 搭建一套完整的企業(yè)級 K8s 集群（kubeadm方式）
點亮，服務器三年不宕機
