Application Lifecycle Management in Kubernetes

Rolling Updates and Rollbacks

Rollout and Versioning

• When you first create a deployment, it triggers a rollout.

• A new rollout creates a new deployment revision.

• In the future, when the application is upgraded, meaning when the container version is updated, a new rollout is triggered, and a new deployment revision is created.

• This helps us to keep track of the changes made to our deployment and enables us to roll back to a previous version of the deployment if necessary.

Rollout Commands

1. kubectl rollout status <deployment_name>

   • To view the status of the rollout.

2. kubectl rollout history <deployment_name>

   • To view the revisions and history of the rollout.

Deployment Strategy

1. Recreate

   • In this type of very simple deployment, all of the old pods are killed all at once and replaced all at once with the new ones.

   • Here, the application faces downtime.

2. Rolling Update

   • The rolling deployment is the standard default deployment to Kubernetes. It works one by one, replacing pods of the previous version of your application with pods of the new version without any cluster downtime.

Rollback

• Undoing the latest update.

• Here, the deployment destroys the pod in the new replicaset and brings the older ones up in the old replicaset.

• kubectl rollout undo <deploymentt_name>

Configure Applications

Application Commands and Arguments

• The command and args fields in Kubernetes Pod YAML files specify the command to be run in the container and any additional arguments to be passed to the command, respectively.

• The command field corresponds to the ENTRYPOINT instruction in a Dockerfile, while the args field corresponds to the CMD instruction.

• By specifying these fields, you can customize the commands and arguments that are executed in the container, giving you the flexibility to run any command in the container.

• 

Environment Variables in Kubernetes

• In Kubernetes, environment variables are scoped to a container, and there are three main ways of adding them.

Direct

• The first option is, that you can simply specify environment variables directly in your pod definition with an env keyword.

• 

ConfigMaps

• ConfigMaps are used to pass configuration data in the form of key-value pairs in Kubernetes in plane-text format.

  • When a pod is created, inject the Configap into the pod, so the key-value pairs are available as environment variables for the application hosted inside the container in the pod.

  • There are two phases involved in configuring ConfigMaps.

    1. Create the ConfigMap.

    2. Inject them into the pod.

  • There are two ways to create ConfigMaps.

    • Using command (Imperative way)

      • kubectl create configmap <config_name> --from-literal=<key>=<value> --from-literal=<key>=<value> ...

      • Ex: kubectl create configmap app-config --from-literal=APP_COLOR=blue

      • kubectl create configmap <config_name> --from-file=<path_to_file>

      • Ex. kubectl create configmap app-config --from-file=app_config.properties

    • Using config map configuration file (Declarative way)

      • kubectl create -f config-map.yaml

      • 

    • kubectl get configmaps - To view the created config maps.

    • kubectl describe configmaps - To list the configuration data.

    • 

Secrets

• Secrets are used to store sensitive information like passwords or keys.

• They are similar to ConfigMaps except that they are stored in an encoded format.

• There are two phases involved in working with Secrets.

  1. Create the Secrets.

  2. Inject them into the pod.

• There are two ways to create Secrets.

  1. Using command (Imperative way)

     • kubectl create secret generic <secret_name> --from-literal=<key>=<value> --from-literal=<key>=<value> ...

     • Ex: kubectl create secret generic app-secret--from-literal=APP_COLOR=blue

     • kubectl create secret generic <secret_name> --from-file=<path_to_file>

     • Ex. kubectl create secret generic app-secret --from-file=app_secret.properties

  2. Using secret configuration file (Declarative way)

     • kubectl create -f secret-data.yaml

     • 

       

• kubectl get secrets- To view the created secrets.

• kubectl describe secrets- To view more information on created secrets.

• kubectl get secrets <secret_name> -o yaml - To view information of secrets with encoded values.

• 

  

  

Note on Secrets

• Secrets are not encrypted. Only encoded.

• Secrets are not encrypted in ETCD - Enable encryption at rest.

• Anyone able to create pods/deployments in the same namespace can access the secrets - Configure least-privilege access to secrets (RBAC).

• Consider third-party secrets store providers.

Multi-Container Pods

• A single pod can have multiple containers, except for the fact that the multiple containers are not of the same kind, this pod is known as Multi-Container Pod.

• Multi-Container Pod includes one main container which is responsible for performing the main task, and other helper containers that may be needed to perform some side tasks to help the main container.

• The two containers can communicate with each other directly by referring to each other as localhost since they share the same network space.

• Plus they can easily share the same storage space as well.

Init Containers

• In a multi-container pod, each container is expected to run a process that stays alive as long as the POD's lifecycle. For example in the multi-container pod that has a web application and logging agent, both the containers are expected to stay alive at all times. The process running in the log agent container is expected to stay alive as long as the web application is running. If any of them fail, the POD restarts.

• But at times you may want to run a process that runs to completion in a container. For example, a process that pulls a code or binary from a repository that will be used by the main web application. That is a task that will be run only one time when the pod is first created. Or a process that waits for an external service or database to be up before the actual application starts. That's where initContainers comes in.

• An initContainer is configured in a pod like all other containers, except that it is specified inside a initContainers section.

• 

  When a POD is first created the initContainer is run, and the process in the initContainer must run to a completion before the real container hosting the application starts.

• You can configure multiple such initContainers as well, like how we did for multi-containers pod. In that case, each init container is run one at a time in sequential order.

• If any of the initContainers fail to complete, Kubernetes restarts the Pod repeatedly until the Init Container succeeds.

•