【问题标题】:Active-Passive Jenkins Setup in KubernetesKubernetes 中的主动-被动 Jenkins 设置
【发布时间】:2019-03-31 16:23:32
【问题描述】:

我们计划使用 kubernetes 在容器平台中设置高可用 Jenkins。我们正在考虑设置一个活动主机和另一个处于待机模式的主机。 Jenkins 数据量将存储在两个主容器之间共享的全局存储中。

如果活动主服务器不可用,则请求应故障转移到其他主服务器。从站应该只与活动主站通信。

我们如何在 Kubernetes 中以主动/被动模式完成 Jenkins HA 设置。请提供您的建议。

我们希望通过下面的链接实现如下图所示

https://endocode.com/img/blog/jenkins-ha-setup_concept.png

【问题讨论】:

    标签: jenkins kubernetes high-availability active-passive


    【解决方案1】:

    这与 IMHO 在 Kubernetes 中运行应用程序的方式相矛盾。主动/被动是上个世纪的概念。

    改为为 Jenkins 部署配置运行状况检查。如果失败,Kubernetes 将自动终止该任务并启动一个替换(在检测到活动的任务不健康后仅几秒钟即可使用)。

    【讨论】:

    • 要求一个jenkins master在active模式,一个在standby模式。
    • 制定错误的要求..也许他们应该更好地要求替代品在 X 秒内变为活动状态,而不是描述诸如主动/被动实现之类的技术细节。
    • 参考我们想要实现的设计。查看问题中的链接
    • 但我猜这并不是在考虑 K8s 的情况下制作的。这在较低的基础设施层解决了这个问题。
    • @StephenKing 依赖 K8S 故障转移,我们应该有持久卷,所以如果 jenkins 实例在其他节点上获取计划它应该有可用的数据,我们如何在节点之间同步数据?外部存储选项不可用,只有三个节点,每个节点都有备用磁盘。
    【解决方案2】:

    在模拟容器的主动/被动设置方面一直存在积极考虑,但请注意,作为产品功能,这确实不是必须具备的,因此不是内置的。这很可能作为 OOB 功能集成实现,您可以在其中集成必须精心设计您的应用程序以至少执行以下操作:

    1. 一般leader选举(用于master选择和流量路由, 也许是一个边车容器来进行选举和消息路由)
    2. 使 liveness/readiness 探测检测例程(和故障转移逻辑)修补失败范例下的所有 pod,不再通过任何 pod 选择器等式选择
    3. 如果发生另一次故障转移,您仍然必须确保另一个标签补丁(这次跨越新旧 pod)来更新 pod 元数据(也称为标签)

    如果您正在寻找最简单的东西,配置 liveness/readiness 探针可能会为您解决问题。与往常一样,您应该避免使用临时补丁来大规模改变 pod 标签以进行角色选择

    https://github.com/kubernetes/kubernetes/issues/45300

    【讨论】:

      【解决方案3】:

      如果您对固执己见的框架感到满意,那么 JenkinsX 可能会帮助您。它默认带有您需要的功能。

      【讨论】:

        猜你喜欢
        • 2019-08-20
        • 1970-01-01
        • 1970-01-01
        • 2018-09-14
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2018-11-16
        • 1970-01-01
        相关资源
        最近更新 更多