到目前为止,我看到有三个地方可能适用,每个地方都有优缺点:
echo $HOSTNAME
或 hostname
cat /proc/self/cgroup
cat /proc/self/mountinfo
$HOSTNAME
很容易,但是它是部分的,并且也会被 K8s 覆盖为 pod 名称。
/proc/self/cgroup
在使用 cgroupV1 时似乎有效,但在 cgroupV2 中不可用。
/proc/self/mountinfo
对于 cgroupV2 仍将具有容器 ID,但是挂载点将根据不同的容器运行时具有不同的值。
678 655 254:1 /docker/containers/7a0144cee1256c539fab790199527b7051aff1b603ebcf7ed3fd436440ef3b3a/resolv.conf /etc/resolv.conf rw,relatime - ext4 /dev/vda1 rw
在
ContainerD
中(最近的K8s默认引擎),它看起来像这样:
1733 1729 0:35 /kubepods/besteffort/pod3272f253-be44-4a82-a541-9083e68cf99f/7a0144cee1256c539fab790199527b7051aff1b603ebcf7ed3fd436440ef3b3a /sys/fs/cgroup/blkio ro,nosuid,nodev,noexec,relatime master:17 - cgroup cgroup rw,blkio
此外,所有上述的最大问题是它们都是实现,没有抽象化,而且它们随时可能会改变。有一个正在努力将其标准化的项目,我认为值得关注:
https://github.com/opencontainers/runtime-spec/issues/1105
/var/run/docker.sock
权限,可以轻松地打破 Docker 提供的封闭环境,并获取主机的权限。显然,这可能是危险的。 - ProgrammingLlama