How to use cron with Kubernetes to schedule tasks

how-to-use-cron-with-kubernetes-to-schedule-tasks

If you’ve ever needed to schedule a single or recurring task in your Kubernetes clusters, it’s just a cronjob away. Jack Wallen shows you how.

Image: Jack Wallen

Kubernetes is one of the most flexible and powerful container managers on the market. The deeper you dive into the technology, the more you realize it can do. Take for instance, Kubernetes’ ability to use the Linux cron tool for the scheduling of tasks.

Using the combination of Kubernetes and cron make it possible to not just create recurring tasks, but scheduled tasks. With the scheduling of tasks, you are able to have them run at a time when usage is low, as to not bog down your cluster with tasks that are necessary but may not be directly related to your production workflow.

So how do you integrate cron into your Kubernetes cluster? You do it on a manifest-by-manifest basis. I’m going to show you how to do just that. I’ll demonstrate with a very basic task, so you can easily understand the concept. 

What you’ll need

In order to add cron jobs, you’ll need a running Kubernetes cluster. If you’ve yet to deploy one, check out my article: How to deploy a Kubernetes cluster on Ubuntu server.

SEE: Implementing DevOps: A guide for IT pros (free PDF) (TechRepublic)

How to create the YAML file

The first thing we must do is create a YAML file for the task. Remember, this is a very basic task, so our YAML file won’t contain too much information. Let’s break it down.

The first section defines the API version and the kind of job we’re creating. That section looks like:

apiVersion: batch/v1beta1
kind: CronJob

The next section details the metadata for the job. That section looks like:

metadata:
  name: cron-hello

Next, we have the specs for the job. This section contains our parameters for cron and is defined by way of the schedule option, which will run the task every 15 minutes. This section looks like:

spec:
  schedule: "0,15,30,45 "

Now we have the job template section, some of which will remain blank (for simplicity). This section defines the image used for the container to be deployed–in this case, busybox. It also includes a few arguments, one of which is the output to be printed for the job (remember, this is a simple task). The output will be the date and a text message printed every 15 minutes, as defined by the schedule option. 

This section looks like:

jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: cron-hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello, TechRepublic!
          restartPolicy: OnFailure

Create the new file with the command:

nano cron.yaml

In that file, paste the entire contents of the manifest shown below:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cron-hello
spec:
  schedule: "0,15,30,45 "
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: cron-hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello, TechRepublic!
          restartPolicy: OnFailure

Save and close the file.

How to deploy the job

Now we’re going to deploy the job that includes the scheduled task. To do that, issue the command:

kubectl create -f cron.yaml

Once the job runs, it’ll report that cron-hello has been created (Figure A).

Figure A

Our scheduled task deployment was successful.

You can ensure the cronjob task is running with the command:

kubeclt get cronjobs

This will list out every cronjob task on your cluster (Figure B).

Figure B

I have two containers that include cronjobs on my Kubernetes cluster.

How to watch for the cronjob

Let’s say you’ve deployed a container with an associated cronjob and you want to watch for it. To do that, you’d issue the command:

kubectl get jobs --watch

The output of that command will include a running list of every deployed job (Figure C).

Figure C

I have a number of created jobs that have run, thanks to cronjob.

To end that watch, use the Ctrl+C combination.

How to delete the cronjob

Deleting a cron-scheduled job is quite simple. To do this, issue the command:

kubectl delete cronjob NAME

Where NAME is the name used in the metadata section of the YAML file. 

And that’s the gist of using cronjob to schedule single and recurring tasks to your Kubernetes cluster. This simple tool can go a long way to make your Kubernetes admin job a bit easier. Give it a go and see if you don’t wind up making use of cronjob more and more.

http://www.techrepublic.com/

Data Center Trends Newsletter

DevOps, virtualization, the hybrid cloud, storage, and operational efficiency are just some of the data center topics we’ll highlight.
Delivered Mondays and Wednesdays



Sign up today

Also see

How to create a Kubernetes ReplicaSet

how-to-create-a-kubernetes-replicaset

If you’re looking to maintain a stable set of Kubernetes replica pods running at any given time, the tool you need is ReplicaSets. Find out how to use this handy feature.

Image: Jack Wallen

When you deploy a pod within a Kubernetes cluster, you will often create replicas of the pod to scale an application or service. The best way to control these replicas is via a ReplicaSet, which makes sure specified replica pods are always running at the desired state. Without a ReplicaSet, you would have to create multiple manifests for a given number of pods needed for a single application or service.

For those that have used Kubernetes for a while, the ReplicaSet is considered the next-gen replacement for the replication controller. 

I want to show you how to create a ReplicaSet on a running Kubernetes cluster. We’ll use the tried and true NGINX pod as an example (since you’re probably already familiar with the deployment of such a pod). 

SEE: Hiring kit: Database administrator (TechRepublic Premium)

What you’ll need

In order to create a ReplicaSet, you’ll need a running Kubernetes cluster. If you’ve yet to deploy such a cluster, read my article: How to deploy a Kubernetes cluster on Ubuntu server. If you’ve deployed your cluster on a third-party service, such as AWS, this how-to should work without much change.

As you probably expected, I’ll be demonstrating with a Kubernetes cluster running on three instances of Ubuntu Server.

How to create the YAML file

As with just about everything related to Kubernetes, we define our ReplicaSet via a YAML file. Create the file with the command:

nano rs.yaml

Let’s break down the contents of the file. The first two lines define the API version to be used (v1) and what the YAML file will be deploying (ReplicaSet). These lines are:

apiVersion: apps/v1
kind: ReplicaSet

The next section defines the metadata for the pod, which declares what we’re trying to achieve with the pod. In our instance we’re creating an NGINX proxy pod to serve as a frontend. This section looks like:

metadata:
  name: nginx-proxy
  labels:
    app: nginx-proxy
    tier: frontend

In the next section, we define the specs for the ReplicaSet. We start off by deploying five replicas and then we use matchLabels to instruct Kubernetes what pods the deployment will apply to (in our case, nginx-proxy). We’ll also name the containers and define the image to be used for the pod (nginx). This section looks like:

spec:
  replicas: 5
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: nginx
        image: nginx

When you put this entire YAML together, it looks like:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-proxy
  labels:
    app: nginx-proxy
    tier: frontend

spec:
  replicas: 5
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: nginx
        image: nginx

Save and close the file.

How to deploy the ReplicaSet

Now that you have your YAML file together, we’ll deploy it so it will create five replicas of the NGINX pod. To do that, issue the command:

kubectl apply -f rs.yaml

You could also use the command:

kubectl create -f rs.yaml

The command will report back that the ReplicaSet was created. You can verify this with the command:

kubectl get replicaset

You should see the new ReplicaSet running (Figure A).

Figure A

Our ReplicaSet has been successfully deployed.

How to alter the running ReplicaSet

Say you need to scale the ReplicaSet up from five to 10. That’s actually really easy. Open your YAML file and change the line:

replicas: 5

To:

replicas: 10

Save and close the file. Rerun the command:

kubectl apply -f rs.yaml

You should see replicaset.apps/nginx-proxy configured reported back. To verify the change, issue the command:

kubectl get replicaset

You should now see that ReplicaSet is in the new desired state (Figure B).

Figure B

We’ve scaled our replicas from five to 10.

You can also check the status of the individual pods with the command:

kubectl get pods

You should see all 10 pods running (Figure C).

Figure C

Our 10 NGINX proxy pods are running.

And that’s how easy it is to deploy a Kubernetes ReplicaSet. To learn more about this important feature, make sure to give the official Kubernetes documentation a read.

http://www.techrepublic.com/

Data Center Trends Newsletter

DevOps, virtualization, the hybrid cloud, storage, and operational efficiency are just some of the data center topics we’ll highlight.
Delivered Mondays and Wednesdays



Sign up today

Also see

How to create a Kubernetes namespace

how-to-create-a-kubernetes-namespace

Namespaces are crucial to better Kubernetes management. Learn how to create a new namespace and then deploy a pod to it.

Image: Jack Wallen

Within the realm of Kubernetes, a namespace is used in certain environments where multiple users are spread across teams or projects. By using namespaces, it is possible to divide resources between users without running into name collision.

For example: Within a Kubernetes cluster, you cannot have pods of the same name. However, by using namespaces, those pods with the same name can be isolated within a namespace, such that Kubernetes will have no problem with their existence. In other words, namespaces are a sort of virtual cluster. In a similar fashion as having multiple guest VMs on a host, you can have multiple namespaces on a single cluster.

SEE: Implementing DevOps: A guide for IT pros (free PDF) (TechRepublic)

Upon deploying your Kubernetes cluster, you’ll find at least three basic namespaces:

  • default – Used for deployments not given a namespace

  • kube-system – Used for everything related to the Kubernetes system

  • kube-public – Readable by everyone, but reserved for system use only

You can view the list of current namespaces by issuing the command:

kubectl get namespaces

You should see those three namespaces at a minimum (Figure A).

Figure A

The basic namespaces are listed with a few extra in my test cluster.

What you’ll need

In order to create a new namespace, you’ll need a Kubernetes cluster up and running. If you’ve not already taken care of that, follow the steps in: How to deploy a Kubernetes cluster on Ubuntu server.

How to create a namespace

Let’s create a namespace called staging. To do that, open a terminal window on your Kubernetes controller and issue the command:

kubectl create namespace staging

The kubectl command will report back the namespace has been created (Figure B).

Figure B

Our staging namespace has been created.

How to deploy a pod to a namespace

Now that we’ve created our namespace, how do we deploy to it? That’s easy. Say you want to deploy an NGINX pod to the new staging namespace. For that you would issue the command:

kubectl run nginx --image=nginx --namespace=staging

The kubectl command will report back that your pod has been created (Figure C).

Figure C

Our NGINX pod has been deployed to the staging namespace.

To ensure the pod was in fact deployed to the staging namespace, issue the command:

kubectl get pods --namespace=staging

The kubectl command will report back that the NGINX pod is running (Figure D).

Figure D

Our NGINX pod is running.

How to set the default namespace

Let’s say you’ve created a namespace you intend to always use as your default. Instead of having to use the –namespace= option in your deployment/management commands, you could always set that new namespace as the default. 

To do that, you would issue the command:

kubectl config set-context --current --namespace=NAMESPACE

Where NAMESPACE is the name of the namespace you wish to use as the default.

Now, if you were to deploy that NGINX pod to the staging namespace (which we’ve set as our default), the command would simply be:

kubectl run nginx --image=nginx

And that’s all there is to creating a Kubernetes namespace. Play around with this feature so you’re confident in its usage because you will eventually need namespaces to make your clusters easier to manage.

http://www.techrepublic.com/

Cloud and Everything as a Service Newsletter

This is your go-to resource for XaaS, AWS, Microsoft Azure, Google Cloud Platform, cloud engineering jobs, and cloud security news and tips.
Delivered Mondays



Sign up today

Also see