There are many basic principles of object-oriented design, two of which I think describe the Kubernetes object design idea more appropriately, one is "single responsibility" and the other is "composition is better than inheritance".
"Single responsibility" means that the object should only focus on doing one thing well, don't be greedy for everything, and keep the granularity small enough to make it easier to reuse and manage.
"Combination is better than inheritance" means that objects should be connected at runtime as much as possible to keep loose coupling, instead of fixing the relationship of objects in a hard-coded way.
Applying these two principles, it will be very clear when we look at the resource objects of Kubernetes. Because the Pod is already a relatively complete object, which is responsible for managing the container, we should not blindly expand its functions by "adding to the snake", but to maintain its independence. Functions outside the container need to define other functions. Object that "composes" the Pod as a member of it.
In this way, each Kubernetes object can only focus on its own business field, only do what it is best at, and hand over other tasks to other objects, neither "absence" nor "offside", both division of labor and collaboration , so as to achieve maximum benefit at minimum cost.
Corresponding to Kubernetes, "temporary task" is the API object Job, and "scheduled task" is the API object CronJob. Using these two objects, you can schedule and manage any offline business in Kubernetes.
The YAML "file header" part of the job is still the required fields. Simply put:
- apiVersion is not v1, but batch/v1.
- kind is Job, which is consistent with the name of the object.
- There still needs to be a name tag name in the metadata, and you can also use labels to add arbitrary labels.
Lists several important fields that control offline jobs.
- activeDeadlineSeconds, set the timeout period for Pod running.
- backoffLimit, set the number of failed retries of the Pod.
- completions, how many Pods need to be run to complete the Job, the default is 1.
- Parallelism, which is related to completions, indicates the number of Pods allowed to run concurrently to avoid excessive resource occupation.
CronJob uses timing rules to control Job, Job uses concurrent number to control Pod, Pod defines parameters to control container, container then isolates and controls the process, and the process finally realizes business functions. The progressive form is a bit like Decorator (decoration mode) in design mode , each link in the chain performs its own duties and completes the task under the unified command of Kubernetes.
CronJob In addition to defining the "jobTemplate" field of the Job object, CronJob also has a new field "schedule", which is used to define the rules for the periodic operation of the task. It uses standard Cron syntax to specify minutes, hours, days, months, and weeks, just like crontab on Linux.
This article is a study note for Day 13 in July. The content comes from "Kubernetes Introductory Practical Course" by Geek Time . This course is recommended.