Although the Readiness Probe is not mandatory to run your K8s Manifests in Harness, without it, you might fall into a few corner cases.
As we know, Kubernetes considers the Container as “Ready” as soon as it is started. After that “milestone”, Harness will mark it as successful, and the “Wait for Steady State” step will pass with no problems.
With that said, if your Pod/Deployment/StatefulSet/etc crashes (like with a CrashLoopBack) after it started, you might have a False Positive on Harness Deployment.
This article is going to walk you through the steps required to configure your Manifests. Buckle up!
In our Lab, focusing on conciseness, we’ll use a very simple NGINX setup.
I’ll use the same template Manifests Harness provides. But I’ll just trim it a little bit. We want to focus on the Deployment only.
Important: kubelet (and Harness) will look for probes in the container section. That means you can put your Readiness Probe on a Deployment, on a Pod, on a StatefulSet, etc.
So, as usual, this small deployment.yaml will spin up one very basic default Nginx workload:
If you read this documentation from Kubernetes.io, you are going to see that a Readiness Probe of HTTP type is a perfect match to our Deployment.
I mean, it’s a good way to check if our layer is actually serving the correct content after a start process, right?
Important: In real life, you should definitely rely on a “/healthcheck” endpoint or something similar. Some articles will tell you that your health check must be the only source of truth. That means it needs to check all dependencies, even on the backend!
So, even an AWS ALB would have some pillar to determine if it can start sending requests to that “node”.
But, check this out:
readinessProbe: httpGet: scheme: HTTP path: /index.html port: 80 initialDelaySeconds: 10 periodSeconds: 5
Let’s test that thing out! I’ll use one simple templated Rolling K8s Deployment Workflow:
Last Step - Let’s break that, just in case
Why don’t we use the wrong port, just to test if Harness works as expected?
With that done, now you are able to trust in the Engine. Harness will consider that into the “Wait for Steady State” on your Deployment.
<cloud: aws, azure, tanzu, gcp, on-prem, kubernetes>
<category: kubernetes, gitops, templates, readinessprobe, harness, deployment>