[Kubernetes Deployment] Readiness Probes - How to tell Harness that your Container is Ready

Harness Experts
1

Howdy, gang! :rocket:

Harness_Logo
Harness_Logo977Ă—350 46.7 KB

Introduction

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! :rocket:

Tutorial

First Step

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:

Second Step

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

303Ă—507 34.9 KB

Third Step

Let’s test that thing out! I’ll use one simple templated Rolling K8s Deployment Workflow:

780Ă—473 34.8 KB

737Ă—183 27.5 KB

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?

And voilĂ !

Outcome:

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.

Further reading:

Tags:

<cloud: aws, azure, tanzu, gcp, on-prem, kubernetes>
<function: ci,cd>
<role: swdev,devops,secops,itexec>
<type: howto>
<category: kubernetes, gitops, templates, readinessprobe, harness, deployment>

4 Likes