在擁有了一個基礎(chǔ)設(shè)施完善的Kubernetes集群之后，想必大家就想把以前的服務(wù)以及后續(xù)的服務(wù)一股腦兒的搬到k8s集群里面了，然后指望著k8s就能自由的調(diào)度服務(wù)沒有后顧之憂了。實際上這才只是開始，還欠缺很多東西。

規(guī)劃namespace

首先建議大家先規(guī)劃一下如何分配namespace，這點非常的重要，否則你用著用著就會發(fā)現(xiàn)namespace會越來越多，并且越用越隨意，最后完全無法管理。

目前我們公司namespace的規(guī)劃是這樣的。
1、每個項目都單獨創(chuàng)建namespace，這個項目下的所有服務(wù)都放到這個namespace里面，這樣不同項目之間資源就不會沖突，而且給研發(fā)人員分配權(quán)限的時候也好處理，當然也可以按照：項目名-dev、項目名-test、項目名-release，這種方式來把一個項目的不同環(huán)境區(qū)分出來。

2、所有的工具服務(wù)全部丟到tools這個namespace下面，包括gitlab、drone、harbor、metersphere等，所有的工具都由運維人員統(tǒng)一管理，當然也可以分的更新一些，比如test-tools表示測試用的工具等。

3、創(chuàng)建一個temp的命名空間，這個命名空間專門用來創(chuàng)建一些臨時的測試用的容器，但是隨時可能會被刪除。

4、有一些chart包會限定namespace的就按照文檔要求創(chuàng)建，一般這樣的服務(wù)不會太多。

5、所有的演示用的項目都放到一個歸檔的namespace下面，這些服務(wù)一般不會改動了，僅作為演示使用。當一個項目完成之后，其服務(wù)也可以搬到歸檔用的namespace下面。

以上這些只是我們公司的一些規(guī)范，僅供參考，如果大家有其他的更好的規(guī)范也可以提出來一起學習一下。

規(guī)劃CICD

kubernetes對程序員而言其實是不友好的，畢竟打包、打鏡像、部署，這比直接java -jar可麻煩多了。所以我們要規(guī)劃好CICD，減少程序員與Kubernetes的直接打交道。

CICD工具的話也比較多，傳統(tǒng)的如jenkins，gitlab-ci等，都是可以的。之前有過一段時間使用jenkins，但總覺的太重了（至于JenkinsX那沉重的簡直離了大譜），而且還要寫大段的腳本。然后在一次意外的服務(wù)器崩潰，腳本數(shù)據(jù)丟失之后我就干脆拋棄了jenkins，選擇了更輕量級的Drone CI作為CICD工具。

Drone CI分為兩個部分，一個是Drone Server，它對接gitlab并且提供可視化界面。一個是Drone Runner，它從Server接收build請求，然后進行處理。對于中小型的團隊來說Drone CI絕對是夠用了。

只需要在項目里面定義一個.drone.yml就可以自動進行項目的構(gòu)建與打包了，非常的方便，一開始連CD我也是通過Drone來做，直到有一天無意間看到GitOps這個概念，然后發(fā)現(xiàn)了ArgoCD這個神奇的玩意兒。

ArgoCD的作用主要是從git倉庫中讀取kubenetes使用的例如yaml文件，然后把git倉庫里面的yaml文件的信息同步到Kubernetes集群中，并且還能做消息通知。這就帶來了一個很大的好處，可以直接看到每次更新deployment的信息了，并且把服務(wù)遷移到其他集群里面的時候，這些yaml文件就可以直接使用了，避免了要重寫yaml文件的尷尬。

后面我會詳細描述一下我是如何通過Drone CI和ArgoCD來搭建公司的CICD流程的。