Skip to content

Tutorial Part 4

Jump to bottom
Emilien Lancelot edited this page Sep 14, 2022 · 3 revisions

Tutorial - Part 4 - Creating dynamic Kubernetes templates

Prerequisite

  • Having followed part 3

What will be covered here

In the previous tutorial we found out that a lambda could respond a value to the caller. Now we will discover that you can dynamically change the Kubernetes deployment at startup.
You can use this functionnality to do pretty much anything. But for instance you could update the size of your lambda's volume dynamically. You also could pass any ENV values or update the retry strategy of the deployment.

Let's go

Customizing the deployment during startup

You can render the Job manifest dynamically. For instance we can dynamically update the key backoffLimit: 0 to any value.
backoffLimit is a Job option that acts like a retry when the container fails. By setting it to "0" Kubernetes won't create another pod instance. But if set to "1" and the pod crashes Kubernetes will spawn a new one.

To try this out we will update the Job manifest with a custom template variable and also force the pod to crash.

apiVersion: batch/v1
kind: Job
metadata:
  name: replace-{{RANDOM}}
spec:
  ttlSecondsAfterFinished: 3600
  backoffLimit: {{CUSTOM-VAR}}   # <== This value will be rendered dynamically
  template:
    spec:
      containers:
      - name: replace
        image: wingardiumleviosa/demo-gitfaas-replace:0.0.1
        command: ["python3", "crash.py"]  # <== We update the CMD to make the container crash (file doesn't exists)
        env:
        - name: PALYLOAD
          value: "{{PAYLOAD}}"
      restartPolicy: Never

➡️ Commit this updated version

To force Gitfaas to pull your commit immediately you can do:

$ curl http://127.0.0.1:5000/refresh

To define the value of CUSTOM-VAR we must use query params on the POST request. You can set as many as you want.

$ curl -X POST "http://127.0.0.1:5000/publish/replace?CUSTOM-VAR=1"

The section /replace?CUSTOM-VAR=1 is what defines the value of backoffLimit. It will have the value "1".

ℹ️ Note that we haven't define any request body with -d as the container will crash it's not usefull. You can trigger lambdas but don't necessarily have to give them an input message. It depends on what does your lambdas.

$ kubectl get pods -n gitfaas
replace-job-89c6afc9-381d-43af-965a-baa3341e7f46--1-fgdr9   0/1     Error     0          10s
replace-job-89c6afc9-381d-43af-965a-baa3341e7f46--1-zxj6j   0/1     Error     0          15s

We have two pods. The original one and the one that got retried by kubernetes.
If you check the value of backoffLimit inside the Job (kubectl describe job) you'll see it has been set to 1.

**Let's test with 4 retries: **

$ kubectl delete job -n gitfaas # Cleaning the old jobs

$ curl -X POST "http://127.0.0.1:5000/publish/replace?CUSTOM-VAR=4"

$ kubectl get pods -n gitfaas
replace-job-b4853364-f161-426f-9942-bfcdc7d188de--1-69np8   0/1     Error     0          2m5s
replace-job-b4853364-f161-426f-9942-bfcdc7d188de--1-gh2ht   0/1     Error     0          90s
replace-job-b4853364-f161-426f-9942-bfcdc7d188de--1-gzdgd   0/1     Error     0          2m
replace-job-b4853364-f161-426f-9942-bfcdc7d188de--1-xv9bs   0/1     Error     0          10s
replace-job-b4853364-f161-426f-9942-bfcdc7d188de--1-zmhtx   0/1     Error     0          110s

ℹ️ Kubernetes might take some time to boot the 4 retries so don't worry if you don't instantly get 4.

This concludes the tutorial. It covered all Gitfaas functionnalities.
Remember that Gitfaas can apply any kind of Kubernetes manifests not only Jobs. The templating system allows you to tweak everything so have fun !

Clone this wiki locally