[[420578]]

Kubernetes已經(jīng)成為行業(yè)標(biāo)準(zhǔn)，并且也成為了運(yùn)維標(biāo)配，現(xiàn)在出去面試，如果哪個(gè)公司沒(méi)有注明需要Kubernetes技能(國(guó)企除外)，那么這個(gè)公司你就不要考慮了(錢給的實(shí)在多除外^_^)。

Kubernetes雖然成為了標(biāo)準(zhǔn)，但是不同的運(yùn)維在實(shí)施的時(shí)候，或者說(shuō)不同的公司在使用的時(shí)候是千奇百怪的，我們也會(huì)經(jīng)常在一些Kubernetes社區(qū)群里看到一些千奇百怪的問(wèn)題，這些問(wèn)題除了提升自身硬實(shí)力之外，也要樹立一些做事的規(guī)范。這里從下面四個(gè)方面說(shuō)一些個(gè)人的看法和見解，這些都是我自己在實(shí)際工作中運(yùn)用的，說(shuō)的不對(duì)的地方請(qǐng)指正。

樹標(biāo)準(zhǔn)

俗話說(shuō)，無(wú)規(guī)則不成方圓。Kubernetes已經(jīng)成為了標(biāo)準(zhǔn)，但是對(duì)于實(shí)施來(lái)說(shuō)卻沒(méi)有標(biāo)準(zhǔn)，這就導(dǎo)致了一萬(wàn)人有一萬(wàn)個(gè)Kubernetes集群，玩法多變，也會(huì)導(dǎo)致問(wèn)題多變。那這里的樹標(biāo)準(zhǔn)主要是指什么呢?

基礎(chǔ)設(shè)施標(biāo)準(zhǔn)

隨著云的能力不斷提升，很多互聯(lián)網(wǎng)公司已經(jīng)不太去關(guān)心底層設(shè)施了，比如服務(wù)器的型號(hào)、維保，交換機(jī)的配置、機(jī)柜的信息等。那我們?cè)谶x擇基礎(chǔ)設(shè)施的時(shí)候主要關(guān)注哪些呢?

我這里以阿里云為例，簡(jiǎn)要列出以下幾點(diǎn)。

(1)ECS型號(hào) 在很多時(shí)候并不太關(guān)心型號(hào)問(wèn)題，大多數(shù)情況下這是資金驅(qū)動(dòng)，公司舍得花錢就買好點(diǎn)的，不舍得就將就用。我這里之所以列出來(lái)是為了避免因?yàn)椴煌男吞?hào)導(dǎo)致一些莫名奇妙的問(wèn)題，比如說(shuō)有的機(jī)器是獨(dú)享型，有的機(jī)器是共享型，共享型機(jī)器難免會(huì)被別的服務(wù)器影響導(dǎo)致一些不可描述的事情，這時(shí)候作為使用方來(lái)說(shuō)很難去定位到具體的原因，大部分情況都會(huì)把這類問(wèn)題推給云廠商。

但是運(yùn)維的難處就在于“只要出問(wèn)題，那就是你的問(wèn)題”。雖然可以把鍋丟給云廠商，但是實(shí)際問(wèn)題依舊存在，所以我們?cè)谧鯡CS選型的時(shí)候除了考慮價(jià)格，也要規(guī)避一些可能出現(xiàn)的問(wèn)題，最好做到實(shí)例統(tǒng)一。

(2)系統(tǒng)版本 對(duì)于Kubernetes來(lái)說(shuō)，不太去關(guān)注底層使用什么操作系統(tǒng)，但是作為運(yùn)維來(lái)說(shuō)最好統(tǒng)一，這樣最大的好處就是便于維護(hù)。維護(hù)難度降低了，在一定的程度上降低了風(fēng)險(xiǎn)。

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

(3)內(nèi)核版本 內(nèi)核和系統(tǒng)其實(shí)應(yīng)該放在一起說(shuō)，這里之所以單擰出來(lái)，主要還是Kubernetes、Docker對(duì)內(nèi)核的要求還是比較高，在很多情況下我們都需要升級(jí)內(nèi)核以滿足需求。

在選擇內(nèi)核升級(jí)的時(shí)候一定要選擇穩(wěn)定版，而且所有服務(wù)器都統(tǒng)一升級(jí)，這樣可以確定基礎(chǔ)設(shè)施是一致的。

(4)安全組配置 在公有云上都有安全組這一說(shuō)，主要是控制網(wǎng)絡(luò)的進(jìn)出。如果一套環(huán)境還是統(tǒng)一比較好，不僅方便管理控制，也大大降低了復(fù)雜度，不論是自己維護(hù)的復(fù)雜度，也包括交接出去的復(fù)雜度。

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

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

應(yīng)用標(biāo)準(zhǔn)

在很多公司，運(yùn)維都是一個(gè)不受重視的群體，換句話說(shuō)就是沒(méi)有話語(yǔ)權(quán)，那怎么才能逐漸提升話語(yǔ)權(quán)呢?第一是主動(dòng)，在應(yīng)用的整個(gè)生命周期主動(dòng)去參與，了解應(yīng)用的動(dòng)態(tài)，掌握應(yīng)用的機(jī)制。第二是制定標(biāo)準(zhǔn)，在應(yīng)用的生命周期中，去發(fā)現(xiàn)問(wèn)題并針對(duì)問(wèn)題給出解決方法，然后指定一系列標(biāo)準(zhǔn)，久而久之，大家都會(huì)按照這些去執(zhí)行了。

話說(shuō)回來(lái)，運(yùn)維并不參與具體的代碼開發(fā)，大部分運(yùn)維也看不到開發(fā)代碼，那如何去定義標(biāo)準(zhǔn)呢?

我從運(yùn)維常會(huì)問(wèn)或者常會(huì)用的幾個(gè)方面來(lái)進(jìn)行簡(jiǎn)要說(shuō)明。

(1)打包方式 為什么要說(shuō)打包方式呢?因?yàn)樵诮o應(yīng)用做CI的時(shí)候都會(huì)涉及到應(yīng)用打包，如果應(yīng)用打包方式統(tǒng)一我們是不是只需要做一個(gè)CI模板，或者說(shuō)可以更好的減少參數(shù)配置。比如后端使用的開發(fā)語(yǔ)言都是java應(yīng)用，有的時(shí)候習(xí)慣使用maven，有的人習(xí)慣使用gradle，哪種比較好呢?其實(shí)都差不多，但是如果規(guī)定只使用一種，是不是更簡(jiǎn)單一點(diǎn)。

比如我這里就規(guī)定了只要java應(yīng)用，全都采用gradle進(jìn)行管理，那我在做CI的時(shí)候基本都不需要詢問(wèn)開發(fā)人員如何打包了。

(2)應(yīng)用目錄 應(yīng)用目錄涉及如下幾個(gè)。

為什么把這幾個(gè)目錄單獨(dú)列出來(lái)呢?實(shí)際上是這幾個(gè)目錄在整個(gè)應(yīng)用生命周期中都扮演著非常重要的角色，把這幾個(gè)目錄統(tǒng)一的，不論是制作鏡像還是收集日志，甚至是排查問(wèn)題都能夠直接明了，不用為了找目錄而浪費(fèi)時(shí)間。

比如目錄按以下方式：

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

(3)應(yīng)用日志 做運(yùn)維這么多年，深深的領(lǐng)悟了一個(gè)道理：日志不規(guī)范，運(yùn)維兩行淚。所以應(yīng)用日志定義好統(tǒng)一的格式以及輸出方式，最好能夠輸出到控制臺(tái)，這樣在做日志收集的時(shí)候方便快捷。

(4)運(yùn)行參數(shù) 應(yīng)用的運(yùn)行時(shí)參數(shù)配置，比如運(yùn)行端口、Java的JVM參數(shù)配置，以及新生代、老生代、永生代的堆內(nèi)存大小配置等。

比如應(yīng)用統(tǒng)一使用端口8080，JVM參數(shù)參考如下配置：

-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" 

當(dāng)然，這只是一個(gè)樣例，不是標(biāo)準(zhǔn)，具體的優(yōu)化或者配置是根據(jù)具體情況進(jìn)行微調(diào)的。

制品標(biāo)準(zhǔn)

Kubernetes中的應(yīng)用制品都是容器鏡像，所以這里說(shuō)的就是容器的制作一些建議。

(1)選擇標(biāo)準(zhǔn)并且統(tǒng)一的母鏡像，這樣更便于升級(jí)、更新、漏洞修復(fù)。

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

(3)應(yīng)用使用非root用戶運(yùn)行，不要開啟特權(quán)模式

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

CI/CD標(biāo)準(zhǔn)

不同的公司有不同的CI/CD，有基于開源軟件的，有自研的，這里闡述的主要是針對(duì)開源軟件，在國(guó)內(nèi)這種才是主流。

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

• 公司在過(guò)去的時(shí)間內(nèi)使用的是什么工具，這些工具目前的優(yōu)缺點(diǎn)是什么，如果要換工具，如何能保證優(yōu)點(diǎn)繼續(xù)保持，缺點(diǎn)能夠得到改進(jìn)，如果只是想單純的換個(gè)工具玩玩，真不建議去做切換，費(fèi)力不討好。
• 公司整個(gè)的組織形式、人員情況。因?yàn)檫@套工具不只是運(yùn)維使用，開發(fā)、測(cè)試都要使用，雖然運(yùn)維能夠占據(jù)一定的主導(dǎo)地位，也要考慮整個(gè)團(tuán)隊(duì)的接受能力。
• 選擇自己熟悉并且擅長(zhǎng)的東西。這些工具說(shuō)到底還是需要運(yùn)維來(lái)進(jìn)行維護(hù)管理，選擇自己熟悉的，避免出問(wèn)題只有百度的尷尬局面。

但我們決定好使用的工具之后，就是真正實(shí)施的階段了。這里以Jenkins進(jìn)行簡(jiǎn)單的闡述，相對(duì)來(lái)說(shuō)，我對(duì)jenkins熟悉點(diǎn)，所以在公司里我會(huì)首選這個(gè)。

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

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

常積累

為什么要常積累?主要是因?yàn)楝F(xiàn)在技術(shù)發(fā)展的太快了，在這么高速迭代的時(shí)代，很多東西不可能一下就學(xué)完、學(xué)會(huì)，那就需要我們經(jīng)常積累知識(shí)，將這些知識(shí)進(jìn)行統(tǒng)一管理，在需要問(wèn)題或者想學(xué)習(xí)的時(shí)候便于查找。

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

多分享

積累是向內(nèi)輸出，分享是向外輸出。向內(nèi)輸出相對(duì)容易，因?yàn)檫@些東西都是別人整理好的，我們只是把需要的東西納為己用。向外輸出就相對(duì)難一點(diǎn)，因?yàn)檫@不僅僅是寫文章那么簡(jiǎn)單。

如果是在社群分享，那就要把文章寫的易懂，為什么這么說(shuō)呢?因?yàn)榇蟛糠秩藳](méi)有太多的時(shí)間去研究很深的東西，都是走馬觀花的看看，如果需要喜歡的就駐留一下，不喜歡的就直接劃過(guò)，如果寫的太深，許多人都不愿意看的。

如果是在團(tuán)隊(duì)內(nèi)分享，不僅要寫的易懂，還要講的易懂。我之前的領(lǐng)導(dǎo)給我說(shuō)過(guò)一句話：你要把別人都當(dāng)成什么都不懂的小白。在分享的時(shí)候不要扯太多高大上的名詞，這些名詞除了吹牛逼，沒(méi)有太大的實(shí)際效果。

不論是哪種方式、哪種形式，都要養(yǎng)成多分享的習(xí)慣，當(dāng)我們到達(dá)一定的階段過(guò)后，都逃不過(guò)這個(gè)過(guò)程，不論是管理還是技術(shù)專家。

勤學(xué)習(xí)

這個(gè)和"常積累"相輔相成。

學(xué)習(xí)是一件終身的事情，不論是何年齡，在何公司，處于何地位，都應(yīng)該持續(xù)學(xué)習(xí)，當(dāng)然在不同的階段學(xué)習(xí)的東西不一樣而已。

我每個(gè)月會(huì)看1~2本書，有純技術(shù)類的，也有育兒類的，還有成長(zhǎng)類的，不論是哪種書籍，到現(xiàn)在已經(jīng)保持3年多了，看到不錯(cuò)的書籍還會(huì)多看1-2遍。

這個(gè)社會(huì)被分成了不同的階層，但是大部分都是底層的人，這類人都需要慢慢的向上爬，如何才能保持這種向上成長(zhǎng)的趨勢(shì)呢?除了運(yùn)氣之外，自身的實(shí)力才最主要，不然運(yùn)氣來(lái)了你也抓不住。所以我們需要不斷的擴(kuò)展我們的知識(shí)、技能，學(xué)習(xí)就是其中最主要的一環(huán)。

寫在最后

上面分享了一點(diǎn)個(gè)人的看法，在工作中一定要標(biāo)準(zhǔn)先行，然后圍繞標(biāo)準(zhǔn)做擴(kuò)展，并且要時(shí)常保持一種向上成長(zhǎng)的姿態(tài)，多學(xué)習(xí)，多積累，多分享。把這些培養(yǎng)成習(xí)慣，讓習(xí)慣成為自然，生活不是得過(guò)且過(guò)，是要不斷的向上。

本文轉(zhuǎn)載自微信公眾號(hào)「運(yùn)維開發(fā)故事」

【編輯推薦】