Supercronic: Crontabs Voor In Je Containers

Sudo Friday cron supercronic containers kubernetes
  Wander Boessenkool

Regelmatig terugkerende taken op een container paltform kun je op Kubernetes inregelen met een CronJob. Maar als je die taak elke minuut gaat uitvoeren levert dat misschien een belastingspatroon op op je cluster dat ongewenst is, helemaal als de taak veel resources als externe filesystemen nodig heeft.

Nu zou je natuurlijk een traditionele Cron daemon in een container kunnen draaien, maar dan kom je er al snel achter dat deze graag als root draaien, met setgid en setuid permissies, en dat vind een container platform als OpenShift weer minder grappig zonder dat je SecurityContextConstraints met veel rechten gaat uitdelen. Ook zul je een init systeem in je container moeten stoppen omdat anders mogelijke zombie processen niet goed opgeruimd worden, en voor je het weet ben je een half OS in je container aan het stoppen.

Ook als je je taken vaker dan eens per minuut wilt draaien, of als je specifieke scheduling wensen hebt zoals “elke derde dinsdag van September” voldoet een traditionele Cron daemon of een Kubernetes CronJob al snel niet meer.

In deze video laat Wander een andere oplossing zien: supercronic. Een Cron vervanger die niet van gebruikers switched, environment variabelen niet reset, en die extra scheduling mogelijkheden, zoals secondes, jaren, X-de weekdag van de maand, etc, ondersteund.

Linkjes

Gerelateerde posts

Promoties met Kustomize

Wanneer je kustomize gebruikt om met Overlays de lifecycle-fases van je applicatie te beheren dan ga je vroeger dan later een keer de vragen stellen hoe je promoties van images (en Bases) tussen deze fases kunt automatiseren. Met de hand references en image transformers doorzetten is meestal geen optie vanwege de kans op fouten, en het willen automatiseren van de promotie pipelines. Nu zijn er bestaande oplossingen met tools als Renovate die dit (gedeeltelijk) voor je kunnen oplossen, maar die hebben vaak wat meer infrastructuur nodig. Als je deze tools nog niet gebruikt dan zou je zelf wat scriptjes kunnen schrijven, maar nu heb je nog iets extras om te beheren en bij te houden.

Promotions Between Kustomizations

In a typical containerized application we have a lifecycle that goes a little like this: Developers push code to an application repository. A pipeline builds the latest code and pushes the resulting image to a registry The pipeline updates the images: transformer in a Kustomization Overlay for the dev environment with the new image by using a command like kustomize edit set image foobar=registry.example.com/foobar@sha256:deadbeef A tool like ArgoCD picks up the new image and starts a new deployment. This works well for the dev environment, but when that image needs to be promoted to a new environment like tst we either need to copy the updated image transformer manually, or try to read the updated version from the dev Kustomization. And images are not the only thing. A typical Kustomize Overlay will include a versioned Base with something like this: 1apiVersion: kustomize.config.k8s.io/v1beta1 2kind: Kustomization 3resources: 4- git.example.com/foobar.git/deploy/base?ref=v0.2.1 In this example we see that the Base that is being used comes from the Git tag or branch called v0.2.1. If a newer version of the application needs a newer Base a developer can update that reference in the dev Overlay, but promotions will need to be handled as well. Simply copying the kustomization.yaml file between Overlays will most likely not work, since different Overlays typically use different Replica transformers, different ConfigMap en Secret Generators etc. Read on to learn how you can automate this.

Kubernetes Authenticatie Uitgelegd

Basis Kubernetes kent maar twee manieren van authenticatie: Een lijst van statische oauth bearer tokens, gekoppeld aan gebruikers en groepen, en client TLS certificaten met de gebruikersnaam in het “CN” (Common Name) veld en eventuele groepen in één of meer “O” (Organization) velden.