Kubernetes Container Environment Variables Tutorial. Here Coding compiler sharing a tutorial on Kubernetes Container Environment Variables. In this tutorial, we will discuss on Kubernetes containers, Container Environment Variables, and Kubernetes Container Lifecycle Hooks. Let’s start learning about Kubernetes. Happy learning.
Container Environment Variables
The Kubernetes Container environment provides several important resources to Containers:
- A filesystem, which is a combination of an image and one or more volumes.
- Information about the Container itself.
- Information about other objects in the cluster.
The hostname of a Container is the name of the Pod in which the Container is running. It is available through the
hostname command or the
gethostname function call in libc.
The Pod name and namespace are available as environment variables through the downward API.
User defined environment variables from the Pod definition are also available to the Container, as are any environment variables specified statically in the Docker image.
A list of all services that were running when a Container was created is available to that Container as environment variables. Those environment variables match the syntax of Docker links.
For a service named foo that maps to a container named bar, the following variables are defined:
FOO_SERVICE_HOST=<the host the service is running on> FOO_SERVICE_PORT=<the port the service is running on>
Services have dedicated IP addresses and are available to the Container via DNS, if DNS addon is enabled.
Container Lifecycle Hooks Overview
Analogous to many programming language frameworks that have component lifecycle hooks, such as Angular, Kubernetes provides Containers with lifecycle hooks. The hooks enable Containers to be aware of events in their management lifecycle and run code implemented in a handler when the corresponding lifecycle hook is executed.
There are two hooks that are exposed to Containers:
This hook executes immediately after a container is created. However, there is no guarantee that the hook will execute before the container ENTRYPOINT. No parameters are passed to the handler.
This hook is called immediately before a container is terminated. It is blocking, meaning it is synchronous, so it must complete before the call to delete the container can be sent. No parameters are passed to the handler.
A more detailed description of the termination behavior can be found in Termination of Pods.
Hook handler implementations
Containers can access a hook by implementing and registering a handler for that hook. There are two types of hook handlers that can be implemented for Containers:
- Exec – Executes a specific command, such as
pre-stop.sh, inside the cgroups and namespaces of the Container. Resources consumed by the command are counted against the Container.
- HTTP – Executes an HTTP request against a specific endpoint on the Container.
Hook handler execution
When a Container lifecycle management hook is called, the Kubernetes management system executes the handler in the Container registered for that hook.
Hook handler calls are synchronous within the context of the Pod containing the Container. This means that for a
PostStart hook, the Container ENTRYPOINT and hook fire asynchronously. However, if the hook takes too long to run or hangs, the Container cannot reach a
The behavior is similar for a
PreStop hook. If the hook hangs during execution, the Pod phase stays in a
Terminating state and is killed after
terminationGracePeriodSeconds of pod ends. If a
PreStop hook fails, it kills the Container.
Users should make their hook handlers as lightweight as possible. There are cases, however, when long running commands make sense, such as when saving state prior to stopping a Container.
Hook delivery guarantees
Hook delivery is intended to be at least once, which means that a hook may be called multiple times for any given event, such as for
PreStop. It is up to the hook implementation to handle this correctly.
Generally, only single deliveries are made. If, for example, an HTTP hook receiver is down and is unable to take traffic, there is no attempt to resend. In some rare cases, however, double delivery may occur. For instance, if a kubelet restarts in the middle of sending a hook, the hook might be resent after the kubelet comes back up.
Debugging Hook handlers
The logs for a Hook handler are not exposed in Pod events. If a handler fails for some reason, it broadcasts an event. For
PostStart, this is the
FailedPostStartHook event, and for
PreStop, this is the
FailedPreStopHook event. You can see these events by running
kubectl describe pod <pod_name>.
RELATED KUBERNETES TUTORIALS
Want to learn Kubernetes from industry experts?
Get register for a FREE demo on Kubernetes Training @ Contact us.