[[420578]]

Kubernetes已經成為行業標準，并且也成為了運維標配，現在出去面試，如果哪個公司沒有注明需要Kubernetes技能(國企除外)，那么這個公司你就不要考慮了(錢給的實在多除外^_^)。

Kubernetes雖然成為了標準，但是不同的運維在實施的時候，或者說不同的公司在使用的時候是千奇百怪的，我們也會經常在一些Kubernetes社區群里看到一些千奇百怪的問題，這些問題除了提升自身硬實力之外，也要樹立一些做事的規范。這里從下面四個方面說一些個人的看法和見解，這些都是我自己在實際工作中運用的，說的不對的地方請指正。

樹標準

俗話說，無規則不成方圓。Kubernetes已經成為了標準，但是對于實施來說卻沒有標準，這就導致了一萬人有一萬個Kubernetes集群，玩法多變，也會導致問題多變。那這里的樹標準主要是指什么呢?

基礎設施標準

隨著云的能力不斷提升，很多互聯網公司已經不太去關心底層設施了，比如服務器的型號、維保，交換機的配置、機柜的信息等。那我們在選擇基礎設施的時候主要關注哪些呢?

我這里以阿里云為例，簡要列出以下幾點。

(1)ECS型號 在很多時候并不太關心型號問題，大多數情況下這是資金驅動，公司舍得花錢就買好點的，不舍得就將就用。我這里之所以列出來是為了避免因為不同的型號導致一些莫名奇妙的問題，比如說有的機器是獨享型，有的機器是共享型，共享型機器難免會被別的服務器影響導致一些不可描述的事情，這時候作為使用方來說很難去定位到具體的原因，大部分情況都會把這類問題推給云廠商。

但是運維的難處就在于“只要出問題，那就是你的問題”。雖然可以把鍋丟給云廠商，但是實際問題依舊存在，所以我們在做ECS選型的時候除了考慮價格，也要規避一些可能出現的問題，最好做到實例統一。

(2)系統版本 對于Kubernetes來說，不太去關注底層使用什么操作系統，但是作為運維來說最好統一，這樣最大的好處就是便于維護。維護難度降低了，在一定的程度上降低了風險。

當然選擇系統版本也要選擇熟悉的系統，比如你熟悉CentOS，那就選擇CentOS好了，不要去用什么Debian、Ubuntu等，雖然它們之前的變化不是很大。

(3)內核版本 內核和系統其實應該放在一起說，這里之所以單擰出來，主要還是Kubernetes、Docker對內核的要求還是比較高，在很多情況下我們都需要升級內核以滿足需求。

在選擇內核升級的時候一定要選擇穩定版，而且所有服務器都統一升級，這樣可以確定基礎設施是一致的。

(4)安全組配置 在公有云上都有安全組這一說，主要是控制網絡的進出。如果一套環境還是統一比較好，不僅方便管理控制，也大大降低了復雜度，不論是自己維護的復雜度，也包括交接出去的復雜度。

(5)網絡劃分 在公有云上不需要去管理實際的路由器、交換機，但是需要我們劃分網絡。我習慣根據業務劃分，比如有A\B\C三個業務部門，給A劃分192.168.1.0/24，給B劃分192.168.2.0/24，給C劃分192.168.3.0/24的網段，為什么要這么劃分呢?我是基于出口好配置來考慮的，在云上出口基本是使用Nat網關的，如果是同一個IP段，Nat網關就只能創建一個，如果多個網段就可以創建多個NAT網關，這樣可以在大流量的情況下進行一定的分流。

做這些的目的其實是讓運維的線路圖更清晰明了，運維的工作本身就比較雜，我們只有努力化繁為簡，才能更好的保障穩定性，也才有更多的時間去攻堅其他東西。

應用標準

在很多公司，運維都是一個不受重視的群體，換句話說就是沒有話語權，那怎么才能逐漸提升話語權呢?第一是主動，在應用的整個生命周期主動去參與，了解應用的動態，掌握應用的機制。第二是制定標準，在應用的生命周期中，去發現問題并針對問題給出解決方法，然后指定一系列標準，久而久之，大家都會按照這些去執行了。

話說回來，運維并不參與具體的代碼開發，大部分運維也看不到開發代碼，那如何去定義標準呢?

我從運維常會問或者常會用的幾個方面來進行簡要說明。

(1)打包方式 為什么要說打包方式呢?因為在給應用做CI的時候都會涉及到應用打包，如果應用打包方式統一我們是不是只需要做一個CI模板，或者說可以更好的減少參數配置。比如后端使用的開發語言都是java應用，有的時候習慣使用maven，有的人習慣使用gradle，哪種比較好呢?其實都差不多，但是如果規定只使用一種，是不是更簡單一點。

比如我這里就規定了只要java應用，全都采用gradle進行管理，那我在做CI的時候基本都不需要詢問開發人員如何打包了。

(2)應用目錄 應用目錄涉及如下幾個。

為什么把這幾個目錄單獨列出來呢?實際上是這幾個目錄在整個應用生命周期中都扮演著非常重要的角色，把這幾個目錄統一的，不論是制作鏡像還是收集日志，甚至是排查問題都能夠直接明了，不用為了找目錄而浪費時間。

比如目錄按以下方式：

- 部署目錄 /app 
- 緩存目錄 /app/cache 
- 日志目錄 /app/logs 
- 臨時目錄 /app/tmp 

(3)應用日志 做運維這么多年，深深的領悟了一個道理：日志不規范，運維兩行淚。所以應用日志定義好統一的格式以及輸出方式，最好能夠輸出到控制臺，這樣在做日志收集的時候方便快捷。

(4)運行參數 應用的運行時參數配置，比如運行端口、Java的JVM參數配置，以及新生代、老生代、永生代的堆內存大小配置等。

比如應用統一使用端口8080，JVM參數參考如下配置：

-server  
-XX:+UseG1GC  
-XX:MaxGCPauseMillis=50  
-Xms1G -Xmx1G 
-XX:MetaspaceSize=128m JAVA_MAXMETA_SIZE="512m"  
-XX:LargePageSizeInBytes=128m  
-XX:+ParallelRefProcEnabled  
-XX:+PrintAdaptiveSizePolicy  
-XX:+UseFastAccessorMethods  
-XX:+TieredCompilation  
-XX:+ExplicitGCInvokesConcurrent  
-XX:AutoBoxCacheMax=20000  
-XX:+UnlockExperimentalVMOptions  
-XX:+UseCGroupMemoryLimitForHeap  
-XX:+PerfDisableSharedMem  
-verbosegc  -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:/app/logs/gc.log" 
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/app/logs/oom-`date +%Y%m%d%H%M%S`.hprof" 

當然，這只是一個樣例，不是標準，具體的優化或者配置是根據具體情況進行微調的。

制品標準

Kubernetes中的應用制品都是容器鏡像，所以這里說的就是容器的制作一些建議。

(1)選擇標準并且統一的母鏡像，這樣更便于升級、更新、漏洞修復。

(2)鏡像的層級越少越好

(3)應用使用非root用戶運行，不要開啟特權模式

(4)不要安裝過多的命令軟件，在很多情況下，并不需要。

CI/CD標準

不同的公司有不同的CI/CD，有基于開源軟件的，有自研的，這里闡述的主要是針對開源軟件，在國內這種才是主流。

開源軟件的選擇也非常多，有GitlabCI，有jenkins，還有更云原生的比如Token、Argo Workflow等，那究竟選什么呢?我發現在很多群里經常有人在問“你們公司都用什么做CI/CD的，什么工具比較牛逼”。我個人覺得，在選擇什么工具的時候主要考慮以下幾點：

• 公司在過去的時間內使用的是什么工具，這些工具目前的優缺點是什么，如果要換工具，如何能保證優點繼續保持，缺點能夠得到改進，如果只是想單純的換個工具玩玩，真不建議去做切換，費力不討好。
• 公司整個的組織形式、人員情況。因為這套工具不只是運維使用，開發、測試都要使用，雖然運維能夠占據一定的主導地位，也要考慮整個團隊的接受能力。
• 選擇自己熟悉并且擅長的東西。這些工具說到底還是需要運維來進行維護管理，選擇自己熟悉的，避免出問題只有百度的尷尬局面。

但我們決定好使用的工具之后，就是真正實施的階段了。這里以Jenkins進行簡單的闡述，相對來說，我對jenkins熟悉點，所以在公司里我會首選這個。

• 充分使用Jenkins shareLibrary，將一些重復的代碼進行抽離形成單獨的方法，方便擴展。
• 前后端同一門開發語言的項目，Jenkinsfile最好能統一，這樣便于管理維護。
• Jenkinsfile中涉及的固定參數和可變參數需要固定好變量名，命令要規范易懂。
• 如果是多環境發布，需要做好分類管理，并且做好權限控制。
• 應用的發布不論是使用Helm Chart還是普通的deployment文件，為了便于管理最好使用同一種，減少混合使用的情況。

標準很重要，標準卻沒有標準。這句話是不是很矛盾?在很多情況下，并沒有嚴格意義上的標準，所謂的標準是因人而異、因地而異的，上面列出的也僅是我在工作中常用的，只能稱為是我的標準。

常積累

為什么要常積累?主要是因為現在技術發展的太快了，在這么高速迭代的時代，很多東西不可能一下就學完、學會，那就需要我們經常積累知識，將這些知識進行統一管理，在需要問題或者想學習的時候便于查找。

我每天早上會看一個小時左右的文章，如果看到比較不錯的文章就會把它們收藏歸類，并且會時不時去看一下。如果是自己新學的知識或者某種技能，就會把這些東西整理到語雀上，按著一定的目錄結構進行歸檔分類，在我需要的時候就能輕松的查詢。

多分享

積累是向內輸出，分享是向外輸出。向內輸出相對容易，因為這些東西都是別人整理好的，我們只是把需要的東西納為己用。向外輸出就相對難一點，因為這不僅僅是寫文章那么簡單。

如果是在社群分享，那就要把文章寫的易懂，為什么這么說呢?因為大部分人沒有太多的時間去研究很深的東西，都是走馬觀花的看看，如果需要喜歡的就駐留一下，不喜歡的就直接劃過，如果寫的太深，許多人都不愿意看的。

如果是在團隊內分享，不僅要寫的易懂，還要講的易懂。我之前的領導給我說過一句話：你要把別人都當成什么都不懂的小白。在分享的時候不要扯太多高大上的名詞，這些名詞除了吹牛逼，沒有太大的實際效果。

不論是哪種方式、哪種形式，都要養成多分享的習慣，當我們到達一定的階段過后，都逃不過這個過程，不論是管理還是技術專家。

勤學習

這個和"常積累"相輔相成。

學習是一件終身的事情，不論是何年齡，在何公司，處于何地位，都應該持續學習，當然在不同的階段學習的東西不一樣而已。

我每個月會看1~2本書，有純技術類的，也有育兒類的，還有成長類的，不論是哪種書籍，到現在已經保持3年多了，看到不錯的書籍還會多看1-2遍。

這個社會被分成了不同的階層，但是大部分都是底層的人，這類人都需要慢慢的向上爬，如何才能保持這種向上成長的趨勢呢?除了運氣之外，自身的實力才最主要，不然運氣來了你也抓不住。所以我們需要不斷的擴展我們的知識、技能，學習就是其中最主要的一環。

寫在最后

上面分享了一點個人的看法，在工作中一定要標準先行，然后圍繞標準做擴展，并且要時常保持一種向上成長的姿態，多學習，多積累，多分享。把這些培養成習慣，讓習慣成為自然，生活不是得過且過，是要不斷的向上。

本文轉載自微信公眾號「運維開發故事」

【編輯推薦】