Kubenete study notes (Deployment)

Deploy new version to pods of a service:
1.Modify image name in replication controller’s pod template. Manually delete old pods.
Drawback: slight down time before new pods are created by replication controller.

2.Blue/green deployment:
Use two replication controllers for old/new version (different image name/template label, same replica number).
Change the service’s pod selector to match new template label.
Manually delete old pods.
Drawback: more resources are required

3.Rolling update:
Use two replication controllers for old/new version (different image name/replica number, same appname label but different deployment label, replication controller pod selector matches appname + label, service selector matches appname).
Scale up second replication controller/Scale down first replication controller
kubectl rolling-update [original replication set name] [new replication set name] --image=[new image name]
Drawback: rolling update performed by client, subject to reliability issue

4.Deployment:
Backed by two replication sets for old/new version, replication set name contains hash of pod template
Deployment contains a label selector, a desired replica count, and a pod template
Trigger deployment: kubectl set image deployment [deployment name][containers.name]=[image name]
Change deployment rolling interval: kubectl patch deployment [deployment name] -p '{"spec": {"minReadySeconds": 10}}

Deployment Strategies:

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

Rolling update: Roll out pods of new version gradually
Recreate: Delete old pods at once and create new onces (small down time)
maxSurge controls how many pods with new version are allowed to create during rolling update.
maxUnavailable controls how many pods should be available during rolling update (replication count - max unavailable)

Deployment operations:
View deployment status: kubectl rollout status deployment [deployment name]
View deployment history: kubectl rollout history deployment [deployment name]
Revision history maintains old replication set (inactive), number controlled by: revisionHistoryLimit
Undo deployment: kubectl rollout undo deployment [deployment name] --to-revision=[revision number]
Pause deployment: kubectl rollout pause deployment [deployment name]
Resume deployment: kubectl rollout resume deployment [deployment name]
Do not include number of replica if deployment is updated during rolling out
Define a proper readiness probe to prevent deployment from continuing with bad pod with new version.
kubectl describe deploy [name], condintion: ProgressDeadlineExceeded indicates deployment failed with deadline