k8s~通过探针实现服务的平滑部署
对于k8s上的pod来说,它由于容器组成,它是k8s里的最基本单位,你可以通过service来实现对pod的负载均衡,对外提供服务,而可以不需要传统的nginx做负载了,当然如果你的域名是公开的,不需要云上的负载服务的,也可以直接使用k8s的ingress来实现。
参考:https://www.bluematador.com/blog/kubernetes-deployments-rolling-update-configuration
不能平滑发布
pod在部署过程中,会出现pod未准备好的情况,而如果这时你的外布负载直接打过来,就出现了503的问题,当然如果你又加了一层nginx,可以避免这种问题。
怎么判断Pod是否Ready
Kubernetes自身实现了一个叫做Ready Pod的概念来辅助滚动更新。具体来说就是,ReadinessProbe (就绪探针)可以使Deployment逐步更新Pod,同时也可以使用它控制何时才能进行滚动更新,Service也使用它来确定应该将哪些Pod包含在服务的Endpoints中。
readinessProbe容器中的探针
containers:
- name: keycloak-controller
image: jboss/keycloak:14.0.0
readinessProbe: #探针功能,服务启动成功后再加到service的endpoints中
periodSeconds: 10 #每10秒检测一次
initialDelaySeconds: 5 #pod启动后,延时5秒
httpGet:
path: /auth/realms/master/
port: 8080
上面的配置中,我们探针是容器里的api接口/auth/realms/master/,我们每10秒去检查一次它的状态,当成功之后,延时5秒加入到service的Endpoints中,以便对外提供服务。
滚动部署
我们按说3个pod副本来说,我们让它1个1个的pod进行替换,下面代码体现了这个逻辑
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
特别注意
对于探针检查和service里的能数publishNotReadyAddresses:true
是冲突的,当你配置它之后,你的探针是无效的,因为无论你的容器是否就绪,当publishNotReadyAddresses
为true
时,都会加入到service的endpoints里,这一点要非常注意。
有些时间需要把publishNotReadyAddresses设为true,当你的多个pod在就绪之前就直接相互通讯时,例如使用jgroup进行组建集群时,你就需要把publishNotReadyAddresses改为true,否则你的集群也起不来。
- 最后进行测试之后,发现也是有500毫秒的服务不可用状态
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
· 上周热点回顾(2.17-2.23)
2017-11-30 Git~分支真的很轻
2012-11-30 Js-$.extend方法使方法参数更灵活