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是冲突的,当你配置它之后,你的探针是无效的,因为无论你的容器是否就绪,当publishNotReadyAddressestrue时,都会加入到service的endpoints里,这一点要非常注意。

有些时间需要把publishNotReadyAddresses设为true,当你的多个pod在就绪之前就直接相互通讯时,例如使用jgroup进行组建集群时,你就需要把publishNotReadyAddresses改为true,否则你的集群也起不来。

  • 最后进行测试之后,发现也是有500毫秒的服务不可用状态
posted @   张占岭  阅读(961)  评论(0编辑  收藏  举报
编辑推荐:
· 一个奇形怪状的面试题: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方法使方法参数更灵活
点击右上角即可分享
微信分享提示