當日志顯示 200 響應時，Kubernetes 活性探測失敗

Question

這個賞金已經結束。 此問題的答案有資格獲得+100聲望賞金。 賞金寬限期在19 小時后結束。 阿卡莎想引起更多人對這個問題的關注。

我正在使用https://pypi.org/project/django-health-check/在通過kubernetes_wsgi運行的 Django 應用程序中使用以下 YAML 進行健康檢查：

        livenessProbe:
          httpGet:
            path: /ht/
            port: 8020
            httpHeaders:
              - name: Host
                value: pdt-staging.nagyv.com
          initialDelaySeconds: 5
          periodSeconds: 10
          successThreshold: 1
          failureThreshold: 10
        readinessProbe:
          httpGet:
            path: /ht/
            port: 8020
            httpHeaders:
              - name: Host
                value: pdt-staging.nagyv.com
          initialDelaySeconds: 20
          timeoutSeconds: 5

pod 日志聲稱探測成功：

INFO:twisted:"-" - - [22/Jul/2022:22:11:07 +0000] "GET /ht/ HTTP/1.1" 200 1411 "-" "kube-probe/1.22"

同時，pod 事件否認了這一點：

Liveness probe failed: Get "http://10.2.1.43:8020/ht/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

...一段時間后，吊艙會定期重新啟動。

吊艙似乎功能齊全。 我也可以到達/ht/端點。 一切似乎都有效，除了活性探針。

我讀到了導致問題的緩慢響應，但這非常快。

知道問題可能是什么嗎？

Answer 1

python 容器通常取高 memory，一般給別人。 當您在 gunicorn 后面運行 django 時，容器默認使用大約 150M（對我而言）您的 memory（也取決於您的源代碼量[對我們而言，源代碼約為 50M]）。 它也取決於為您的應用程序安裝在容器上的 pip 包。 其良好的做法是提供通常比使用 gunicorn 的 django 高 20% 的 memory。 您還應該根據您在一個容器中處理的流量將timeoutSeconds增加到30或20 。 另外，容器上要么有readinessProbe要么livenessProbe ，這兩個探測器都會對容器產生過多的噪聲流量。 另外，使用 HPA 擴展您的應用程序，將應用程序擴展為 60% cpu 和 60% memory 以控制流量突發。

當您使用線程時，請注意 db 上的活動連接數。 您還將導出 django 健康指標（到prometheus ），這是應用程序功能的補充，請記住為此添加額外資源。 prometheus抓取也會在容器上產生過多的開銷，因此請明智地選擇 prometheus 抓取同一容器的數量和scrape_interval 。 您不希望您的容器僅服務於內部流量。

有關此問題的更多相關參考： https://github.com/kubernetes/kubernetes/issues/89898