Empiricamente, parece kubectl exece sshse comporta de maneira diferente nas desconexões do cliente.
Realizei os seguintes experimentos.
SSH
# Terminal 1
ssh <random_host_in_aws>
bash -c 'sleep 600000'
Terminal 2
kill -9 <pid_of_ssh_process>
ssh <random_host_in_aws>
ps aux | grep sleep
# No sleep processes
Executivo Kubectl
# Terminal 1
kubectl exec ...
bash -c 'sleep 600000'
# Terminal 2
kill -9 <pid_of_kubectl_process>
kubectl exec ...
ps aux | grep sleep
# Sleep process is still around.
Existe alguma configuração mágica no cluster ou cliente Kubernetes que o forçará a se comportar da mesma maneira que sshdiante de desconexões do cliente?
SSH e Kubectl são bem diferentes.
Com o protocolo SSH, há uma conexão entre o cliente SSH e o servidor SSH, há tráfego TCP indo e voltando, parte desse tráfego é uma sessão shell que executa o bash no caso que você descreveu, e alguns ping/pong trânsito também. Quando esta conexão TCP for interrompida (porque você matou o cliente SSH) e o servidor SSH não receber mais comunicação do cliente SSH, ele encerrará a sessão shell, enviando um sinal de "desligamento" para qualquer processo dentro dessa sessão, encerrando assim seu bash shell e o processo sleep gerado dentro desse shell.
Com kubectl exec, você está transmitindo interativamente seu terminal para o terminal de contêiner (kubectl -> servidor API -> Kubelet -> runc-exec), e qualquer processo executado lá continuará em execução, independentemente de você ainda estar transmitindo ou interrompeu o streaming eliminando o processo kubectl do cliente. Sequências de controle como Ctrl+C também são transmitidas para o contêiner.
Não acho que seja possível obter um comportamento semelhante ao SSH com kubectl exec sem alguns scripts de ping/pong. Se você precisar encerrar um processo em execução dentro do contêiner, encontrar seu pid e matá-lo dentro do contêiner é provavelmente o caminho a percorrer.
Algumas discussões relacionadas/semelhantes aqui sobre este problema: https://github.com/opencontainers/runc/issues/3359