● RollingUpdate
It is the default rollout strategy for update in Kubernetes.
With this strategy, Kubernetes gradually replaces the old ReplicaSet with the new ReplicaSet, as described above.
It replaces pods, one by one, of the previous version of our application with pods of the new version without any cluster downtime.
The update is applied Pod-by-Pod. (OR) It update one-by-one from the old Pods to the new Pods.
It will delete a one old Pod with old version and creates a one new Pod with new version. This will be repeated for the other Pods one-by-one.

● Recreate
With this strategy, Kubernetes first scales down the old ReplicaSet to zero replicas, and then scales up the new ReplicaSet to the desired number of replicas.
This strategy is less common than RollingUpdate, as it can cause downtime during the rollout process.

● Blue/Green
Blue environment - The current production environment that runs the existing version of the application.
Green environment - The new environment that runs the updated version of the application.
It reduces downtime and risk by running two identical production environments called Blue and Green.
So, instead of updating the current production (blue) environment with the new application version, a new production (green) environment is created.
When it’s time to release the new application, version traffic is routed from the blue environment to the green environment.
So, if there are any problems, deployment can be easily rolled back.
                                  |---------------------> Blue (Live App Version 1)
                                  |   100% Traffic            ⇅               
                                  |                           ⇅               switch traffic from Version 1 to Version 2          
                                  |                           ⇅
                                  |                           ⇅               if any thing wents wrong with new feature app in Version 2
        DNS_Load_Balancer --------|                           ⇅                
                                  |                           ⇅               simply disconnect the DNS_Load_Balancer from Version 2 and connect back to the Version 1, must run both the new and old versions concurrently and its become costly 
                                  |                           ⇅
                                  |                           ⇅               switch traffic from Version 2 to Version 1 
                                  |                           ⇅
                                  |---------------------> Green (App with new features Version 2)   

● Canary
In the process, 90% of production traffic may still go through the older version while only 10% goes through the newer one.
                                         USER
                                          |
                                          |
                                90%       |      10%
                            -------------ELB-------------
                            |                           |
                            |                           |
                            |                           |
                         V1(old)                    V2(new)
Ingress manifest YAML file in annotations has to enable the Canary option:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "10"
