DEV Community

Wycliffe A. Onyango
Wycliffe A. Onyango

Posted on

100 Days of DevOps: Day 57

#devops #kubernetes #containers #bash

Deploying and Testing a Kubernetes Pod with Environment Variables

The aim of this task is to set up prerequisites for an application designed to send greetings to various users. This involved deploying a sample pod on a Kubernetes cluster to test the configuration of environment variables and commands. This article outlines the steps taken, provides explanations for each action, and showcases the successful outputs.

Objective

The primary goal was to create a Kubernetes pod named print-envars-greeting with a specific container (print-env-container using the bash image). This container was configured with three environment variables: GREETING, COMPANY, and GROUP. A command was then executed within the container to print a concatenated message using these variables, with a restartPolicy of Never to prevent a crash loop after completion.

Step 1: Defining the Pod with a YAML Manifest

The first step involved creating a YAML manifest file that precisely defines the Kubernetes Pod's desired state. This file, named print-envars-greeting.yaml, specifies the pod's metadata, container details, environment variables, the command to execute, and the restart policy.

Here's the content of the print-envars-greeting.yaml file:

apiVersion: v1
kind: Pod
metadata:
  name: print-envars-greeting
spec:
  containers:
  - name: print-env-container
    image: bash
    env:
    - name: GREETING
      value: "Welcome to"
    - name: COMPANY
      value: "Stratos"
    - name: GROUP
      value: "Industries"
    command: ["/bin/sh", "-c"]
    args: ['echo "$(GREETING) $(COMPANY) $(GROUP)"']
  restartPolicy: Never
Enter fullscreen mode Exit fullscreen mode

Explanation:

  • apiVersion: v1: Specifies the Kubernetes API version used for this object (a Pod in this case).
  • kind: Pod: Declares that this manifest defines a Pod resource.
  • metadata.name: print-envars-greeting: Assigns a unique name to our pod.
  • spec.containers: Defines the containers that will run inside the pod.
    • name: print-env-container: The name of our single container.
    • image: bash: The Docker image to use for the container. We chose bash because our command relies on shell execution.
    • env: An array defining environment variables.
      • Each entry consists of name (the variable's name) and value (its assigned string).
    • command: ["/bin/sh", "-c"]: This tells the container to execute /bin/sh with the -c option, which means "read commands from the string operand."
    • args: ['echo "$(GREETING) $(COMPANY) $(GROUP)"']: This is the string operand passed to /bin/sh -c. It uses shell expansion ($()) to retrieve the values of the GREETING, COMPANY, and GROUP environment variables and then prints them to standard output.
  • restartPolicy: Never: This crucial setting dictates what happens to the pod after its container terminates. By setting it to Never, we ensure that the pod does not attempt to restart its container after the echo command completes. This is appropriate for single-run tasks.

Step 2: Applying the Pod Manifest to the Kubernetes Cluster

Once the YAML file was prepared, it was applied to the Kubernetes cluster from the jumphost using the kubectl apply command.

Command Executed:

thor@jumphost ~$ kubectl apply -f print-envars-greeting.yaml
Enter fullscreen mode Exit fullscreen mode

Output:

pod/print-envars-greeting created
Enter fullscreen mode Exit fullscreen mode

Explanation:

  • kubectl apply: This command is used to create or update Kubernetes resources based on a configuration file.
  • -f print-envars-greeting.yaml: The -f flag specifies the file containing the resource definition.
  • The output pod/print-envars-greeting created confirms that the Kubernetes API server successfully processed our manifest and initiated the creation of the pod.

Step 3: Verifying Pod Status

After applying the manifest, it's essential to check the status of the newly created pod to ensure it's running as expected and has completed its task.

Command Executed:

thor@jumphost ~$ kubectl get pods print-envars-greeting
Enter fullscreen mode Exit fullscreen mode

Output:

NAME                       READY   STATUS      RESTARTS   AGE
print-envars-greeting      0/1     Completed   0          24s
Enter fullscreen mode Exit fullscreen mode

Explanation:

  • kubectl get pods: This command fetches information about pods in the cluster.
  • print-envars-greeting: Specifies that we only want information about the pod with this particular name.
  • The output shows:
    • NAME: The name of our pod.
    • READY: 0/1: Indicates that 0 out of 1 container within the pod is currently running and ready. Since our pod's task is short-lived and its restartPolicy is Never, it transitions quickly from Running to Completed.
    • STATUS: Completed: This is the desired status. It signifies that the container within the pod has executed its command successfully and terminated without errors.
    • RESTARTS: 0: Confirms that the container did not restart, aligning with our restartPolicy: Never.
    • AGE: 24s: Shows how long the pod has been in existence.

Step 4: Viewing the Pod's Output (Logs)

The final and most crucial step was to verify that the echo command executed correctly and produced the expected greeting. This is done by inspecting the logs of the pod's container.

Command Executed:

thor@jumphost ~$ kubectl logs -f print-envars-greeting
Enter fullscreen mode Exit fullscreen mode

Output:

Welcome to Stratos Industries
Enter fullscreen mode Exit fullscreen mode

Explanation:

  • kubectl logs: This command is used to retrieve the standard output and standard error logs from containers within a pod.
  • -f: The "follow" flag streams the logs in real-time. Although for a completed pod, it just displays the entire log history.
  • print-envars-greeting: The name of the pod whose logs we want to inspect.
  • The output Welcome to Stratos Industries confirms that the environment variables were correctly injected into the container, and the echo command successfully concatenated and printed their values to the standard output.

Conclusion

This exercise successfully demonstrated the deployment of a Kubernetes pod with custom environment variables and the execution of a specific command. By setting restartPolicy: Never, we ensured that the pod behaved like a completed job, making it ideal for one-off tasks or initialization processes. This foundational understanding of environment variables and pod lifecycle management is critical for building more complex and dynamic applications within a Kubernetes ecosystem.

Top comments (0)