Troubleshooting

The kubectl top pods command with the namespace flag is the correct way to retrieve CPU and memory metrics for pods, as it queries the metrics-server API to display current resource consumption.

The describe command does not have a show-metrics flag and displays pod specifications rather than live metrics. The get pods command has no resources flag for retrieving metrics. While sort-by=cpu would seem logical, the correct flag is sort-by=memory or sort-by=cpu without the equals sign format, and this option adds unnecessary complexity for the basic requirement.

This tests understanding of kubectl top for monitoring resource usage via metrics-server.

The correct answer is to verify that the Service port definition specifies the correct protocol and that the targetPort matches the container port in the Pod spec.

Let's analyze the scenario step by step:

1. The curl command to the Service DNS name (data-api.backend.svc.cluster.local:443) returns 'connection refused'
2. However, curling the endpoint IP on port 8443 works successfully
3. The endpoints are healthy and kube-proxy/iptables appear correct

This behavior strongly suggests a port mapping or protocol mismatch in the Service definition. The key clue is that connecting to the endpoint IP on port 8443 works, but the Service on port 443 fails. This indicates the Service is likely not properly routing traffic from port 443 to targetPort 8443, possibly due to:
- A protocol mismatch (e.g., Service configured for HTTP but pods expecting HTTPS)
- The targetPort in the Service spec not matching what's actually defined
- The port configuration being incorrect in some way

The other options are incorrect for the following reasons:

The externalTrafficPolicy option is wrong because externalTrafficPolicy only applies to LoadBalancer and NodePort Services, not ClusterIP Services. Since this is a ClusterIP Service, this setting would have no effect.

The TCP/UDP protocol mismatch option is less likely because the error is 'connection refused' not 'connection timed out'. A TCP/UDP mismatch would typically result in no response at all (timeout), not an active refusal. Additionally, HTTPS connections use TCP, so if the curl to the endpoint IP works, the pods are clearly listening on TCP.

The stale iptables rules option is incorrect because the question states that iptables rules appear correct and kube-proxy logs show no errors. If the ClusterIP had been reassigned with stale rules, this would show up in iptables inspection or cause different symptoms like routing to wrong endpoints.

The most probable cause of a 0-byte snapshot file when etcdctl completes successfully with exit code 0 is a permission issue on the target directory.

When the user running the etcdctl snapshot save command lacks write permissions on the destination directory, the command may create an empty file (0 bytes) but fail to write the actual snapshot data. This behavior can occur because:

1. The file creation succeeds (creating an empty file)
2. The actual write operation fails silently
3. etcdctl may still report success (exit code 0) in certain scenarios where the command execution completes but the data write fails

This is a common gotcha in etcd backup operations, especially when running backups as different users or in containerized environments where volume mount permissions may not match the executing user.

The other options are less likely:

• Running a snapshot from a follower node would not produce a 0-byte file. etcdctl handles follower-to-leader communication internally, and if there were an issue, it would typically result in an error message rather than an empty file.

• Missing the --endpoints flag would not cause this behavior. etcdctl defaults to localhost:2379 when no endpoint is specified, and if the endpoint were unreachable, the command would fail with an error rather than produce an empty file. The question also states endpoint connectivity is confirmed.

• Concurrent etcd compaction does not interfere with snapshot operations in a way that produces 0-byte files. etcd snapshots are atomic operations and compaction running simultaneously would not cause empty snapshots - at worst, it might cause a brief delay or a specific error message.