<p>I have configured a spring-boot pod and configured the <code>liveness</code> and <code>readiness</code> probes.
When I start the pod, the <code>describe</code> command is showing the below output.</p>
<pre><code>Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  92s                default-scheduler  Successfully assigned pradeep-ns/order-microservice-rs-8tqrv to pool-h4jq5h014-ukl3l
  Normal   Pulled     43s (x2 over 91s)  kubelet            Container image &quot;classpathio/order-microservice:latest&quot; already present on machine
  Normal   Created    43s (x2 over 91s)  kubelet            Created container order-microservice
  Normal   Started    43s (x2 over 91s)  kubelet            Started container order-microservice
  Warning  Unhealthy  12s (x6 over 72s)  kubelet            Liveness probe failed: Get &quot;http://10.244.0.206:8222/actuator/health/liveness&quot;: dial tcp 10.244.0.206:8222: connect: connection refused
  Normal   Killing    12s (x2 over 52s)  kubelet            Container order-microservice failed liveness probe, will be restarted
  Warning  Unhealthy  2s (x8 over 72s)   kubelet            Readiness probe failed: Get &quot;http://10.244.0.206:8222/actuator/health/readiness&quot;: dial tcp 10.244.0.206:8222: connect: connection refused
</code></pre>
<p>The pod definition is like below</p>
<pre><code>apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: order-microservice-rs
  labels:
    app: order-microservice
spec:
  replicas: 1
  selector:
    matchLabels:
      app: order-microservice
  template:
    metadata:
      name: order-microservice
      labels:
        app: order-microservice
    spec:
      containers:
        - name: order-microservice
          image: classpathio/order-microservice:latest
          imagePullPolicy: IfNotPresent
          env:
            - name: SPRING_PROFILES_ACTIVE
              value: dev
            - name: SPRING_DATASOURCE_USERNAME
              valueFrom:
                secretKeyRef:
                  key: username
                  name: db-credentials
            - name: SPRING_DATASOURCE_PASSWORD
              valueFrom:
                secretKeyRef:
                  key: password
                  name: db-credentials
          volumeMounts:
            - name: app-config
              mountPath: /app/config
            - name: app-logs
              mountPath: /var/log
          livenessProbe:
            httpGet:
              port: 8222
              path: /actuator/health/liveness
            initialDelaySeconds: 10
            periodSeconds: 10
          readinessProbe:
            httpGet:
              port: 8222
              path: /actuator/health/readiness
            initialDelaySeconds: 10
            periodSeconds: 10
          resources:
            requests:
              memory: &quot;550Mi&quot;
              cpu: &quot;500m&quot;
            limits:
              memory: &quot;550Mi&quot;
              cpu: &quot;750m&quot;
      volumes:
        - name: app-config
          configMap:
            name: order-microservice-config
        - name: app-logs
          emptyDir: {}
      restartPolicy: Always
</code></pre>
<p>If I disable the <code>liveness</code> and <code>readiness</code> probe in the <code>replica-set</code> manifest and I <code>exec</code> into the pod, I am getting a valid response when invoking <code>http://localhost:8222/actuator/health/liveness</code> and <code>http://localhost:8222/actuator/health/readiness</code> endpoint.
Why is my pod restarting and failing when invoking the <code>readiness</code> and <code>liveness</code> endpoint with Kubernetes. Where am I going wrong?</p>
<p><strong>Update</strong>
If I remove the <code>resource</code> section, the pods are running but when added the <code>resource</code> parameters, the <code>probes</code> are failing.</p>

<p>When you limit the container / spring application to 0.5 cores (500 millicores) the startup probably takes longer than the given liveness probe thresholds.</p>
<p>You can either increase them, or use a startupProbe with more relaxed settings (f.e. failureThreshold 10). You can reduce the period for the liveness probe in that case and get faster feedback after a successful container start was detected.</p>
