Your company has an application running as a Deployment in a Google Kubernetes Engine (GKE) cluster. When releasing new versions of the application via a rolling deployment, the team has been causing outages. The root cause of the outages is misconfigurations with parameters that are only used in production. You want to put preventive measures for this in the platform to prevent outages. What should you do?
Configuring liveness and readiness probes in the Pod specification ensures that only healthy Pods are serving traffic. Liveness probes check if the application inside the Pod is running, and readiness probes check if the application is ready to serve traffic. By setting up these probes, you can avoid routing traffic to misconfigured or non-functional Pods during rolling deployments, thus preventing outages caused by production-only parameter misconfigurations.
A: Configuring the right liveness and readiness probes prevents outages when rolling out a new ReplicaSet of a Deployment, because Pods are only getting traffic when they are considered ready. B: With GKE, you do not deal with MIGs. C: Does not use GKE tools and is therefore not the best option. D: Does alert you but does not prevent the outage.
more explanation in the below link..https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-setting-up-health-checks-with-readiness-and-liveness-probes
A. There are no MIGs in GKE. Only thing that makes sense is to have good readiness probes
Configure liveness and readiness probes in the Pod specification. This will help to prevent outages by ensuring that only healthy Pods are serving traffic. The liveness probe will check that the Pod is running and responding to requests. The readiness probe will check that the Pod is ready to serve traffic, such as by checking that the application is installed and configured.
Option A is correct. Since it is regarding GKE and the application deployed in GKE cluster. Therefore, managed instance group does not have anything to do. So, right answer is: A. Configure liveness and readiness probes in the Pod specification.
A is the answer. Kubernetes Health Checks with Readiness and Liveness Probes https://www.youtube.com/watch?v=mxEvAPQRwhw
Liveness and readiness probes are used to determine the health of a Pod. Liveness probes are used to determine whether a Pod is running, and readiness probes are used to determine whether a Pod is able to receive traffic. By configuring liveness and readiness probes in the Pod specification, you can help to prevent outages when releasing new versions of the application via a rolling deployment. If a Pod fails a liveness or readiness probe, it will be restarted, which can help to prevent issues caused by misconfigured parameters or other problems. The correct answer is A: Configure liveness and readiness probes in the Pod specification.
Option B: Configuring health checks on the managed instance group is not relevant in this scenario, as the application is running in a GKE cluster, not on a managed instance group. Option C: Creating a Scheduled Task to check whether the application is available may help to detect outages, but it will not prevent them from occurring. To prevent outages, you should focus on identifying and addressing the root cause of the problem. Option D: Configuring an uptime alert in Cloud Monitoring may help to detect outages, but it will not prevent them from occurring. To prevent outages, you should focus on identifying and addressing the root cause of the problem.
D. Configure an uptime alert in Cloud Monitoring. Configuring an uptime alert in Cloud Monitoring will notify the team when the application becomes unavailable. This will help in detecting outages before they occur and mitigate the risks of releasing new versions with misconfigurations. While configuring liveness and readiness probes in the Pod specification and configuring health checks on the managed instance group are important for ensuring that the application is running, they do not prevent outages caused by misconfigurations with production parameters. Creating a Scheduled Task to check whether the application is available is also useful, but it is not preventive in nature. By the time a scheduled task detects an outage, the damage may have already been done.
why not A ? * Configuring liveness and readiness probes in the Pod specification is important to detect when a container in a Pod becomes unresponsive or starts experiencing problems. However, it does not directly prevent outages caused by misconfigurations with parameters that are only used in production. Liveness and readiness probes can help to detect issues with the application, but they do not provide information about the health of the underlying infrastructure. Misconfigurations with parameters that are only used in production can cause problems with the infrastructure itself, which may not be detected by liveness and readiness probes. In summary, while configuring liveness and readiness probes is important, it should be done in addition to other preventive measures such as configuring an uptime alert in Cloud Monitoring to ensure timely detection of outages and reduce their impact on the application.
A without any doubts
B is out since MIGs relate to compute engine. D and C are both not preventive measures.
A is best answer
A is ok
A Is the Correct Answer
Who answered aside from A never read/implementes kubernetes best practices. Link https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-creating-a-highly-available-gke-cluster
Right answer is D. Liveness and readiness probes (option A) are essential for overall application health but might not directly detect misconfigurations during deployments. They focus on ensuring pods are healthy and responsive, not necessarily catching configuration issues.
uptime and monitoring will not stop outages in application, howver you will be informed on time to respond to the issue. A. Configuring liveness and readiness probe in each pod will stop starting pods from receiving traffic before they are declared ready and available. hence before taking down a working pod.
There is not such a thing as Managed compute instances in GKE https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-setting-up-health-checks-with-readiness-and-liveness-probes