Au trecut săptămâni de când am o mulțime de timeout când gcp lbs verifică ingress-nginx healthz în timp ce totul răspunde corect.
Am un cluster GKE cu sistem de operare Container Optimized și n1-standard-4 ca versiune de mașină și kubernetes v1.21.10-gke.2000
.
Iată nodurile mele:
kubectl top nr
NUME CPU(nuclee) CPU% MEMORY(octeți) MEMORY%
gke-xxx-gke-cluster0-xxx-gke-cluster0-0a2ef32c-6lj0 821m 20% 3683Mi 29%
gke-xxx-gke-cluster0-xxx-gke-cluster0-98567a10-pqk2 2302m 58% 4983Mi 40%
gke-xxx-gke-cluster0-xxx-gke-cluster0-cd892740-3v6m 83m 2% 852Mi 6%
Iată podurile și serviciile mele de ingress-nginx:
STAREA NUMELE GATA REINCEPE VARSTA
pod/nginx-ingress-controller-fnxlc 1/1 Alergare 0 65m
pod/nginx-ingress-controller-m4nq2 1/1 Alergare 0 67m
pod/nginx-ingress-controller-tb4gc 1/1 Rulare 0 66m
NUME TIP CLUSTER-IP EXTERN-IP PORT(E) Vârsta
service/nginx-ingress-controller NodePort EXPANSAT <niciun> 80:32080/TCP,443:32443/TCP 69d
service/nginx-ingress-controller-metrics ClusterIP EXPIRAT <niciun> 10254/TCP 69d
Iată valorile mele pentru cârmă ngress-nginx/ingress-nginx
versiune 4.1.0
:
ingressClassResource:
nume: nginx
activat: adevărat
implicit: fals
controllerValue: „k8s.io/ingress-nginx”
fel: DaemonSet
livenessProbe:
httpGet:
cale: „/healthz”
port: 10254
schema: HTTP
initialDelaySeconds: 10
perioadaSecunde: 10
timeoutSecunde: 1
Pragul de succes: 1
Pragul de eșec: 5
ReadinessProbe:
httpGet:
cale: „/healthz”
port: 10254
schema: HTTP
initialDelaySeconds: 10
perioadaSecunde: 10
timeoutSecunde: 1
Pragul de succes: 1
Pragul de eșec: 3
podAdnotations:
prometheus.io/scrape_metrics_app: „adevărat”
prometheus.io/scrape_metrics_port_app: „10254”
prometheus.io/scrape_metrics_port_name_app: metrics
resurse:
cereri:
CPU: 100 m
memorie: 120 Mi
serviciu:
activat: adevărat
adnotari:
cloud.google.com/backend-config: „{"ports": {"80":"security-policy"}}"
targetPorts:
http: http
https: https
tip: NodePort
nodePorts:
http: 32080
https: 32443
tcp:
8080: 32808
metrici:
port: 10254
# dacă acest port este schimbat, modificați healthz-port: în extraArgs: în consecință
activat: adevărat
priorityClassName: nginx-ingress
Admitere webhooks:
activat: fals
plasture:
priorityClassName: nginx-ingress
Configurația mea de backend:
---
apiVersion: scheduling.k8s.io/v1
fel: PriorityClass
metadate:
nume: nginx-ingress
valoare: 1000000
globalDefault: false
---
apiVersion: cloud.google.com/v1
fel: BackendConfig
metadate:
nume: securitate-politică
specificație:
timeoutSec: 60
conexiuneDrenare:
drainingTimeoutSec: 10
politică de securitate:
nume: „EXPULGAT”
control medical:
checkIntervalSec: 10
timeoutSec: 5
prag sănătos: 1
prag nesănătos: 2
port: 32080
tip: HTTP
requestPath: /healthz
---
apiVersion: networking.k8s.io/v1
fel: Intrare
metadate:
nume: nginx-ingress-controller-gke
adnotari:
kubernetes.io/ingress.global-static-ip-name: „EXPREDAT”
kubernetes.io/ingress.class: „gce”
specificație:
ingressClassName: nginx
defaultBackend:
serviciu:
nume: nginx-ingress-controller
port:
număr: 80
Regula mea pentru firewall:
permis:
- IPProtocol: tcp
porturi:
- „32080”
- '80'
creationTimestamp: „EXPREDAT”
Descriere: ''
regia: INGRESS
dezactivat: fals
id: „EXPANDAT”
fel: calcule#firewall
logConfig:
activare: fals
nume: REDACTED-allow-i-google-gke-health
reţea: https://www.googleapis.com/compute/v1/projects/REDACTED/global/networks/REDACTED
prioritate: 1000
selfLink: https://www.googleapis.com/compute/v1/projects/REDACTED/global/firewalls/REDACTED-allow-i-google-gke-health
sursă intervale:
- 130.211.0.0/22
- 35.191.0.0/16
targetServiceAccounts:
- EXTRACTAT
Serviciul meu de backend este sănătos:
---
backend: https://www.googleapis.com/compute/v1/projects/REDACTED/zones/europe-west1-b/instanceGroups/k8s-ig--REDACTED
stare:
stare de sănătate:
- healthState: SANATOS
exemplu: https://www.googleapis.com/compute/v1/projects/REDACTED/zones/europe-west1-b/instances/REDACTED
Adresa ip: EXTERGAT
port: 32080
fel: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/REDACTED/zones/europe-west1-c/instanceGroups/k8s-ig--REDACTED
stare:
stare de sănătate:
- healthState: SANATOS
exemplu: https://www.googleapis.com/compute/v1/projects/REDACTED/zones/europe-west1-c/instances/REDACTED
Adresa ip: EXTERGAT
port: 32080
fel: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/REDACTED/zones/europe-west1-d/instanceGroups/k8s-ig--REDACTED
stare:
stare de sănătate:
- healthState: SANATOS
exemplu: https://www.googleapis.com/compute/v1/projects/REDACTED/zones/europe-west1-d/instances/REDACTED
Adresa ip: EXTERGAT
port: 32080
fel: compute#backendServiceGroupHealth
Proxy-urile mele http/https țintă sunt OK.
Problema este că, de la GKE 1.21, am mult timp de expirare a verificărilor de sănătate de la google lb:
{
"insertId": "120vrdac2cf",
„jsonPayload”: {
„healthCheckProbeResult”: {
"healthCheckProtocol": "HTTP",
"healthState": "NESĂNĂTOS",
"previousHealthState": "SĂNĂTOS",
"probeResultText": "Răspuns HTTP: , Eroare: Timeout în așteptare pentru conectare",
"probeSourceIp": "35.191.13.216",
"ipAddress": "EXPURAT",
"probeCompletionTimestamp": "2022-04-27T15:40:52.868912018Z",
"previousDetailedHealthState": "SĂNĂTOS",
"targetIp": "EXPULGAT",
"detailedHealthState": "TIMEOUT",
"responseLatency": "5.001074s",
„targetPort”: 32080,
"probeRequest": "/healthz"
}
},
"resursa": {
"type": "gce_instance_group",
„etichete”: {
„instance_group_name”: „k8s-ig--d350a72156e88e7d”,
„instance_group_id”: „7274987390644036118”,
"locație": "europe-west1-c",
"project_id": "EXPREDAT"
}
},
„stamp”: „2022-04-27T15:40:53.307035382Z”,
"severity": "INFO",
„logName”: „projects/REDACTED/logs/compute.googleapis.com%2Fhealthchecks”,
„receiveTimestamp”: „2022-04-27T15:40:54.568716762Z”
}
Iată o captură de ecran cu toate erorile:
erori de verificare a stării de sănătate
Nu am probleme de firewall.
De la un nod, nu există probleme de verificare a stării de sănătate:
în timp ce adevărat; do curl -m 2 -o /dev/null -sw "%{http_code} %{time_total}s\n" 0:32080/healthz; Terminat
200 0,000984s
200 0,000845s
200 0,000704s
200 0,002411s
200 0,001235s
200 0,000784s
200 0,001471s
200 0,000498s
Răspunsul http este întotdeauna 200.
Toate acestea înseamnă că atât gke, cât și pod-urile sunt sănătoase. Dacă păstăile nu au fost sănătoase, voi avea câteva reporniri pe care nu le am deloc.
Verificările de sănătate a capsulelor mele răspund întotdeauna în milisecunde.
Dar dintr-un motiv necunoscut, am o mulțime de probleme de sănătate Timeout în așteptare pentru conectare
care provoacă probleme de trafic pe site-ul meu.
În timpul depanării, nu am trafic pe site-ul meu.
Nu-mi amintesc să fi avut probleme cu GKE 1.19/1.20
. Desigur, am încercat multe versiuni de 1.21, dar tot nu am avut noroc.
Am trecut de la ingress-nginx 4.0.16
la 4.1.0
dar problema este încă prezentă.
Am crescut, de asemenea, intervalul de verificare a stării de sănătate și timeout, dar aceeași problemă.
M-am gândit că poate nginx își reîncarcă configurația de multe ori, dar de fapt nu este cazul, deoarece în jurnalele sunt aproape la fel:
nginx-ingress-controller-fnxlc controller I0427 16:10:38.352350 8 event.go:285] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"nginx-ingress", Name:"nginx-ingress-controller- gke", UID:"45baf918-c5b9-499e-9930-b6e5d03aa38e", APIVersion:"networking.k8s.io/v1", ResourceVersion:"83550719", FieldPath:""}): tip: „Normal” motiv: „ Sincronizare' Programat pentru sincronizare
Are cineva aceeasi problema?
Orice ajutor?