考虑以下清单：
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
so 如果理解好的话，设置为false，用kubectl exec -ti firstpod bash 应该是不可能跑到容器里的。不过，我还是可以的！！！
我已阅读 this answer ，但我的问题是“其他方式”：我将 tty 设置为 false 但仍然可以在容器中执行命令
我误会了什么？
【问题讨论】：
标签： kubernetes kubernetes-pod tty
kubectl exec 是一个调试工具，它在现有 pod 的容器中生成一个额外的进程。该附加进程可以独立地附加一个虚拟 tty，也可以不附加。另外，您通常也可以运行带有或不带有 tty 的交互式 shell，只要它仍然可以从其标准输入读取命令并将响应写入其标准输出。
实际上，您几乎不需要为 Kubernetes 容器设置 tty: true。设置与否不仅会影响容器中的主进程，不会影响您使用kubectl exec 或其他类似调试工具启动的任何内容。
如果您的目标是阻止kubectl exec，那么您需要使用 Kubernetes 权限系统来禁止它。在某些情况下，可以构建一个不包含外壳的非常坚固的容器，这也会有效地禁用kubectl exec（尽管它也会使某些类型的调试变得更加困难）；这只有在您使用编译语言并且不需要复杂的启动器脚本（通常是静态链接的 Go 程序的 FROM scratch 图像）时才真正可行。
【讨论】：
不是这样，不久前我在article 中遇到了这种潜入kubectl exec，我认为您可能会觉得有趣。
第二个是stack 案例，其中一个社区用户通过并显示与以-i 和-t 开头的容器的几个进程差异，而没有这些。
最后值得一提的是，您还可以使用 kubectl attach：
除了交互式执行命令，您现在还可以 附加到任何正在运行的进程。像 kubectl 日志一样，你会得到 stderr 和标准输出数据，但通过附加，您还可以发送标准输入 从您的终端到程序。非常适合交互式调试， 甚至只是将 ctrl-c 发送到行为不端的应用程序。
这里的区别在于您与之交互的过程。 Attach 将与当前运行的那个交互（没有选择）。
【讨论】：