k8s~pod单副本的平滑部署
  2xk0JyO908yA 2024年04月11日 26 0

如果你的服务器资源紧张,pod可能只能是单副本了,这时在进行平滑的滚动部署时,应该如何配置呢?总不能在部署期间503吧,这是不能接受的!

maxUnavailable来配置不可用数量

我们可以在spec.strategy.strategy.rollingUpdate中,将不可用数maxUnavailable改成0即可实现平滑部署,配置如下:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: keycloak-deployment
  namespace: kc
spec:
  replicas: 1
  #滚动升级策略
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0 #当副本为1时,我们采用这个配置,即不允许有多余的pod

如果是多个副本,你也可以通过rollingUpdate中的maxSurge来控制可用节点数,maxUnavailable来控制不可用数,如下面的配置,在副本为3个时,可用数至少为1个,不可用也是0个,相当于1个1个的副本去启动,整个deployment对外始终是3个可用的pod。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: keycloak-deployment
  namespace: kc
spec:
  replicas: 3
  #滚动升级策略
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

部署过程如图,1个副本时,在发布期间,也始终有1个是可用的

k8s如何探测pod启动了

readinessProbe 是 Kubernetes 中用来检查容器是否准备好接收流量的机制。通过配置 readinessProbe,Kubernetes 可以确保只有在容器完全就绪并能够处理请求时才会将流量引导到该容器。以下是关于 readinessProbe 的总结:

  1. 作用readinessProbe 用于确定容器是否已经准备好接收流量。如果容器的 readinessProbe 失败,Kubernetes 将不会将流量路由到该容器。

  2. 配置方式readinessProbe 可以通过 HTTP、TCP 或执行命令的方式进行配置。你可以指定一个 HTTP 请求路径、端口号或自定义命令,并设置相应的超时时间和周期。

  3. 成功条件readinessProbe 根据配置的方式来判断容器的就绪状态。例如,对于 HTTP 探测,返回状态码在200-399之间表示成功;对于 TCP 探测,连接成功即为成功;对于执行命令探测,返回值为0表示成功。

  4. 失败处理:当 readinessProbe 失败时,Kubernetes 不会将流量路由到该容器。容器可能会被标记为 Unready 状态,并从 Service 的负载均衡中剔除。

  5. 重试策略:如果 readinessProbe 失败,Kubernetes 将按照配置的间隔时间进行重试。只有当连续多次探测失败后,容器才会被认定为不可用。

  6. 应用场景:适用于需要一段时间来启动服务或加载数据的应用程序,以确保在容器完全就绪之前不接收流量。

  7. 常见配置:示例配置如下,包括 HTTP 探测、TCP 探测和执行命令探测:

    readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    

通过合理配置 readinessProbe,可以提高容器的稳定性和可靠性,确保应用程序在容器就绪后再接收流量,避免因为服务未完全启动而导致的请求失败。希望这个总结对你有所帮助。如果还有其他问题,请随时告诉我。

【版权声明】本文内容来自摩杜云社区用户原创、第三方投稿、转载,内容版权归原作者所有。本网站的目的在于传递更多信息,不拥有版权,亦不承担相应法律责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@moduyun.com

  1. 分享:
最后一次编辑于 2024年04月11日 0

暂无评论

推荐阅读
  2xk0JyO908yA   2024年04月11日   26   0   0 Kubernetes
  az2L92p17wYQ   29天前   26   0   0 Kubernetes
2xk0JyO908yA