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