CloudNativePG 排障實(shí)戰(zhàn)指南從基礎(chǔ)診斷到應(yīng)急備份、日志分析與已知問題處理【免費(fèi)下載鏈接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pgCloudNativePG 是基于 Kubernetes 的 PostgreSQL Operator其官方 troubleshooting 文檔 系統(tǒng)性地總結(jié)了在 Kubernetes 環(huán)境中診斷 CloudNativePG 集群故障的完整方法。本文以該文檔為核心骨架結(jié)合倉庫內(nèi) API 類型定義、Cluster 狀態(tài)處理邏輯、實(shí)例管理器啟動參數(shù) 與 系統(tǒng)工具層 等源碼實(shí)現(xiàn)為你提供一套可直接上手的排障清單從收集環(huán)境信息、利用kubectl cnpg插件快速定位問題到執(zhí)行緊急邏輯備份、按 JSON 日志過濾 PostgreSQL 錯誤、等待集群條件再到處理磁盤寫滿、副本失步、NetworkPolicy 阻斷等高頻故障場景。排障前的準(zhǔn)備環(huán)境信息與必備工具明確底層 Kubernetes 環(huán)境開始任何排障動作之前先確認(rèn)以下關(guān)于底層 Kubernetes 系統(tǒng)的信息它們往往是定位問題的關(guān)鍵上下文正在使用的 Kubernetes 發(fā)行版與版本PostgreSQL 實(shí)例所在節(jié)點(diǎn)的規(guī)格CPU、內(nèi)存、磁盤盡可能詳細(xì)的 存儲 信息包括 StorageClass、以及上線前做過的基準(zhǔn)測試數(shù)據(jù)集群中正在運(yùn)行的相關(guān) Kubernetes 應(yīng)用如 Prometheus、Grafana、Istio、Cert-manager 等連續(xù)備份Continuous Backup的現(xiàn)狀確認(rèn)其是否已配置并正常工作——如果沒有備份在進(jìn)行任何可能造成破壞的操作前務(wù)必先按下文 緊急邏輯備份 執(zhí)行一次備份。推薦的工具集除必需的kubectl外文檔推薦在排障環(huán)境中準(zhǔn)備以下工具工具用途cnpg插件kubectl的 CloudNativePG 插件提供status、report、logs等子命令是排障首選jq輕量靈活的 JSON 命令行處理器用于解析 CloudNativePG 的 JSON 結(jié)構(gòu)化日志grep在日志中匹配指定模式Windows 用戶可用findstr代替或通過wsl安裝 *nix 發(fā)行版后使用上述工具第一步獲取集群與 Operator 的整體視圖使用kubectl cnpg插件插件是快速獲取集群或 Operator 安裝全貌的主要工具status 子命令提供集群的概覽信息report 子命令提供集群與 Operator 部署的完整 manifest可通過--logs選項(xiàng)附帶日志生成的報(bào)告包含完整集群 manifest。在無法聯(lián)網(wǎng)air-gapped的環(huán)境中插件可以通過離線包安裝完整說明參見 kubectl 插件文檔。拿到集群 manifest 后應(yīng)立即核對備份是否已配置并處于工作狀態(tài)根據(jù)結(jié)論決定是否需要先做一次 緊急備份。在沒有定期備份的情況下操作生產(chǎn)數(shù)據(jù)庫是極其危險(xiǎn)的。獲取 Operator 運(yùn)行信息默認(rèn)情況下CloudNativePG Operator 以Deployment形式安裝在cnpg-system命名空間中詳見 部署細(xì)節(jié)。# 列出 Operator 相關(guān)的 Pod kubectl get pods -n cnpg-system正常情況下應(yīng)有一個以cnpg-controller-manager-開頭的 Pod 運(yùn)行 Operator若為高可用部署則有多個。這些 Pod 由名為cnpg-controller-manager的 Deployment 管理。收集指定 PodPOD的詳細(xì)信息與日志kubectl describe pod -n cnpg-system POD kubectl logs -n cnpg-system POD多副本 Operator 部署下可一次獲取 Deployment 內(nèi)所有容器的日志并加-f實(shí)時跟蹤kubectl logs -n cnpg-system \ deployment/cnpg-controller-manager --all-containerstrue將日志以 JSON 格式落盤保存注意每個日志條目本身是 JSON用jq -r .可去除引號包裝kubectl logs -n cnpg-system \ deployment/cnpg-controller-manager --all-containerstrue | \ jq -r . cnpg_logs.json通過插件獲取 Operator 版本信息kubectl-cnpg status CLUSTER輸出示例含版本號、復(fù)制狀態(tài)、實(shí)例狀態(tài)等Cluster in healthy state Name: cluster-example Namespace: default System ID: 7044925089871458324 PostgreSQL Image: ghcr.io/cloudnative-pg/postgresql:18.6-system-trixie Primary instance: cluster-example-1 Instances: 3 Ready instances: 3 Current Write LSN: 0/5000000 (Timeline: 1 - WAL File: 000000010000000000000004) Continuous Backup status Not configured Streaming Replication status Name Sent LSN Write LSN Flush LSN Replay LSN Write Lag Flush Lag Replay Lag State Sync State Sync Priority ---- -------- --------- --------- ---------- --------- --------- ---------- ----- ---------- ------------- cluster-example-2 0/5000000 0/5000000 0/5000000 0/5000000 00:00:00 00:00:00 00:00:00 streaming async 0 cluster-example-3 0/5000000 0/5000000 0/5000000 0/5000000 00:00:00.10033 00:00:00.10033 00:00:00.10033 streaming async 0 Instances status Name Database Size Current LSN Replication role Status QoS Manager Version ---- ------------- ----------- ---------------- ------ --- --------------- cluster-example-1 33 MB 0/5000000 Primary OK BestEffort 1.12.0 cluster-example-2 33 MB 0/5000000 Standby (async) OK BestEffort 1.12.0 cluster-example-3 33 MB 0/5000060 Standby (async) OK BestEffort 1.12.0緊急邏輯備份Emergency Backup在緊急情況下你可能需要對主庫的app數(shù)據(jù)庫執(zhí)行一次邏輯備份。重要以下指令僅應(yīng)在緊急情況下執(zhí)行且臨時備份文件需符合組織的安全與數(shù)據(jù)保護(hù)策略。dump 文件會保存在執(zhí)行kubectl命令的客戶端機(jī)器上請確保相應(yīng)保護(hù)措施到位、磁盤空間充足。對cluster-example集群的app數(shù)據(jù)庫執(zhí)行邏輯備份從cluster-example-1Pod 發(fā)起kubectl exec cluster-example-1 -c postgres \ -- pg_dump -Fc -d app app.dump上述命令以自定義格式-Fc執(zhí)行pg_dump這是 PostgreSQL 中最靈活的邏輯備份方式見 pg_dump 官方文檔。只需替換為你環(huán)境中實(shí)際的集群與數(shù)據(jù)庫名稱即可復(fù)用?；謴?fù)的前提是目標(biāo)集群已初始化完成且app數(shù)據(jù)庫為空。連接到新集群new-cluster-example的主實(shí)例new-cluster-example-1Pod執(zhí)行恢復(fù)kubectl exec -i new-cluster-example-1 -c postgres \ -- pg_restore --no-owner --roleapp -d app --verbose app.dump重要該示例假設(shè)沒有其他需要 dump/restore 的全局對象數(shù)據(jù)庫與角色。若存在多個角色請用pg_dumpall -g單獨(dú)備份并手工恢復(fù)到新集群若存在多個數(shù)據(jù)庫需要逐個數(shù)據(jù)庫重復(fù)上述操作并確保分配正確的屬主。如果不熟悉 PostgreSQL建議在專業(yè)支持團(tuán)隊(duì)的指導(dǎo)下執(zhí)行這些關(guān)鍵操作。上述步驟未來可能會整合進(jìn)cnpg插件。日志分析從 JSON 結(jié)構(gòu)化日志中快速定位問題CloudNativePG 創(chuàng)建和管理的所有資源都遵循 Kubernetes 慣例向標(biāo)準(zhǔn)輸出寫日志格式為 JSON詳見 日志文檔。排障時可直接從命令行讀取日志主要有三種方式用kubectl logs獲取特定資源日志配合jq提升可讀性使用kubectl cnpg logs命令 獲取 CloudNativePG 專屬日志借助 stern 等開源工具通過cnpg.io/clusterName標(biāo)簽聚合多資源日志、過濾條目、自定義輸出格式。下面給出針對各種資源的日志檢索示例。實(shí)例Pod日志按集群標(biāo)簽列出實(shí)例列表附帶角色標(biāo)簽rolekubectl get pod -l cnpg.io/clusterCLUSTER -L role -n NAMESPACE輸出示例NAME READY STATUS RESTARTS AGE ROLE CLUSTER-1 1/1 Running 0 10d4h5m primary CLUSTER-2 1/1 Running 0 10d4h4m replica CLUSTER-3 1/1 Running 0 10d4h4m replica檢查 Pod 的完整 YAML判斷啟動參數(shù)、掛載、狀態(tài)等kubectl get pod -n NAMESPACE -o yaml CLUSTER-N獲取指定實(shí)例的全部日志kubectl logs -n NAMESPACE CLUSTER-N只過濾 PostgreSQL 進(jìn)程自身的日志消息kubectl logs -n NAMESPACE CLUSTER-N | \ jq select(.loggerpostgres) | .record.message附加時間戳輸出為 CSV 兩列kubectl logs -n NAMESPACE CLUSTER-N | \ jq -r select(.loggerpostgres) | [.ts, .record.message] | csv若時間戳為 Unix Epoch 格式可轉(zhuǎn)換為易讀格式kubectl logs -n NAMESPACE CLUSTER-N | \ jq -r select(.loggerpostgres) | [(.ts|strflocaltime(%Y-%m-%dT%H:%M:%S %Z)), .record.message] | csv針對崩潰與錯誤的過濾技巧查看已崩潰容器的上一次日志kubectl logs -n NAMESPACE --previous CLUSTER-N提取指定 Pod 中的 FATAL 錯誤按 PostgreSQL 的error_severity字段過濾kubectl logs -n NAMESPACE CLUSTER-N | \ jq -r .record | select(.error_severity FATAL)輸出示例這是典型的streaming_replica角色不存在的復(fù)制失敗場景{ log_time: 2021-11-08 14:07:44.520 UTC, user_name: streaming_replica, process_id: 68, connection_from: 10.244.0.10:60616, session_id: 61892f30.44, session_line_num: 1, command_tag: startup, session_start_time: 2021-11-08 14:07:44 UTC, virtual_transaction_id: 3/75, transaction_id: 0, error_severity: FATAL, sql_state_code: 28000, message: role \streaming_replica\ does not exist, backend_type: walsender }過濾日志中的數(shù)據(jù)庫錯誤消息err字段非空kubectl logs -n NAMESPACE CLUSTER-N | jq -r .err | select(. ! null)輸出示例控制器 UNIX socket 路徑連接失敗dial unix /controller/run/.s.PGSQL.5432: connect: no such file or directory按msg字段匹配 err 關(guān)鍵字kubectl logs -n NAMESPACE CLUSTER-N | jq -r .msg | grep err輸出示例2021-11-08 14:07:39.610 UTC [15] LOG: ending log output to stderr獲取 PostgreSQL 進(jìn)程的全部原始日志行l(wèi)oggerpostgres且排除內(nèi)層record消息kubectl logs -n NAMESPACE CLUSTER-N | \ jq -r . | select(.logger postgres) | select(.msg ! record) | .msg輸出示例日志重定向到收集器進(jìn)程的典型啟動序列2021-11-08 14:07:52.591 UTC [16] LOG: redirecting log output to logging collector process 2021-11-08 14:07:52.591 UTC [16] HINT: Future log output will appear in directory /controller/log. 2021-11-08 14:07:52.591 UTC [16] LOG: ending log output to stderr 2021-11-08 14:07:52.591 UTC [16] HINT: Future log output will go to log destination csvlog.將多個日志字段用|連接成一行輸出kubectl logs -n NAMESPACE CLUSTER-N | \ jq -r [.level, .ts, .logger, .msg] | join( | )輸出示例WAL 歸檔未配置的提示與 PostgreSQL 記錄行info | 1636380469.5728037 | wal-archive | Backup not configured, skip WAL archiving info | 1636383566.0664876 | postgres | record集群信息狀態(tài)、條件與鏡像版本查看 Cluster 資源查看集群概覽kubectl get cluster -n NAMESPACE CLUSTER輸出示例NAME AGE INSTANCES READY STATUS PRIMARY CLUSTER 10d4h3m 3 3 Cluster in healthy state CLUSTER-1健康狀態(tài)下集群應(yīng)有 3 個實(shí)例、全部readyCLUSTER-1為 primary。若處于非健康狀態(tài)可通過完整 manifest 深入排查kubectl get cluster -o yaml -n NAMESPACE CLUSTER使用插件查看狀態(tài)--verbose可輸出更多信息kubectl cnpg status -n NAMESPACE CLUSTER獲取 PostgreSQL 容器鏡像版本kubectl describe cluster CLUSTER_NAME -n NAMESPACE | grep Image Name輸出示例Image Name: ghcr.io/cloudnative-pg/postgresql:18.6-system-trixie也可以直接用kubectl-cnpg status -n NAMESPACE CLUSTER_NAME獲得同樣信息。備份與存儲信息列出某集群的所有 Backup 資源按cnpg.io/cluster標(biāo)簽過濾kubectl get backup -l cnpg.io/clusterCLUSTER核對集群使用的 StorageClass先從 Pod 的 PVC 上取 StorageClass 名因?yàn)槎鄶?shù)集群使用默認(rèn) StorageClass 創(chuàng)建STORAGECLASS$(kubectl get pvc POD -o jsonpath{.spec.storageClassName}) kubectl get storageclasses $STORAGECLASS -o yaml節(jié)點(diǎn)信息查看工作節(jié)點(diǎn)及其狀態(tài)kubectl get nodes -o wide查看某集群 Pod 分布所在節(jié)點(diǎn)對排查 親和/反親和與容忍 配置非常有價(jià)值kubectl get pod -l cnpg.io/clusterCLUSTER \ -L role -n NAMESPACE -o wide基于 Conditions 的自動化等待與健康判斷與 Kubernetes 原生對象一樣Cluster在status.conditions中暴露結(jié)構(gòu)化條件允許腳本“等待”特定事件發(fā)生而不是依賴整體健康狀態(tài)。當(dāng)前文檔列出的可用條件如下其定義可在 api/v1/cluster_types.go 中確認(rèn)條件Type含義True 的含義LastBackupSucceeded最近一次備份的狀態(tài)最近一次備份已正確完成ContinuousArchivingWAL 歸檔的狀態(tài)最近一次 WAL 歸檔已正確完成Ready集群是否就緒實(shí)例數(shù)滿足用戶要求且主實(shí)例就緒等待特定條件# 等待最近一次備份成功 kubectl wait --forconditionLastBackupSucceeded cluster/CLUSTER-NAME -n NAMESPACE # 等待 WAL 歸檔正常 kubectl wait --forconditionContinuousArchiving cluster/CLUSTER-NAME -n NAMESPACE # 等待集群就緒 kubectl wait --forconditionReady cluster/CLUSTER-NAME -n NAMESPACEReady條件尤其適合在創(chuàng)建集群的腳本中用于阻塞等待集群可用。失敗條件的示例以下是一個cluster.status中同時包含失敗條件的片段例如 barman-cloud WAL 歸檔返回退出碼 2 時status: conditions: - message: unexpected failure invoking barman-cloud-wal-archive: exit status 2 reason: ContinuousArchivingFailing status: False type: ContinuousArchiving - message: exit status 2 reason: LastBackupFailed status: False type: LastBackupSucceeded - message: Cluster Is Not Ready reason: ClusterIsNotReady status: False type: Ready從源碼看這些 reason 常量均有對應(yīng)定義api/v1/cluster_types.goContinuousArchivingFailing、LastBackupFailed、ClusterIsNotReady等而Ready、LastBackupSucceeded條件也會由備份控制器在 api/v1/cluster_conditions.go 中根據(jù)備份成功/失敗結(jié)果動態(tài)構(gòu)建。可以推斷條件中的type/reason是腳本與告警系統(tǒng)做分支判斷的穩(wěn)定契約。網(wǎng)絡(luò)排障NetworkPolicy 與連通性CloudNativePG 要求具備基本的網(wǎng)絡(luò)連通性詳見 networking 文檔。在既有環(huán)境中安裝時可能已存在網(wǎng)絡(luò)策略或定制化網(wǎng)絡(luò)配置影響 Operator 與集群 Pod 之間、以及 Pod 之間的連通性。查看現(xiàn)有網(wǎng)絡(luò)策略kubectl get networkpolicies輸出示例NAME POD-SELECTOR AGE allow-prometheus cnpg.io/clustercluster-example 47m default-deny-ingress none 57m提示一個典型的連通性受損信號是 Operator 日志中出現(xiàn)類似Cannot extract Pod status…Get \http://pod IP:8000/pg/status\: dial tcp pod IP:8000: i/o timeout的消息。此時應(yīng)列出網(wǎng)絡(luò)策略并檢查是否有策略限制了連通性例如上例中的default-deny-ingresspodSelector: {}且policyTypes: [Ingress]會默認(rèn)拒絕所有入站流量。可參考 networking 頁面 提供的 NetworkPolicy 模板定制一個顯式允許 Operator 跨命名空間訪問集群 Pod 的策略。性能剖析啟用實(shí)例級 pprofCloudNativePG 集成了 pprof支持在兩層收集與分析性能剖析數(shù)據(jù)Operator 層為 Operator 部署添加--pprof-servertrue啟動選項(xiàng)啟用參見 Operator 配置Postgres 集群層在Cluster資源上添加alpha.cnpg.io/enableInstancePprof注解啟用。當(dāng)注解alpha.cnpg.io/enableInstancePprof設(shè)為true時每個實(shí)例 Pod 都會由實(shí)例管理器instance manager暴露一個 Go pprof HTTP 服務(wù)服務(wù)監(jiān)聽 Pod 內(nèi)0.0.0.0:6060Pod spec 中會自動增加名為pprof的容器端口6060/TCP。這一點(diǎn)與實(shí)例管理器源碼實(shí)現(xiàn)一致run子命令提供--pprof-server標(biāo)志啟用時其綁定地址為0.0.0.0:6060見 internal/cmd/manager/instance/run/cmd.go 與 getPprofServerAddress。隨時可通過移除注解或?qū)⑵湓O(shè)為false來禁用 pprofOperator 會自動滾動更新以移除 pprof 端口與標(biāo)志。重要pprof 服務(wù)僅提供6060端口的明文 HTTP 服務(wù)。啟用示例apiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: name: cluster-example annotations: alpha.cnpg.io/enableInstancePprof: true spec: instances: 3 # ...修改該注解會更新實(shí)例 Pod spec增加端口6060與對應(yīng)標(biāo)志并觸發(fā)滾動更新。警告下面的示例僅用于本地測試。這不是在生產(chǎn)中暴露該功能的正確方式。請將 pprof 視為敏感的調(diào)試接口切勿公開暴露若必須遠(yuǎn)程訪問請用網(wǎng)絡(luò)策略和訪問控制進(jìn)行保護(hù)。通過端口轉(zhuǎn)發(fā)訪問 pprof 端點(diǎn)kubectl port-forward -n namespace pod/instance-pod 6060 curl -sS http://localhost:6060/debug/pprof/ go tool pprof http://localhost:6060/debug/pprof/profile?seconds30也可以用瀏覽器訪問http://localhost:6060/debug/pprof/。pprof 排障步驟確認(rèn)集群上設(shè)置了alpha.cnpg.io/enableInstancePprof: true注解檢查實(shí)例管理器命令行包含--pprof-server標(biāo)志、且暴露了6060/TCP端口可通過kubectl -n namespace describe pod instance-pod查看Command與Ports部分若未使用端口轉(zhuǎn)發(fā)請確認(rèn) NetworkPolicy 放行了6060/TCP端口。PostgreSQL core dump 的定位與收集PostgreSQL 偶爾會崩潰并在PGDATA目錄下生成 core dump——這通常是 PostgreSQL 自身的 bug很可能已被修復(fù)這也是為何應(yīng)始終運(yùn)行最新的 PostgreSQL 小版本。CloudNativePG 通過cnpg.io/coredumpFilter注解控制 core dump 包含的內(nèi)容標(biāo)準(zhǔn)注解清單見 Labels and annotations。默認(rèn)值為0x31用于從 dump 中排除共享內(nèi)存段——這是大多數(shù)情況下最安全的做法。該默認(rèn)值與實(shí)現(xiàn)一致GetCoredumpFilter在未設(shè)置注解時返回 pkg/system/system.go 中定義的DefaultCoredumpFilter 0x31并由實(shí)例管理器在啟動時通過SetCoredumpFilter寫入/proc/self/coredump_filter見 internal/management/controller/instance_controller.go。關(guān)于控制 core dump filter 的位掩碼含義可參考 Linux 內(nèi)核文檔中 Core dump filtering settings 一節(jié)。重要該設(shè)置僅在 Pod 啟動時生效修改注解不會自動觸發(fā)實(shí)例滾動更新。即使你本人不參與分析 core dump也可能被要求提供 dump 文件供 PostgreSQL 專家排查。先在正確的實(shí)例 Pod 上確認(rèn)PGDATA目錄中是否有 core dump正常情況應(yīng)返回空kubectl exec -ti POD -c postgres \ -- find /var/lib/postgresql/data/pgdata -name core.*假設(shè)找到如下文件/var/lib/postgresql/data/pgdata/core.14177確認(rèn)磁盤空間充足后用kubectl cp把 core dump 取到本地機(jī)器kubectl cp POD:/var/lib/postgresql/data/pgdata/core.14177 core.14177拿到文件后記得清理服務(wù)端空間刪除 core dump 文件。已知問題與典型故障場景磁盤已滿Storage is full存儲寫滿后PostgreSQL Pod 將無法寫入新數(shù)據(jù)若是存放 WAL 段的磁盤寫滿PostgreSQL 會直接關(guān)閉。日志中出現(xiàn)磁盤寫滿消息時應(yīng)擴(kuò)大受影響的 PVC編輯 PVC 修改spec.resources.requests.storage字段同時更新 Cluster 資源為新容量使同樣的變更應(yīng)用到所有 Pod詳見 Volume expansion 一節(jié)。若 WAL 空間耗盡Pod 會不斷崩潰重啟crash-looping集群狀態(tài)報(bào)告Not enough disk space。同樣通過擴(kuò)大 PVC 和 Cluster 資源容量解決可參考 Disk Full Failure 一節(jié)。Pod 卡在Pending狀態(tài)先檢查 Pod 的Events段kubectl describe pod -n NAMESPACE POD可能的原因包括沒有任何節(jié)點(diǎn)匹配nodeSelectorTolerations 未正確配置以匹配節(jié)點(diǎn) taints集群中根本沒有可用節(jié)點(diǎn)——也可能與cluster-autoscaler觸及某些限制或出現(xiàn)臨時故障有關(guān)。此時檢查命名空間事件也很有用kubectl get events -n NAMESPACE # 按時間順序列出事件 kubectl get events -n NAMESPACE --sort-by.metadata.creationTimestamp未配置備份時副本失步Replicas out of sync副本可能因維護(hù)如節(jié)點(diǎn)被 drain而短暫下線。若集群未配置備份副本重新上線時可能需要一個主庫上已不存在的 WAL 文件該文件已按 WAL 管理策略被回收參見postgresql配置段從而失步。類似地pg_rewind可能因找不到已回收的 WAL 文件而報(bào)pg_rewind: error: could not open file。此時 Pod 無法再變?yōu)?ready需要刪除 PVC 讓 Operator 重建副本。如果使用動態(tài)供給的 Persistent Volume且確認(rèn)可以刪除 PV可執(zhí)行PODNAMEPOD VOLNAME$(kubectl get pv -o json | \ jq -r .items[]|select(.spec.claimRef.name\$PODNAME\)|.metadata.name) kubectl delete pod/$PODNAME pvc/$PODNAME pvc/$PODNAME-wal pv/$VOLNAME注意在刪除 PVC/PV 前務(wù)必確認(rèn)數(shù)據(jù)可恢復(fù)或可重建并遵從組織的數(shù)據(jù)保護(hù)規(guī)范。集群卡在Creating new replica集群狀態(tài)卡在 Creating a new replica而 Pod 日志未見明顯問題——這通常與下述 NetworkPolicy 導(dǎo)致的連通性問題有關(guān)。網(wǎng)絡(luò)問題會以如下方式體現(xiàn)在狀態(tài)列中Instance Status Extraction Error: HTTP communication issueNetworkPolicy 干擾網(wǎng)絡(luò)Networking is impaired如前文所述本地網(wǎng)絡(luò)策略可能阻止部分必需連通性。Operator 日志中出現(xiàn)以下消息是連通性受損的典型信號Cannot extract Pod status, […snipped…] Get \http://pod IP:8000/pg/status\: dial tcp pod IP:8000: i/o timeout列出網(wǎng)絡(luò)策略并查找任何限制性策略kubectl get networkpoliciesNAME POD-SELECTOR AGE allow-prometheus cnpg.io/clustercluster-example 47m default-deny-ingress none 57m例如上表中的default-deny-ingress就是可疑對象進(jìn)一步查看其內(nèi)容kubectl get networkpolicies default-deny-ingress -o yamlspec: podSelector: {} policyTypes: - Ingress在 networking 頁面 可以找到一個可定制的網(wǎng)絡(luò)策略文件創(chuàng)建顯式允許 Operator 跨命名空間連接集群 Pod 的NetworkPolicy。初始化數(shù)據(jù)目錄時報(bào)錯Bootstrap init container Bus error若 Cluster 的 bootstrap init 容器崩潰報(bào)Bus error (core dumped) child process exited with exit code 135很可能是需要修正 Cluster 的 hugepages 設(shè)置。原因是 cgroup v1 對 hugepages 支持不完整v2 中已修復(fù)相關(guān)背景見 PostgreSQL BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes。先在 Kubernetes 節(jié)點(diǎn)上運(yùn)行g(shù)rep HugePages /proc/meminfo確認(rèn)是否存在 hugepages、其大小與剩余數(shù)量。若存在需要在 Cluster 中為每個 PostgreSQL Pod 配置可用的 hugepages 內(nèi)存量。例如postgresql: parameters: shared_buffers: 128MB resources: requests: memory: 512Mi limits: hugepages-2Mi: 512Mi請記住集群中每個 Pod 都必須有足夠的空閑 hugepages 內(nèi)存才能被調(diào)度上例中每個 Pod 至少需要 512MiB 空閑。Bootstrap init 容器卡在 Running 狀態(tài)若實(shí)例 Pod 的 bootstrap init 容器卡在Running并提示 error while waiting for the API server to be reachable通常是網(wǎng)絡(luò)問題阻斷了與 Kubernetes API Server 的通信。bootstrap init 容器與 Operator 的大多數(shù)組件一樣需要訪問 Kubernetes API請檢查網(wǎng)絡(luò)。另一種可能原因是配置了邊車注入sidecar injection。Istio 等邊車可能在啟動階段臨時使網(wǎng)絡(luò)不可用。若啟用了 sidecar 注入請關(guān)閉注入后重試。故障切換后副本重連延遲超過兩分鐘主實(shí)例故障后Operator 會將最領(lǐng)先的 standby 提升為主其余 standby 嘗試通過-rw服務(wù)重連復(fù)制。但重連過程中kube-proxy可能尚未更新其路由信息導(dǎo)致 standby 發(fā)出的首個SYN包無法到達(dá)目標(biāo)。若網(wǎng)絡(luò)配置為靜默丟包而非拒絕standby 收不到響應(yīng)會按指數(shù)退避重試。Linux 內(nèi)核參數(shù)tcp_syn_retries默認(rèn)值為 6意味著系統(tǒng)約嘗試 127 秒后才放棄顯著延遲重連過程詳見 tcp_syn_retries 文檔?？赏ㄟ^在 Operator 配置 中設(shè)置STANDBY_TCP_USER_TIMEOUT來規(guī)避該參數(shù)使 standby 在指定超時內(nèi)未收到SYN確認(rèn)時主動關(guān)閉 TCP 連接從而更快地重試連接。總結(jié)一份可執(zhí)行的排障清單綜合官方文檔與源碼實(shí)現(xiàn)CloudNativePG 的排障可歸納為以下固定動作序列準(zhǔn)備確認(rèn) Kubernetes 發(fā)行版/版本、節(jié)點(diǎn)規(guī)格、存儲與 StorageClass、相關(guān)應(yīng)用、連續(xù)備份狀態(tài)全景用kubectl cnpg status/kubectl cnpg report必要時帶--logs獲取集群與 Operator 完整信息備份核查確認(rèn) Backup 資源kubectl get backup -l cnpg.io/clusterCLUSTER與 WAL 歸檔條件ContinuousArchiving正常否則先做 緊急邏輯備份日志通過kubectl logs配合jq按logger、error_severity、err、msg等字段過濾定位錯誤條件等待用kubectl wait --forcondition...Ready/LastBackupSucceeded/ContinuousArchiving做自動化判斷深入按需檢查 StorageClass、節(jié)點(diǎn)分布、NetworkPolicy、cnpg.io/coredumpFilter注解、實(shí)例級 pprofalpha.cnpg.io/enableInstancePprof等專項(xiàng)處置針對磁盤寫滿、Pending、副本失步、卡在 Creating new replica、hugepages/Bus error、重連延遲等已知問題按上文對應(yīng)的操作步驟處理。掌握這套方法后你就能在 CloudNativePG 的 Kubernetes 部署中系統(tǒng)、快速地完成從“發(fā)現(xiàn)問題”到“收集證據(jù)”再到“恢復(fù)服務(wù)”的完整排障閉環(huán)。【免費(fèi)下載鏈接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pg創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考