Application Lifecycle Management

Summary

•  Rolling Updates and Rollbacks in Deployments
•  Configure Applications
•  Scale Applications
•  Self-Healing Application

Rolling Updates and Rollbacks in Deployments

Deployment strategy: there is two strategies

• Recreate : delete all pods and create new pods ==> unavailability of applications

spec:
 strategy:
   type: Recreate

• Rolling Update : delete and create pods one by one or 2 by 2 ... (default strategy in K8S)

spec:
 strategy:
   type: RollingUpdate
   rollingUpdate:
     maxUnavailable: 0
     maxSurge: 1

Summarize Commands
kubectl rollout status deployment/myapp-deployment (know the status of the rolling update)
kubectl rollout history deployment/myapp-deployment (know histroy revisions to apply a rollout undo with a specific revision)
kubectl create –f deployment-definition.yml
kubectl get deployments
kubectl apply –f deployment-definition.yml
kubectl set image deployment.apps/deployment-name container-name=new-image-name
kubectl rollout undo deployment/myapp-deployment (undo to a specific revision:kubectl rollout undo deployment.apps/demo-app --to-revision=2)

 

Configure Applications

Configure application need to understand : configuring  command and arguments on applications, Environnement variables and secrets

Configure command are in docker files or pod definition :

docker file :
from Ubuntu
CMD sleep 5
commands:
docker build -t ubuntu-sleeper
docker run ubuntu-sleeper

CMD command param1 : CMD sleep 5
CMD["command","param1"] : CMD["sleep","5"]

The parameter '5' is hard coded, if we want to run a container and changing parameters during pod running like docker run ubuntu-sleeper 10 (argument)

docker file with cmd as argument:
FROM Ubuntu
ENTRYPOINT["sleep"]
CMD["5"]

commands with the file over :
docker run --name ubuntu-sleeper ubuntu-sleeper 10 or docker run --entrypoint sleep2.0 ubuntu-sleeper 10

Pod definition : 'command' replace 'ENTRYPOINT in a docker file and args the CMD in a docker file. the file is the equivalent of 'docker run --entrypoint sleep2.0 ubuntu-sleeper 10'

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-sleeper-pod
spec:
  containers:
  - name: ubuntu-sleeper
    image: ubuntu-sleeper
    command: ["sleep2.0"]
    args: ["10"]

 

For configuration of variables env, there is various methodes :

- Key value method :

apiVersion: v1
kind: Pod
metadata:
  name: envar-demo
  labels:
    purpose: demonstrate-envars
spec:
  containers:
  - name: envar-demo-container
    image: gcr.io/google-samples/node-hello:1.0
    env:
    - name: DEMO_GREETING
      value: "Hello from the environment"
    - name: DEMO_FAREWELL
      value: "Such a sweet sorrow"

- ConfigMapkeyref method

apiVersion: v1
kind: Pod
metadata:
  name: envar-demo
  labels:
    purpose: demonstrate-envars
spec:
  containers:
  - name: envar-demo-container
    image: gcr.io/google-samples/node-hello:1.0
    env:
    - name: DEMO_GREETING
      valueFrom:
          configMapKeyRef: - SecretKeyRef method apiVersion: v1
kind: Pod
metadata:
  name: envar-demo
  labels:
    purpose: demonstrate-envars
spec:
  containers:
  - name: envar-demo-container
    image: gcr.io/google-samples/node-hello:1.0
    env:
    - name: DEMO_GREETING
      valueFrom:
          secretKeyRef:

Details of ConfigMaps:

when we have a lot of env variables, it's important to use configMaps :

create a configMap imperative:

kubectl create configmap \  name-configmap --from-literal=APP_COLOR_KEY=blue_value

kubectl create configmap \ 
  name-configmap --from-file=appconfig.properties

or declarative:

apiVersion: v1
kind: ConfigMap
metadata:
  name: game-demo
data:
  # property-like keys; each key maps to a simple value
  player_initial_lives: "3"
  ui_properties_file_name: "user-interface.properties"

kubectl create -f config-map.yaml
kubectl get configmaps

to inject config map into a pod:

apiVersion: v1
kind: Pod
metadata:
  name: envar-demo
  labels:
    purpose: demonstrate-envars
spec:
  containers:
  - name: envar-demo-container
    image: gcr.io/google-samples/node-hello:1.0
    envFrom:
    - configMapKeyRef:
          name: app-configmap

 

there is also many method to inject configmap into a pod definitoon yaml plus envForm:

Single env :

env:
- name: DEMO_GREETING
  valueFrom:
        configMapKeyRef:
           name: app-config
           key: APP_COLOR

Volume:

volumes:
- name: app-config-volume configMap: name: app-config

Details of Secrets method:

- Create a secret imperative:

kubectl create secret \ 
name-secret --from-literal=DB_HOSTY=mysql \
            --from-literal=DB_User=root
            --from-literal=DB_Password=passwrd
or

kubectl create secret \ 
name-secret --from-file=appsecret.properties

- Create a secret declarative

apiVersion: v1
kind: secret
metadata:
  name: app-secret
data:
  DB_Host: mysql
  DB_User: root
  DB_Password: passwrd

kubectl create -f secret-data.yaml

kubectl get secrets

to inject secret created before into a pod:

apiVersion: v1
kind: Pod
metadata:
  name: envar-demo
  labels:
    purpose: demonstrate-envars
spec:
  containers:
  - name: envar-demo-container
    image: gcr.io/google-samples/node-hello:1.0
    envFrom:
    - secretRef:
          name: app-secret

There is also many method to inject secrets into a pod definition yaml rather than envForm:

Single env :

env:
- name: DB_PASSWORD
  valueFrom:
        secretKeyRef:
           name: app-secret
           key: DB_Password

Volume:

volumes:
- name: app-secret-volume secret: secretName: app-secret

To check volumes inside container : ls /opt/app-secret-volumes or cat /opt/app-secret-volumes/DB_Password

Secret are not encrypted in  etcd

Don't forget to consider secrets providers : Vault Provider (https://www.vaultproject.io/), AWS Provider....

Scale Applications

Scale application with creating other containers by changing or yaml file, we can use multi-container or sidecar when we need an agent :

apiVersion: v1
kind: Pod
metadata:
  name: simple-webapp
  labels:
      name: simple-webapp
spec:
    containers:
    - name: simple-webapp
       image: simple-webapp
     ports:
         - containerPort: 8080
  - name: log-agent
    image: log-agent

There are tree pattern for multi-container Pods : SideCar, Adapter and Ambassador

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, for more information :

https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

Self-Healing Application

For self healing application, two concept are used : through Liveness and Readiness Probes