【问题标题】:Kubernetes Deployment with Zero Down Time零停机时间的 Kubernetes 部署
【发布时间】:2018-10-05 02:45:31
【问题描述】:

作为 Kubernetes 概念的精益者,它们的工作和部署。我有几个我不知道如何实现的案例。我正在寻找实现它的建议或指南。

我正在使用谷歌云平台。下面描述当前的运行流程。推送到 google 源代码库会触发 Cloud Build,它会创建一个 docker 映像并将该映像推送到正在运行的集群节点。

案例 1:现在我希望在新的 pod 启动并运行时这样做。然后流量被路由到新的 Pod。杀死旧 pod,但在每个 pod 完成其运行请求之后。我希望实现零停机时间。

案例 2:如果运行的 pod 的空间达到 100 并且在 Debian 的情况下 inode 计数达到满容量会发生什么。 Kubernetes 会创建新的 pod 来管理吗?

案例 3:如何管理 pod 到数据库的连接限制?

【问题讨论】:

    标签: kubernetes google-cloud-platform


    【解决方案1】:
    1. 像其他答案一样使用Liveness and Readiness probes。基本上,将一个新的 pod 添加到服务池中,然后它只会在就绪探测通过后才提供流量。旧的 pod 从服务池中删除,然后排空,然后终止。这发生在滚动方式上,一次一个吊舱。

    2. 这实际上取决于集群的容量以及根据容器中容器的限制调度 pod 的能力。有关设置容器限制的更多信息,请参阅here。就 inode 限制而言,如果您在某个节点上达到它,kubelet 将无法在该节点上运行更多的 pod。 kubelet 驱逐管理器还有一个mechanism,其中使用最多的 inode 驱逐一些 pod。你也可以在 kubelet 上配置你的eviction thresholds

    3. 结合您的有状态应用程序配置,这将是操作系统级别的更多限制。您可以将此配置保存在ConfigMap 中。例如,在 MySql 中,选项是 max_connections

    【讨论】:

      【解决方案2】:

      我可以回答案例1,因为我自己做过。

      通过 readinessProbeslivelinessProbes 使用部署

      【讨论】:

        猜你喜欢
        • 2019-11-22
        • 1970-01-01
        • 2017-12-18
        • 1970-01-01
        • 1970-01-01
        • 2022-06-24
        • 2013-05-12
        • 1970-01-01
        • 2021-12-12
        相关资源
        最近更新 更多