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