Also this error might not occur every time you delete a pod. Why this error sometimes: The Core Issue: Static Pod Selection The fundamental reason for this inconsistency is that kubectl port-forward, even when you specify a service name, actually selects a single, specific pod instance behind that service and tunnels traffic only to that one pod. It does not create a persistent, load-balanced tunnel to the service abstraction itself that automatically switches to a new pod if the current one disappears. When the Error Occurs The "error: lost connection to pod" message is guaranteed to appear if you specifically target a pod by its unique name, and then delete that exact pod instance. However, when you target a Service with the kubectl port-forward service/my-app 8080:80 command, one of two things happens: Error Occurs: The kubectl command initially picks one running pod (let's call it pod-A). If you delete pod-A while the command is running, the connection is lost, and you see the error message in your terminal. The command then terminates. Error Does Not Occur: If the kubectl command happens to pick a pod that is not the one you manually deleted, the connection remains active to the still-running, chosen pod, and you won't see the error. The error message is normal confirmation that the specific network tunnel you established has broken because its target no longer exists. The inconsistency arises because targeting a service is just a convenient shortcut for selecting one specific pod, and it might not always select the pod you are actively deleting.

Does anybody have anything to add to this?

How about the land down under. How do the stats compare against the US and Europe

Hi @Romyen Sasithorn

Hi @Romyen Sasithorn Who are you? @Romyen Sasithorn or @Linda Fox