前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Kubexit:一款轻松解决 Kubernetes Pod 中多容器有序部署的利器

Kubexit:一款轻松解决 Kubernetes Pod 中多容器有序部署的利器

作者头像
iMike
发布2023-12-26 15:36:25
2190
发布2023-12-26 15:36:25
举报
文章被收录于专栏:运维之美

设为「星标」,每天带你玩转 Linux !

本文译自:https://medium.com/@aditya.barik32/ordering-of-container-within-pod-a423d2e5ba52

摘要:本文讨论了在 Kubernetes Pod 中排序容器的需求,介绍了开源工具 Kubexit 实现容器的有序启动和终止,提高工作流灵活性。


为什么要在 Pod 中对容器进行排序?

在某些情况下,Pod 的排序可能是一个使用案例,我们需要确保某些容器在启动应用程序代码之前已经正常运行。假设我们有一个 Java 应用程序,需要一个数据库(Mysql)、缓存(Aerospike/Redis)和 Kafka 来提供流量。与此同时,我们还需要这些依赖关系是特定于实例或与应用程序堆栈本地关联的。在这种情况下,在 v1.28 版本之前,Kubernetes 没有提供一个开箱即用的解决方案。对于版本小于 1.28 的集群,没有正式的解决方法。为了缓解这个问题,我们有另一种不太知名的开源解决方法,叫做 Kubexit。

什么是 Kubexit?

Kubexit 是一个开源项目,旨在提供一种协调的方式来启动和终止 Pod 内的容器。

无法在这里使用InitContainer,因为在 initContainers 中声明的容器需要在通常容器(在Container部分声明的容器)开始之前完成(容器状态应为完成)。例如,如果在initContainer部分声明一个 MySQL 容器,那么 Pod 将卡在 Pod 初始化状态,因为在Container部分声明的其他容器将永远等待 initContainers 完成。

Kubexit 是一个二进制文件,我们需要在deployment.yamlinitContainer部分声明它,以用于内部容器排序。为了使 Kubexit 按预期工作,我们需要了解它是如何做到的。

Kubexit 允许您声明两种类型的依赖关系:

  1. 1. Birth Dependency:这种依赖关系允许您声明容器的出生顺序。
  2. 2. Death Dependency:这种依赖关系允许您声明容器的死亡顺序。

如何将 Kubexit 与 Deployment 集成?

为了在 Pod 内使用 Kubexit,我们需要配置一些东西。

  • • 在initContainer中声明 kubexit,以便它将二进制文件下载到 Pod 中。 /kubexit目录是我们在 Pod 内下载和存储二进制文件的地方。
  • • 我们还需要覆盖所有需要排序的容器的镜像 Pod的entrypoint和/或args。在entrypoint或args之前附加关键字kubexit。
  • • 我们需要在所有需要排序的容器上创建并挂载一个共享卷。 /graveyard是需要在参与排序的所有容器之间共享的目录。
  • • 还要定义其他配置,例如:
    • KUBEXIT_NAME:Kubexit 的容器名称。
    • KUBEXIT_BIRTH_DEPS:在当前容器启动之前需要正常运行的容器的名称(这可以是逗号分隔的列表)。在此声明的名称是在容器的KUBEXIT_NAME中声明的名称。

Kubexit 的工作原理

Kubexit 需要一个 ServiceAccount 和 Role 来监视 Pod 容器和共享卷。它监视 Pod 内的共享卷,使其能够确定容器的状态并通知其他容器是否存在依赖关系。为了实现这一点,必须在所有需要彼此协调的容器中挂载共享卷。

此配置允许 Kubexit 使用就绪探针监视容器状态。它通过将*/kubexit/kubexit(*二进制文件的路径)附加到容器的 entrypoint/args 中来完成这一点。当在启动时执行 entrypoint 时,Kubexit 开始通过就绪探针监视容器。一旦就绪探针确认容器已启动,Kubexit 通过在共享卷中放置一个墓碑(例如,在给定示例中的/graveyard 中)来标记相关容器的诞生。同样,当一个容器不存在时,Kubexit 添加一个墓碑以指示容器的消亡。其他容器然后可以监视共享卷,检查它们的依赖关系是否已启动,从而启动它们的启动过程。

注意:Kubernetes 已经为这样的用例提供了支持,在 v1.28 中我们可以将initContainer保持为SideCarContainers(链接[1])。

参考

  • • Kubexit GitHub 仓库[2]
  • • Kubernetes 官方博客文章[3]
引用链接

[1] 链接: https://kubernetes.io/blog/2023/08/25/native-sidecar-containers/ [2] Kubexit GitHub 仓库: https://github.com/karlkfi/kubexit [3] Kubernetes 官方博客文章: https://kubernetes.io/blog/2023/08/25/native-sidecar-containers

本文转载自:「云原生社区动态」,原文:https://url.hi-linux.com/kPj8q,版权归原作者所有。欢迎投稿,投稿邮箱: editor@hi-linux.com。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2023-12-26,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 奇妙的Linux世界 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 为什么要在 Pod 中对容器进行排序?
  • 什么是 Kubexit?
  • 如何将 Kubexit 与 Deployment 集成?
  • Kubexit 的工作原理
  • 参考
    • 引用链接
    相关产品与服务
    容器服务
    腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
    领券
    问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档