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