NGINX 502不良网关在Kubernetes中使用单个复制时

Question

我需要在零停机时间内部署HTTP应用程序。我也有使用单pod(replica = 1(的限制。但是问题是当我做一些HTTP请求时，当我对K8S POD进行了一些更改时，有502个糟糕的网关。

我参考以下两个问题[1] [2]，但是当我有一个以上的复制品时，这些问题正常。对于单个复制品，Nginx Ingress仍然有少量的停机时间，小于1毫秒。

根据上述问题的答案[1] [2]。

 spec:
  strategy:
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 0
    type: RollingUpdate
    ...
    spec:
        ....
        lifecycle:
          preStop:
            exec:
              command:
              - sleep
              - "30"

请注意，我有安装在此部署的配置地图。我不确定这会影响这种停机时间。

另外，我指的是这两个博客[3] [4]，但它们也没有解决我的问题。但是，当我推荐此博客[4]时，它表明K8即使使用单个复制品也可以达到零停机时间。不幸的是，在[4]中，他没有使用Ingress-nginx控制器。

简而

参考

1 https://github.com/kubernetes/ingress-nginx/issues/489

2 https://github.com/kubernetes/ingress-nginx/issues/322

3 https://blog.sebastian-daschner.com/entries/zero-downtime-updates-kubernetes

4 http://rahmonov.me/posts/zero-downtime-deployment-with-kubernetes/

Answer 1

我想您的单pod限制是在运行时，而不是在升级期间，否则您将无法实现目标。

我的看法是您的滚动升级策略很好，您可以添加一个poddistruptipionbudget来管理中断以确保至少有1个POD。

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: sample-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      <your_app_label>

另一个非常重要的是探针，根据文档：

kubelet使用LIVISE探针来知道何时重新启动容器。例如，Livices探针可能会陷入困境，在该应用程序正在运行，但无法取得进展。在这样的状态下重新启动容器可以帮助使应用程序更可用。

kubelet使用准备探针来知道何时准备好开始接受流量。当所有容器都准备就绪时，将其视为准备就绪。此信号的一种用途是控制哪些POD用作服务的后端。当吊舱准备就绪时，将其从服务负载平衡器中删除。

您应该设置LIVISE探测器，但是最重要的是，只有当您的新吊舱真的准备好接受新连接时，才能返回成功响应将在新的连接之前被销毁。

Answer 2

nginx作为反击代理，如果后端的IP地址没有更改，则能够处理0停机时间，但是在您的情况下，我认为只有1个复制品的要求和安装的卷总是会使下降过程更慢，无法实现0停机时间，因为如果您在新豆荚上安装相同的体积开始唤醒过程。

在您引用的博客文章中解释如何实现这一目标，该示例不使用卷，而是使用非常小的图像，使拉动过程变得非常快。

我建议您研究自己的数量需求，并尝试将其作为薄弱的过程中的阻止。