请考虑以下清单：
apiVersion: v1
kind: Pod
metadata:
name: firstpod
spec:
containers:
- name: container2
image: varunuppal/nonrootsudo
tty: false
stdin: false
我在这里读到tty表示">
Whether this container should allocate a TTY for itself
所以如果理解得很好，把它设置为 false，应该不可能用 kubectl exec -ti firstpod bash 跑到容器中。但是，我仍然可以做到这一点!!
我已经阅读了这个答案，但我的问题是"另一种方式"：我将tty设置为false，但仍然可以在容器中执行命令
我误解了什么？
kubectl exec是一个调试工具，它会在现有 Pod 的容器中生成一个额外的进程。 该附加进程可以独立地附加虚拟 tty，也可以不附加。 另外，您通常也可以运行一个附加或不附加 tty 的交互式 shell，只要它仍然可以从其 stdin 读取命令并对其 stdout 写入响应。
在实践中，你几乎不需要为 Kubernetes 容器设置tty: true。 设置或不设置它不仅会影响容器中的主进程，而不会影响您使用kubectl exec或其他类似调试工具启动的任何内容。
如果你的目标是防止kubectl exec那么你需要使用 Kubernetes 权限系统来禁止它。 在某些情况下，可以构建一个不包含 shell 的非常强化的容器，这也将有效地禁用kubectl exec(尽管它也使某些类型的调试变得更加困难);只有当您使用编译语言并且不需要复杂的启动器脚本(最常见的是静态链接的 Go 程序的FROM scratch图像)时，这才真正可能。
不久前，我在kubectl exec文章中遇到了这个深入的文章，我认为您可能会觉得有趣。
第二个是这个堆栈案例，其中一个社区用户通过并显示容器以-i和 -t开头和没有这些的几个过程差异。
最后值得一提的是，您还有kubectl attach可供使用：
除了交互式执行命令外，您现在还可以 附加到任何正在运行的进程。像kubectl logs一样，你会得到stderr。 和标准输出数据，但通过附件，您还可以发送标准输出 从您的终端到程序。非常适合交互式调试， 甚至只是将 Ctrl-C 发送到行为异常的应用程序。
这里的区别在于您与之交互的过程。Attach将与当前正在运行的交互(别无选择)。