前陣子幫某集團(tuán)客戶做容器化改造一個環(huán)境里同時上了 Zookeeper、Redis Cluster、MySQL 主從、Nginx 加 Tomcat 的 Java 應(yīng)用、LNMP 一套、Dubbo 微服務(wù)還有 Ingress 統(tǒng)一網(wǎng)關(guān)整套搬進(jìn) Kubernetes 之后踩了不少坑也沉淀了不少經(jīng)驗。這套組合基本上覆蓋了日常工作中絕大部分的 K8S 落地場景今天把整個實戰(zhàn)過程梳理一遍從有狀態(tài)應(yīng)用部署到無狀態(tài)應(yīng)用編排再到流量入口管理一次講透。1. 先把應(yīng)用按有狀態(tài)和無狀態(tài)攤開部署順序和策略的底層邏輯很多人拿到一堆應(yīng)用就往 K8S 里塞結(jié)果發(fā)現(xiàn) MySQL 數(shù)據(jù)丟了、Zookeeper 集群起不來、Dubbo 服務(wù)注冊一堆亂碼最后回頭罵 K8S 不好用。其實問題不在于 K8S而在于沒有先做應(yīng)用分類。1.1 為什么這套方案里 Zookeeper 和 MySQL 必須單獨對待無狀態(tài)應(yīng)用比如 Nginx、Tomcat、純 Java 后端特點是隨便殺、隨便擴(kuò)實例之間不需要互相認(rèn)識數(shù)據(jù)不落在本地。這類應(yīng)用用 Deployment 加 HPA 就能搞定。但有狀態(tài)應(yīng)用完全反過來——Zookeeper 需要維護(hù)節(jié)點之間的選舉關(guān)系MySQL 需要保證數(shù)據(jù)不丟Redis Cluster 需要 Gossip 通信和槽位管理它們都要求穩(wěn)定的身份和穩(wěn)定的存儲。所以我拿到這套需求后的第一件事就是把應(yīng)用分成兩個池子。第一個池子是無狀態(tài)的Nginx、Tomcat、Java 應(yīng)用、LNMP 里的 PHP 和 Nginx。第二個池子是有狀態(tài)的Zookeeper、Redis、MySQL以及 Dubbo 微服務(wù)里的注冊中心一般也掛在 Zookeeper 上。池子分清楚了后續(xù)的 StatefulSet、Headless Service、PVC 這些概念才派得上用場。1.2 實戰(zhàn)里推薦的整體部署順序先底座后業(yè)務(wù)再入口我的部署順序是固定的這套路徑跑通了無數(shù)次。先部署 Zookeeper 和 MySQL 這類底座型中間件因為它們會被上層應(yīng)用依賴再部署 Redis 緩存層接著部署無狀態(tài)的 Nginx 加 Tomcat 和 Java 業(yè)務(wù)應(yīng)用然后處理 LNMP 組合和 Dubbo 微服務(wù)最后統(tǒng)一配置 Ingress 把流量收口。這個順序不是隨便定的。如果先部署應(yīng)用后部署 Zookeeper應(yīng)用啟動時找不到注冊中心Dubbo 接口暴露失敗又要重啟應(yīng)用純屬浪費排障時間。K8S 雖然有 InitContainer 可以做依賴等待但能用正確的部署順序解決的問題沒必要引入額外的復(fù)雜度。2. Zookeeper 集群上 K8SHeadless Service 與選舉機(jī)制的那些坑Zookeeper 是這套環(huán)境里第一個要落地的有狀態(tài)應(yīng)用。它要解決的核心問題是集群內(nèi)每個節(jié)點必須知道彼此的存在并且節(jié)點的網(wǎng)絡(luò)身份不能隨著 Pod 重啟而變化。2.1 為什么普通 Service 滿足不了 Zookeeper 的集群發(fā)現(xiàn)先看一個反例。我見過有人用普通 Service 給 Zookeeper 做負(fù)載均衡結(jié)果集群永遠(yuǎn)選舉不出 Leader。原因在于 Zookeeper 的節(jié)點之間需要直接通過 IP 或主機(jī)名通信而普通 Service 會把請求隨機(jī)分發(fā)到任意一個后端 Pod 上客戶端拿到的地址是虛擬的 ClusterIP節(jié)點之間無法建立真實的 TCP 連接選舉直接失敗。正確的做法是給 StatefulSet 配一個 Headless Service也就是 ClusterIP 為 None 的 Service。這種 Service 不做負(fù)載均衡DNS 解析直接返回所有 Pod 的真實 IP。配合 StatefulSet 的命名規(guī)則每個 Pod 會得到一個穩(wěn)定的網(wǎng)絡(luò)標(biāo)識比如zk-0.zk-headless.namespace.svc.cluster.local。這樣 Zookeeper 配置文件里的server.1zk-0.zk-headless...這類條目就能真正生效。2.2 配置 Zookeeper 集群時最容易漏掉的三個參數(shù)第一個是POD_IP環(huán)境變量。Zookeeper 的啟動腳本需要知道自己當(dāng)前 Pod 的 IP然后寫入配置文件的quorumListenOnAllIPs。我用的是 downward API 把status.podIP注入到環(huán)境變量里啟動時再通過腳本拼進(jìn)配置文件。第二個是ZOO_MY_ID這個值直接對應(yīng) StatefulSet 的序號必須是穩(wěn)定的不能隨機(jī)生成。第三個很多人忽略——JVMFLAGS里的堆內(nèi)存設(shè)置。Zookeeper 默認(rèn)堆內(nèi)存只有 256M在容器里跑線上集群明顯不夠。我一般設(shè)置為 1G 到 2G通過環(huán)境變量傳進(jìn)去。順便提一嘴Zookeeper 是 CPU 密集型應(yīng)用不建議給它設(shè)置 CPU Limit 限制得太死否則 GC 線程調(diào)度不過來選舉超時的情況會頻繁出現(xiàn)。2.3 實測中遇到的 Zookeeper 集群腦裂問題與解決思路我有一次在做滾動升級時把三個 Zookeeper 節(jié)點同時重啟結(jié)果集群出現(xiàn)了短暫的腦裂現(xiàn)象。兩個節(jié)點各自主導(dǎo)了一個偽集群客戶端連接全部報錯。排查下來發(fā)現(xiàn)是 StatefulSet 的podManagementPolicy默認(rèn)值是OrderedReady理論上會逐個更新節(jié)點但我在配置清單里漏掉了這個字段。如果對可用性要求極高可以設(shè)置podManagementPolicy: Parallel配合 ReadinessProbe。但一般情況下建議保持默認(rèn)的 OrderedReady 策略讓 K8S 按照節(jié)點順序逐個更新避免所有節(jié)點同時處于不可用狀態(tài)。另外務(wù)必給每個 Zookeeper Pod 配置 PreStop 鉤子在 Pod 終止前主動執(zhí)行zkServer.sh stop讓節(jié)點優(yōu)雅退出否則會出現(xiàn)集群重選舉業(yè)務(wù)側(cè)感知到抖動。3. MySQL 主從與 Redis Cluster持久化存儲和故障恢復(fù)的實戰(zhàn)要訣中間件里 MySQL 和 Redis 是最考驗持久化設(shè)計的兩兄弟。MySQL 不能丟數(shù)據(jù)Redis 要保證分片和副本的高可用。這兩類應(yīng)用在 K8S 里的部署方式和踩坑路徑完全不同。3.1 MySQL 主從復(fù)制在 K8S 里的存儲方案選型先說存儲。MySQL 的數(shù)據(jù)文件必須存放在 PV 里我這次用的是 NFS 動態(tài)供給配合 StorageClass 實現(xiàn) PVC 自動創(chuàng)建。如果條件允許生產(chǎn)環(huán)境更推薦用云廠商的塊存儲性能比 NFS 好很多。但 NFS 有個致命問題需要提前規(guī)避——它不支持文件鎖如果 MySQL 配置了skip-name-resolve之外還用了某些依賴鎖的特性可能存在隱患。穩(wěn)妥的做法是把 MySQL 數(shù)據(jù)目錄掛載到 PVbinlog 也放在同一份存儲里。StorageClass 的配置清單我會限制reclaimPolicy: Retain防止 PVC 刪除時 PV 連帶銷毀。這個細(xì)節(jié)非常關(guān)鍵——一旦設(shè)置成 Delete節(jié)點宕機(jī)后重建 Pod 時舊數(shù)據(jù)可能直接被回收我見過有人因此在測試環(huán)境里把數(shù)據(jù)庫搞丟過。3.2 主從復(fù)制初始化的一次完整排障鏈路用 Helm 或手工編排 MySQL 主從時最常見的問題是從庫一直停在Waiting for master to send event狀態(tài)。我當(dāng)時部署完成后發(fā)現(xiàn)從庫的Seconds_Behind_Master一直是 NULL主庫狀態(tài)正常但 binlog 沒有傳過來。排查鏈路是這樣的先看從庫的SHOW SLAVE STATUS發(fā)現(xiàn)Last_IO_Errno是 1236說明從庫請求的 binlog 位置在主庫已經(jīng)被清理掉了。原因是主庫的expire_logs_days設(shè)置太短而從庫因為網(wǎng)絡(luò)延遲或初始化時間過長追不上主庫的 binlog 清理進(jìn)度。解決辦法是先停止從庫的復(fù)制線程在主庫上用mysqldump重新導(dǎo)一份全量備份記錄好MASTER_LOG_FILE和MASTER_LOG_POS再從那個位置繼續(xù)復(fù)制。整套操作下來從庫才真正追平。這次經(jīng)驗告訴我MySQL 主從初始化不能無腦相信CHANGE MASTER TO配一次就行必須確認(rèn)全量備份和 binlog 點位是對齊的。如果依賴的是mysqldump --master-data2需要嚴(yán)查導(dǎo)出的二進(jìn)制日志位置坐標(biāo)。3.3 Redis Cluster 的 Gossip 通信與 Kubernetes 網(wǎng)絡(luò)模型適配Redis Cluster 在 K8S 里部署比單機(jī) Redis 復(fù)雜得多。每個 Redis 節(jié)點都要監(jiān)聽兩個端口一個是客戶端通信端口 6379另一個是集群總線端口 16379用于節(jié)點間 Gossip 通信。K8S 網(wǎng)絡(luò)模型默認(rèn)情況下 Pod 之間的通信是通的但要小心 NetworkPolicy 把 16379 端口擋住否則集群節(jié)點之間無法交換心跳槽位遷移和故障轉(zhuǎn)移全部失效。我這次的配置是給 Redis Cluster 單獨建了一個命名空間然后放行該命名空間內(nèi)所有 Pod 之間的 6379 和 16379 端口。不要在默認(rèn)命名空間里和業(yè)務(wù)應(yīng)用混部否則網(wǎng)絡(luò)策略寫起來又長又容易出錯。存儲方面用的是 local 卷或者云盤保證每個節(jié)點都有獨立的持久化路徑。3.4 Redis 故障轉(zhuǎn)移時的一個高頻坑DNS 緩存導(dǎo)致的路由錯亂Redis Cluster 客戶端在連接節(jié)點時會通過 Cluster 節(jié)點返回的 MOVED 重定向指令找到正確的分片。但在 K8S 環(huán)境里如果客戶端使用了 Pod 的 IP 直連那么節(jié)點重啟或者擴(kuò)縮容后客戶端緩存里的節(jié)點信息就是過期的導(dǎo)致大量CLUSTERDOWN報錯。更穩(wěn)的方案是給 Redis Cluster 的每個節(jié)點用 StatefulSet 加 Headless Service客戶端通過 DNS 域名來連接。這樣節(jié)點重啟后 IP 變了域名不變客戶端可以正常重連。我在實際項目中就是讓 Java 應(yīng)用配置的 Redis 地址從 IP 改成域名然后用 Redisson 或 Lettuce 的集群模式問題一下子少了很多。4. Nginx 負(fù)載 Tomcat 集群與 Java 應(yīng)用部署鏡像分層、探針與優(yōu)雅上下線接下來是純無狀態(tài)應(yīng)用的部署。Java 應(yīng)用加 Nginx 入口是這套方案里最常見的組合。Nginx 負(fù)責(zé)流量分發(fā)和靜態(tài)資源處理Tomcat 跑 Java Web 服務(wù)。4.1 Nginx 鏡像里的 Tomcat 后端地址如何動態(tài)注入Nginx 的 upstream 配置在容器化環(huán)境里不能寫死 IP。我采用的是環(huán)境變量加模板渲染的方式。鏡像里的nginx.conf是模板文件啟動腳本用envsubst把${TOMCAT_UPSTREAM}替換為真實的 Service 地址。比如 Tomcat 的 Service 叫tomcat-app命名空間是prod那 upstream 就是tomcat-app.prod.svc.cluster.local:8080。這種方式既避免了配置的硬編碼也方便后續(xù)通過修改環(huán)境變量來切換上下游。需要特別留意的是envsubst默認(rèn)會替換所有${...}格式的內(nèi)容如果 nginx.conf 里有正則表達(dá)式包含$字符會被這工具誤傷。我遇到過$host被替換成空字符串的問題最后把模板文件里的非法變量統(tǒng)一轉(zhuǎn)義或者改用 Python 腳本做更精確的替換。4.2 Java 應(yīng)用容器化時的堆內(nèi)存配置和分層鏡像優(yōu)化Java 應(yīng)用在容器里的第一道坎是 JVM 參數(shù)。老版本的 JVM 無法自動識別容器 CPU 和內(nèi)存限制會把堆內(nèi)存設(shè)置成宿主機(jī)內(nèi)存大小導(dǎo)致 Pod 直接被 OOM Killer 殺掉。我這次用的 JDK 版本是 11 以上默認(rèn)開啟了容器感知。如果還在用 JDK 8務(wù)必手工加上-XX:MaxRAMPercentage75.0和-XX:InitialRAMPercentage50.0讓 JVM 根據(jù)容器內(nèi)存限制自動分配。鏡像大小方面我的做法是采用多階段構(gòu)建?；A(chǔ)鏡像用精簡版 JDK然后在構(gòu)建階段編譯打包運(yùn)行階段只拷貝最終的 JAR 文件和一個最小的基礎(chǔ)鏡像。實測下來鏡像體積從 800 多 MB 縮小到 250 MB 左右推送到私有倉庫的速度快了不少拉鏡像占用的節(jié)點磁盤也少了。4.3 就緒探針和優(yōu)雅停機(jī)配置的完整參數(shù)Java 應(yīng)用啟動比較慢如果 ReadinessProbe 的initialDelaySeconds設(shè)置得太短Pod 還沒起來就被 K8S 判定為不健康然后被重啟形成死循環(huán)。我一般設(shè)置為 20 秒配合periodSeconds: 5給應(yīng)用留足啟動時間。LivenessProbe 的判定閾值要放寬一點因為 JVM 在 GC 停頓或頻繁 Full GC 時可能幾秒鐘沒有響應(yīng)容易誤殺。優(yōu)雅停機(jī)這里我用的參數(shù)是terminationGracePeriodSeconds: 60并在 Pod 里配置了 PreStop 鉤子執(zhí)行sleep 5配合應(yīng)用本身的優(yōu)雅停機(jī)機(jī)制。這樣在發(fā)布滾動更新時舊 Pod 先停止接收新流量再等待已經(jīng)進(jìn)來的請求處理完畢最后才真正退出容器。實測下來線上請求的失敗率從 5% 降到了 0。5. LNMP 組合上 K8S 的拆分思路與 Dubbo 微服務(wù)的注冊發(fā)現(xiàn)LNMP 和微服務(wù)這兩塊是這套環(huán)境里架構(gòu)最復(fù)雜的部分。LNMP 涉及三個組件的協(xié)作Dubbo 則是典型的注冊中心加多服務(wù)調(diào)用鏈兩者在 K8S 上的處理方式差異很大。5.1 LNMP 組合里 Nginx、PHP-FPM、MySQL 的容器協(xié)作方式LNMP 在傳統(tǒng)服務(wù)器上是一個單體環(huán)境但容器化之后必須拆開。我的拆分方式是Nginx 容器負(fù)責(zé)靜態(tài)資源和反向代理PHP-FPM 容器負(fù)責(zé)執(zhí)行 PHP 代碼MySQL 獨立部署。Nginx 和 PHP-FPM 之間通過 FastCGI 協(xié)議通信Nginx 的fastcgi_pass配置指向 PHP-FPM 的 Service 地址。這中間有一個關(guān)鍵細(xì)節(jié)PHP 代碼文件必須同時掛載到 Nginx 容器和 PHP-FPM 容器里。Nginx 需要讀取靜態(tài)文件和判斷文件是否存在PHP-FPM 需要找到對應(yīng)的.php文件執(zhí)行。我用的是共享 PVC把代碼目錄掛載到兩個 Pod 上保持路徑一致。不然會出現(xiàn) Nginx 能找到 PHP 文件但 PHP-FPM 報File not found的情況。5.2 PHP-FPM 容器遇到的一個經(jīng)典權(quán)限問題PHP-FPM 容器里的執(zhí)行用戶默認(rèn)是www-dataUID 是 33。如果代碼目錄掛載的是 NFS 存儲文件屬主和容器用戶不一致PHP-FPM 就沒法讀取文件頁面直接白屏報 403 或 500。我排查過一次最后發(fā)現(xiàn)是 PV 目錄的屬主是 1000而容器里跑的用戶是 33。解決方式有兩個一是在 PV 目錄上直接用chown -R 33:33但這在共享存儲上未必每次都生效二是在 PHP-FPM 鏡像里修改用戶 ID或者用initContainers在啟動前把代碼目錄的屬主改掉。我最后選了 initContainer 方案用一條chown -R 33:33 /var/www/html的命令把代碼目錄權(quán)限校正穩(wěn)定且不需要手工介入。5.3 Dubbo 微服務(wù)遷移 K8S 的注冊中心適配Dubbo 框架在 K8S 上部署最核心的變化是服務(wù)注冊與發(fā)現(xiàn)。原來 Dubbo 服務(wù)通過 ZooKeeper 注冊提供方啟動后把 IP 和端口寫入 ZK消費方監(jiān)聽 ZK 獲取列表。在 K8S 里如果 Dubbo 注冊的是 Pod IP那么 Pod 重建后 IP 變了消費方會拿到失效地址調(diào)用直接失敗。解決方案是讓 Dubbo 注冊 K8S 的 Service 名稱。具體做法是給每個 Dubbo 服務(wù)單獨建一個無頭 Service然后在啟動參數(shù)里配置DUBBO_IP_TO_REGISTRY指向 Service 的 DNS 域名。這樣消費方拿到的是穩(wěn)定域名而不是易變的 Pod IP。我在實際操作中是把環(huán)境變量注入 Deployment通過dubbo.registry.address指向 ZK 的同時設(shè)置dubbo.protocol.host為 Service 域名。5.4 微服務(wù)滾動發(fā)布時的優(yōu)雅上下線流程Dubbo 滾動發(fā)布時最怕的是服務(wù)下線瞬間消費方還在調(diào)用已經(jīng)被刪除的 Provider導(dǎo)致報錯No provider available。K8S 默認(rèn)的滾動更新策略是逐個重建 Pod但 Dubbo 的注冊中心更新有延遲。我的經(jīng)驗是把滾動更新前的 PreStop 鉤子用來做 Dubbo 主動下線調(diào)dubbo的qos端口發(fā)送offline指令然后等待幾秒再退出容器。這個等待時間非常關(guān)鍵太短了下線指令沒送達(dá)太長了拖慢發(fā)布節(jié)奏。我一般設(shè)置為 10 秒實測下來發(fā)布過程不會出現(xiàn)服務(wù)不可用的情況。消費方側(cè)如果依賴了本地緩存的服務(wù)列表也要定期刷新避免長期持有失效地址。6. Ingress 統(tǒng)一入口多服務(wù)路由規(guī)則配置與流量治理的細(xì)節(jié)最后一塊是入口流量管理。整套環(huán)境里有 Java 應(yīng)用、LNMP、Dubbo 的網(wǎng)關(guān)層等多個 HTTP 或 gRPC 服務(wù)不可能每個服務(wù)都暴露一個 NodePortIngress 就是用來統(tǒng)一收口流量的。6.1 Ingress 路由規(guī)則的編寫思路按域名、按路徑分層我的配置策略是一個域名對應(yīng)多個服務(wù)按路徑進(jìn)行區(qū)分。比如api.example.com域名下/java路徑轉(zhuǎn)發(fā)到 Java 應(yīng)用的 Service/php路徑轉(zhuǎn)發(fā)到 LNMP 的 Nginx Service/dubbo路徑轉(zhuǎn)發(fā)到 Dubbo 網(wǎng)關(guān) Service。這樣只用一個域名就能覆蓋所有業(yè)務(wù)入口證書管理也方便。路由規(guī)則里我用的是前綴匹配K8S 的 Ingress 規(guī)范從 1.22 版本開始推薦pathType: Prefix。同時要注意路徑的斜杠問題——如果用/java作為路徑且后端服務(wù)本身有 contextPath需要確認(rèn) Ingress 的 rewrite-target 注解行為避免路徑被改寫后后端找不到資源。6.2 Ingress Controller 選型和配置參數(shù)Ingress 只是一個資源對象真正干活的是 Ingress Controller。我用的方案是社區(qū)最主流的 ingress-nginx部署方式是用 Helm。核心配置參數(shù)我會打開這幾個proxy-body-size調(diào)到 100m因為 LNMP 那邊會上傳文件keep-alive設(shè)置為 300 秒降低后端連接的頻繁重建enable-real-ip打開讓后端能拿到真實的客戶端 IP而不是 Nginx 轉(zhuǎn)發(fā)過來的內(nèi)部地址。Helm 安裝時建議把hostNetwork設(shè)為 true讓 Ingress Controller 直接占用宿主機(jī)端口 80 和 443。這樣比 NodePort 多一跳的轉(zhuǎn)發(fā)更高效也方便直接在負(fù)載均衡器上把流量轉(zhuǎn)到幾個節(jié)點的對應(yīng)端口。6.3 TLS 證書配置與路由兼容性的一次實測踩坑有一次我給域名配置 HTTPS 證書時發(fā)現(xiàn)客戶端訪問https://api.example.com/java報證書無效。排查了半天最后定位到問題不在證書本身而在 Ingress 規(guī)則里的 host 和后端 Service 的響應(yīng)。Nginx Ingress Controller 默認(rèn)會透傳 SNI如果后端 Tomcat 啟動了 HTTPS 連接器的證書校驗Ingress 和后端之間的協(xié)商就對不上。解決方案是后端應(yīng)用全部走 HTTP由 Ingress 統(tǒng)一終結(jié) TLS不要在后端重復(fù)配置 HTTPS。Ingress 規(guī)則里用tls段綁定證書和 host然后后端 Service 只暴露 80 端口。這套架構(gòu)清晰也避免了證書鏈嵌套導(dǎo)致的各類兼容性問題。6.4 Ingress 的灰度發(fā)布和流量分流能力擴(kuò)展Ingress 天然支持按 header 或權(quán)重做流量分發(fā)我用它做了灰度發(fā)布。比如新版 Java 應(yīng)用先部署一套新的后端 Service然后通過 Ingress 注解nginx.ingress.kubernetes.io/canary-weight: 10把 10% 的流量切到新版本。驗證通過后把權(quán)重調(diào)到 100再清理舊副本。這套方案比直接改 Service 指向更平滑而且不需要停機(jī)。實際配置時要注意灰度規(guī)則只在同一 host 下生效且需要確保新舊兩個 Service 都是可用的否則會把錯誤流量引入灰度版本影響線上用戶體驗。7. 從部署到穩(wěn)定運(yùn)行的運(yùn)維視角這套架構(gòu)在真實環(huán)境里還要盯什么前面把每一類應(yīng)用的部署和踩坑都講了一遍最后補(bǔ)充一些從整體架構(gòu)視角出發(fā)的運(yùn)維細(xì)節(jié)。很多項目部署完沒問題但跑一段時間后就頻繁故障問題基本都出在這些容易被忽略的環(huán)節(jié)。7.1 資源規(guī)劃給每類應(yīng)用預(yù)留多少資源才夠用我把這套環(huán)境的資源分配做個參考Zookeeper 每個節(jié)點 1C2G三個節(jié)點MySQL 主節(jié)點 4C8G 加 500G 存儲從節(jié)點 2C4G 加 200GRedis 每個分片 2C4G六個分片Java 應(yīng)用平均 2C4G按 HPA 在 3 到 10 個副本之間彈性伸縮Nginx 入口 2C4G兩個副本。資源不是越高越好但要保證核心中間件有足夠的余量。MySQL 和 Kafka 這類 IO 密集應(yīng)用建議把 CPU Request 和 Limit 設(shè)得接近一些避免 CPU 被搶占導(dǎo)致 IO 等待時間拉長。Java 應(yīng)用則要關(guān)注堆內(nèi)存和容器內(nèi)存的比例避免容器設(shè)置了 4G Limit 但 JVM 堆只分配到 1G 的浪費。7.2 日志和監(jiān)控的統(tǒng)一收集方案K8S 環(huán)境下日志收集不能再像傳統(tǒng)服務(wù)器一樣tail -f去翻文件。我為每個節(jié)點部署了 Filebeat以 DaemonSet 方式運(yùn)行采集/var/log/containers/*.log下的容器日志輸出到 Elasticsearch。這套方案的優(yōu)點是無需改造應(yīng)用鏡像直接用標(biāo)準(zhǔn)輸出日志即可。監(jiān)控方面用的是 Prometheus 加 Grafana。Node Exporter 采集節(jié)點指標(biāo)cAdvisor 采集容器指標(biāo)MySQL Exporter 和 Redis Exporter 分別采集中間件指標(biāo)。告警規(guī)則我會重點盯這幾個Pod 頻繁重啟、PVC 使用率超過 85%、Redis 內(nèi)存超過 80%、MySQL 主從延遲超過 30 秒。這些指標(biāo)直接對應(yīng)線上故障命中率高誤報少。7.3 發(fā)布回滾預(yù)案如何快速恢復(fù)受損應(yīng)用有狀態(tài)應(yīng)用的發(fā)布回滾比無狀態(tài)應(yīng)用風(fēng)險高得多。MySQL 升級版本時萬一失敗不要直接重啟因為自動恢復(fù)可能會把數(shù)據(jù)文件搞壞。我的習(xí)慣是升級前先全量備份備份文件放到集群外存儲然后手動修改 StatefulSet 開啟滾動更新。如果啟動驗證失敗立即把鏡像 tag 改回原版本執(zhí)行回滾同時確認(rèn)所有 PVC 沒有被殘留的定時任務(wù)清理掉。無狀態(tài)應(yīng)用的回滾相對簡單Deployment 的rollout undo一條命令就能回到上一個版本。但需要注意如果同時改了 ConfigMap回滾不會自動恢復(fù) ConfigMap 的版本需要額外處理配置文件的回退。我這次上線 Dubbo 版本時踩過這個坑最后總結(jié)的經(jīng)驗是凡是涉及配置變更的發(fā)布必須把 ConfigMap 版本和鏡像版本一起放進(jìn)發(fā)布單里管理。7.4 團(tuán)隊協(xié)作中的命名規(guī)范和環(huán)境隔離最后說一個團(tuán)隊協(xié)作層面的建議。K8S 的命名空間是最好的隔離工具我這次把開發(fā)、測試、生產(chǎn)三個環(huán)境用命名空間強(qiáng)制隔離資源配額也分別限制。命名空間內(nèi)部再用標(biāo)簽區(qū)分應(yīng)用和中間件比如appjava-app、appredis。這樣無論是排查問題還是寫網(wǎng)絡(luò)策略目標(biāo)都清晰。命名規(guī)范上Service 名、配置名、PVC 名統(tǒng)一加應(yīng)用前綴比如mysql-prod-data、zk-headless、java-app-config。后期維護(hù)時一眼就能看出來對應(yīng)的資源類型和用途。這套組合從部署到現(xiàn)在跑了兩三個月整體穩(wěn)定性是過關(guān)的。中間件和業(yè)務(wù)應(yīng)用的日常操作沒有出現(xiàn)明顯故障彈性伸縮和灰度發(fā)布流程也已經(jīng)沉淀成團(tuán)隊內(nèi)部的標(biāo)準(zhǔn)化操作。希望這次完整的實戰(zhàn)拆解能給正在做 K8S 落地的朋友一些參考少走一點我已經(jīng)趟過的彎路。