我前前后后折騰了大半年踩了無數(shù)坑才把公司那套從“代碼提交到線上發(fā)布全靠手搓”的流程逐步升級成了以Docker、K8s、Jenkins為核心的云原生DevOps全鏈路體系。這套體系上線后部署效率提升得非常明顯而且因為流程標準化了新同事上手也快了很多。這篇文章就結(jié)合我的實操經(jīng)歷把整個體系的構(gòu)建思路、關(guān)鍵細節(jié)、以及那些文檔里不會寫的坑一次性說清楚。如果你正在打算搞這套東西或者已經(jīng)在這條路上但遇到了瓶頸這篇文章應(yīng)該能給你一些切實可用的參考。先說清楚這套體系到底解決了什么問題。在傳統(tǒng)方式下開發(fā)把代碼提交到Git倉庫運維手動去服務(wù)器拉代碼、打包、停服、部署偶爾還要半夜爬起來處理發(fā)布事故。環(huán)境不一致的問題、依賴沖突的問題、回滾困難的問題每一個都讓人頭疼。而云原生DevOps的核心思路就是把“環(huán)境”和“應(yīng)用”都變成代碼化的、可版本管理的資源通過自動化的流水線把構(gòu)建、測試、部署這一整條鏈路串起來。Docker負責(zé)把應(yīng)用連同它的運行環(huán)境一起打包成鏡像解決環(huán)境一致性問題K8s負責(zé)這些鏡像的編排調(diào)度和生命周期管理解決部署和擴縮容問題Jenkins則作為那個“總控臺”把代碼拉取、鏡像構(gòu)建、鏡像推送、K8s滾動更新這一系列動作編排成一條自動化的流水線。這篇內(nèi)容我會從最底層的Docker基礎(chǔ)環(huán)境搭建開始講然后到K8s集群的部署規(guī)劃再到Jenkins流水線的設(shè)計最后會重點講一下這套體系跑起來之后最常見的那些故障和排查思路。整個內(nèi)容都是按照我實際落地的順序來的你可以把它當(dāng)成一份從0到1的實戰(zhàn)筆記來看。1. 為什么偏偏是DockerK8sJenkins這三件套很多剛開始接觸云原生的朋友會問市面上的容器和編排工具那么多為什么組合來組合去最終繞不開這三樣。其實答案很簡單這三者分別解決的是不同層面的問題而且恰好能嚴絲合縫地銜接在一起。Docker解決的是環(huán)境一致性和打包標準化的問題。在沒有容器之前最經(jīng)典的一句話就是“在我機器上是好的啊”。開發(fā)環(huán)境、測試環(huán)境、生產(chǎn)環(huán)境之間的系統(tǒng)版本、依賴庫版本、配置差異導(dǎo)致同一個應(yīng)用在A機器上跑得好好的到了B機器上就各種報錯。Docker把應(yīng)用二進制文件和它依賴的所有庫、配置文件、環(huán)境變量打包成了一個只讀的鏡像然后用這個鏡像去創(chuàng)建容器運行。所有環(huán)境跑的是同一個鏡像環(huán)境差異這個老大難問題從根上被解掉了。K8s解決的是大規(guī)模容器的編排調(diào)度和管理的問題。當(dāng)你的容器數(shù)量只有幾個的時候手動docker run完全夠用。但當(dāng)容器數(shù)量上升到幾十個上百個分布在好幾臺機器上時你需要知道容器跑在哪些機器上、哪些容器掛掉了需要重啟、流量如何在不同副本間分發(fā)、高峰期怎么快速擴容。這些都是K8s的看家本領(lǐng)。它把一組機器抽象成一個資源池你只需要聲明“我要跑3個副本”K8s自己會去找合適的機器把Pod拉起來。Jenkins解決的是整個鏈條的自動化串聯(lián)的問題。代碼從提交到上線中間經(jīng)歷拉代碼、單元測試、鏡像構(gòu)建、鏡像推送、更新K8s deployment等一系列操作。Jenkins Pipeline把這些操作編排成一段可以版本管理的腳本只要代碼一提交到指定分支Pipeline自動觸發(fā)一條龍跑完整個流程。它相當(dāng)于這條自動化生產(chǎn)線的總控臺。這三者單獨拿出來各自都有替代品但組合在一起形成了一條從代碼到容器的完整通路。Docker負責(zé)把代碼變成鏡像K8s負責(zé)把鏡像變成服務(wù)Jenkins負責(zé)讓這一切自動發(fā)生。理解了這一層依賴關(guān)系你再去看后文的實操內(nèi)容思路會清晰很多。2. 從一臺干凈服務(wù)器開始的Docker基礎(chǔ)環(huán)境搭建不管你是要在生產(chǎn)環(huán)境用還是先搭一套測試環(huán)境練手Docker的基礎(chǔ)環(huán)境都必須搞扎實。這里我把自己在Linux環(huán)境下的安裝過程和需要注意的點完整列出來。別小看這一步很多人后面出問題追根溯源都是Docker這一層就沒裝干凈。2.1 操作系統(tǒng)準備與內(nèi)核參數(shù)調(diào)整Docker對宿主機內(nèi)核有要求官方推薦使用Linux內(nèi)核3.10以上版本。CentOS 7.9、Ubuntu 20.04及以上版本的系統(tǒng)默認內(nèi)核都能滿足要求。我建議優(yōu)先選用Ubuntu 20.04以上的版本因為后續(xù)K8s對內(nèi)核模塊和iptables版本的要求Ubuntu的兼容性明顯比CentOS 7系列省心。當(dāng)然CentOS 7.9也能跑但如果你還沒選型我會優(yōu)先推薦Ubuntu。裝系統(tǒng)的時候有一個細節(jié)值得注意磁盤分區(qū)時盡量把 /var 目錄單獨分一個大區(qū)。因為Docker默認的數(shù)據(jù)目錄就掛在 /var/lib/docker 下面鏡像、容器層、卷數(shù)據(jù)全在這里。如果你把 / 和 /var 放在一起跑一陣子鏡像多了很容易把根分區(qū)撐爆。我見過不少同事的服務(wù)器掛掉不是系統(tǒng)出問題就是Docker數(shù)據(jù)目錄把磁盤塞滿了。安裝docker之前先確認一下系統(tǒng)內(nèi)核網(wǎng)絡(luò)轉(zhuǎn)發(fā)功能是開啟的# 永久開啟內(nèi)核轉(zhuǎn)發(fā) cat EOF | sudo tee /etc/sysctl.d/k8s.conf net.ipv4.ip_forward 1 net.bridge.bridge-nf-call-iptables 1 EOF # 立即生效 sudo sysctl -p /etc/sysctl.d/k8s.conf這個配置非常關(guān)鍵如果不開啟后面容器和容器之間通信、容器訪問外網(wǎng)都會出現(xiàn)各種莫名其妙的超時問題。這一步做完再開始正式安裝Docker。2.2 Docker引擎安裝與國內(nèi)鏡像源加速我在Ubuntu上習(xí)慣用官方腳本或者是直接添加官方GPG密鑰來安裝。這里用最穩(wěn)妥的手動方式# 卸載可能存在的舊版本 sudo apt-get remove docker docker-engine docker.io containerd runc # 安裝依賴 sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg lsb-release # 添加Docker官方GPG密鑰 sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 添加軟件源 echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin安裝完成后有一個國內(nèi)網(wǎng)絡(luò)環(huán)境下必須做的事——配置鏡像加速器。Docker Hub在國內(nèi)的訪問速度很不穩(wěn)定不配置加速器拉一個幾十MB的鏡像可能要等幾分鐘甚至更久一旦鏡像體積到幾百MB基本就沒法用了。sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [ https://docker.m.daocloud.io ] } EOF sudo systemctl daemon-reload sudo systemctl restart docker關(guān)于鏡像加速地址這個變化頻率很快你可以在網(wǎng)上搜一下當(dāng)前可用的加速器。不同加速器的穩(wěn)定性和速度差別很大我建議是配置兩三個萬一某一個掛了還有備用的。另外提醒一句加速器只影響拉取鏡像不影響你往自己的私有倉庫推送鏡像。配置完成后驗證Docker是否正常工作sudo docker run hello-world sudo docker info看到Server Version那行輸出版本號說明Docker引擎已經(jīng)正常工作了。2.3 Docker常用命令速查與理解容器生命周期Docker的命令很多但對于做DevOps鏈路來說高頻用到的就是鏡像管理和容器生命周期管理這兩類。這里把我平時最常用的命令整理成一個速查表命令作用備注docker pull 鏡像名:標簽拉取鏡像到本地不寫標簽?zāi)Jlatestdocker images查看本地鏡像列表-docker rmi 鏡像ID刪除鏡像有容器引用時需先刪容器docker ps -a查看所有容器-a參數(shù)能看到退出的容器docker run -d --name 容器名 -p 宿主機端口:容器端口 鏡像名啟動容器-d后臺運行docker exec -it 容器ID bash進入容器排障時常用docker logs -f 容器ID查看容器日志-f表示實時跟讀docker stop / docker rm停止/刪除容器-f參數(shù)可強制刪除運行中容器docker system prune清理懸空鏡像和停止的容器慎用會刪除未使用的資源有一個很容易犯的誤區(qū)就是混淆了鏡像和容器的關(guān)系。打個比方鏡像是“類”容器是“實例”。同一個鏡像可以啟動多個容器每個容器都是獨立運行的。修改容器里的文件不會影響鏡像本身。所以當(dāng)你改了容器里的配置來排查問題發(fā)現(xiàn)重啟容器后配置又變回去了別慌這是正常的因為容器是基于鏡像創(chuàng)建的。2.4 Docker數(shù)據(jù)卷和網(wǎng)絡(luò)的核心配置生產(chǎn)環(huán)境使用Docker有兩個問題必須有清醒的規(guī)劃數(shù)據(jù)持久化和網(wǎng)絡(luò)模型。數(shù)據(jù)卷用于解決容器刪除后數(shù)據(jù)丟失的問題。Docker容器是無狀態(tài)的容器一刪容器內(nèi)寫入的文件立即消失。對于MySQL、Redis這類需要存數(shù)據(jù)的應(yīng)用數(shù)據(jù)必須掛載到宿主機目錄或者使用命名卷。啟動MySQL容器時我習(xí)慣這樣docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDyourpassword \ -v /data/mysql:/var/lib/mysql \ mysql:8.0-v參數(shù)把宿主機 /data/mysql 目錄映射到容器內(nèi)的數(shù)據(jù)目錄這樣即使容器損壞刪掉數(shù)據(jù)也還在宿主機上。在K8s環(huán)境里這個思想演變成了PersistentVolumePV和PersistentVolumeClaimPVC抽象底層邏輯是相通的。網(wǎng)絡(luò)方面Docker默認的bridge網(wǎng)絡(luò)適合單機容器通信。但K8s集群里容器跨宿主機通信需要更復(fù)雜的網(wǎng)絡(luò)方案比如Calico、Flannel等。這一塊我們后面講K8s的時候再展開你在單機測試階段只要明白同一個宿主機上如果多個容器需要互相訪問可以通過自定義bridge網(wǎng)絡(luò)通信也可以通過宿主機端口映射訪問。這已經(jīng)是基本夠用的網(wǎng)絡(luò)知識了。3. K8s集群搭建前的硬件規(guī)劃與架構(gòu)設(shè)計思路K8s集群和Docker單機完全是兩個量級的復(fù)雜度。常見錯誤是直接用一臺機器既裝Docker又裝K8s單節(jié)點一開始測試沒問題真正跑業(yè)務(wù)時才發(fā)現(xiàn)各種調(diào)度上的坑。我在搭建集群之前先把架構(gòu)規(guī)劃講清楚。3.1 生產(chǎn)環(huán)境最小集群的節(jié)點角色劃分K8s集群的基本角色分為Master節(jié)點控制平面和Worker節(jié)點工作節(jié)點。生產(chǎn)環(huán)境為了保證高可用Master節(jié)點至少要3臺通過高可用組件如keepalived或云廠商的負載均衡對外提供穩(wěn)定入口。但如果你搭建的是測試環(huán)境或者剛開始學(xué)習(xí)單Master節(jié)點的集群也能跑起來——只要你能接受管理節(jié)點掛了的時候整個集群不可調(diào)度這件事。我比較推薦的起步配置是1臺Master 2臺Worker或者3臺Master 3臺Worker。前者適合學(xué)習(xí)驗證后者適合小規(guī)模生產(chǎn)。節(jié)點角色分配如下角色數(shù)量核心組件建議配置Master1~3kube-apiserver, kube-controller-manager, kube-scheduler, etcd4C8GSSDWorker2~3kubelet, kube-proxy, 容器運行時8C16G起步Master節(jié)點的核心是etcd。etcd是K8s的大腦存儲了集群全部狀態(tài)數(shù)據(jù)它的讀寫性能直接決定集群的響應(yīng)速度。有條件的一定要把etcd數(shù)據(jù)目錄放到專門的高性能SSD盤上。我踩過的一個坑是etcd數(shù)據(jù)目錄和系統(tǒng)盤共用一塊普通機械硬盤集群一跑起來Pod調(diào)度和狀態(tài)同步慢得像蝸牛爬。3.2 如何規(guī)劃鏡像倉庫和存放鏡像的持久化存儲K8s要拉取鏡像來創(chuàng)建Pod鏡像從哪里來是一個需要提前想清楚的問題。如果K8s節(jié)點都直接去Docker Hub拉鏡像首先速度很難保證其次生產(chǎn)環(huán)境的鏡像是不能隨便用公共倉庫的。所以搭建K8s之前先把私有鏡像倉庫規(guī)劃好。常見的私有鏡像倉庫方案是Harbor它不僅支持鏡像存儲和權(quán)限控制還自帶漏洞掃描和復(fù)制功能是國內(nèi)使用最廣泛的方案之一。另一種輕量級的方案是直接使用Docker自帶的Registry鏡像簡單場景夠用但缺少UI界面和權(quán)限管理。構(gòu)建DevOps鏈路時我強烈建議第一步先把Harbor部署起來讓它成為整個體系的鏡像中轉(zhuǎn)站# 下載Harbor離線安裝包解壓后修改harbor.yml wget https://github.com/goharbor/harbor/releases/download/v2.9.0/harbor-offline-installer-v2.9.0.tgz tar xvf harbor-offline-installer-v2.9.0.tgz cd harbor cp harbor.yml.tmpl harbor.yml vim harbor.ymlharbor.yml里有幾個關(guān)鍵配置項hostname: 配置為你給Harbor規(guī)劃的域名或IPharbor_admin_password: 管理員的初始密碼安裝完記得改不要一直用默認的Harbor12345data_volume: 鏡像存儲路徑建議單獨掛一個大磁盤如果只打算用HTTP訪問記得把https相關(guān)配置注釋掉配置完成后運行./install.sh然后通過瀏覽器訪問http://你的服務(wù)器IP就能看到Web界面了。K8s節(jié)點從Harbor拉取私有鏡像有兩種方式。一是在每個節(jié)點上通過docker login登錄Harbor這樣Docker就會把憑證緩存到本地K8s經(jīng)由CRI調(diào)用容器運行時拉鏡像時自然用上了。二是通過K8s的Secret機制創(chuàng)建鏡像拉取憑證kubectl create secret docker-registry regcred \ --docker-serveryour-harbor-server \ --docker-usernameadmin \ --docker-passwordyourpassword \ --docker-emailyourmailexample.com然后在Deployment的YAML里通過imagePullSecrets字段引用這個Secret。我后文在Jenkins流水線編排時應(yīng)用部署這一步會用到這個Secret你先把概念理解清楚。3.3 節(jié)點內(nèi)核參數(shù)與kubeadm初始化實戰(zhàn)K8s集群的搭建我推薦使用kubeadm工具這是官方推薦的標準工具零散手動配置的步驟被大大簡化。但從實踐來看如果你在CentOS 7或者Ubuntu環(huán)境里按kubeadm流程走有幾個環(huán)節(jié)特別容易出錯我專門列出來。首先是關(guān)閉swap分區(qū)。K8s集群節(jié)點要求關(guān)閉swap因為kubelet的cgroup管理默認假設(shè)節(jié)點沒有啟用swapsudo swapoff -a sudo sed -i / swap / s/^/#/ /etc/fstab不關(guān)swap的話kubelet會直接啟動失敗錯誤日志會提示你“running with swap on is not supported, please disable swap”。這句話我太熟了當(dāng)初在虛擬機里折騰的時候第一次初始化失敗就是這個原因。然后是加載內(nèi)核模塊和設(shè)置系統(tǒng)參數(shù)cat EOF | sudo tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF sudo modprobe overlay sudo modprobe br_netfilter cat EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.ip_forward 1 EOF sudo sysctl --system這些和Docker安裝時的內(nèi)核參數(shù)類似但K8s的要求更嚴格一些br_netfilter模塊必須加載否則iptables規(guī)則無法作用于bridge網(wǎng)絡(luò)流量Service的流量轉(zhuǎn)發(fā)會出問題。接下來就可以正式安裝kubelet、kubeadm、kubectl這三個核心組件并初始化集群了。安裝部分略過細節(jié)直接把初始化命令寫出來sudo kubeadm init \ --apiserver-advertise-address192.168.1.10 \ --image-repository registry.aliyuncs.com/google_containers \ --pod-network-cidr10.244.0.0/16 \ --kubernetes-versionv1.28.2這里有一個非常關(guān)鍵的參數(shù)--image-repository registry.aliyuncs.com/google_containers。因為K8s核心組件鏡像默認是從registry.k8s.io拉取的這個地址在部分網(wǎng)絡(luò)環(huán)境下訪問速度很慢甚至直接失敗。使用阿里云的鏡像倉庫加速可以快速拉取到所有K8s核心組件的鏡像。初始化成功之后按提示執(zhí)行配置kubectl的命令然后安裝Pod網(wǎng)絡(luò)插件。我用的比較多的是Calico它性能好并且支持NetworkPolicykubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/calico.yaml等kubectl get pods -n kube-system里所有Pod都變成Running狀態(tài)再將Worker節(jié)點加入集群。Worker節(jié)點上執(zhí)行kubeadm join命令這個命令在Master初始化時末尾會打印出來需要記下來。3.4 K8s的LNMP架構(gòu)部署實驗理解工作負載和Service的核心邏輯集群搭好之后別急著跑各種復(fù)雜業(yè)務(wù)先用一個經(jīng)典的LNMP架構(gòu)部署實驗把K8s的核心概念串一遍。這個實驗特別適合驗證集群網(wǎng)絡(luò)、存儲和Pod調(diào)度是否正常工作而且部署過程中能直觀理解K8s的幾個核心對象Deployment、Service、ConfigMap、PersistentVolumeClaim。LNMP架構(gòu)也就是Linux Nginx MySQL PHP的組合。在K8s里的部署思路是這樣拆分的MySQL作為有狀態(tài)服務(wù)需要持久化存儲用StatefulSet或DeploymentPVC的方式部署并通過ClusterIP Service 對內(nèi)暴露3306端口Nginx和PHP-FPM是典型的Web服務(wù)分別部署成DeploymentNginx通過ConfigMap配置反向代理到PHP-FPM的ServicePHP-FPM的代碼文件需要掛載共享存儲Nginx和PHP-FPM兩個Pod同時掛載同一個PVC這樣才能讓Nginx找到PHP文件這里以部署MySQL為例YAML長這樣apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mysql-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi --- apiVersion: apps/v1 kind: Deployment metadata: name: mysql spec: replicas: 1 selector: matchLabels: app: mysql template: metadata: labels: app: mysql spec: containers: - name: mysql image: mysql:8.0 ports: - containerPort: 3306 env: - name: MYSQL_ROOT_PASSWORD valueFrom: secretKeyRef: name: mysql-secret key: password volumeMounts: - name: mysql-data mountPath: /var/lib/mysql volumes: - name: mysql-data persistentVolumeClaim: claimName: mysql-pvc注意兩個細節(jié)一個是通過secretKeyRef從Secret里讀取MySQL的root密碼不要明文寫在YAML里另一個是通過PVC把MySQL數(shù)據(jù)持久化到集群存儲中Pod被重新調(diào)度到其他節(jié)點后數(shù)據(jù)不丟。我這個實驗在第一次跑的時候也遇到了Pod調(diào)度失敗的情況原因是在PV還沒創(chuàng)建好的時候PVC一直處于Pending狀態(tài)Deployment對應(yīng)的Pod就卡在ContainerCreating。所以說K8s的排障第一步永遠是看狀態(tài)、看事件kubectl describe pod能告訴你最直接的原因。4. Jenkins編排流水線打通提交代碼到滾動上線的最后一公里整套體系中引入Jenkins的價值在于把所有手動操作變成一條可控、可追溯、可重復(fù)執(zhí)行的流水線。你前面通過Docker解決了鏡像的構(gòu)建和交付通過K8s解決了應(yīng)用的部署和運維而Jenkins負責(zé)把“構(gòu)建-推送-部署”這幾個環(huán)節(jié)串成一個整體。這一章我來講實際流水線的設(shè)計思路以及那些環(huán)境變量和權(quán)限控制的細節(jié)。4.1 Jenkins的兩種主要安裝方式對比Jenkins的安裝部署方式有幾種我給你分析一下各自的適用場景。傳統(tǒng)的方式是直接在服務(wù)器上安裝一個獨立的Java運行環(huán)境然后跑Jenkins war包這是最經(jīng)典的玩法。優(yōu)點是排障直觀、符合大多數(shù)人的使用習(xí)慣缺點是和環(huán)境耦合較緊升級維護需要花時間。如果你已經(jīng)折騰過若干次Jenkins部署這套方式應(yīng)該很順手。另一種方式是Docker方式運行Jenkins。官方鏡像jenkins/jenkins:lts-jdk17可以直接跑。優(yōu)點是隔離干凈升級鏡像即可升級Jenkins缺點是容器內(nèi)外文件權(quán)限、Docker socket掛載這些細節(jié)需要特別注意。我個人的建議是如果打算做完整的DevOps鏈路推薦Docker方式運行Jenkins但需要把Docker socket掛載給Jenkins容器。什么意思就是讓Jenkins容器能直接調(diào)用宿主機的Docker守護進程這樣流水線里可以直接執(zhí)行docker build、docker push這些命令而不需要在Jenkins容器內(nèi)再套一層Docker也就是所謂的Docker in Docker這個方案弊病不少不建議用。Docker方式啟動Jenkins的命令大致長這樣docker run -d \ --name jenkins \ -p 8080:8080 \ -p 50000:50000 \ -v /var/jenkins_home:/var/jenkins_home \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /usr/bin/docker:/usr/bin/docker \ jenkins/jenkins:lts-jdk17這中間有兩個極容易踩的坑。第一個容器內(nèi)的用戶是jenkinsUID 1000而掛載的宿主機目錄如果權(quán)限設(shè)置不對Jenkins容器寫不了/var/jenkins_home目錄初始化就會失敗。解決辦法是宿主機上先創(chuàng)建好目錄并授權(quán)mkdir -p /var/jenkins_home chown -R 1000:1000 /var/jenkins_home第二個掛載Docker socket之后Jenkins容器內(nèi)執(zhí)行docker命令實際上操作的是宿主機Docker這帶來便利的同時也意味著——任何能創(chuàng)建Jenkins Job的人都相當(dāng)于擁有了宿主機的root權(quán)限。權(quán)限分配上必須格外謹慎不能讓每個普通開發(fā)都隨便創(chuàng)建自由的Pipeline任務(wù)。4.2 第一次跑通流水線必須搞懂的Jenkins Pipeline語法Jenkins Pipeline有兩種寫法一種是Declarative Pipeline聲明式一種是Scripted Pipeline腳本式。我更推薦聲明式因為它結(jié)構(gòu)清晰、強制定義了各個階段而且配合Blue Ocean界面觀看執(zhí)行過程非常直觀。一個典型的聲明式Pipeline骨架是這樣的pipeline { agent any environment { DOCKER_REGISTRY your-harbor-server.com DOCKER_CREDENTIALS credentials(harbor-admin) } stages { stage(Checkout) { steps { git branch: main, url: https://your-gitlab.com/your-project.git, credentialsId: gitlab-credentials } } stage(Build Image) { steps { script { docker.withRegistry(https://${DOCKER_REGISTRY}, harbor-admin) { def customImage docker.build(${DOCKER_REGISTRY}/library/myapp:${BUILD_NUMBER}) customImage.push() } } } } stage(Deploy to K8s) { steps { script { sh kubectl set image deployment/myapp \ myapp${DOCKER_REGISTRY}/library/myapp:${BUILD_NUMBER} -n production } } } } }這段代碼里有幾個關(guān)鍵點需要逐一解釋。第一個是agent any。它表示這個Pipeline可以在任何一個可用的Jenkins執(zhí)行器上運行。如果你有多個不同用途的節(jié)點比如一個專用于構(gòu)建鏡像的節(jié)點可以替換成agent { label docker-builder }。第二個是environment塊里的DOCKER_REGISTRY。這個值建議不要直接寫死在代碼里而是通過Jenkins的配置或者環(huán)境變量統(tǒng)一管理。否則不同環(huán)境的Harbor地址變了你還得回頭改代碼不能忍。第三個是docker.withRegistry這個DSL語法。它能自動用給定的憑證harbor-admin登錄Harbor完成鏡像構(gòu)建和推送。這里的credentialsId對應(yīng)的是Jenkins里提前配置好的用戶名密碼憑證。在Jenkins管理后臺的“憑據(jù)”頁面添加一個“Username with password”的憑據(jù)ID填成harbor-admin即可。第四個是部署階段的kubectl set image命令。這是最直觀的一種“滾動更新”做法直接命令K8s把某個Deployment的鏡像tag更新K8s會自動觸發(fā)一次滾動更新逐步替換舊Pod。相比用kubectl apply -f去apply一個新的YAML文件set image更輕量適合快速更新。4.3 參數(shù)化構(gòu)建同一個Job如何同時支持手動選擇模塊和其他觸發(fā)方式實際工作中你會遇到一個很典型的需求同一個應(yīng)用可能分為多個模塊日常提交代碼時只需要構(gòu)建發(fā)生變更的那個模塊而不是每次把整個項目重頭構(gòu)建一遍但有時候測試又希望手動指定構(gòu)建哪個模塊跑完整流程。這個需求在Jenkins里是通過參數(shù)化構(gòu)建實現(xiàn)的。在Pipeline里定義一個Choice參數(shù)讓用戶在點擊“立即構(gòu)建”時選擇模塊pipeline { agent any parameters { choice(name: MODULE, choices: [all, user-service, order-service, gateway], description: 請選擇要構(gòu)建的模塊) string(name: VERSION, defaultValue: v1.0.0, description: 指定鏡像版本號) } stages { stage(Checkout) { steps { // 拉取代碼 } } stage(Build Selected Module) { steps { script { switch (params.MODULE) { case all: sh ./build-all.sh break case user-service: sh ./build-module.sh user-service break default: sh ./build-module.sh ${params.MODULE} } } } } } }結(jié)合定時觸發(fā)如果你希望每天凌晨都跑一遍全量構(gòu)建不需要人工值班盯著就在Pipeline里增加一個triggers { cron(H 2 * * *) }當(dāng)手動參數(shù)化構(gòu)建和定時觸發(fā)同時存在時Jenkins默認工作得很好手動點構(gòu)建就走手動參數(shù)構(gòu)建定時觸發(fā)時參數(shù)使用默認值對于choice默認取第一個選項“all”。我之前也擔(dān)心過這兩者會不會沖突實測下來是不會的——定時觸發(fā)的構(gòu)建和使用默認參數(shù)手動觸發(fā)構(gòu)建本質(zhì)上等價它們會各自生成一次獨立的Build記錄不會互相干擾。這里有一個我實際踩過的坑想提醒你。當(dāng)初為了圖省事把多個模塊的全部代碼放在同一個Git倉庫里Pipeline里執(zhí)行 git checkout 時拉取的是整個倉庫。當(dāng)代碼倉庫膨脹到幾個G的時候每次構(gòu)建光是拉代碼就花好幾分鐘。對這種情況我后來在Pipeline里加入了sparse checkout的優(yōu)化策略只拉取與本次構(gòu)建模塊相關(guān)的目錄構(gòu)建速度提升非常明顯。4.4 Jenkins憑證管理和權(quán)限控制的細節(jié)Jenkins涉及Git憑證、Harbor憑證、K8s的kubeconfig憑證、云平臺AK/SK憑證如果管理不當(dāng)安全性會成為一個很大的隱患。我在這里提供一套簡潔但有效的做法。所有憑證統(tǒng)一走Jenkins的“憑據(jù)”管理頁面。Pipeline里通過credentials()或者withCredentials來引用。例如引用一個SSH私鑰類型的憑證withCredentials([sshPrivateKey(credentialsId: gitlab-ssh-key, keyFileVariable: SSH_KEY)]) { sh GIT_SSH_COMMANDssh -i $SSH_KEY -o StrictHostKeyCheckingno git clone gityour-gitlab:yourproject.git }權(quán)限控制方面重點介紹如何配置只給某個用戶某個Job的權(quán)限而不是把所有Jenkins的全部權(quán)限都放開。Jenkins插件Role-based Strategy能實現(xiàn)精細化的權(quán)限管控。大致做法是安裝Role-based Authorization Strategy插件在“Manage Jenkins” - “Security”里把授權(quán)策略切換成“Role-Based Strategy”在“Manage and Assign Roles”下創(chuàng)建一個Project角色并用正則表達式指定該角色能訪問哪些Job例如/^myapp-.*/表示可以操作所有myapp-前綴的Job把具體用戶分配到這個角色名下這樣我就能放心地讓前端開發(fā)只擁有構(gòu)建自己前端項目的權(quán)限無法觸達后端部署任務(wù)而運維則持有全量管理權(quán)限。還有一點關(guān)于Jenkins可用環(huán)境變量的說明。在Pipeline里像${BUILD_NUMBER}、${JOB_NAME}、${WORKSPACE}這些內(nèi)置環(huán)境變量非常常用。它們的含義分別是構(gòu)建序號、任務(wù)名稱、工作區(qū)路徑。其中BUILD_NUMBER我特別常用因為它天然是單調(diào)遞增的非常適合作為鏡像的tag。每個鏡像都用BUILD_NUMBER來標記后續(xù)排查問題時分分鐘能通過鏡像tag反查出是哪次構(gòu)建產(chǎn)生的格外方便。4.5 Jenkins與GitLab同機部署的兼容性研判有朋友問過我Jenkins和GitLab能不能運行在同一臺主機的Docker里這個問題我仔細驗證過直接給結(jié)論可以前提是宿主機的資源給夠。GitLab本身是一個比較吃內(nèi)存的應(yīng)用官方建議至少4GB內(nèi)存才能流暢運轉(zhuǎn)Jenkins作為持續(xù)集成服務(wù)構(gòu)建任務(wù)多的時候也非常消耗CPU和內(nèi)存。如果兩臺服務(wù)共用一臺8G內(nèi)存的機器我實測下來機器會比較吃力偶爾會出現(xiàn)構(gòu)建卡頓或GitLab響應(yīng)變慢。我的建議是測試環(huán)境8G內(nèi)存起步、16G更穩(wěn)生產(chǎn)環(huán)境單獨部署。如果你只是為了本地體驗或小團隊內(nèi)網(wǎng)用同機Docker部署完全可行分別映射兩個端口GitLab 80/443Jenkins 8080互不沖突。有一點要注意兩個容器不要同時掛在同一個加速器端口上啟動時用docker run -p指定不同的宿主端口就可以了。5. 從Docker Compose平滑升級到K8s容器編排的演進之路很多團隊早期的容器化方案都是從Docker Compose開始。Compose在單機上管理多個容器確實非常方便用一個docker-compose.yml文件就能把一組服務(wù)定義清楚然后一條命令docker-compose up -d啟動全部服務(wù)。但當(dāng)服務(wù)數(shù)量增長、需要跨多臺宿主機部署時Compose就力不從心了。這需要順理成章地演進到K8s。好消息是從Compose到K8s是有平滑過渡路線的。5.1 為什么Compose撐不住而K8s可以Compose的編排模型是“一臺宿主機上的多個容器”它雖然能定義服務(wù)、網(wǎng)絡(luò)、卷但無法解決跨節(jié)點的服務(wù)發(fā)現(xiàn)、自動擴縮容、故障自愈等分布式場景下的核心問題。而K8s天然把這些能力內(nèi)建了。最直觀的差異表現(xiàn)在擴縮容能力上。Compose想擴展某個服務(wù)的副本數(shù)需要手動改配置文件再加上--scale參數(shù)擴展出來的副本也都在這臺機器上無法跨節(jié)點調(diào)度。K8s里只需要kubectl scale deployment myapp --replicas5自動在集群中挑選可用節(jié)點去分布這5個副本遇到有節(jié)點宕機K8s會把上面的Pod自動遷移到健康節(jié)點重新拉起。這就是云原生架構(gòu)的“不可變基礎(chǔ)設(shè)施”思想的落地副本是一種聲明期望狀態(tài)控制器負責(zé)去實現(xiàn)這個期望狀態(tài)。5.2 讓Compose時代的鏡像無縫跑進K8s好消息是如果你已經(jīng)有了標準的Docker鏡像和Compose配置文件遷移到K8s的成本思想負擔(dān)比想象中小很多。因為Compose里的服務(wù)定義和K8s里的Deployment、Service、ConfigMap在邏輯上一一對應(yīng)。比如Compose里的一段服務(wù)定義services: web: image: nginx:1.25 ports: - 8080:80 environment: - ENVprod對應(yīng)的K8s Deployment就是apiVersion: apps/v1 kind: Deployment metadata: name: web spec: replicas: 3 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: web image: nginx:1.25 ports: - containerPort: 80 env: - name: ENV value: prod需要注意的是Compose的ports映射是“宿主機端口:容器端口”K8s通常不推薦這種宿主機端口隔離模式而是建議用Service抽象。因為K8s集群里的Pod IP是隨時變化的你不能指望外部直接通過某個固定IP和端口去訪問它。正確方式是創(chuàng)建一個Service對象由K8s為Service分配一個穩(wěn)定的虛擬IPClusterIP并在集群內(nèi)部做負載均衡和轉(zhuǎn)發(fā)apiVersion: v1 kind: Service metadata: name: web-service spec: selector: app: web ports: - protocol: TCP port: 80 targetPort: 80 type: ClusterIP如果希望從集群外部訪問把type改為NodePortK8s會在每個節(jié)點上選擇一個端口范圍默認30000-32767轉(zhuǎn)發(fā)到Service。生產(chǎn)環(huán)境通常再用Ingress如Nginx Ingress Controller或Traefik統(tǒng)一管理外部訪問入口基于域名做路由轉(zhuǎn)發(fā)避免直接暴露一堆NodePort端口。從實踐來看Compose遷移到K8s最容易出錯的不是YAML寫不寫得出來而是你還沒適應(yīng)“Pod是臨時動物”這個新的世界觀。在Compose時代你習(xí)慣盯著某個固定容器看日志到K8s里Pod隨時可能因為調(diào)度、重啟、故障被銷毀重建你需要盡快習(xí)慣地把注意力放到Deployment、Service、以及各種控制器的期望狀態(tài)上而不是某個具體Pod本身。6. 這套體系跑起來之后那些高頻故障和完整排查思路講完構(gòu)建鏈路最要緊的還是運維階段的真實故障。這里我把這套體系上線這幾個月以來遇到頻率最高的幾個問題以及我的完整排查思路整理出來這部分內(nèi)容價值比較高建議你先收藏等出了類似問題再翻回來對照看看。6.1 K8s Pod卡在ContainerCreating到底卡在哪一步Pod一直處于ContainerCreating狀態(tài)是新手和高頻碰到最多的現(xiàn)象。排查的第一步不是盯著kubectl get pods干等而是用kubectl describe pod查看詳細事件kubectl describe pod pod-name -n namespace事件里通常會出現(xiàn)幾類不同的信息對應(yīng)的原因和處理方式完全不同。一種常見的情況是鏡像拉取失敗事件里會有Failed to pull image或者ImagePullBackOff。這就要檢查鏡像名寫沒寫錯、鏡像是否存在、拉取憑證是否配好。尤其用到私有Harbor時如果鏡像名里帶了Harbor的地址但Secret沒創(chuàng)建或沒在Deployment里引用事件里會出現(xiàn)x509: certificate signed by unknown authority或unauthorized: authentication required這就是憑證問題去查Secret的創(chuàng)建和引用是否正確。另一種常見情況是端口占用或硬盤資源不足事件里明確告訴你端口bind失敗或者Failed to create pod sandbox。這種事件通常會伴隨具體的報錯信息比如no space left on device說明docker數(shù)據(jù)目錄爆了。處理方式建議清理無用的鏡像和容器docker system prune -a --volumes還有一種是PVC一直無法掛載事件里提示FailedMount。這種情況一般是PV沒有綁定成功PVC處于Pending狀態(tài)。用kubectl get pvc查看PVC狀態(tài)如果確實是Pending再用kubectl describe pvc查看底層卷提供商返回的錯誤。排查思路切記一條鐵律先看事件再看日志最后看網(wǎng)絡(luò)。不要一上來就憑感覺重啟所有東西。事件里往往藏著最直接的原因。6.2 Pod反復(fù)重啟的CrashLoopBackOff日志與探針的配合診斷另一個高頻問題就是Pod能創(chuàng)建成功但一直處于CrashLoopBackOff狀態(tài)意思就是容器啟動后立即崩潰被K8s反復(fù)重啟進入退避循環(huán)。排查第一件事肯定是看日志kubectl logs pod-name -n namespace如果Pod在啟動過程中就崩了日志可能很短只看到類似exec /bin/sh: exec format error之類的啟動報錯這說明鏡像的啟動腳本跟你聲明的command參數(shù)不匹配或者說鏡像構(gòu)建時平臺不對比如構(gòu)建了arm64的鏡像試圖跑在amd64節(jié)點上。另一個容易被忽略的原因和健康檢查探針有關(guān)。如果你的Deployment配置了livenessProbe存活探針并且探針的路徑、端口配置錯誤導(dǎo)致K8s認為容器不健康也會主動重啟容器甚至把它當(dāng)成反復(fù)崩潰來重啟。所以看到CrashLoopBackOff不要一心只懷疑應(yīng)用本身要看日志里是否有探針失敗的痕跡。使用kubectl describe pod查看Events列表里有沒有Liveness probe failed或者Readiness probe failed。排查出來之后第一步不是改應(yīng)用而是確認探針的路徑是否正確、端口是否對應(yīng)容器內(nèi)的監(jiān)聽端口、超時時間是否太短導(dǎo)致誤判。6.3 DNS解析時好時壞CoreDNS的配置是重點集群里經(jīng)常有應(yīng)用之間通過Service域名互相訪問比如前端Pod通過http://backend-service訪問后端服務(wù)。如果出現(xiàn)時好時壞的連接失敗很大概率就是CoreDNS出了狀況。CoreDNS是K8s集群內(nèi)的DNS服務(wù)負責(zé)把Service名稱解析成ClusterIP。排查DNS問題的流程是先確認CoreDNS Pod本身是否健康kubectl get pods -n kube-system | grep coredns如果CoreDNS的Pod一直處于Restic狀態(tài)或者大量重啟查看它的日志kubectl logs -n kube-system -l k8s-appkube-dns --tail100常用的定位方法是在故障應(yīng)用所在的Pod里直接測試DNS解析kubectl exec -it pod-name -n namespace -- nslookup backend-service如果提示解析不到檢查Service的名稱和命名空間是否寫對?？缑臻g的訪問要用backend-service.production.svc.cluster.local這樣的FQDN。還有一個小細節(jié)如果節(jié)點上的/etc/resolv.conf配置了特殊的本地DNS參數(shù)可能會影響Pod內(nèi)DNS解析。K8s的Pod默認dnsPolicy是ClusterFirst意思是優(yōu)先使用集群內(nèi)的CoreDNS。如果你在Pod定義里設(shè)置了hostNetwork: trueDNS策略可能會繼承宿主機的配置造成解析不規(guī)則。6.4 鏡像拉取慢的應(yīng)急預(yù)案即使配置了鏡像加速器也難免遇到某些鏡像就是拉不下來或者特別慢的情況。特別是在新節(jié)點加入集群時需要一次性拉取所有基礎(chǔ)鏡像那速度簡直讓人著急。我的補救思路有兩條第一條提前預(yù)拉鏡像。集群里跑的業(yè)務(wù)相對固定可以做一個離線鏡像包把常用的基礎(chǔ)鏡像Nginx、MySQL、Redis、自研應(yīng)用鏡像提前在部署節(jié)點上手動docker pull一遍后續(xù)Pod調(diào)度到這些節(jié)點時就不用臨時拉取。第二條給Containerd或Docker配置鏡像倉庫的代理加速。如果你的私有Harbor是內(nèi)網(wǎng)訪問的可以在K8s節(jié)點上配置HTTP代理讓Docker拉取公共鏡像時走穩(wěn)定通道。這個方法配置項比較瑣碎核心是在Docker的daemon.json里增加代理設(shè)置。這里有一個安全前提代理服務(wù)器的出口必須是合法合規(guī)的不能用任何不合規(guī)方式繞過網(wǎng)絡(luò)管理的要求。6.5 多節(jié)點通信異常時的網(wǎng)絡(luò)排查鏈路K8s集群節(jié)點間通信出現(xiàn)問題應(yīng)用間的訪問會大面積失敗這種問題最讓人壓力大。排查通常從Service層面開始kubectl get svc -A kubectl get endpoints -Aendpoints的列表能告訴你Service后面實際關(guān)聯(lián)的Pod IP。如果endpoints為空說明Service的selector沒匹配到任何Pod檢查Deployment的labels和Service的selector是否對得上。如果endpoints正常應(yīng)用還是訪問不通就要在故障Pod里直接測試ClusterIPkubectl exec -it pod-name -n namespace -- curl http://cluster-ip如果ClusterIP都不通大概率是網(wǎng)絡(luò)插件問題了。Calico的Pod狀態(tài)要先確認kubectl get pods -n kube-system | grep calicoCalico正常運行時有種經(jīng)典問題是節(jié)點之間OpenStack或VPC安全組把BGP端口封了導(dǎo)致Calico網(wǎng)絡(luò)建不起來。這種問題排查起來相當(dāng)隱蔽延綿好幾個小時。我的建議是任何時候做跨節(jié)點通信實驗之前先確保自己的基礎(chǔ)設(shè)施安全組和系統(tǒng)防火墻沒有屏蔽節(jié)點之間的通訊端口比如Calico用的BGP 179端口?；A(chǔ)網(wǎng)絡(luò)不通上層K8s怎么折騰都白搭。7. 結(jié)合業(yè)務(wù)規(guī)模做選型時的常見問題答疑最后這部分我總結(jié)了一些網(wǎng)友和同事問得最多的問題這些問題沒有絕對唯一的答案但我會給出符合大多數(shù)場景的經(jīng)驗判斷希望能幫你少走一些彎路。7.1 云原生AI運維優(yōu)化與自動化交付項目怎么結(jié)合這套體系最近AI和大模型相關(guān)的項目比較多圍繞K8s的AI運維優(yōu)化也常常被問起。如果你做的自動化交付項目需要承載AI訓(xùn)練或推理任務(wù)那么這套體系依然可以沿用但需要在幾個地方做針對性的加強。AI訓(xùn)練任務(wù)通常需要GPU資源。K8s集群需要提前安裝Device Plugin組件如NVIDIA Device Plugin然后在Pod配置里聲明resources.limits: nvidia.com/gpu: 1調(diào)度器才能識別GPU資源并分配。這部分我測試下來穩(wěn)定性尚可但要注意GPU節(jié)點的驅(qū)動和容器運行時兼容性。另一個與AI更相關(guān)的是模型版本的管理。模型的版本和服務(wù)代碼的版本一樣需要被記錄、被回滾?？梢园涯Ｐ臀募瑫r打進鏡像做成帶版本號的純鏡像交付物或者把模型掛在對象存儲中在部署時通過環(huán)境變量指定版本路徑。這兩種方式前者簡化了部署流程后者更靈活且鏡像更小。如果你傾向于頻繁更新模型但代碼很少改動我建議后者。7.2 Docker Desktop和Linux的Docker有什么區(qū)別很多朋友在Windows上學(xué)習(xí)Docker用的是Docker Desktop。這里我覺得有必要明確一個使用邊界。Docker Desktop在Windows上依賴虛擬化技術(shù)如WSL2或Hyper-V運行Linux虛擬機在開發(fā)聯(lián)調(diào)階段完全可以正常使用。包括安裝Nginx、MySQL、Redis這些開發(fā)依賴Docker Desktop完全勝任。但如果是部署到生產(chǎn)環(huán)境的K8s集群那肯定是以Linux服務(wù)器為主。如果你在Docker Desktop上測試K8s可以直接用它內(nèi)置的Kubernetes功能或者配合kindKubernetes in Docker工具做單機測試效果和體驗都很不錯。但和學(xué)習(xí)生產(chǎn)級部署的區(qū)別要心里有數(shù)Docker Desktop屏蔽了很多網(wǎng)絡(luò)、存儲和系統(tǒng)底層的細節(jié)動手部署時還是建議在Linux虛擬機上從零搭建一遍這個過程才能真正掌握K8s的完整原理。7.3 Docker和K8s的區(qū)別一句話說透有不少剛?cè)腴T的朋友分不清Docker和K8s的區(qū)別。我提供一個特別直白的類比Docker相當(dāng)于集裝箱制造廠它把貨物打包成一個個標準集裝箱容器鏡像K8s相當(dāng)于港口調(diào)度系統(tǒng)它負責(zé)把成千上萬只集裝箱正確分配到不同的貨船節(jié)點上并且管理它們的啟航、靠泊和冗余。簡單說Docker容器化是基礎(chǔ)K8s編排是平臺。一個管打包一個管調(diào)度。兩者聯(lián)動才能構(gòu)成完整的云原生基礎(chǔ)設(shè)施底座。7.4 學(xué)習(xí)路線圖和時間投入預(yù)期關(guān)于云原生學(xué)習(xí)路線我經(jīng)常被問到“從零到熟練掌握這套體系需要多久”。我根據(jù)自己帶過的新人團隊的實際節(jié)奏給出一個保守但現(xiàn)實的預(yù)期基礎(chǔ)階段2-4周掌握Docker的鏡像、容器、卷、網(wǎng)絡(luò)、Compose的使用。這個階段去B站等視頻平臺找?guī)讉€完整的實戰(zhàn)教程跟著把LNMP環(huán)境用Docker跑起來基本就入門了。不用貪多但一定要動手。進階階段4-6周掌握K8s常用對象Pod、Deployment、Service、Ingress、ConfigMap、Secret、PVC的用法獨立部署一套單Master集群并成功部署一次LNMP架構(gòu)。這個階段重點理解Pod的調(diào)度邏輯和Service的流量轉(zhuǎn)發(fā)機制。DevOps串聯(lián)階段2-4周安裝Jenkins把Git代碼提交到觸發(fā)構(gòu)建、推送鏡像、更新K8s Deployment整條Pipeline跑通。體會參數(shù)化構(gòu)建、憑證管理、多分支流水線這些功能的實際用途。整體下來兩到三個月的業(yè)余時間投入能完成基本功。但如果你在過程中不斷遇到一些奇怪的網(wǎng)絡(luò)、存儲問題那這些“意外”本身就是最寶貴的經(jīng)驗踩過的每一個坑都會加速你的成長。8. 再聊幾個我來回折騰多次后沉淀下來的經(jīng)驗整套體系跑通到現(xiàn)在有幾個經(jīng)驗是我想特別多強調(diào)幾句的因為它們不是看官方文檔能直接看出來的而是需要在實際操作中反復(fù)碰壁才能體會到。第一件事是關(guān)于鏡像倉庫的規(guī)劃。我見過一些團隊Harbor只要能用就開始用從來沒有做過鏡像清理策略。跑了半年倉庫里堆滿了不同tag的鏡像占用好幾個T的存儲空間。我建議從第一天就啟用Harbor的鏡像清理規(guī)則保留最近幾個版本比如每條tag只保留最近10個過期自動回收。存儲省下來了排查版本問題也更清爽。第二件事是Jenkins的插件管理。我強烈建議不要為了圖方便“建議安裝”所有插件。插件太多版本沖突和啟動緩慢的問題會撲面而來。只安裝實際需要的插件典型的有Blue Ocean、Pipeline、Git、Kubernetes CLI、Role-based Strategy、Docker Pipeline這幾個就夠了。裝得太多升級時維護成本呈指數(shù)增長。第三件事是日志收集的提前規(guī)劃。K8s里的Pod是隨時流動的容器一旦被銷毀重建日志就隨容器一起消失了。想排障的時候發(fā)現(xiàn)日志沒了那種無力感我這輩子不想再經(jīng)歷。所以整套體系里一定要有一個日志接收端最輕量的方案是部署一套LokiPromtail或者ELK全家桶也行。Promtail收集每個節(jié)點上容器日志Loki存儲和查詢這套東西搭好之后感覺就像給系統(tǒng)加裝了行車記錄儀排查問題心里有底。第四件事是關(guān)于開發(fā)環(huán)境和生產(chǎn)環(huán)境的隔離。有不少小團隊圖省事開發(fā)和測試環(huán)境共用一套K8s集群用Namespace區(qū)分。我可以明確告訴你這會在資源隔離層面制造麻煩。有一些Pod在開發(fā)環(huán)境里瘋狂吃資源很容易影響生產(chǎn)應(yīng)用。有條件就讓集群全隔離別在同一套集群里混跑不同環(huán)境。這些經(jīng)驗對我來說都是真金白銀買來的分享出來希望你能少走幾段彎路。整套DockerK8sJenkins的鏈路單看每一環(huán)都不難理解但把它們捏合成一個穩(wěn)定的自動化體系確實需要大量實踐。如果你正在搭建自己的體系遇到具體報錯可以照著文章里的排查鏈路一步不落地走一遍大概率能自己找到答案。