集群優化

思考：

1. 現目前的架構是什麼？業務邏輯？
   ​ 研發一臺，測試&生產共用一套k8s集群。
   ​ 目前前端已經遷移到k8s，生產後端暫時沒有上k8s。

2. 造成目前架構的原因是什麼？
   ​ 歷史遺留原因 造成架構不合理

3. 那些地方不合理，為什麼？
   （1）.使用經典公網模式，會自動分配區域網ip地址 ， nginx-ingress-controller lb沒有固定
   （2）.使用名稱空間做測試和生產環境的隔離，安全幾乎無保障
   （3）.線上只有一套環境而且是生產&測試兩用，對於運維來講等於沒有測試環境(因為大多數系統應用具備全域穿透)
   （4）.研發代碼可以直接通過gitlab上生產，卻不具備回滾功能，一旦出現未知bug(之前沒有檢測到的)，恢復不能做到快速簡捷
   （5）.集群架構和業務邏輯圖沒有做到實時更新，現有架構圖不能清晰展示生產&測試 應用邏輯
   （6）.許可權不嚴格，目前公司內部的許可權很混亂，目錄結構也混亂，不能根據目錄名稱看出目錄內容
   （7）. 伺服器優化不夠，伺服器上存在大量無效內容，造成伺服器的運行不是很理想
   （8）.伺服器設備配置不合理，存在相當一部分小伺服器，實用性不高

4. 要改造的架構是什麼？他們的優點？
   ​ 對目前架構主要改造點：
   ​ （1）.將目前測試環境剝離出線上K8S集群
   ​ （2）.增配一套線上預發環境(縮小版生產環境)
   ​ （3）.將原集群的網路模式有經典公網改為專用網路+彈性IP
   ​ 優點：
   ​ （1）.提高生產環境的穩定性和安全性
   ​ （2）.使用預發環境完全模擬生產環境，提高應用上生產的靠保障性

5. 改造後能給公司帶來什麼？是效率更高？更安全？還是更省錢？

   改造後的集群系統，形成，測試、預發、生產三套系統，測試線上下，預發和生產線上上，應用app 經過預發環境驗證後再上生產環境，安全性得到保障。將小伺服器更換大伺服器，既省錢又便於管理維護。

6. 改造牽涉的人有多少？需不需要動代碼？

   ​ 監管協助人：XXX

   ​ 業務協助人：XXX

   ​ 實際操作人：XXX

   目前方案，確定不動代碼。

考慮優化點：

統一環境名稱： 研發 預發 生產

研發環境： 線下 供研發人員使用

預發環境： 線上 縮小版的生產環境，並且兩者環境應儘可能一致（版本、應用等）

生產環境：線上 只有在預發環境經過驗證的應用，且總結有相應操作步驟和故障演練的文檔才能改動生產環境。

對生產的操作嚴格要求

（1）對生產的操作應提前在預發環境完成並得到驗證(而不是線上下的研發環境)。

（2）對生產的操作要嚴格進行：公司內部通知、官網通告、預案報告

（3）對生產的操作要嚴格按照許可權進行。生產的操作許可權縮小到個別人。提高安全級別。

對集群的優化

（1）. 合理設置各目錄的作用。如：
​ /data 目錄放數據
/var/log/xxx 放日誌
/service/scripts 目錄放腳本文件
/yaml/xxx/xxx xxx是大的方向 比如日誌系統(elfk) xxx是資源文件

（2）. 對集群的登陸 生產環境只能在公司辦公區域內登陸，預發環境可以公網登陸 加強對集群的管理

（3）. 公司內部業務、集群(業務)拓撲圖及時更新 有應用改動就更新

（4）. 加強對集群的穩定性優化 比如：對磁碟空間進行及時清理

（5）. 網路這塊原：經典公網ip 新：專用網路 + 彈性IP

（6）.故障演練，每隔一段時間(半年)進行一次故障演練，可以及時有效的檢驗集群的健壯性

操作流程規範化

生產環境：

1. 每次改動要提前提交郵件進行確認
2. 每次改動要形成文檔
3. 每次線上上的改動要記錄下操作命令和重要信息
4. 線上的改動除緊急bug外，一律先在預發環境進行驗證
5. 對cicd流程 進行切分，預發cicd，線上cd。
6. 對線上環境的改動要在辦公區進行，且改動涉及到的所有人員都應該在現場。

響應等級

業務可用類故障等級表

故障響應時間表

架構圖優化

優化點：
​ 1. 許可權分明
2. 測試、預發、生產區分明
3. 可靠性、安全性比優化前更高