Section 4 : Application life cycle management

Rolling updates and rollbacks

● Let’s define terms : rollout, revision and rollback.

○ When you create a deployment for the first time it triggers a

rollout.
◆ k rollout status deployment/<deployment-name> :- to view

rollout status.
◆ k rollout history deployment/<deployment-name> :- to view

rollout history.
○ A new rollout create a new deployment revision.
○ When you make changes to your containers in the deployment and

new rollout is triggered and a new deployment revision is created.

◆ Changes can include :
2
– Changing a container image : k set image deployment/
<deployment-name> <container-name>:<new-image-
1
name>
◆ This helps us to keep track of our deployments and enables us

to rollback to previous deployment if we later realize that we

made a mistake.

○ There a new deployment strategies :

. Rolling update : This is the default strategy where pods few
taken down as newer ones are brought up.
. Recreate : This is where all pods are taken down so that newer
pods can be brought.
◆ The recreate strategy causes some downtime as new pods

are being deployed.

◆ To get the changes in revision view the replicaSets in a

deployment with command:- k get replicasets

○ Rollback is undoing the latest deployment to return the

deployment to an older stable state.
◆ Command : k rollout undo deployment/<deployment-name>

Commands and arguments

 ● Commands are used to issue an entry point or a startup command for
a container in a pod.
● An entry-point in a docker file is a command in a k8s definition file.
○ ENTRYPOINT [“sleep”] ⸻> command : [“sleep”]
● CMD in a docker file is and argument in a k8s definition file.
○ CMD [“5000”] ⸻> args : [“5000”]

○ Commands and arguments can also be presented as :-

◆ command:

– “sleep”
– “5000”

Environment variables

● Environment variables can be passed into a pod as startup commands.

● To set an environment variable use the env property. It is an array
where each item has a name and value property.
○ env :

– name :
value :
– name :
value :

○ Another way to set an environment variable in a pod is through

configMaps.

ConfigMaps in K8s

● When you have a lot of pod definition files it can be difficult to manage
environment data in each file.
○ ConfigMaps can be used to manage environment data centrally.
● A configMaps is used to pass configuration data in form of key-value
pairs.
○ When a pod is created, we inject the configMap into the pod so

that the key-value pairs are available as environment variables for

the application hosted inside the container in the pod.
○ There are two steps involved in configuring configMaps :

. creating configMaps.
◆ imperative way : k create configmap <config-name> --

from-literal=key=value
– --from-literal is used to specify the key-value pair
 –
from the command itself.
– --from-file is used to specify the file which contains
the config data. The file has .properties extension.
◆ declarative way :-
– create a definition file.
◆ It 4 properties :-

– apiVersion: v1
– kind: ConfigMap
– metadata
◆ name: <config-name>

– data
◆ key1: value1
◆ key2: value2

– Run : k create -f definition-file.yaml to create the

configMap

. Injecting the into a pod.

◆ Under spec.containers, use property :
◆ envFrom:

– configMapRef:
name: <configMap-name>

◆ The above method used is to inject all properties of the

configMap into the pod. Other methods include :-

◆ Injecting it as a single variable from the configMap;

◆ env:

– name: <property-name>
valueFrom:
configMapKeyRef:
name: <configMap-name>
key: <property-name>

◆ Injecting it as a volume :-
◆ volumes:

– name: <volume-name>
configMap:
name: <configMap-name>

Kubernetes secrets

● Secrets are used to store sensitive information such as password or

●

keys.
● They are similar to configMaps except that they are stored in an
encoded format.
○ As with configMaps, there are two steps involved in configuring

secrets :
. creating the secret.
◆ imperative way : k create secret generic <secret-name>

--from-literal=key=value
– --from-literal is used to specify the key-value pair
from the command itself.
– --from-file is used to specify the file which contains
the config data. The file has .properties extension.
◆ declarative way :-

– create a definition file.

◆ It 4 properties :-

– apiVersion: v1
– kind: Secret
– metadata
◆ name: <secret-name>

– data
◆ key1: value1 # value in base64 format
◆ key2: value2 # value in base64 format

– Run : k create -f definition-file.yaml to create the

secret
. Inject it into a pod.
◆ Under spec.containers, use property :
◆ envFrom:

– secretRef:
name: <secret-name>

◆ The above method used is to inject all secrets of the secret

files into the pod. Other methods include :-

◆ Injecting it as a single secret from the secrets file;

◆ env:

– name: <property-name>
valueFrom:
secretKeyRef:
name: <secret-name>
key: <property-name>

◆ Injecting it as a volume :-
◆ When inject a secret as a volume, each key is created as
file with values stored inside.
 ◆ volumeMounts:
– name: <volumeMount-name> # same as
volume-name
mountPath: “/opt/foo" # can be any file path
readOnly: true

◆ volumes:
– name: <volume-name>
configMap:
name: <secret-name>

Important note on secrets

○ Secrets are not encrypted but encoded. So anyone can get the
secrets file decode it with base64 and have your confidential data.
◆ Therefore, do not to put your secret objects to any SCM like

Github along with your code.

○ Secrets are not encrypted in ETCD by default.
◆ Therefore, enable encryption at rest.
○ Anyone able to create a pod/deployment in the namespace can
access secrets.
◆ Therefore, configure least-privilege access to secrets with

RBAC.
◆ Consider a third party secret store provider such as :-

– AWS
– Azure
– GCP
– Vault Provider

Multi-container pods

● Multi-container pods are pods with more that one containers inside.
● Sometimes there necessary in cases, where a web-app pod needs to
be coupled with a logging agent to collect all logs.
○ A logging container can be created with :-
◆ ports
◆ volumePaths etc.

Init-containers
● These are specialized containers that runs and terminates before app
containers can run in a pod.
● X-tics include :-
○ Init containers are run in sequence according to how they were

defined in the pod definition file.

○ Init containers runs to completion.
○ Each init container must complete successfully before another one

can start.
○ If one fails, Kubelet repeatedly restarts it until it runs to completion

unless restartPolicy is set to Never.

● They can be used as follows :-
○ Pulling code to be used by the app container from a SCM.
○ Running some startup scripts
○ Wait for a service to be created before the pod etc.