Other Deployment strategies
1. Other Deployment strategies
GKE supports multiple deployment strategies to give you the flexibility and control over how you introduce changes and updates to your applications. Let’s briefly explore three primary deployment options: recreate deployment, blue/green deployment, and canary test. First, you can use the recreate strategy. Unlike a rolling strategy, where both old and new Pods are running simultaneously, the recreate strategy is to delete the old Pods before creating new ones. The advantage of this strategy is that once the new Pods are available, all users will gain access to the updated deployment at the same time. The disadvantage is that because all Pods won’t be instantly available, users will experience disruptions while new Pods are being created. Another option is to use the blue/green deployment strategy. This strategy is to create a completely new Deployment with a newer version of the application. Blue refers to the old version, and green refers to the new version. When the Pods are ready, the traffic can be switched from the old blue version to the new green version. Then, Pods in the blue deployment version will be deleted. The advantage of this strategy is that the rollouts are instantaneous, and the newer versions can be tested internally before releasing them to all users. The disadvantage is that resource usage is doubled during the Deployment process, resulting in cost increases, capacity constraints, and inefficiencies. Finally, the canary update strategy is to gradually move traffic to the new version of your application. The main advantage of this strategy is that it minimizes excess resource usage during the update. Also, because the rollout is gradual, issues can be identified before they affect all instances in the application. The disadvantages are that canary deployments are often slower and may require tools like Anthos Service Mesh to accurately move the traffic to the new version. Now, what if there’s an issue with a deployment? You’ll likely need to undo, or “roll back” the update by using the kubectl rollout undo command. The rollout undo command will revert the Deployment to the previous version or to a different version that you specify. Using the kubectl rollout history command, you can inspect the rollout history. By default, the previous 10 ReplicaSets are retained. You can change the default by specifying a revision history limit in the Deployment specification. The kubectl rollout undo and kubectl rollout history commands can also be run from Cloud Shell in the Google Cloud console. You can view a revision list before making any changes. Typically, an automatic rollout is triggered when a deployment is edited, so frequent updates with small fixes will lead to a large amount of rollouts. In these situations, it can be difficult to pinpoint which specific rollout is causing a problem. You can use the kubectl rollout pause command to halt the rollout so that you can troubleshoot. Please note that any new changes to the deployment will only be implemented after the rollout is resumed by using the kubectl rollout resume command. Then all new changes will be released as one new version. To monitor the status of a rollout, you can use the kubectl rollout status command. Finally, you can use the kubectl delete command to delete a rollout, or you can delete it by using the Google Cloud console. Kubernetes will delete all resources managed by the Deployment, including any running Pods.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.