如何解决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
将与当前运行的互动(没有选择)。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。