使systemctl在debian拉伸映像中从容器内部工作。

Question

目的-我想达到什么目的？

我想从运行kubernetes节点的容器中访问systemctl (ami:运行debian扩展)

工作装置：

• kope.io/k8s-1.10-debian-jessie-amd64-hvm-ebs-2018-08-17：节点AMI
• 安装在容器中以使systemctl工作的节点目录：

- /var/run/dbus
- /run/systemd
- /bin/systemctl
- /etc/systemd/system

​

不工作设置：

• kope.io/k8s-1.11-debian-stretch-amd64-hvm-ebs-2018-08-17：节点AMI
• 安装在容器中以使systemctl工作的节点目录：

- /var/run/dbus
- /run/systemd
- /bin/systemctl
- /etc/systemd/system

​

为解决问题而进行的调试

在不支持与debian-stretch相同挂载的systemctl的systemctl映像中调试此问题

1)我首先通过在nginx中安装上面提到的卷来编制nginx部署。

kubectl apply -f https://k8s.io/examples/application/deployment.yaml

kubectl exec -it nginx-deployment /bin/bash

root@nginx-deployment-788f65877d-pzzrn:/# systemctl
systemctl: error while loading shared libraries: libsystemd-shared- 
232.so: cannot open shared object file: No such file or directory

2)如上述问题所示，未找到文件libsystemd-shared-232.so。我通过查看节点找到了实际的路径。

admin@ip-10-0-20-11:~$ sudo find / -iname 'libsystemd-shared-232.so'
/lib/systemd/libsystemd-shared-232.so

3)将/lib/systemd安装在nginx吊舱中，并再次运行systemctl。

 kubectl exec -it nginx-deployment /bin/bash

 root@nginx-deployment-587d866f54-ghfll:/# systemctl
 systemctl: error while loading shared libraries: libcap.so.2:cannot 
 open shared object file: No such file or directory

4)现在systemctl失败了，出现了一个新的丢失错误

root@nginx-deployment-587d866f54-ghfll:/# systemctl
systemctl: error while loading shared libraries: libcap.so.2: cannot 
open shared object file: No such file or directory

5)为了解决上述错误，我再次搜索节点，寻找libcap.so.2，在下面的路径中找到它。

admin@ip-10-0-20-11:~$ sudo find / -iname 'libcap.so.2'
/lib/x86_64-linux-gnu/libcap.so.2 

( 6)看到上面的目录没有安装在我的舱内。我把下面的小径安装在尼克斯舱里。

/lib/x86_64-linux-gnu mounted in the nginx pod(deployment)

( 7)添加上述支架后，nginx荚不能上浮。获取以下错误：

$ k logs nginx-deployment-f9c5ff956-b9wn5
standard_init_linux.go:178: exec user process caused "no such file 
or directory"

请建议如何进一步调试。以及在debian扩展环境中，要使systemctl从容器内部工作所需的所有安装。

任何进一步进行调试的指针都可能有帮助。

Answer 1

您可以只在容器中安装systemd，而不是从主机挂载一些库文件。

$ apt-get -y install systemd

现在，这并不一定会使systemctl运行。您需要在您的容器中运行systemd，这是由/sbin/init在您的系统上生成的。/sbin/init需要以根用户的形式运行，因此您必须在Kubernetes上使用privileged标志或容器安全上下文来运行它。现在，这是不安全的，而且是关于在容器中运行systemd的有着悠久的历史，在容器中，码头工人主要反对它(安全性)，而红帽人员说它是必需的。

尽管如此，红帽的人们还是想出了一条通往标志的途径。你需要：

• /run作为tmpfs在容器中挂载。
• 安装为只读的/sys/fs/cgroup是可以的.
• /sys/fs/cgroup/systemd/挂载为读/写。
• 用于STOPSIGNAL SIGRTMIN+3

在Kubernetes中，您需要一个emptyDir来挂载tmpfs。其他的可以作为主机卷挂载。

Answer 2

将主机的/lib目录挂载到容器中之后，Pod很可能不会启动，因为Docker映像的/lib目录包含Nginx服务器需要的一些库，这些库应该在容器中启动。通过从主机挂载/lib，Nginx所需的库将不再可访问。这将导致在尝试启动Nginx时没有这样的文件或目录错误。

为了使systemctl从容器中可用，我建议只在容器中安装它，而不是尝试将所需的二进制文件和库安装到容器中。这可以在容器的Dockerfile中完成

FROM whatever

RUN apt-get update && apt-get install systemd

无需使用此解决方案挂载/bin/systemd或/lib/。

Answer 3

我遇到了类似的问题，我的Dockerfile中的一行是:运行apt-get安装-y --重新安装systemd，但是在docker重新启动之后，当我尝试使用systemctl命令时。输出是:未能连接到总线:没有这样的文件或目录。为了解决这个问题，我将以下内容添加到我的docker -Compose.yml中:卷：- " /sys/fs/cgroup:/sys/fs/cgroup:ro“它也可以通过以下方法完成: sudo运行-d -v /sys/fs/fs/cgroup:/sys/fs/cgroup:ro{其他选项}