一、容器的時(shí)間問(wèn)題

在測(cè)試環(huán)境已經(jīng)全面使用 k8s 部署了，今天突然有一個(gè)測(cè)試同學(xué)，因?yàn)樘厥鈭?chǎng)景，希望更改一下服務(wù)對(duì)應(yīng)的容器時(shí)間，當(dāng)時(shí)我心想，這不是挺簡(jiǎn)單的。

于是就來(lái)到容器當(dāng)中，執(zhí)行如下命令進(jìn)行更改：

[root@a-admin-f478dbd55-ddv7x /]# date
Tue Jun 18 14:01:34 CST 2019
[root@a-admin-f478dbd55-ddv7x /]# date -s 05/28
date: cannot set date: Operation not permitted
Tue May 28 00:00:00 CST 2019
[root@a-admin-f478dbd55-ddv7x /]# date
Tue Jun 18 14:01:48 CST 2019

報(bào)了一個(gè)錯(cuò)誤

date: cannot set date: Operation not permitted

而且也沒(méi)有更改成功。當(dāng)時(shí)還不知道一些深層次的原因，于是開始了搜索之旅。

最先搜索到的，是解決 date 命令報(bào)錯(cuò)的問(wèn)題：需要在啟動(dòng)容器的時(shí)候，加上--cap-add SYS_TIME的參數(shù)。

docker run -it --cap-add SYS_TIME --name centos centos /bin/bash

簡(jiǎn)單說(shuō)明一下這里添加的參數(shù)，深入的后邊探討。

在添加這些特殊權(quán)限的時(shí)候，可以有如下幾種操作：

• --cap-add：給容器添加某個(gè)權(quán)限。
• --cap-drop：去掉容器的某個(gè)權(quán)限。
• --privileged：將所有的權(quán)限添加給容器。
• --cap-drop ALL：去掉所有權(quán)限。

然后再進(jìn)入到容器里，重復(fù)執(zhí)行上邊改時(shí)間的操作，就能成功了。

因?yàn)槟壳笆褂?rancher 進(jìn)行 k8s 的管理，因此掛載的方式如下，可點(diǎn)擊pod升級(jí)，在高級(jí)選項(xiàng)的最后，有增加內(nèi)核的選項(xiàng)，選中SYS_TIME，然后點(diǎn)擊升級(jí)即可。

事實(shí)上可能問(wèn)題到這里，就已經(jīng)沒(méi)有問(wèn)題了，但是接著測(cè)試同學(xué)發(fā)現(xiàn)，時(shí)間會(huì)自動(dòng)又變成現(xiàn)在的時(shí)間了，以至于無(wú)法進(jìn)行測(cè)試，我當(dāng)時(shí)心想，難道說(shuō)，k8s 自己有這樣的時(shí)間修正機(jī)制么，，，

后來(lái)想到會(huì)不會(huì)是定時(shí)任務(wù)的因素，于是乎，來(lái)到了剛剛那個(gè)容器所在的主機(jī)之上，一看，果然有時(shí)間校準(zhǔn)的定時(shí)任務(wù)，每分鐘執(zhí)行一次，于是注釋掉，再次更改容器時(shí)間，這次才真正的生效，與此同時(shí)，發(fā)現(xiàn)了另外一個(gè)重大問(wèn)題，那就是容器時(shí)間變更為 5 月 28 日之后，宿主機(jī)的時(shí)間也跟著變更了，讓我一陣兒惶恐，盡管這是在測(cè)試環(huán)境，宿主機(jī)的時(shí)間更改可也不是鬧著玩的呀

到后來(lái)才知道，原來(lái)上邊操作的 --cap-add SYS_TIME是為了將宿主機(jī)的內(nèi)核時(shí)間掛載進(jìn)來(lái)與容器共享，因此容器時(shí)間更改了，宿主機(jī)時(shí)間也會(huì)跟著更改。說(shuō)到底，還是對(duì) docker 理解不深的緣故，但是借著這個(gè)機(jī)緣，倒是靜下心來(lái)，看了如下的一些資料，讓自己對(duì)容器技術(shù)有了新的一層認(rèn)識(shí)。

二、docker 之 Namespace

內(nèi)核為容器提供了兩種技術(shù)cgroup和namespace，分別對(duì)容器進(jìn)行資源限制和資源隔離。

• 容器本質(zhì)是進(jìn)程，cgroup用來(lái)限制容器的資源使用量，避免單個(gè)容器耗盡系統(tǒng)資源。
• namespace用來(lái)隔離容器與宿主機(jī)，以及不同的容器。

這里，就先針對(duì) namespace 這個(gè)概念進(jìn)行一下探析。

如上列出的這六項(xiàng)，是目前構(gòu)建一個(gè)容器所默認(rèn)賦予的基礎(chǔ)能力，可以有別于原宿主機(jī)而在容器當(dāng)中單獨(dú)存在（當(dāng)然還是基于宿主機(jī)），這個(gè)時(shí)候就能夠理解，上邊改時(shí)間的操作之所以失敗，就是因?yàn)槟J(rèn)情況下，容器是沒(méi)有 Time（時(shí)間）這個(gè) Namespace 的，通過(guò)--cap-add SYS_TIME掛載也是引用了系統(tǒng)的內(nèi)核時(shí)間，因此改了容器時(shí)間之后，系統(tǒng)時(shí)間跟著變化，也就不稀奇了。

1、UTS namespace

UTS(UNIX Time-sharing System)namespace 提供了主機(jī)名與域名的隔離，這樣每個(gè) docke 容器就可以擁有獨(dú)立的主機(jī)名和域名了，在網(wǎng)絡(luò)上可以被視為一個(gè)獨(dú)立的節(jié)點(diǎn)，而非宿主機(jī)上的一個(gè)進(jìn)程。

docker 中，每個(gè)鏡像基本都以自身所提供的服務(wù)名稱來(lái)命名鏡像的 hostname，且不會(huì)對(duì)宿主機(jī)產(chǎn)生任何影響，其原理就是使用了 UTS namespace。

2、IPC namespace

進(jìn)程間通信 (Inter-Process Communication，IPC) 涉及的 IPC 資源包括常見的信號(hào)量、消息隊(duì)列和共享內(nèi)存。申請(qǐng) IPC 資源就申請(qǐng)了一個(gè)全局唯一的 32 位 ID，所以 IPC namespace 中實(shí)際上包含了系統(tǒng) IPC 標(biāo)識(shí)符以及實(shí)現(xiàn) POSIX 消息隊(duì)列的文件系統(tǒng)。在同一個(gè) IPC namespace 下的進(jìn)程彼此可見，不同 IPC namespace 下的進(jìn)程則互相不可見。

目前使用 IPC namespace 機(jī)制的系統(tǒng)不多，其中比較有名的有 PostgreSQL。Docker 當(dāng)前也使用 IPC namespace 實(shí)現(xiàn)了容器與宿主機(jī)、容器與容器之間的 IPC 隔離。

3、PID namespace

PID namespace 隔離非常實(shí)用，它對(duì)進(jìn)程 PID 重新標(biāo)號(hào)，即兩個(gè)不同 namespace 下的進(jìn)程可以有相同的 PID。每個(gè) PID namespace 都有自己的計(jì)數(shù)程序。內(nèi)核為所有的 PID namespace 維護(hù)了一個(gè)樹狀結(jié)構(gòu)，最頂層的是系統(tǒng)初始時(shí)創(chuàng)建的，被稱為 root namespace，它創(chuàng)建的心 PID namespace 被稱為 child namespace(樹的子節(jié)點(diǎn))，而原先的 PID namespace 就是新創(chuàng)建的 PID namespace 的 parent namespace(樹的父節(jié)點(diǎn))。通過(guò)這種方式，不同的 PID namespace 會(huì)形成一個(gè)層級(jí)體系。所屬的父節(jié)點(diǎn)可以看到子節(jié)點(diǎn)中的進(jìn)程，并可以通過(guò)信號(hào)等方式對(duì)子節(jié)點(diǎn)中的進(jìn)程產(chǎn)生影響。反過(guò)來(lái)，子節(jié)點(diǎn)卻不能看到父節(jié)點(diǎn) PID namespace 中的任何內(nèi)容，由此產(chǎn)生如下結(jié)論。

• 每個(gè) PID namespace 中的第一個(gè)進(jìn)程 “PID 1”，都會(huì)像全通 Linux 中的 init 進(jìn)程一樣擁有特權(quán)，其特殊作用。
• 一個(gè) namespace 中的進(jìn)程，不可能通過(guò) kill 或 ptrace 影響父節(jié)點(diǎn)或者兄弟節(jié)點(diǎn)中的進(jìn)程，因?yàn)槠渌麕c(diǎn)的 PID 在這個(gè) namespace 沒(méi)有任何意義。
• 如果你在新的 PID namespace 中重新掛載 / proc 文件系統(tǒng)，會(huì)發(fā)現(xiàn)其下只顯示同屬一個(gè) PID namespace 中的其他進(jìn)程。
• 在 root namespace 中看到所有的進(jìn)程，并且遞歸包含所有子節(jié)點(diǎn)中的進(jìn)程。到這里，讀者可能已經(jīng)聯(lián)想到了一種在 Docker 外部監(jiān)控運(yùn)行程序的方法了，就是監(jiān)控 Docker daemon 所在的 PID namespace 下的所有進(jìn)程及子進(jìn)程，在進(jìn)行篩選即可。

4、mount namespace

mount namespace 通過(guò)隔離文件系統(tǒng)掛載點(diǎn)對(duì)隔離文件系統(tǒng)提供支持，它是歷史上第一個(gè) Linux namespace，所以標(biāo)示位比較特殊，就是CLONE_NEWNS。隔離后，不同的 mount namespace 中的文件結(jié)構(gòu)發(fā)生變化也互不影響。也可以通過(guò) / proc/[pid]/mounts 查看到所有掛載在當(dāng)前 namespace 中的文件系統(tǒng)，還可以通過(guò) / proc/[pid]/mountstats 看到 mount namespace 中文件設(shè)備的統(tǒng)計(jì)信息，包括掛載文件的名字、文件系統(tǒng)的類型、掛載位置等。

進(jìn)程在創(chuàng)建 mount namespace 時(shí)，會(huì)把當(dāng)前的文件結(jié)構(gòu)復(fù)制給新的 namespace。新 namespace 中的所有 mount 操作都只影響自身的文件系統(tǒng)，對(duì)外界不會(huì)產(chǎn)生任何影響。這種做法非常嚴(yán)格的實(shí)現(xiàn)了隔離，但對(duì)某些狀況可能并不適用。比如父節(jié)點(diǎn) namespace 中的進(jìn)程掛載了一張 CD-ROM，這時(shí)子節(jié)點(diǎn) namespace 復(fù)制的目錄結(jié)構(gòu)是無(wú)法自動(dòng)掛載上這張 CD-ROM 的，因?yàn)檫@種操作會(huì)影響到父節(jié)點(diǎn)的文件系統(tǒng)。

一個(gè)掛載狀態(tài)可能為以下一種：

• 共享掛載
• 從屬掛載
• 共享 / 從屬掛載
• 私有掛載
• 不可綁定掛載

傳播事件的掛載對(duì)象稱為共享掛載；接收傳播事件的掛載對(duì)象稱為從屬掛載；同時(shí)兼有前述兩者特征的掛載對(duì)象為共享 / 從屬掛載；既不傳播也不接受事件的掛載對(duì)象稱為私有掛載；另一種特殊的掛載對(duì)象稱為不可綁定掛載，它們與私有掛載相似，但不允許執(zhí)行綁定掛載，即創(chuàng)建 mount namespace 時(shí)這塊文件對(duì)象不可被復(fù)制。

5、netword namespace

network namespace 主要提供了關(guān)于網(wǎng)絡(luò)資源的隔離，包括網(wǎng)絡(luò)設(shè)備、IPv4 和 IPv6 協(xié)議棧、IP 路由表、防火墻、/proc/net 目錄、/sys/class/net 目錄、socket 等。一個(gè)物理的網(wǎng)絡(luò)設(shè)備最多存在于一個(gè) network namespace 中，可以通過(guò)創(chuàng)建 veth pair(虛擬網(wǎng)絡(luò)設(shè)備對(duì)：有兩端，類似管道，如果數(shù)據(jù)從一端傳入另一端也能接受，反之亦然) 在不同的 network namespace 間創(chuàng)建通道，以達(dá)到通信目的。

也許你會(huì)好奇，在建立起 veth pair 之前，新舊 namespace 該如何通信呢？答案是pipe(管道)。以 Docker daemon 啟動(dòng)容器的過(guò)程為例，假設(shè)容器內(nèi)初始化的進(jìn)程稱為 init。Docker daemon 在宿主機(jī)上負(fù)責(zé)創(chuàng)建這個(gè) veth pair，把一段綁定到 docker0 網(wǎng)橋上，另一端介入新建的 network namespace 進(jìn)程中。這個(gè)過(guò)程執(zhí)行期間，Docker daemon 和 init 就通過(guò) pipe 進(jìn)行通信。具體來(lái)說(shuō)，就是在 Docker deamon 完成 veth pair 的創(chuàng)建之前，init 在管道的另一端循環(huán)等待，直到管道另一端傳來(lái) Docker daemon 關(guān)于 veth 設(shè)備的信息，并關(guān)閉管道。init 才結(jié)束等待的過(guò)程，并把它的 “eth0” 啟動(dòng)起來(lái)。

與其他 namespace 類似，對(duì) network namespace 的使用其實(shí)就是在創(chuàng)建的時(shí)候添加 CLONE_NEWNET 標(biāo)識(shí)符位。

6、user namespace

user namespace 主要隔離了安全相關(guān)的標(biāo)識(shí)符 (identifier) 和屬性 (attribute)，包括用戶 ID、用戶組 ID、root 目錄、key(指密鑰) 以及特殊權(quán)限。通俗地講，一個(gè)普通用戶的進(jìn)程通過(guò) clone()創(chuàng)建的新進(jìn)程在新 user namespace 中可以擁有不同的用戶和用戶組。這意味著一個(gè)進(jìn)程在容器外屬于一個(gè)沒(méi)有特權(quán)的普通用戶，但是它創(chuàng)建的容器進(jìn)程卻屬于擁有所有權(quán)限的超級(jí)用戶，這個(gè)技術(shù)為容器提供了極大的自由。

user namespace 時(shí)目前的 6 個(gè) namespace 中最后一個(gè)支持的，并且直到 linux 內(nèi)核 3.8 版本的時(shí)候還未完全實(shí)現(xiàn) (還有部分文件系統(tǒng)不支持)。user namespace 實(shí)際上并不算完全成熟，很多發(fā)行版擔(dān)心安全問(wèn)題，在編譯內(nèi)核的時(shí)候并未開啟 USER_NS。Docker 在 1.10 版本中對(duì) user namespace 進(jìn)行了支持。只要用戶在啟動(dòng) Docker daemon 的時(shí)候制定了–user-remap，那么當(dāng)用戶運(yùn)行容器時(shí)，容器內(nèi)部的 root 用戶并不等于宿主機(jī)的 root 用戶，而是映射到宿主機(jī)上的普通用戶。

Docker 不僅使用了 user namespace，還使用了在 user namespace 中涉及的 Capability 機(jī)制。從內(nèi)核 2.2 版本開始，Linux 把原來(lái)和超級(jí)用戶相關(guān)的高級(jí)權(quán)限分為不同的單元，稱為 Capability。這樣管理員就可以獨(dú)立的對(duì)特定的 Capability 進(jìn)行使用或禁止。Docker 同時(shí)使用 namespace 和 Capability，這很大程度上加強(qiáng)了容器的安全性。

這些似乎都是 docker 相關(guān)的基礎(chǔ)性概念，過(guò)去也許并非沒(méi)有看過(guò)，但都一帶而過(guò)沒(méi)有留下印象，若非今日時(shí)間問(wèn)題這個(gè)機(jī)緣，恐怕自己也還一直不懂得這些原理，有時(shí)候?qū)W習(xí)就是如此，要看緣分。重要的是，如果緣分來(lái)了，不要錯(cuò)失！

三、如何單獨(dú)更改容器時(shí)間

后來(lái)經(jīng)過(guò)朋友分享，發(fā)現(xiàn)可以通過(guò)曲線救國(guó)的方式更改容器的時(shí)間。

在github上有一個(gè)libfaketime項(xiàng)目,我們可以使用LD_PRELOAD這個(gè)環(huán)境變量使date連接這個(gè)項(xiàng)目編譯的庫(kù)來(lái)fake（欺騙）應(yīng)用，達(dá)到修改docker容器時(shí)間的目的。

1、先導(dǎo)試驗(yàn)

通過(guò)如下操作可以獲得依賴庫(kù)：

$ git clone https://github.com/wolfcw/libfaketime.git
$ cd libfaketime/src/
$ make install

編譯之后，將會(huì)獲得對(duì)應(yīng)的庫(kù)文件。

src/libfaketime.so.1

同時(shí)也在系統(tǒng)之中生成了對(duì)應(yīng)的文件。
/usr/local/lib/faketime/libfaketime.so.1

接著來(lái)啟動(dòng)一個(gè)容器操作一下看看。

docker run -itd --name aa 192.168.112.69/public/jdk:1.8
docker cp src/libfaketime.so.1 aa:/usr/local/lib

然后進(jìn)入到容器之中引用并更改時(shí)間。

sh-4.2# date
Thu Jun 20 15:35:18 CST 2019

sh-4.2# export LD_PRELOAD=/usr/local/lib/libfaketime.so.1 FAKETIME="-10d"

sh-4.2# date
Mon Jun 10 15:35:39 CST 2019

這樣就實(shí)現(xiàn)了容器時(shí)間變更，而宿主機(jī)時(shí)間并不會(huì)變。

但是我個(gè)人測(cè)試的情況是，進(jìn)入容器之后的確可以實(shí)現(xiàn)，但是退出容器重新進(jìn)入之后，時(shí)間就又回到與宿主機(jī)一致的了。

所以如上操作是有一些問(wèn)題的，問(wèn)題不在于操作的過(guò)程有問(wèn)題，而在于那個(gè)環(huán)境變量出了問(wèn)題，當(dāng)前聲明沒(méi)有問(wèn)題，但是從新進(jìn)入容器之后，聲明的環(huán)境變量就沒(méi)有了，這也是退出容器重新進(jìn)入之后時(shí)間變成當(dāng)前時(shí)間的原因。接下來(lái)將配置真正可以更改容器時(shí)間的方案。

2、正式操作

現(xiàn)在只是把流程步驟記錄一下，實(shí)際生產(chǎn)應(yīng)用的話，僅作為效果參考，不代表實(shí)際生產(chǎn)鏡像配置最終效果

準(zhǔn)備內(nèi)容：

$ ls
Dockerfile      libfaketime.tar     faketime.sh

其中 libfaketime.tar就是我下載的源碼打的包。 查看對(duì)應(yīng)內(nèi)容：

faketime.sh

#!/bin/bash
targetTime="$1"
if [[ ${targetTime} == "" ]];then
  echo "need a absolute time. eg: 2020-12-24 20:30:00"
  exit;
fi
current=`date +%s`
target=`date -d "$targetTime" +%s`
let time=($target-$current)
if [[ $time -gt 0 ]];then
  time="+$time"
fi
echo $time
echo $time > /etc/faketimerc

Dockerfile

# Dockerizing CentOS7: Dockerfile for building CentOS images
#需要一個(gè)基礎(chǔ)鏡像，這里從國(guó)內(nèi)的daocloud下載，速度比較快。
FROM       daocloud.io/library/centos:centos7.4.1708

#維護(hù)者
MAINTAINER eryajf <Linuxlql@163.com>

ADD libfaketime.tar /opt
ADD faketime.sh /mnt

RUN yum -y install gcc automake autoconf libtool make gcc-c++ && cd /opt/libfaketime/src && make install && touch /etc/faketime

ENV TZ "Asia/Shanghai"
ENV LD_PRELOAD "/usr/local/lib/faketime/libfaketime.so.1" #重要的就是這個(gè)聲明，是他，成就了時(shí)間穿梭的效果

構(gòu)建一下：

$ docker build -t test .

啟動(dòng)驗(yàn)證：

$ docker run -itd --name test test
$ docker exec -it test bash

容器內(nèi)驗(yàn)證：

[root@c23c65999a52 mnt]# date
Wed Aug  7 11:09:13 CST 2019

[root@c23c65999a52 mnt]# ./faketime.sh "2020-12-24 20:30:00"
+43696422

[root@c23c65999a52 mnt]# date
Thu Dec 24 20:30:27 UTC 2020

退出容器重新進(jìn)入，時(shí)間也是更改之后的時(shí)間了，如果想要讓時(shí)間變成當(dāng)前時(shí)間，可以刪除 /etc/faketimerc文件，即可。

[root@443422a71e6e /]# rm -f /etc/faketimerc
[root@443422a71e6e /]# date
Wed Aug  7 11:11:05 CST 2019

如此就集成了更改容器時(shí)間的功能了，這個(gè)功能，可以集成到基礎(chǔ)容器當(dāng)中去。

3、終稿版本

最終個(gè)人自用的基礎(chǔ)鏡像小操作，首先把上邊編譯好的庫(kù)文件拷貝出來(lái)，然后利用如下dockerfile構(gòu)建一個(gè)基礎(chǔ)鏡像。

$ cat Dockerfile
# Dockerizing CentOS7: Dockerfile for building CentOS images
#需要一個(gè)基礎(chǔ)鏡像，這里從國(guó)內(nèi)的daocloud下載，速度比較快。
FROM       daocloud.io/library/centos:centos7.4.1708

#維護(hù)者
MAINTAINER eryajf <Linuxlql@163.com>

ADD libfaketime.so.1 /usr/local/lib/
ADD faketime /usr/local/bin

RUN yum -y install lrzsz wget curl vim net-tools rsync git && yum clean all
ENV TZ "Asia/Shanghai"
ENV LD_PRELOAD "/usr/local/lib/libfaketime.so.1"

直接把庫(kù)文件放在系統(tǒng)中，然后也把更改時(shí)間的腳本放到環(huán)境變量下，如此以來(lái)，直接運(yùn)行faketime命令即可。

docker build -t registry.cn-hangzhou.aliyuncs.com/eryajf/centos:7.5 .
docker push registry.cn-hangzhou.aliyuncs.com/eryajf/centos:7.5

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。