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