Approaches to resource management

In order to deploy an application on Kubernetes, we need to interact with the Kubernetes API to create resources. kubectl is the tool we use to talk to the Kubernetes API. kubectl is a command-line interface (CLI) tool used to abstract the complexity of the Kubernetes API from end users, allowing them to more efficiently work on the platform.

Let’s discuss how kubectl can be used to manage Kubernetes resources.

Imperative and declarative configurations

The kubectl tool provides a series of subcommands to create and modify resources in an imperative fashion. Here is a small list of these commands:

• create
• describe
• edit
• delete

The kubectl commands follow a common format, as shown here:

kubectl <verb> <noun> <arguments>

The verb refers to one of the kubectl subcommands, and the noun refers to a particular Kubernetes resource. For example, the following command can be run to create a deployment:

kubectl create deployment my-deployment --image=busybox

This would instruct kubectl to talk to the Deployment API endpoint and create a new deployment called my-deployment, using the busybox image from Docker Hub.

You could use kubectl to get more information on the deployment that was created by using the describe subcommand, as follows:

kubectl describe deployment my-deployment

This command would retrieve information about the deployment and format the result in a readable format that allows developers to inspect the live my-deployment deployment on Kubernetes.

If a change to the deployment was desired, a developer could use the edit subcommand to modify it in place, like this:

kubectl edit deployment my-deployment

This command would open a text editor, allowing you to modify the deployment.

When it comes to deleting a resource, the user could run the delete subcommand, as illustrated here:

kubectl delete deployment my-deployment

This would call the appropriate API endpoint to delete the my-deployment deployment.

Kubernetes resources, once created, exist in the cluster as JavaScript Object Notation (JSON) resource files, which can be exported as YAML Ain’t Markup Language (YAML) files for greater human readability. An example resource in YAML format can be seen here:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
spec:
  replicas: 1
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
        - name: main
          image: busybox
          args:
            - sleep
            - infinity

The preceding YAML format presents a very basic use case. It deploys the busybox image from Docker Hub and runs the sleep command indefinitely to keep the Pod running.

While it may be easier to create resources imperatively using the kubectl subcommands we have just described, Kubernetes allows you to directly manage the YAML resources in a declarative fashion to gain more control over resource creation. The kubectl subcommands do not always let you configure all the possible resource options, but creating YAML files directly allows you to more flexibly create resources and fill in the gaps that the kubectl subcommands may contain.

When creating resources declaratively, users first write out the resource they want to create in YAML format. Next, they use the kubectl tool to apply the resource against the Kubernetes API. While in imperative configuration developers use kubectl subcommands to manage resources, declarative configuration relies primarily on only one subcommand—apply.

Declarative configuration often takes the following form:

kubectl apply -f my-deployment.yaml

This command gives Kubernetes a YAML resource that contains a resource specification, although the JSON format can be used as well. Kubernetes infers the action to perform on resources (create or modify) based on whether or not they exist.

An application may be configured declaratively by following these steps:

1. First, the user can create a file called deployment.yaml and provide a YAML-formatted specification for the deployment. We will use the same example as before, as follows:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: busybox
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: busybox
     template:
       metadata:
         labels:
           app: busybox
       spec:
         containers:
           - name: main
             image: busybox
             args:
               - sleep
               - infinity

2. A deployment can then be created with the following command:

   kubectl apply –f deployment.yaml

Upon running this command, Kubernetes will attempt to create a deployment in the way you specified.

3. If you wanted to make a change to the deployment by changing the number of replicas to 2, you would first modify the deployment.yaml file, as follows:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: busybox
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: busybox
     template:
       metadata:
         labels:
           app: busybox
       spec:
         containers:
           - name: main
             image: busybox
             args:
               - sleep
               - infinity

4. You would then apply the change with kubectl apply, like this:

   kubectl apply –f deployment.yaml

After running that command, Kubernetes would apply the provided deployment declaration over the previously applied deployment. At this point, the application would scale up from a replica value of 1 to 2.

5. When it comes to deleting an application, the Kubernetes documentation actually recommends doing so in an imperative manner; that is, using the delete subcommand instead of apply, as illustrated here:

   kubectl delete –f deployment.yaml

As you can see, the delete subcommand uses the –f flag to delete the resource from the given file.

With an understanding of how Kubernetes resources are created, let’s now discuss some of the challenges involved in resource configuration.