1. 為什么我最終選了 Rancher 2.7 來管生產(chǎn)集群做容器平臺(tái)運(yùn)維這些年我經(jīng)手過的集群管理方案不算少?gòu)淖钤缡执甓M(jìn)制腳本到后來用各類發(fā)行版工具再到近兩年把重心壓到 Rancher 上中間踩的坑能寫滿一個(gè)筆記本。Rancher 2.7 這個(gè)版本對(duì)我而言是個(gè)分水嶺——它把下游集群的 provisioning 邏輯、Fleet 的 GitOps 能力、以及基于 Helm 的應(yīng)用管理整合得相對(duì)成熟了尤其是對(duì)多集群場(chǎng)景下的權(quán)限收斂和審計(jì)追溯比早期版本省了太多手工活。先說清楚這個(gè)內(nèi)容面向誰。如果你手里管著三五個(gè)以上的 K8s 集群或者正準(zhǔn)備把一批業(yè)務(wù)從虛擬機(jī)往容器平臺(tái)遷移又或者你是個(gè)剛接手平臺(tái)運(yùn)維、需要一套能落地、能復(fù)現(xiàn)的部署方案的中級(jí)工程師那這篇東西就是寫給你的。它不講 K8s 基礎(chǔ)概念也不教你什么是 Pod而是聚焦在“怎么用 Rancher 2.7 把一套生產(chǎn)級(jí)集群從零搭起來、并且長(zhǎng)期穩(wěn)住”這件事上。核心關(guān)鍵詞就三個(gè)Rancher 2.7、生產(chǎn)級(jí)部署、集群運(yùn)維。這三個(gè)詞貫穿全文后面所有章節(jié)都圍繞它們展開。我見過太多團(tuán)隊(duì)在測(cè)試環(huán)境用 Rancher 跑得挺歡一上生產(chǎn)就各種問題證書過期、etcd 抖動(dòng)、下游集群失聯(lián)、升級(jí)把業(yè)務(wù)搞掛。根子往往不在 Rancher 本身而在于部署階段的設(shè)計(jì)取舍沒想清楚。所以這篇博文我會(huì)把“為什么這么選”講透而不是甩一堆 YAML 讓你抄。抄配置誰都會(huì)但生產(chǎn)環(huán)境出問題時(shí)能快速定位的前提是你知道每個(gè)參數(shù)背后的意圖。2. 部署前的整體設(shè)計(jì)與關(guān)鍵取舍2.1 架構(gòu)分層管理集群和業(yè)務(wù)集群必須分開這是我最想強(qiáng)調(diào)的一條。Rancher 的架構(gòu)里跑 Rancher Server 的那個(gè)集群叫管理集群management cluster被它納管的叫下游集群downstream cluster。很多小團(tuán)隊(duì)圖省事把 Rancher 直接裝在業(yè)務(wù)集群里結(jié)果就是管理面和業(yè)務(wù)面互相拖累——業(yè)務(wù)高峰把管理 API 打滿或者管理組件升級(jí)時(shí)業(yè)務(wù)跟著抖。我的做法是物理隔離管理集群?jiǎn)为?dú)一套只跑 Rancher Server、Fleet 控制器、監(jiān)控棧這些平臺(tái)組件業(yè)務(wù)集群按環(huán)境或業(yè)務(wù)域劃分通過 Rancher 納管。管理集群規(guī)模不用大三個(gè)節(jié)點(diǎn)起步但一定要獨(dú)立。這樣即使某個(gè)業(yè)務(wù)集群出問題管理面還能正常操作不至于“指揮中心跟著前線一起塌”。管理集群的節(jié)點(diǎn)規(guī)格我一般給到 4C8G 起步etcd 單獨(dú)放 SSD。為什么是 4C8GRancher Server 本身不重但 Fleet 在同步大量 GitRepo 時(shí)會(huì)有明顯的 CPU 和內(nèi)存波動(dòng)加上內(nèi)置的監(jiān)控和審計(jì)日志2C4G 在集群數(shù)量超過五個(gè)后就會(huì)吃緊。這個(gè)數(shù)字不是拍腦袋是我在幾個(gè)中等規(guī)模環(huán)境里實(shí)測(cè)出來的經(jīng)驗(yàn)值。2.2 高可用方案內(nèi)置 etcd 還是外部數(shù)據(jù)庫(kù)Rancher 2.7 支持兩種高可用模式一種是 Rancher Server 跑在 K8s 上、用內(nèi)置 etcd 存狀態(tài)另一種是外部數(shù)據(jù)庫(kù)MySQL/PostgreSQL模式。我強(qiáng)烈建議生產(chǎn)環(huán)境用內(nèi)置 etcd 的 RKE2 集群來承載 Rancher Server。理由很直接外部數(shù)據(jù)庫(kù)模式雖然理論上更“傳統(tǒng)”但它把數(shù)據(jù)庫(kù)的高可用、備份、故障切換全甩給你自己管而 Rancher 的狀態(tài)數(shù)據(jù)對(duì)一致性要求很高數(shù)據(jù)庫(kù)層面出一點(diǎn)問題Rancher 的 UI 和 API 就可能出現(xiàn)詭異的不一致。內(nèi)置 etcd 模式由 RKE2 統(tǒng)一管理 etcd 的生命周期快照、恢復(fù)、成員變更都有成熟工具鏈運(yùn)維負(fù)擔(dān)反而更小。這里有個(gè)細(xì)節(jié)RKE2 的 etcd 快照默認(rèn)是開啟的但默認(rèn)保留策略不一定夠用。我通常會(huì)把快照間隔調(diào)到 6 小時(shí)、保留數(shù)量調(diào)到 30 份以上并且把快照目錄掛到獨(dú)立磁盤。原因是一旦需要恢復(fù)你希望手里有足夠多的歷史點(diǎn)可選而不是只有最近一兩份。2.3 證書與域名別等過期了才想起來Rancher 的證書問題是我見過最高頻的生產(chǎn)事故來源。2.7 版本默認(rèn)用 cert-manager 管理證書但如果你用自簽證書或者內(nèi)部 CA續(xù)期邏輯需要提前驗(yàn)證。我的習(xí)慣是部署完第一件事就是確認(rèn)證書的簽發(fā)者和過期時(shí)間并且把續(xù)期監(jiān)控接進(jìn)告警。域名規(guī)劃上管理集群的訪問入口我一般用獨(dú)立子域比如平臺(tái)內(nèi)部約定的一個(gè)固定域名通過內(nèi)部負(fù)載均衡器暴露。這里不展開具體域名重點(diǎn)是證書的 SAN 必須覆蓋你實(shí)際訪問用的域名否則瀏覽器和 API 客戶端都會(huì)報(bào)錯(cuò)。我見過有人部署完發(fā)現(xiàn)證書只簽了默認(rèn)的 localhost結(jié)果外部訪問全部失敗返工重簽。2.4 網(wǎng)絡(luò)與存儲(chǔ)的前置規(guī)劃生產(chǎn)級(jí)部署里網(wǎng)絡(luò)和存儲(chǔ)是最容易被低估的兩塊。網(wǎng)絡(luò)層面Rancher 管理集群和下游集群之間的通信走的是 Rancher 的 tunnel需要保證管理集群的 443 端口對(duì)下游集群可達(dá)。如果你的環(huán)境有網(wǎng)絡(luò)分區(qū)提前把這條鏈路打通別等納管時(shí)才發(fā)現(xiàn)連不上。存儲(chǔ)層面管理集群需要一塊可靠的存儲(chǔ)給 etcd 和 Rancher 的持久化數(shù)據(jù)。我傾向用本地 SSD 做 etcd 盤Rancher 的 PV 則用支持 ReadWriteOnce 的塊存儲(chǔ)。下游集群的存儲(chǔ)按業(yè)務(wù)需求來但要注意 Rancher 納管后Fleet 和監(jiān)控組件也會(huì)在下游集群創(chuàng)建 PV提前留好 StorageClass。3. 管理集群的實(shí)操部署過程3.1 節(jié)點(diǎn)準(zhǔn)備與系統(tǒng)調(diào)優(yōu)三臺(tái)管理節(jié)點(diǎn)操作系統(tǒng)我一般選主流的 Linux 發(fā)行版內(nèi)核版本不要太老。部署前每臺(tái)機(jī)器要做的基礎(chǔ)調(diào)優(yōu)包括關(guān)閉 swap、加載必要的內(nèi)核模塊、調(diào)整網(wǎng)絡(luò)參數(shù)。這些在 RKE2 的官方文檔里有清單但我想強(qiáng)調(diào)兩個(gè)容易漏的點(diǎn)。第一是時(shí)間同步。etcd 對(duì)時(shí)鐘漂移非常敏感節(jié)點(diǎn)間時(shí)間差超過一定閾值就會(huì)導(dǎo)致選舉異常。我要求所有節(jié)點(diǎn)接同一個(gè)內(nèi)網(wǎng)時(shí)間源并且部署后驗(yàn)證chronyc tracking或等價(jià)命令的輸出確認(rèn)偏移在毫秒級(jí)。第二是文件句柄數(shù)和進(jìn)程數(shù)限制。容器密集運(yùn)行時(shí)默認(rèn)的 limits 很容易被打滿表現(xiàn)為各種“too many open files”。我會(huì)在系統(tǒng)層面把 nofile 調(diào)到 65535 以上并且確認(rèn) systemd 的 LimitNOFILE 也同步調(diào)整因?yàn)?RKE2 是以 systemd 服務(wù)方式運(yùn)行的光改 limits.conf 不夠。# 系統(tǒng)調(diào)優(yōu)示例每臺(tái)管理節(jié)點(diǎn)執(zhí)行 swapoff -a sed -i /swap/s/^/#/ /etc/fstab cat /etc/sysctl.d/99-k8s.conf EOF net.bridge.bridge-nf-call-iptables 1 net.ipv4.ip_forward 1 fs.inotify.max_user_instances 8192 fs.inotify.max_user_watches 524288 EOF sysctl --system cat /etc/security/limits.conf EOF * soft nofile 65535 * hard nofile 65535 EOF3.2 RKE2 集群初始化與 Rancher 安裝管理集群我用 RKE2 來搭第一個(gè)節(jié)點(diǎn)作為 server 初始化后續(xù)節(jié)點(diǎn)以 server 角色加入形成高可用。初始化時(shí)通過配置文件指定關(guān)鍵參數(shù)而不是全靠命令行參數(shù)這樣便于版本管理和復(fù)現(xiàn)。# /etc/rancher/rke2/config.yaml首個(gè) server 節(jié)點(diǎn) token: 預(yù)共享的集群令牌 tls-san: - 管理集群訪問域名 - 負(fù)載均衡器地址 etcd-snapshot-schedule-cron: 0 */6 * * * etcd-snapshot-retention: 30 etcd-snapshot-dir: /data/etcd-snapshots write-kubeconfig-mode: 0644這里tls-san是關(guān)鍵必須把你實(shí)際訪問 Rancher 用的域名和 LB 地址都列進(jìn)去否則 API Server 證書校驗(yàn)會(huì)失敗。etcd-snapshot-dir指向獨(dú)立數(shù)據(jù)盤避免和系統(tǒng)盤搶 IO。集群起來后用 Helm 安裝 Rancher。我習(xí)慣把 Rancher 的 Helm chart 版本固定住不用 latest生產(chǎn)環(huán)境最忌諱版本漂移。安裝時(shí)通過 values 指定副本數(shù)、資源限制和 ingress 配置。helm repo add rancher-stable 內(nèi)部約定的 chart 倉(cāng)庫(kù)地址 helm repo update helm install rancher rancher-stable/rancher \ --namespace cattle-system \ --create-namespace \ --version 固定版本號(hào) \ --set hostname管理集群訪問域名 \ --set replicas3 \ --set ingress.tls.sourcesecret \ --set resources.requests.cpu500m \ --set resources.requests.memory1Gireplicas3配合三節(jié)點(diǎn)集群保證 Rancher Server 本身的高可用。資源 requests 給到 500m/1Gi 是保守值實(shí)際運(yùn)行中 Fleet 同步高峰期會(huì)用到更多但 requests 設(shè)太高會(huì)導(dǎo)致調(diào)度困難我一般讓 limits 留足余量。3.3 部署后的第一輪驗(yàn)證清單裝完不等于完事我有一套固定的驗(yàn)證清單逐項(xiàng)過一遍才算部署成功。這套清單幫我提前發(fā)現(xiàn)過好幾次隱患。驗(yàn)證項(xiàng)檢查方法合格標(biāo)準(zhǔn)證書有效期查看 ingress 證書剩余有效期大于 60 天etcd 健康集群內(nèi)執(zhí)行 etcd 健康檢查所有成員 healthyRancher Pod 狀態(tài)查看 cattle-system 命名空間3 個(gè)副本全部 RunningAPI 可達(dá)性從外部 curl 管理域名返回正常響應(yīng)快照生成檢查快照目錄有近期快照文件節(jié)點(diǎn)時(shí)間偏移各節(jié)點(diǎn)對(duì)比時(shí)間源偏移小于 100ms這張表看著簡(jiǎn)單但每一項(xiàng)背后都對(duì)應(yīng)過真實(shí)故障。比如快照生成這一項(xiàng)我遇到過快照目錄權(quán)限不對(duì)導(dǎo)致快照靜默失敗的情況表面看一切正常真到要恢復(fù)時(shí)才發(fā)現(xiàn)沒有可用快照。所以驗(yàn)證不能只看“有沒有報(bào)錯(cuò)”要看“結(jié)果對(duì)不對(duì)”。4. 下游集群納管與日常運(yùn)維要點(diǎn)4.1 下游集群的注冊(cè)方式選擇Rancher 納管下游集群有幾種方式通過 UI 生成注冊(cè)命令、通過 Terraform 等 IaC 工具自動(dòng)化、或者用 Rancher 的 provisioning 直接創(chuàng)建。生產(chǎn)環(huán)境我傾向用 IaC 工具生成注冊(cè)命令并納入版本管理而不是手工點(diǎn) UI。原因在于可復(fù)現(xiàn)性。手工生成的注冊(cè)命令里帶一次性 token過期就失效而且散落在各人手里容易混亂。用 IaC 管理后集群的注冊(cè)信息、節(jié)點(diǎn)角色、標(biāo)簽都能代碼化重建環(huán)境時(shí)一條命令搞定。對(duì)于已經(jīng)存在的集群比如用其他工具搭好的用注冊(cè)命令納管即可對(duì)于全新集群可以讓 Rancher 直接 provisioning但要注意 provisioning 出來的集群其控制面由 Rancher 管理后續(xù)升級(jí)路徑要跟著 Rancher 的節(jié)奏走。4.2 集群標(biāo)簽與項(xiàng)目隔離的規(guī)劃納管進(jìn)來只是第一步真正影響長(zhǎng)期運(yùn)維效率的是標(biāo)簽體系和項(xiàng)目劃分。Rancher 里的“項(xiàng)目Project”是命名空間的邏輯分組配合 RBAC 能實(shí)現(xiàn)很細(xì)的權(quán)限控制。我的經(jīng)驗(yàn)是項(xiàng)目按“環(huán)境業(yè)務(wù)域”二維劃分比如“生產(chǎn)-訂單”“測(cè)試-支付”而不是簡(jiǎn)單按環(huán)境一刀切。標(biāo)簽則用來做自動(dòng)化篩選。比如給集群打上envprod、regioninternal、tiercritical這類標(biāo)簽后續(xù) Fleet 的 GitRepo 可以按標(biāo)簽選擇目標(biāo)集群監(jiān)控告警也能按標(biāo)簽聚合。標(biāo)簽設(shè)計(jì)要在納管初期就定好后期再補(bǔ)會(huì)非常痛苦因?yàn)橐呀?jīng)部署的工作負(fù)載和策略都綁定了舊的標(biāo)簽邏輯。4.3 用 Fleet 做 GitOps 的落地姿勢(shì)Fleet 是 Rancher 2.7 里我評(píng)價(jià)最高的組件之一。它的核心價(jià)值是你把 K8s 清單放在 Git 倉(cāng)庫(kù)里Fleet 負(fù)責(zé)把清單同步到匹配的下游集群并且持續(xù)糾偏。這意味著集群的實(shí)際狀態(tài)永遠(yuǎn)向 Git 里的期望狀態(tài)收斂。落地時(shí)我建議從“小范圍試點(diǎn)”開始別一上來就把所有業(yè)務(wù)都塞進(jìn) Fleet。先拿一兩個(gè)非核心集群把基礎(chǔ)組件比如監(jiān)控 agent、日志采集用 Fleet 管起來跑順了再逐步擴(kuò)大。Fleet 的 GitRepo 資源里可以配置targets按集群標(biāo)簽選擇目標(biāo)配合paths指定清單目錄結(jié)構(gòu)清晰。apiVersion: fleet.cattle.io/v1alpha1 kind: GitRepo metadata: name: platform-base namespace: fleet-default spec: repo: 內(nèi)部 Git 倉(cāng)庫(kù)地址 branch: main paths: - /clusters/base targets: - clusterSelector: matchLabels: env: prod這里有個(gè)實(shí)操心得Fleet 同步失敗時(shí)的報(bào)錯(cuò)信息有時(shí)候比較隱晦排查時(shí)先看 GitRepo 的 status 字段再看對(duì)應(yīng) Bundle 的狀態(tài)最后到目標(biāo)集群里看實(shí)際部署的資源。三層逐級(jí)往下查比盲目翻日志快得多。4.4 監(jiān)控、日志與告警的接入生產(chǎn)集群沒有監(jiān)控等于裸奔。Rancher 2.7 內(nèi)置了基于 Prometheus 的監(jiān)控能力可以在 UI 里一鍵啟用但我更推薦用 Fleet 把監(jiān)控棧的配置也代碼化這樣多集群的監(jiān)控配置能保持一致。監(jiān)控接入的重點(diǎn)是告警規(guī)則的收斂。默認(rèn)規(guī)則集往往太吵生產(chǎn)環(huán)境需要按業(yè)務(wù)重要性分級(jí)。我的做法是基礎(chǔ)設(shè)施層節(jié)點(diǎn)、etcd、控制面的告警直接推到值班渠道業(yè)務(wù)層告警先聚合到看板按閾值觸發(fā)。日志方面采集 agent 用 DaemonSet 部署輸出到統(tǒng)一的日志后端保留周期按合規(guī)要求設(shè)定。5. 升級(jí)、備份與故障排查實(shí)錄5.1 版本升級(jí)的節(jié)奏與回滾預(yù)案Rancher 的版本升級(jí)我遵循一個(gè)原則管理集群先升下游集群后升且兩者之間留觀察窗口。管理集群升級(jí)前務(wù)必確認(rèn)當(dāng)前版本的已知問題清單以及目標(biāo)版本的變更說明。升級(jí)管理集群用 Helm 的--version指定目標(biāo)版本升級(jí)后觀察至少 24 小時(shí)確認(rèn) UI、API、Fleet 同步都正常再動(dòng)下游集群。下游集群的升級(jí)通過 Rancher UI 或 API 觸發(fā)RKE2 集群的升級(jí)是滾動(dòng)式的控制面節(jié)點(diǎn)逐個(gè)更新。這里的關(guān)鍵是提前確認(rèn)業(yè)務(wù)的工作負(fù)載分布確保升級(jí)期間有足夠的副本在其他節(jié)點(diǎn)上扛住流量?；貪L預(yù)案必須提前寫好etcd 快照的恢復(fù)步驟、Rancher 版本的降級(jí)路徑都要在升級(jí)前演練一遍。我見過升級(jí)出問題后現(xiàn)場(chǎng)翻文檔的那場(chǎng)面相當(dāng)被動(dòng)。5.2 備份策略快照只是其中一環(huán)很多人以為 etcd 快照就是全部備份這是個(gè)誤區(qū)。生產(chǎn)級(jí)備份至少包含三層etcd 快照集群狀態(tài)、Rancher 的持久化數(shù)據(jù)PV 層面、以及 Git 倉(cāng)庫(kù)里的清單配置層面。前兩者保證能恢復(fù)到某個(gè)時(shí)間點(diǎn)后者保證配置本身不丟。etcd 快照的恢復(fù)我實(shí)測(cè)過幾次流程是停掉 Rancher 相關(guān)組件、用快照恢復(fù) etcd、重啟集群、驗(yàn)證 Rancher 狀態(tài)?；謴?fù)后要重點(diǎn)檢查下游集群的納管狀態(tài)有時(shí)候需要重新觸發(fā)一次集群同步。這個(gè)流程建議每季度演練一次別等真出事才第一次操作。5.3 常見故障速查表下面這張表是我這些年遇到的高頻問題匯總按現(xiàn)象、可能原因、排查方向組織方便快速定位?，F(xiàn)象可能原因排查方向下游集群顯示 Unavailabletunnel 鏈路中斷檢查管理集群 443 可達(dá)性、下游 agent Pod 狀態(tài)Rancher UI 登錄后空白證書或 ingress 配置異常查 ingress 日志、證書 SANFleet 同步一直 PendingGit 倉(cāng)庫(kù)憑證失效檢查 GitRepo 的 secret 引用etcd 頻繁 leader 切換磁盤 IO 或時(shí)鐘漂移查 etcd 日志、節(jié)點(diǎn)時(shí)間同步升級(jí)后 API 報(bào) 503副本未就緒或資源不足查 Rancher Pod 事件、節(jié)點(diǎn)資源監(jiān)控?cái)?shù)據(jù)缺失Prometheus 存儲(chǔ)滿或抓取失敗查 PVC 使用率、target 狀態(tài)排查這類問題的通用思路是從外到內(nèi)、從管理面到數(shù)據(jù)面先確認(rèn)管理集群自身健康再看下游集群的 agent 通信最后看具體業(yè)務(wù)負(fù)載。別一上來就鉆到業(yè)務(wù) Pod 里查很多時(shí)候根子在管理面。5.4 幾個(gè)踩過的坑和獨(dú)家心得說幾個(gè)文檔里不太會(huì)寫、但實(shí)際很要命的點(diǎn)。第一個(gè)是Rancher 的 token 管理。UI 里生成的 API token 有有效期如果用在自動(dòng)化腳本里到期后腳本會(huì)靜默失敗。我的做法是給自動(dòng)化場(chǎng)景單獨(dú)建服務(wù)賬號(hào)token 有效期設(shè)長(zhǎng)一些并且把 token 過期時(shí)間納入監(jiān)控。第二個(gè)是下游集群的清理。從 Rancher 里刪除一個(gè)下游集群時(shí)如果只是 UI 上點(diǎn)刪除下游集群里的 cattle-system 相關(guān)資源可能殘留重新納管時(shí)會(huì)沖突。正確做法是先在下游集群執(zhí)行清理腳本再?gòu)?Rancher 移除。這個(gè)順序反了返工成本很高。第三個(gè)是資源配額的前置設(shè)置。Rancher 的項(xiàng)目可以設(shè)資源配額但配額是軟限制超了不會(huì)立刻阻止而是體現(xiàn)在調(diào)度失敗上。所以配額值要結(jié)合業(yè)務(wù)實(shí)際用量留足 buffer并且定期 review別設(shè)完就不管。6. 寫在最后的一點(diǎn)個(gè)人體會(huì)這套方案我在幾個(gè)中等規(guī)模的生產(chǎn)環(huán)境里跑了一年多整體穩(wěn)定性是達(dá)標(biāo)的但也談不上完美。Rancher 2.7 的組件比較多學(xué)習(xí)曲線不算平緩尤其是 Fleet 和 provisioning 的交互邏輯第一次接觸容易繞暈。我的建議是先在測(cè)試環(huán)境把整條鏈路走通包括納管、GitOps 同步、升級(jí)、快照恢復(fù)每個(gè)環(huán)節(jié)都親手操作一遍再上生產(chǎn)。另外工具再?gòu)?qiáng)也替代不了對(duì)底層原理的理解。Rancher 幫你屏蔽了很多 K8s 的復(fù)雜度但出問題時(shí)能不能快速定位還是取決于你對(duì) etcd、網(wǎng)絡(luò)、證書這些基礎(chǔ)組件的熟悉程度。我個(gè)人的習(xí)慣是每次遇到新問題解決后都記一筆時(shí)間長(zhǎng)了就是自己的故障庫(kù)比任何官方文檔都貼合自己的環(huán)境。這套東西后續(xù)還可以往多租戶隔離和跨集群災(zāi)備方向繼續(xù)深挖等有新的實(shí)踐再整理出來。