Deploying Pods on GKE: Upgrading to n2"highmem"16 Nodes Without Downtime

Upgrading to n2"highmem"16 Nodes Without Downtime

Question

Your existing application running in Google Kubernetes Engine (GKE) consists of multiple pods running on four GKE n1"standard"2 nodes.

You need to deploy additional pods requiring n2"highmem"16 nodes without any downtime.

What should you do?

Answers

Explanations

Click on the arrows to vote for the correct answer

A. B. C. D.

B.

The correct answer is B. Create a new Node Pool and specify machine type n2"highmem"16. Deploy the new pods.

Explanation: Google Kubernetes Engine (GKE) allows you to manage and deploy containerized applications on a cluster of virtual machines (nodes). Each node has a defined set of compute resources such as CPU, memory, and disk space. Nodes can be grouped into node pools based on their machine type, which determines their compute capacity.

To deploy additional pods requiring n2"highmem"16 nodes without any downtime, we need to create a new node pool with the required machine type and then deploy the new pods to that node pool. The existing pods will continue to run on the existing node pool until we are ready to migrate them to the new node pool.

Option A (Use gcloud container clusters upgrade. Deploy the new services) is incorrect because gcloud container clusters upgrade is used to upgrade an existing GKE cluster to a new version, not to add new nodes or node pools.

Option C (Create a new cluster with n2"highmem"16 nodes. Redeploy the pods and delete the old cluster) is incorrect because it involves creating a new cluster from scratch and migrating all the existing pods to the new cluster, which will result in downtime.

Option D (Create a new cluster with both n1"standard"2 and n2"highmem"16 nodes. Redeploy the pods and delete the old cluster) is also incorrect because it involves creating a new cluster with both node types, which is not necessary since we only need to add new pods with the higher resource requirements. Additionally, it involves redeploying all the existing pods to the new cluster, which will result in downtime.

Therefore, the best approach is to create a new node pool with the required machine type, deploy the new pods to the new node pool, and gradually migrate the existing pods to the new node pool to avoid any downtime.