You have an application deployed on Google Kubernetes Engine using a Deployment named echo-deployment. The deployment is exposed using a Service called echo-service. You need to perform an update to the application with minimal downtime to the application. What should you do?
To perform an update to a Kubernetes Deployment with minimal downtime, you should use the command 'kubectl set image deployment/echo-deployment <new-image>'. This command will trigger a rolling update, which ensures that the new image is deployed to the pods incrementally while keeping the desired number of pods available throughout the update process. This method avoids downtime by updating the pods one by one, maintaining service availability.
A is correct. B is funny
A is ok
Yes A is correct
Only logical answer is A.
B looks most sensible (not funny). rolling update is a deployment strategy, which will deploy on pods 1 by 1,. i.e. by the time first pod is getting newer version of application, other pods are running with older version... In this way, there will be no downtime of application.. which is real ask from this question. I recommend B
Use the rolling update functionality of the >[Instance Group behind the Kubernetes cluster]<. It's not a rolling update of a Deployment. Read carefully.
Correct is A
https://cloud.google.com/kubernetes-engine/docs/how-to/updating-apps says rolling updates and mentions same command . So 100 % A
Source: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment Deployment ensures that only a certain number of Pods are down while they are being updated. By default, it ensures that at least 75% of the desired number of Pods are up (25% max unavailable). Deployment also ensures that only a certain number of Pods are created above the desired number of Pods. By default, it ensures that at most 125% of the desired number of Pods are up (25% max surge).
Example from official Kubernetes docu (for NGINX): kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
To perform an update to the application with minimal downtime on Google Kubernetes Engine (GKE), you can use a rolling update strategy, which involves updating the application incrementally, one pod at a time, while ensuring that the updated pods are functioning properly before updating the next set. Here's the general process: kubectl set image deployment/echo-deployment echo=<new_image_tag>
https://cloud.google.com/kubernetes-engine/docs/how-to/updating-apps#updating_an_application
I think A is correct: B. I don't understand the objective of this option. C and D. These are eliminated because they involve suffering a downtime when the resources are eliminated, so they are not fulfilling one of the requirements.
The correct answer is C: Update the deployment yaml file with the new container image. Use kubectl delete deployment/echo-deployment and kubectl create –f <yaml-file>. To perform an update to an application deployed on Google Kubernetes Engine with minimal downtime, you can follow these steps: Update the deployment yaml file with the new container image. Use the kubectl delete deployment/echo-deployment command to delete the existing deployment. Use the kubectl create –f <yaml-file> command to create a new deployment using the updated yaml file. This process, known as a rolling update, allows you to update your application with minimal downtime by replacing the old version of the application with the new version one pod at a time, while ensuring that there is always at least one pod available to serve traffic.
Option A: Using kubectl set image deployment/echo-deployment <new-image> will update the image of the containers in the deployment, but it will not perform a rolling update and may result in downtime for the application. Option B: Using the rolling update functionality of the Instance Group behind the Kubernetes cluster is not a valid option, as the rolling update functionality is used to update the instances in the instance group, not the containers in a deployment. Option D: Updating the service yaml file with the new container image and using kubectl delete service/echo-service and kubectl create –f <yaml-file> is not a valid option, as the service is not responsible for running the application containers and updating the service will not update the application.
A is correct, update template spec image in deployment yml will trigger rollout deploy
Answer is A, you are wrong as hell, if you delete deployment its obvious app will face downtime
using kubectl set image deployment/deployment <new-image> will not allow you to perform an update to the application with minimal downtime, even if the deployment is exposed using a Service. This command will update the image of the containers in the deployment, but it will not perform a rolling update. A rolling update allows you to update your application with minimal downtime by replacing the old version of the application with the new version one pod at a time, while ensuring that there is always at least one pod available to serve traffic. Without a rolling update, all of the pods in the deployment will be replaced at the same time, which may result in downtime for the application.
A https://cloud.google.com/kubernetes-engine/docs/how-to/updating-apps#updating_an_application
It's definitely A. See here under updating a deployment on the right hand side. https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment
Answer is A It can't be C, if you delete and recreate the deployment you will have a downtime between the deletion and the recreation.
ok for A
A is right -- kubectl set image deployment/echo-deployment
C. Update the deployment yaml file with the new container image. Use kubectl delete deployment/echo-deployment and kubectl create ג€"f <yaml-file> I agreed with omermahgoub with his explanation.
delete.. minimal downtime.. A is correct ^_^U
Option C - is the best option to perform an update to an application deployed on Google Kubernetes Engine with minimal downtime because it provides control over the update process, ensures high availability, and minimizes disruption. Rolling update functionality can also be used but requires more effort to implement. Option A and Option D may result in downtime if the new image is incompatible with the existing application.
It's A. As per K8s documentation: To update the image of the application to version 2, use the set image subcommand, followed by the deployment name and the new image version: kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=docker.io/jocatalin/kubernetes-bootcamp:v2 The command notified the Deployment to use a different image for your app and initiated a rolling update." "