CloudNativePG 集群 Kubernetes 升级与节点维护完全指南【免费下载链接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.项目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pg本文以 CloudNativePG 的官方文档为骨架系统讲解如何在不中断 PostgreSQL 业务的前提下完成 Kubernetes 集群的升级与节点维护从维护窗口的规划、drain/uncordon的标准流程到节点本地存储场景下集群的临时降级、PodDisruptionBudgetPDB的管理策略以及nodeMaintenanceWindow这一为本地存储而生的维护机制及其在新版本中的演进。读完本文你将能够根据集群存储类型与实例拓扑为生产、开发/测试集群分别制定正确的维护策略并正确使用kubectl drain、enablePDB、nodeMaintenanceWindow.inProgress/reusePVC等关键开关完成一次安全的节点维护。为什么必须重视 Kubernetes 的定期升级保持 Kubernetes 集群处于最新状态是保证性能与安全的基础要求这一点对自管self-managed集群、尤其是运行在裸金属bare metal基础设施上的集群尤为关键。定期升级能够消除技术债Kubernetes 控制面与节点组件的迭代非常快长期停留在旧版本会积累大量配置、API 与依赖层面的历史包袱降低业务风险安全补丁、硬件故障替换、控制面版本升级等维护操作都是降低基础设施整体风险的必要投入。需要正视的是升级过程往往伴随着有计划的停机窗口——例如需要将某个节点临时移出集群进行维护。官方文档在介绍这一话题时引用了 Google SRE 经典书籍中的 Embracing Risk 章节其核心思想是运维不是消除所有风险而是有意识地接受并管理可控风险。将风险量化为可接受的停机时间与数据风险正是规划维护窗口的前提。集群中的标准维护流程Kubernetes 的节点维护通常每次只针对一个节点进行遵循一套标准化的三步流程详见 Kubernetes 官方 kubeadm 升级指南驱逐工作负载drain使用kubectl drain node优雅地将目标节点上的工作负载迁移走确保平滑过渡执行维护操作在节点上执行实际维护例如应用系统更新、替换故障硬件、升级 kubelet 版本等让节点重新加入集群uncordon维护完成后使用kubectl uncordon node将节点重新接入集群恢复其调度职责。这一流程的代价是要么在整个升级期间停止工作负载要么将工作负载迁移到集群中的其他节点。对于 PostgreSQL 这类有状态工作负载后者是否可行高度取决于存储类型——这正是 CloudNativePG 相关设计PDB、维护窗口的出发点。节点本地存储下的临时降级一种可接受的状态标准流程依赖 Kubernetes 的自愈能力保证服务可靠性但在某些场景下允许 PostgreSQL 集群临时处于降级状态是完全可以接受的。这一论断特别适用于依赖节点本地存储node-local storage即 local storage的 PostgreSQL 集群——数据存放在运行 PostgreSQL 的 Kubernetes 工作节点自身的磁盘上以换取更高的 I/O 性能。:::note 何时可以跳过本文其余章节 如果你的数据库文件位于可通过网络访问的共享存储上那么在drain之后卷可以被不同节点上的 Pod 重新使用此时 operator 的默认自愈行为已经能高效处理可以跳过本文后续内容。本文剩余部分专门针对本地存储场景。 :::Pod Disruption Budget默认的守护机制默认行为为每个 Cluster 创建两个 PDB默认情况下CloudNativePG 会在后台守护 PostgreSQL 集群的可用性如果要被drain的节点上运行着集群的primary实例operator 会在drain之前先执行一次 switchover切换把该节点上的实例降级为 replica 后再继续驱逐对于单实例集群由于无法切换CloudNativePG 会阻止驱逐该实例所在的节点对于3 个及以上实例的集群CloudNativePG 保证在drain过程中同一时刻最多只有一个 replica 被优雅关闭。这一行为的实现机制是每个 PostgreSQLCluster都会自动关联两个PodDisruptionBudget资源你可以通过kubectl get pdb立即确认kubectl get pdb -n namespace从源码看这两个 PDB 在 pkg/specs/poddisruptionbudget.go 中分别构建BuildPrimaryPodDisruptionBudget保护 primary 实例避免其被随意驱逐对应上文primary 所在节点先切换、单实例阻止驱逐的行为BuildReplicasPodDisruptionBudget通过MinAvailable instances - 2保证 n 实例集群中始终至少有 n-2 个 replica 可用从而实现一次只优雅关闭一个 replica该函数在cluster.Spec.Instances 3时返回nil见 poddisruptionbudget.go。二者会在集群调和过程中被统一管理见 cluster_create.go 的reconcilePodDisruptionBudget函数。生产建议保持 PDB 开启官方建议对每个生产 PostgreSQL 集群都保持 Pod disruption budget 开启。这一开关由.spec.enablePDB字段控制其语义定义在 cluster_types.go默认值为true此时 PDB 会保护 primary 节点不被终止置为false时不会创建任何 PDB 资源若之前已创建则会被删除允许关闭所有承载 PostgreSQL 集群的节点——后者正是为开发/预发staging用途推荐的配置。从实现上看enablePDB的默认值逻辑在 cluster_funcs.go 的GetEnablePDB()中当字段未设置nil时返回true即默认开启。开发/测试集群禁用 PDB 以便顺利排空节点对于开发用途的 PostgreSQL 集群通常为单实例必须禁用 pod disruption budgets——否则该集群所在节点将永远无法被drain。下面的示例展示了如何为一个单实例的开发集群禁用 PDBapiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: name: dev spec: instances: 1 enablePDB: false storage: size: 1Gi该配置可确保开发期间的维护流程不受限制drain操作可以顺利进行。Node Maintenance Window面向本地存储的维护窗口:::info 重要提示 CloudNativePG 会继续支持节点维护窗口机制但目前官方建议改用上一节直接管理 pod disruption budgets 的方式。本节内容主要为向后兼容而保留。 :::演进背景1.23 之前的唯一声明式手段在 release 1.23 之前当处理本地存储场景时CloudNativePG 只有一种声明式机制来管理 Kubernetes 升级通过nodeMaintenanceWindow选项临时将集群置入维护模式以避免标准的自愈流程介入——典型场景包括在物理节点上扩容分区、或者更新节点本身。:::warning 谨慎使用 请将维护窗口的持续时间限制到最短。在该阶段Kubernetes 的部分预期行为会被禁用或以受限方式运行包括自愈self-healing、滚动更新rolling updates和 Pod disruption budget。 :::两个子选项inProgress与reusePVCnodeMaintenanceWindow包含两个设置字段定义见 cluster_types.go字段类型默认值含义inProgressBooleanfalse文档原文记为off是否处于节点维护窗口进行中。仅在为true时operator 才会评估下面的reusePVC选项reusePVCBooleantrue文档原文记为on维护期间是否复用现有 PVC两者在 cluster_funcs.go 中都有对应的判定方法IsNodeMaintenanceWindowInProgress()L844-L847维护窗口是否激活IsReusePVCEnabled()L859-L866默认reusePVC true仅当显式设置为false时才返回false。reusePVC启用时默认Kubernetes 等待节点重新上线然后复用现有 PVC在此期间PodDisruptionBudget策略会被临时移除。reusePVC禁用时Kubernetes 强制在其他节点上以全新的 PVC 重新创建 Pod借助 PostgreSQL 的物理流复制恢复数据随后连同 Pod 一起销毁旧 PVC。这一场景通常不推荐除非数据库体积很小且重新克隆一个新的 PostgreSQL 实例比等待原节点恢复更快。需要注意该行为不适用于单实例且reusePVC为false的集群详见下文。维护窗口下 PDB 的临时移除逻辑从 cluster_create.go 的调和逻辑可以确认当维护窗口进行中且reusePVC开启时replica 的 PDB 不会被强制执行若此时集群为单实例primary 的 PDB 也会一并移除——否则用户无法把工作负载从底层节点驱逐出去。别忘了--delete-emptydir-data:::note 执行kubectl drain时需要附加--delete-emptydir-data选项。 不必担心它指向的是 operator 内部使用的另一个卷并非 PostgreSQL 数据目录。 :::即正确用法为kubectl drain node --delete-emptydir-data --ignore-daemonsets用enablePDB完全接管 PDB 管理:::info 重要提示 PodDisruptionBudget 的管理可以通过将.spec.enablePDB字段设为false来整体禁用。此时 operator 不再创建PodDisruptionBudget并且会删除之前已创建的资源。 :::这一行为由 cluster_create.go 中的deletePodDisruptionBudgetsIfExist路径保证GetEnablePDB()返回false时直接进入删除逻辑。单实例集群 reusePVC: false数据安全的红线:::info 重要提示 官方建议始终创建多于一个实例的集群以保证高可用high availability。 :::在单实例集群中删除唯一一个 PostgreSQL 实例意味着所有数据丢失。因此即使处于维护模式CloudNativePG 也会阻止用户 drain 这类实例所在的节点——这是 operator 主动守护数据安全的硬性边界。不过当确实需要对这类节点进行维护时你有两个选择启用reusePVC接受停机时间在其他节点上复制实例并执行一次 primary 切换switchover。方案一接受停机只要你的环境能够接受数据库服务的停机操作就很简单将nodeMaintenanceWindow设置为inProgress: true且reusePVC: true。这样实例会被删除并在原始 PVC 可用时立即重建例如节点本地存储场景下节点一恢复即可复用 PVC。对应的 YAML 示意如下apiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: name: single-instance spec: instances: 1 nodeMaintenanceWindow: inProgress: true reusePVC: true storage: size: 20Gi方案二无停机仅切换耗时否则你需要扩容集群在其他节点创建新实例将新实例提升为 primary然后关闭正在维护节点上的原实例。此方案唯一的停机时间就是switchover 的耗时。推荐的操作步骤如下**Cordon封锁**当前实例所在的节点kubectl cordon node扩容集群到 2 个实例耗时取决于数据库大小例如编辑 Cluster 将spec.instances从1改为2新实例运行起来后由于当前 primary 运行在已被 cordon 的节点上operator 会自动执行 switchover缩容集群回到单实例此时旧实例会被删除原 primary 所在节点现在可以成功 drain而新 primary 已运行在新节点上。整个过程把停机窗口压缩到一次切换的时间是本地存储、单实例场景下的推荐路径。总结一张维护策略决策表结合前文可以为不同场景总结出如下决策要点集群类型存储类型推荐配置drain 可行性生产集群≥3 实例网络共享存储保持默认enablePDB: true直接 drainoperator 自愈生产集群≥3 实例节点本地存储保持 PDB逐节点 drain必要时使用维护窗口一次关闭一个 replicaprimary 先切换生产集群单实例节点本地存储扩容→自动切换→缩容或reusePVC: true接受停机需先处理 primary否则被阻止开发/测试集群任意enablePDB: false可直接 drain维护的最终目标是在Kubernetes 自愈能力、PostgreSQL 高可用与可控的停机风险之间取得平衡。理解 PDB 的默认行为、enablePDB开关以及nodeMaintenanceWindow含inProgress/reusePVC的语义是安全执行每一次节点升级的基础。更多字段细节可查阅 CloudNativePG API 参考 中关于ClusterSpec的说明以及仓库中的类型定义 cluster_types.go 与控制器实现 cluster_create.go。【免费下载链接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.项目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pg创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CloudNativePG 集群 Kubernetes 升级与节点维护完全指南
CloudNativePG 集群 Kubernetes 升级与节点维护完全指南【免费下载链接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.项目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pg本文以 CloudNativePG 的官方文档为骨架系统讲解如何在不中断 PostgreSQL 业务的前提下完成 Kubernetes 集群的升级与节点维护从维护窗口的规划、drain/uncordon的标准流程到节点本地存储场景下集群的临时降级、PodDisruptionBudgetPDB的管理策略以及nodeMaintenanceWindow这一为本地存储而生的维护机制及其在新版本中的演进。读完本文你将能够根据集群存储类型与实例拓扑为生产、开发/测试集群分别制定正确的维护策略并正确使用kubectl drain、enablePDB、nodeMaintenanceWindow.inProgress/reusePVC等关键开关完成一次安全的节点维护。为什么必须重视 Kubernetes 的定期升级保持 Kubernetes 集群处于最新状态是保证性能与安全的基础要求这一点对自管self-managed集群、尤其是运行在裸金属bare metal基础设施上的集群尤为关键。定期升级能够消除技术债Kubernetes 控制面与节点组件的迭代非常快长期停留在旧版本会积累大量配置、API 与依赖层面的历史包袱降低业务风险安全补丁、硬件故障替换、控制面版本升级等维护操作都是降低基础设施整体风险的必要投入。需要正视的是升级过程往往伴随着有计划的停机窗口——例如需要将某个节点临时移出集群进行维护。官方文档在介绍这一话题时引用了 Google SRE 经典书籍中的 Embracing Risk 章节其核心思想是运维不是消除所有风险而是有意识地接受并管理可控风险。将风险量化为可接受的停机时间与数据风险正是规划维护窗口的前提。集群中的标准维护流程Kubernetes 的节点维护通常每次只针对一个节点进行遵循一套标准化的三步流程详见 Kubernetes 官方 kubeadm 升级指南驱逐工作负载drain使用kubectl drain node优雅地将目标节点上的工作负载迁移走确保平滑过渡执行维护操作在节点上执行实际维护例如应用系统更新、替换故障硬件、升级 kubelet 版本等让节点重新加入集群uncordon维护完成后使用kubectl uncordon node将节点重新接入集群恢复其调度职责。这一流程的代价是要么在整个升级期间停止工作负载要么将工作负载迁移到集群中的其他节点。对于 PostgreSQL 这类有状态工作负载后者是否可行高度取决于存储类型——这正是 CloudNativePG 相关设计PDB、维护窗口的出发点。节点本地存储下的临时降级一种可接受的状态标准流程依赖 Kubernetes 的自愈能力保证服务可靠性但在某些场景下允许 PostgreSQL 集群临时处于降级状态是完全可以接受的。这一论断特别适用于依赖节点本地存储node-local storage即 local storage的 PostgreSQL 集群——数据存放在运行 PostgreSQL 的 Kubernetes 工作节点自身的磁盘上以换取更高的 I/O 性能。:::note 何时可以跳过本文其余章节 如果你的数据库文件位于可通过网络访问的共享存储上那么在drain之后卷可以被不同节点上的 Pod 重新使用此时 operator 的默认自愈行为已经能高效处理可以跳过本文后续内容。本文剩余部分专门针对本地存储场景。 :::Pod Disruption Budget默认的守护机制默认行为为每个 Cluster 创建两个 PDB默认情况下CloudNativePG 会在后台守护 PostgreSQL 集群的可用性如果要被drain的节点上运行着集群的primary实例operator 会在drain之前先执行一次 switchover切换把该节点上的实例降级为 replica 后再继续驱逐对于单实例集群由于无法切换CloudNativePG 会阻止驱逐该实例所在的节点对于3 个及以上实例的集群CloudNativePG 保证在drain过程中同一时刻最多只有一个 replica 被优雅关闭。这一行为的实现机制是每个 PostgreSQLCluster都会自动关联两个PodDisruptionBudget资源你可以通过kubectl get pdb立即确认kubectl get pdb -n namespace从源码看这两个 PDB 在 pkg/specs/poddisruptionbudget.go 中分别构建BuildPrimaryPodDisruptionBudget保护 primary 实例避免其被随意驱逐对应上文primary 所在节点先切换、单实例阻止驱逐的行为BuildReplicasPodDisruptionBudget通过MinAvailable instances - 2保证 n 实例集群中始终至少有 n-2 个 replica 可用从而实现一次只优雅关闭一个 replica该函数在cluster.Spec.Instances 3时返回nil见 poddisruptionbudget.go。二者会在集群调和过程中被统一管理见 cluster_create.go 的reconcilePodDisruptionBudget函数。生产建议保持 PDB 开启官方建议对每个生产 PostgreSQL 集群都保持 Pod disruption budget 开启。这一开关由.spec.enablePDB字段控制其语义定义在 cluster_types.go默认值为true此时 PDB 会保护 primary 节点不被终止置为false时不会创建任何 PDB 资源若之前已创建则会被删除允许关闭所有承载 PostgreSQL 集群的节点——后者正是为开发/预发staging用途推荐的配置。从实现上看enablePDB的默认值逻辑在 cluster_funcs.go 的GetEnablePDB()中当字段未设置nil时返回true即默认开启。开发/测试集群禁用 PDB 以便顺利排空节点对于开发用途的 PostgreSQL 集群通常为单实例必须禁用 pod disruption budgets——否则该集群所在节点将永远无法被drain。下面的示例展示了如何为一个单实例的开发集群禁用 PDBapiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: name: dev spec: instances: 1 enablePDB: false storage: size: 1Gi该配置可确保开发期间的维护流程不受限制drain操作可以顺利进行。Node Maintenance Window面向本地存储的维护窗口:::info 重要提示 CloudNativePG 会继续支持节点维护窗口机制但目前官方建议改用上一节直接管理 pod disruption budgets 的方式。本节内容主要为向后兼容而保留。 :::演进背景1.23 之前的唯一声明式手段在 release 1.23 之前当处理本地存储场景时CloudNativePG 只有一种声明式机制来管理 Kubernetes 升级通过nodeMaintenanceWindow选项临时将集群置入维护模式以避免标准的自愈流程介入——典型场景包括在物理节点上扩容分区、或者更新节点本身。:::warning 谨慎使用 请将维护窗口的持续时间限制到最短。在该阶段Kubernetes 的部分预期行为会被禁用或以受限方式运行包括自愈self-healing、滚动更新rolling updates和 Pod disruption budget。 :::两个子选项inProgress与reusePVCnodeMaintenanceWindow包含两个设置字段定义见 cluster_types.go字段类型默认值含义inProgressBooleanfalse文档原文记为off是否处于节点维护窗口进行中。仅在为true时operator 才会评估下面的reusePVC选项reusePVCBooleantrue文档原文记为on维护期间是否复用现有 PVC两者在 cluster_funcs.go 中都有对应的判定方法IsNodeMaintenanceWindowInProgress()L844-L847维护窗口是否激活IsReusePVCEnabled()L859-L866默认reusePVC true仅当显式设置为false时才返回false。reusePVC启用时默认Kubernetes 等待节点重新上线然后复用现有 PVC在此期间PodDisruptionBudget策略会被临时移除。reusePVC禁用时Kubernetes 强制在其他节点上以全新的 PVC 重新创建 Pod借助 PostgreSQL 的物理流复制恢复数据随后连同 Pod 一起销毁旧 PVC。这一场景通常不推荐除非数据库体积很小且重新克隆一个新的 PostgreSQL 实例比等待原节点恢复更快。需要注意该行为不适用于单实例且reusePVC为false的集群详见下文。维护窗口下 PDB 的临时移除逻辑从 cluster_create.go 的调和逻辑可以确认当维护窗口进行中且reusePVC开启时replica 的 PDB 不会被强制执行若此时集群为单实例primary 的 PDB 也会一并移除——否则用户无法把工作负载从底层节点驱逐出去。别忘了--delete-emptydir-data:::note 执行kubectl drain时需要附加--delete-emptydir-data选项。 不必担心它指向的是 operator 内部使用的另一个卷并非 PostgreSQL 数据目录。 :::即正确用法为kubectl drain node --delete-emptydir-data --ignore-daemonsets用enablePDB完全接管 PDB 管理:::info 重要提示 PodDisruptionBudget 的管理可以通过将.spec.enablePDB字段设为false来整体禁用。此时 operator 不再创建PodDisruptionBudget并且会删除之前已创建的资源。 :::这一行为由 cluster_create.go 中的deletePodDisruptionBudgetsIfExist路径保证GetEnablePDB()返回false时直接进入删除逻辑。单实例集群 reusePVC: false数据安全的红线:::info 重要提示 官方建议始终创建多于一个实例的集群以保证高可用high availability。 :::在单实例集群中删除唯一一个 PostgreSQL 实例意味着所有数据丢失。因此即使处于维护模式CloudNativePG 也会阻止用户 drain 这类实例所在的节点——这是 operator 主动守护数据安全的硬性边界。不过当确实需要对这类节点进行维护时你有两个选择启用reusePVC接受停机时间在其他节点上复制实例并执行一次 primary 切换switchover。方案一接受停机只要你的环境能够接受数据库服务的停机操作就很简单将nodeMaintenanceWindow设置为inProgress: true且reusePVC: true。这样实例会被删除并在原始 PVC 可用时立即重建例如节点本地存储场景下节点一恢复即可复用 PVC。对应的 YAML 示意如下apiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: name: single-instance spec: instances: 1 nodeMaintenanceWindow: inProgress: true reusePVC: true storage: size: 20Gi方案二无停机仅切换耗时否则你需要扩容集群在其他节点创建新实例将新实例提升为 primary然后关闭正在维护节点上的原实例。此方案唯一的停机时间就是switchover 的耗时。推荐的操作步骤如下**Cordon封锁**当前实例所在的节点kubectl cordon node扩容集群到 2 个实例耗时取决于数据库大小例如编辑 Cluster 将spec.instances从1改为2新实例运行起来后由于当前 primary 运行在已被 cordon 的节点上operator 会自动执行 switchover缩容集群回到单实例此时旧实例会被删除原 primary 所在节点现在可以成功 drain而新 primary 已运行在新节点上。整个过程把停机窗口压缩到一次切换的时间是本地存储、单实例场景下的推荐路径。总结一张维护策略决策表结合前文可以为不同场景总结出如下决策要点集群类型存储类型推荐配置drain 可行性生产集群≥3 实例网络共享存储保持默认enablePDB: true直接 drainoperator 自愈生产集群≥3 实例节点本地存储保持 PDB逐节点 drain必要时使用维护窗口一次关闭一个 replicaprimary 先切换生产集群单实例节点本地存储扩容→自动切换→缩容或reusePVC: true接受停机需先处理 primary否则被阻止开发/测试集群任意enablePDB: false可直接 drain维护的最终目标是在Kubernetes 自愈能力、PostgreSQL 高可用与可控的停机风险之间取得平衡。理解 PDB 的默认行为、enablePDB开关以及nodeMaintenanceWindow含inProgress/reusePVC的语义是安全执行每一次节点升级的基础。更多字段细节可查阅 CloudNativePG API 参考 中关于ClusterSpec的说明以及仓库中的类型定义 cluster_types.go 与控制器实现 cluster_create.go。【免费下载链接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.项目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pg创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考