While trying to deploy my web application in the Kubernetes cluster (AKS) I see that my back end pods are not coming up , they keep on going into RESTART details below :
C:\Work\k8> kubectl get pods
NAME READY STATUS RESTARTS AGE
backend-mypod-backend-766b54f6dd-85v6v 0/1 CrashLoopBackOff 549 35h
backend-mypod-backend-766b54f6dd-j4fm9 0/1 CrashLoopBackOff 551 35h
backend-mypod-backend-766b54f6dd-vckbn 0/1 CrashLoopBackOff 549 35h when I do a describe Pod I see below Error for all the backend Pods:
Warning Unhealthy 26m (x5 over 28m) kubelet, aks-agentpool-33316079-vmss000000 Liveness probe failed: Get http://10.39.67.9:8800/api/healthtest: dial tcp 10.39.67.9:8800: connect: connection refused
Warning Unhealthy 8m10s (x65 over 28m) kubelet, aks-agentpool-33316079-vmss000000 Readiness probe failed: Get http://10.39.67.9:8800/api/healthtest: dial tcp 10.39.67.9:8800: connect: connection refused
Warning BackOff 3m10s (x59 over 19m) kubelet, aks-agentpool-33316079-vmss000000 Back-off restarting failed containerBelow is the section in the deployment yaml where we set the livnessProbe and readinessProbe :
readinessProbe:
httpGet:
path: /api/healthtest
port: {{ .Values.deployment.internalPort }}
livenessProbe:
httpGet:
path: /api/healthtest
port: {{ .Values.deployment.internalPort }}
failureThreshold: 3
periodSeconds: 2010.39.67.97 - This is the IP for the Load Balancer 8800 - This is the internal Port for the deployment
Can some one pls help me of what I am missing here , I presume this to a configuration issue which I am struggling to figure out.
Thanks
Can you just try startupProbe instead of readinessProbe? it's seems like the readinessProbe is failing before the server start. it happens when a server took more time than usual to start.
startupProbe: Startup probes are useful for Pods that have containers that take a long time to come into service. Rather than set a long liveness interval, you can configure a separate configuration for probing the container as it starts up, allowing a time longer than the liveness interval would allow. ref
The benefit of use startupProbe is that other two readinessProbe and livenessProbe will not execute until startupProbe succeed.
startupProbe:
httpGet:
path: /api/healthtest
port: {{ .Values.deployment.internalPort }}
failureThreshold: 30
periodSeconds: 10
livenessProbe:
httpGet:
path: /api/healthtest
port: {{ .Values.deployment.internalPort }}
failureThreshold: 3
periodSeconds: 20