質問: \ systemd-tmpfiles-setup.service ] || rm -f $i; done); \ rm -f /lib/systemd/system/multi-user.target.wants/*;\ rm -f /etc/systemd/system/*.wants/*;\ rm -f /lib/systemd/system/local-fs.target.wants/*; \ rm -f /lib/systemd/system/sockets.target.wants/*udev*; \ rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \ rm -f /lib/systemd/system/basic.target.wants/*;\ rm -f /lib/systemd/system/anaconda.target.wants/*; VOLUME [ "/sys/fs/cgroup" ] CMD ["/usr/sbin/init"] ``` この、`VOLUME [ "/sys/fs/cgroup" ]`が何をやっているのかわかりません。 kubernetesで上記imageをpodにしましたが、CentOSの`/sys/fs/cgroup`には `systemd`の空ディレクトリがあるのみで、 自分としては、 1、ホスト側の`/sys/fs/cgroup`が丸っとマウントされるか 2、`tasks`などのcgroupのファイルが作られるのか と何となく思っていたので、混乱しました。 これは、一般的に期待されるように、コンテナごとにcgroupで切った後、そこからCentOSでinitが始まるように、うまいこと親cgroup(この場合CentOSのcontainer?)から継承されているということでいいのでしょうか。 また、kubernetesやDocker runなどでresourceを指定してあげた場合、CentOSのsystemdはそのリソースをサブシステムとして使うということでいいのでしょうか。 よろしくお願いします。
回答: kernelのdocを読んで少し理解できました。 kubernetesで言えば、securityContextでcapabilitiesの項目を適切に追加すればいいはずです。(まだ試していませんが) もともとrootの概念がcontainerの内外で異なることに少し疑問を持っていましたが、ググり方がわからず、放置していましたが解決しました。 volumeでマウントしても、containerによりシステムコールが制限されているため、空ディレクトリになっているのでした。 containerでrootを制限されても、適切にlinuxのcapabilitiesをセットしてあげることで、container内でもそのcapabilityの制限内で、cgroupで操作できるようです。