我已經實作了一個 gRPC 服務，將它構建到一個容器中，并使用 k8s（特別是 AWS EKS）作為 DaemonSet 部署它。
Pod 啟動并很快進入 Running 狀態，但需要很長時間，通常是 300 秒，才能訪問實際服務。
其實我跑去kubectl logs列印Pod的日志的時候，很長一段時間都是空的。
我在服務一開始就記錄了一些東西。事實上，我的代碼看起來像
package main
func init() {
log.Println("init")
}
func main() {
// ...
}
所以我很確定當沒有日志時，服務還沒有啟動。
我知道 Pod 正在運行和它內部的實際行程正在運行之間可能存在時間間隔。然而，300s 對我來說看起來太長了。
此外，這是隨機發生的，有時服務幾乎立即準備就緒。順便說一句，我的運行時影像基于chromedp headless-shell，不確定它是否相關。
誰能提供一些有關如何除錯和定位問題的建議？非常感謝！
更新
我沒有設定任何準備探測器。
運行kubectl get -o yaml我的 DaemonSet 給出
apiVersion: apps/v1
kind: DaemonSet
metadata:
annotations:
deprecated.daemonset.template.generation: "1"
creationTimestamp: "2021-10-13T06:30:16Z"
generation: 1
labels:
app: worker
uuid: worker
name: worker
namespace: collection-14f45957-e268-4719-88c3-50b533b0ae66
resourceVersion: "47265945"
uid: 88e4671f-9e33-43ef-9c49-b491dcb578e4
spec:
revisionHistoryLimit: 10
selector:
matchLabels:
app: worker
uuid: worker
template:
metadata:
annotations:
prometheus.io/path: /metrics
prometheus.io/port: "2112"
prometheus.io/scrape: "true"
creationTimestamp: null
labels:
app: worker
uuid: worker
spec:
containers:
- env:
- name: GRPC_PORT
value: "22345"
- name: DEBUG
value: "false"
- name: TARGET
value: localhost:12345
- name: TRACKER
value: 10.100.255.31:12345
- name: MONITOR
value: 10.100.125.35:12345
- name: COLLECTABLE_METHODS
value: shopping.ShoppingService.GetShop
- name: POD_IP
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: status.podIP
- name: DISTRIBUTABLE_METHODS
value: collection.CollectionService.EnumerateShops
- name: PERFORM_TASK_INTERVAL
value: 0.000000s
image: xxx
imagePullPolicy: Always
name: worker
ports:
- containerPort: 22345
protocol: TCP
resources:
requests:
cpu: 1800m
memory: 1Gi
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
- env:
- name: CAPTCHA_PARALLEL
value: "32"
- name: HTTP_PROXY
value: http://10.100.215.25:8080
- name: HTTPS_PROXY
value: http://10.100.215.25:8080
- name: API
value: 10.100.111.11:12345
- name: NO_PROXY
value: 10.100.111.11:12345
- name: POD_IP
image: xxx
imagePullPolicy: Always
name: source
ports:
- containerPort: 12345
protocol: TCP
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /etc/ssl/certs/api.crt
name: ca
readOnly: true
subPath: tls.crt
dnsPolicy: ClusterFirst
nodeSelector:
api/nodegroup-app: worker
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
volumes:
- name: ca
secret:
defaultMode: 420
secretName: ca
updateStrategy:
rollingUpdate:
maxSurge: 0
maxUnavailable: 1
type: RollingUpdate
status:
currentNumberScheduled: 2
desiredNumberScheduled: 2
numberAvailable: 2
numberMisscheduled: 0
numberReady: 2
observedGeneration: 1
updatedNumberScheduled: 2
此外，Pod 中有兩個容器。只有其中一個啟動例外緩慢，另一個總是很好。
uj5u.com熱心網友回復：
當您將 HTTP_PROXY 用于您的解決方案時，請注意它的路由與您的底層集群網路有何不同 - 這通常會導致意外超時。
uj5u.com熱心網友回復：
我已經發布了社區維基答案來總結這個主題：
正如gohm'c在評論中提到的：
容器“源”建立的連接是否總是必須通過 HTTP_PROXY，即使它正在連接集群中的服務 - 您是否認為可能因為代理而花費了很長時間？可以嘗試
kubectl exec -it <pod> -c <source> -- shcurl/wget 外部服務。
這是一個很好的觀察。請注意，某些連接可以直接進行，通過代理添加額外流量可能會導致延遲。例如，可能會出現瓶頸。您可以在檔案中閱讀有關使用 HTTP 代理訪問 Kubernetes API 的更多資訊。
此外，您還可以創建就緒探針以了解容器何時準備好開始接受流量。
當 Pod 的所有容器都準備就緒時，就認為 Pod 準備就緒。此信號的一個用途是控制哪些 Pod 用作服務的后端。當 Pod 未準備好時，它會從服務負載均衡器中洗掉。
kubelet 使用啟動探針來了解容器應用程式何時啟動。如果配置了這樣的探測器，它會禁用活動和就緒檢查，直到它成功，確保這些探測器不會干擾應用程式啟動。這可用于對緩慢啟動的容器進行活性檢查，避免它們在啟動和運行之前被 kubelet 殺死。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/317638.html
標籤：Kubernetes