Azure上的Kubernetes-活动性和就绪性探针失败-活动性探针因连接失败:连接被拒绝

时间:2020-10-14 04:56:12

标签: azure kubernetes azure-aks kubernetes-health-check health-check

我是Azure部署,kubernetes和HA实施的新手。当我在应用程序部署中实施运行状况探针时,运行状况探针将会失败,并且当我尝试通过URL访问应用程序时,最终会遇到503(内部服务器错误)或502(错误网关)错误。删除健康状况探针后,我可以使用其URL成功访问该应用程序。

在实施运行状况探测器时,我使用以下yaml部署配置,该配置由Azure devops管道使用。该应用需要不到5分钟的时间才能使用,因此我将运行状况探测器的initialDelaySeconds设置为300s

apiVersion: apps/v1
kind: Deployment
metadata:
   name: myApp
spec:
   ... 
   template:
     metadata:
       labels:
         app: myApp
     spec:
        ...
        containers:
          - name: myApp
            ...
            ports:
              - containerPort: 5000          
            ...
            readinessProbe:
              tcpSocket:
                  port: 5000
              initialDelaySeconds: 300
              periodSeconds: 5
              successThreshold: 1
              failureThreshold: 3
            livenessProbe:
               tcpSocket:
                  port: 5000
               periodSeconds: 30 
               initialDelaySeconds: 300
               successThreshold: 1
               failureThreshold: 3

...

执行部署并描述Pod时,在输出底部的“事件”下看到以下内容:

  Type     Reason     Age                   From                             Message
  ----     ------     ----                  ----                             -------
  Warning  Unhealthy  2m1s (x288 over 86m)  kubelet, aks-vm-id-appears-here  Readiness probe failed: dial tcp 10.123.1.23:5000: connect: connection refused

(这令人困惑,因为它指出年龄为2m1s-但initialDelaySeconds大于此值-因此我不确定为什么它将其报告为年龄)

就绪探测器随后因相同的错误而失败。该IP地址与我的广告连播的IP地址匹配,我在广告连播说明中的Containers下看到了该地址:

Containers:
....
Port:           5000/TCP

活动性和就绪性探针的失败导致吊舱不断终止并重新启动。

该应用具有默认的index.html页面,因此,我相信如果健康状况探针能够连接,它将收到200响应。

由于运行状况探测失败,因此未将Pod IP分配给端点对象,因此也没有针对该服务分配

如果我从部署中注释掉readinessProbelivenessProbe,则当我通过浏览器使用URL时,应用程序将成功运行,并且pod IP被成功分配为该服务可以使用的端点与交流。端点地址的格式为10.123.1.23:5000-即端口5000似乎是Pod的正确端口。

我不明白为什么健康探测器无法连接?在我看来,应该尝试在看起来像10.123.1.23:5000的IP上进行连接是正确的。

打开该端口可能要花费300秒以上的时间,但是我不知道有什么方法可以检查该端口。如果我在Pod上输入bash会话,则watch不可用(我读到watch ss -lnt可用于检查端口的可用性)。

以下答案建议增加initialDelaySeconds,但我已经尝试过-https://stackoverflow.com/a/51932875/1549918

我看到了这个问题-但是资源利用率(例如CPU / RAM)不是问题 Liveness and readiness probe connection refused

更新

如果我从吊舱的副本卷曲到https://10.123.1.23:5000,则会收到类似的错误(Failed to connect to ...the IP.. port 5000: Connection refused)。为什么会失败?我读到的一些东西暗示,尝试从另一个Pod进行此连接可能也表明健康探针的可达性。

2 个答案:

答案 0 :(得分:1)

如果不确定您的应用程序是否正确启动,请用已知良好的图像替换它。例如httpd

将端口更改为80,将图像更改为httpd。

您可能还希望增加运行状况检查的超时,因为它默认为timeoutSeconds = 5的1秒

此外,如果您的图像是Web应用程序,则最好使用a http probe

答案 1 :(得分:0)

你的陈述

<块引用>

应用程序有一个默认的 index.html 页面,所以我相信如果它能够连接,健康探测器应该收到 200 响应。

不正确。

您正在执行 tcpSocket 检查。尝试切换到:

  livenessProbe:
    failureThreshold: 3
    httpGet:
      path: /
      port: 5000
      scheme: HTTP