Your company has a Kubernetes application that pulls messages from Pub/Sub and stores them in Filestore. Because the application is simple, it was deployed as a single pod. The infrastructure team has analyzed Pub/Sub metrics and discovered that the application cannot process the messages in real time. Most of them wait for minutes before being processed. You need to scale the elaboration process that is I/O-intensive. What should you do?

The correct answer is to configure a Kubernetes autoscaling deployment based on the subscription/numundeliveredmessages metric. This metric directly reflects the backlog of messages in Pub/Sub, indicating when the application is falling behind. By scaling based on this metric, new pods are created precisely when the message queue grows, ensuring timely processing. The other options are less effective: kubectl autoscale deployment APPNAME --max 6 --min 2 --cpu-percent 50 scales based on CPU utilization. Since the problem states the process is I/O-intensive, CPU might not be the bottleneck, leading to inefficient scaling. Configuring autoscaling based on subscription/pushrequestlatencies measures how long it takes for Pub/Sub to deliver messages, not necessarily the application's processing speed or backlog. Using the --enable-autoscaling flag when creating the cluster enables cluster autoscaling (adding/removing nodes), not horizontal pod autoscaling (adding/removing pods) for a specific deployment based on application metrics.