Topic Objectives
In this topic we will discuss:
-
Declarative Synchronization
-
Describe different ways of implementing flow control using Validated Patterns and GitOps built-in tools
Declarative Synchronization
Making the transition to GitOps we’re often faced with the challenge of implementing applications and configurations that weren’t built with declarative deployments, more specifically, GitOps in mind
We have come across multiple use-cases where we need to apply imperative actions against a cluster to either get information or apply a change (e.g. node labeling for Red Hat OpenShift Data Foundations )
We needed a way to declaratively define those do-wait-do processes
It is also important to understand how imperative changes fit into declarative deployments
-
WHAT you are doing imperatively won’t change, it become more about HOW you are applying that change to the cluster
-
It’s important to not let the way you solve these problems become your default approach for application deployments.
We have options!
Resource Type |
Explanation |
|
A job creates one or more pods and will continue to retry execution of the pods until a specified number of them successfully terminate |
|
A cronJob creates jobs on a repeating schedule and uses the cron job syntax |
|
ArgoCD Software Agents that automatically pull the desired state declarations from the source |
'Sync-Waves' |
ArgoCD Software Agents that continuously observe actual system state and attempt to apply the desired state |
Jobs
Jobs are part of the kubernetes batch api group
Within the Patterns framework we mainly use jobs to:
-
Wait for dependent resources to become available, giving control over the deployment rollout
-
Configure applications that rely heavily on API or console interaction (e.g. Quay Enterprise)
-
Interrogate clusters resources such as secrets generated by resources out of scope of the pattern
cronJobs
cronJobs are part of the kubernetes batch api group
Within the Patterns framework we mainly use jobs to:
-
schedule imperative tasks in the imperative framework such as keeping the Vault unsealed
-
run Ansible playbooks
Ansible Roles and Playbooks MUST be idempotent to prevent sync failures
The cronJob syntax is the same as in posix systems
# ┌───────────── minute (0 - 59)
# │ ┌───────────── hour (0 - 23)
# │ │ ┌───────────── day of the month (1 - 31)
# │ │ │ ┌───────────── month (1 - 12)
# │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday;
# │ │ │ │ │ 7 is also Sunday on some systems)
# │ │ │ │ │ OR sun, mon, tue, wed, thu, fri, sat
# │ │ │ │ │
# * * * * *Check out these links for more information about Kubernetes Jobs and Kubernetes Cron Jobs
Check out The Path to GitOps by Christian Hernandez!