kubernetes将tty设置为false不能按我预期的那样工作

问题描述

请考虑以下清单：

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进入容器。但是，我仍然可以做到！

我已经读过this answer，但我的问题是“其他方式”：我将tty设置为false，但仍然可以在容器中执行命令

我误会了什么？

解决方法

kubectl exec是一个调试工具，可在现有容器的容器内产生一个额外的进程。该附加进程可以独立地附加或不附加虚拟tty。另外，只要它仍然可以从其stdin读取命令并向其stdout写入响应，通常还可以运行带有或不带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 和stdout数据，但通过附加，您还可以发送stdin 从终端到程序。很棒的交互式调试，甚至只是将ctrl-c发送到行为异常的应用程序。

此处的区别在于您与之交互的过程。 Attach将与当前运行的互动（没有选择）。

kubernetes kubernetes-pod tty