k8s资源之PodDisruptionBudget

 欢迎关注我的公众号:

 目前刚开始写一个月,一共写了18篇原创文章,文章目录如下:

istio多集群探秘,部署了50次多集群后我得出的结论

istio多集群链路追踪,附实操视频

istio防故障利器,你知道几个,istio新手不要读,太难!

istio业务权限控制,原来可以这么玩

istio实现非侵入压缩,微服务之间如何实现压缩

不懂envoyfilter也敢说精通istio系列-http-rbac-不要只会用AuthorizationPolicy配置权限

不懂envoyfilter也敢说精通istio系列-02-http-corsFilter-不要只会vs

不懂envoyfilter也敢说精通istio系列-03-http-csrf filter-再也不用再代码里写csrf逻辑了

不懂envoyfilter也敢说精通istio系列http-jwt_authn-不要只会RequestAuthorization

不懂envoyfilter也敢说精通istio系列-05-fault-filter-故障注入不止是vs

不懂envoyfilter也敢说精通istio系列-06-http-match-配置路由不只是vs

不懂envoyfilter也敢说精通istio系列-07-负载均衡配置不止是dr

不懂envoyfilter也敢说精通istio系列-08-连接池和断路器

不懂envoyfilter也敢说精通istio系列-09-http-route filter

不懂envoyfilter也敢说精通istio系列-network filter-redis proxy

不懂envoyfilter也敢说精通istio系列-network filter-HttpConnectionManager

不懂envoyfilter也敢说精通istio系列-ratelimit-istio ratelimit完全手册

 

————————————————

PodDisruptionBudget:

pod 中断 预算

终止pod前 通过labelSelector机制获取正常运行的pod数目的限制,目的是对主动驱逐的保护措施。

特性:

PDB指定一个pod集合在一段时间内存活的最小实例数量或者百分比

作用于一组被同一个控制器管理的pod。例如:RS或者statefulset

使用PodDisruptionBudget控制器本身无法真正保障指定数量或者百分比的pod存活,PodDisruptionBudget控制器只能保证POD主动逃离的情况下业务不中断或者业务SLA

降级场景局限于:主动驱逐

一个 PDB 对应一个控制器创建的 Pod,例如,DeploymentReplicaSetStatefulSet

maxUnavailable 0%(或0)或者 minAvailable 100%(或与控制器的 .spec.replicas 相等)将阻止节点排空任务

舍入:

如果指定这些值为一个百分数,其计算结果可能不会正好是一个整数。例如,假设有 7 PodminAvailable 设置为 50%,你将很难判断,到底是 3 个还是 4 Pod 必须始终保持可用。Kubernetes 将向上舍入(round up to the nearest integer),因此,此处必须有 4 Pod 始终可用。

示例:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 8
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

[root@master01 pdb]# cat pdb-avaliable.yaml 
apiVersion: policy/v1beta1  
kind: PodDisruptionBudget  
metadata:  
 name: nginx-pdb  
spec:  
 minAvailable: 7  
 selector:  
   matchLabels:  
     app: nginx


[root@master01 pdb]# cat pdb-avaliable-noevit.yaml 
apiVersion: policy/v1beta1  
kind: PodDisruptionBudget  
metadata:  
 name: nginx-pdb  
spec:  
 minAvailable: 100%  
 selector:  
   matchLabels:  
     app: nginx

[root@master01 pdb]# cat pdb-unavaliable.yaml 
apiVersion: policy/v1beta1  
kind: PodDisruptionBudget  
metadata:  
 name: nginx-pdb  
spec:  
 maxUnavailable: 1  
 selector:  
   matchLabels:  
     app: nginx

[root@master01 pdb]# cat pdb-unavaliable-noevit.yaml 
apiVersion: policy/v1beta1  
kind: PodDisruptionBudget  
metadata:  
 name: nginx-pdb  
spec:  
 maxUnavailable: 0% 
 selector:  
   matchLabels:  
     app: nginx

命令:

Kubectl cordon

Kubectl uncordon

kubectl drain

kubectl drain foo –force

kubectl drain foo --grace-period=900

Kubectl drain 192.168.198.156 --ignore-daemonsets --delete-local-data

kubectl create pdb my-pdb --selector=app=nginx --min-available=50%

kubectl create poddisruptionbudget my-pdb --selector=app=rails --min-available=1

Kubectl create pdb my-pdb –selector=app=nginx --max-unavailable=50%

Kubectl create pdb my-pdb –selector=app=nginx --max-unavailable=1

<think>好的,用户让我详细解释Kubernetes中的PodDisruptionBudget(PDB)的使用场景和生产实践。首先,我需要回忆一下PDB的基本概念,它是用来确保在自愿中断(比如节点维护或集群升级)时,保持一定数量的Pod可用。用户可能是在管理生产环境时遇到了需要保证应用可用性的问题,或者他们正在准备进行集群维护,想要了解如何正确配置PDB来避免服务中断。 接下来,我需要考虑用户的使用场景。他们可能运行的是关键业务应用,比如在线支付、数据库或者微服务,这些应用需要高可用性。用户可能对PDB的具体配置方法和实际应用中的注意事项不太清楚,特别是如何设置minAvailable和maxUnavailable这两个参数。另外,生产实践中常见的操作,比如滚动更新、节点维护、集群扩缩容等,都是用户关心的点。 然后,我需要思考用户的潜在需求。他们可能不仅想知道PDB是什么,还想了解如何在实际操作中应用它,包括最佳实践和常见错误。例如,用户可能不知道PDB不能防止非自愿中断(如硬件故障),或者如何根据应用类型选择合适的策略。此外,用户可能对StatefulSet和Deployment在使用PDB时的区别感兴趣,或者如何处理多版本应用的情况。 还要考虑用户可能的误解。比如,他们可能认为设置PDB就能完全避免服务中断,但实际上它只能管理自愿中断。同时,用户可能没有意识到PDB需要与应用副本数合理配合,比如设置minAvailable超过副本数的一半,否则可能导致无法驱逐Pod的问题。 在组织回答时,需要结构清晰,分点讲解。首先介绍PDB的作用和核心概念,然后详细说明使用场景,比如滚动更新、节点维护等。接着讲解生产实践中的配置策略、注意事项,并结合具体例子说明如何操作。最后总结最佳实践,帮助用户全面理解并正确应用PDB。 还要注意用户的身份可能是运维人员或开发人员,他们需要技术细节但也要避免过于复杂的术语。因此,回答需要简明扼要,结合实际操作命令和示例,让用户能够快速应用。同时,提醒用户常见的陷阱,比如与HPA的协同问题,或者资源不足时的处理,确保他们在实际使用中避免这些问题。 最后,确保回答覆盖了用户可能关心的所有方面,包括PDB的局限性、如何验证配置是否生效,以及如何处理多可用区部署的情况。这样用户能有一个全面的认识,并能够在生产环境中正确使用PDB来保障应用的稳定性。</think>以下是关于Kubernetes **PodDisruptionBudget(PDD)** 的全面解析,涵盖核心原理、使用场景、生产实践及注意事项: --- ### 一、什么是PodDisruptionBudget(PDD)? **定义** PDD是Kubernetes中用于**保护应用在自愿中断(Voluntary Disruptions)期间可用性**的资源对象,通过限制同时终止的Pod数量,确保业务不中断。 **核心概念** - **自愿中断**(需PDD控制): 人为触发的操作,如节点维护、集群升级、驱逐Pod(`kubectl drain`)等 - **非自愿中断**(PDD无法控制): 硬件故障、网络中断等意外事件 --- ### 二、核心使用场景 #### 场景1:滚动更新/升级 - **问题**:K8s默认滚动更新策略可能导致过多Pod同时被终止 - **解决方案**: 配置PDD限制每次更新的Pod数量,确保服务最小可用实例数 ```yaml apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: myapp-pdb spec: minAvailable: 2 # 至少保持2个Pod可用 selector: matchLabels: app: myapp ``` #### 场景2:节点维护 - **问题**:执行`kubectl drain`时可能一次性驱逐所有Pod - **解决方案**: 通过PDD限制单次驱逐的Pod数量,确保剩余Pod能继续服务 ```yaml spec: maxUnavailable: 1 # 最多允许1个Pod不可用 ``` #### 场景3:集群缩容(Cluster Autoscaler) - **问题**:自动缩容可能删除仍有Pod运行的节点 - **解决方案**: PDD与Cluster Autoscaler协同,确保缩容时保留足够Pod --- ### 三、生产实践指南 #### 1. 配置策略 | 参数 | 适用场景 | 公式参考 | |------------------|-------------------------|--------------------------| | `minAvailable` | 需保证最小可用实例数 | >= 总副本数 × 50% + 1 | | `maxUnavailable` | 允许最大不可用比例 | <= 总副本数 × 20% | **示例**: 若Deployment有10个副本,建议: ```yaml minAvailable: 6 # 保证至少60%在线 # 或 maxUnavailable: 2 # 最多允许20%离线 ``` #### 2. 与控制器协同 - **Deployment/StatefulSet**: 确保PDD的`selector`与Pod标签匹配 ```yaml selector: matchLabels: app: myapp ``` - **DaemonSet**: 通常无需PDD,因为每个节点只有一个Pod #### 3. 多可用区部署 - **策略**: 结合`topologySpreadConstraints`,在PDD中设置跨可用区的最小可用实例 ```yaml topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule ``` #### 4. 关键操作命令 ```bash # 查看PDD状态 kubectl get pdb # 模拟驱逐测试 kubectl drain <node> --ignore-daemonsets --disable-eviction ``` --- ### 四、注意事项与陷阱 #### 1. 常见错误 - ❌ 设置`minAvailable > 副本数` → PDD永远无法满足 - ❌ 未覆盖所有Pod副本 → 实际保护不生效 - ❌ 与HPA(Horizontal Pod Autoscaler)冲突 → 缩容被PDD阻塞 #### 2. 高级技巧 - **分级保护**:为不同优先级应用设置不同PDD ```yaml priorityClassName: high-availability ``` - **金丝雀发布**:配合PDD逐步更新Pod - **资源预留**:在节点预留资源以应对PDD约束 --- ### 五、最佳实践总结 1. **副本数要求**:应用至少运行3个副本,否则PDD无法发挥价值 2. **更新策略**:滚动更新时PDD与`maxSurge`/`maxUnavailable`配合使用 3. **监控告警**:监控PDD状态(`kubectl describe pdb`中的`Disruptions Allowed`) 4. **混沌测试**:使用Chaos Mesh等工具验证PDD有效性 --- ### 附:典型配置模板 ```yaml apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: critical-service-pdb spec: minAvailable: 80% # 按百分比配置更灵活 selector: matchLabels: tier: critical env: production ``` 通过合理配置PDD,可显著提升生产环境的稳定性。需要根据实际业务需求动态调整参数,并定期进行故障演练。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

hxpjava1

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值