深入剖析Kubernetes系列連載（三）隔離技術Namespace

Kubernetes的學習往往讓人摸不著頭腦，很難理解其中的原理。

深入剖析Kubernetes系列連載是學習《深入剖析Kubernetes》課程的筆記和總結，記錄學習的過程，并且傳遞知識。

PID Namespace

int pid = clone(main_function, stack_size, CLONE_NEWPID | SIGCHLD, NULL);

clone()是線程操作，但linux 的線程是用進程實現的

這時，新創建的這個進程將會“看到”一個全新的進程空間，在這個進程空間里，它的 PID是 1。之所以說“看到”，是因為這只是一個“障眼法”，在宿主機真實的進程空間里，這個進程的 PID 還是真實的數值，比如 100

還有Mount、UTS、IPC、Network 和 User 這些Namespace，用來對各種不同的進程上下文進行“障眼法”操作

Mount Namespace

int container_main(void* arg) { printf("Container - inside the container!\n"); // 如果你的機器的根目錄的掛載類型是 shared，那必須先重新掛載根目錄 // mount("", "/", NULL, MS_PRIVATE, ""); mount("none", "/tmp", "tmpfs", 0, ""); execv(container_args[0], container_args); printf("Something's wrong!\n"); return 1; }

在容器進程啟動之前，加上了一句 mount(“none”, “/tmp”, “tmpfs”, 0, “”) 語句。就這樣，我告訴了容器以 tmpfs（內存盤）格式，重新掛載了 /tmp 目錄。

這就是 Mount Namespace 跟其他 Namespace 的使用略有不同的地方：它對容器進程視圖的改變，一定是伴隨著掛載操作（mount）才能生效

Mount Namespace 正是基于對 chroot 的不斷改良才被發明出來的，它也是Linux 操作系統里的第一個 Namespace

為了能夠讓容器的這個根目錄看起來更“真實”，我們一般會在這個容器的根目錄下掛載一個完整操作系統的文件系統，比如 Ubuntu16.04 的 ISO。這樣，在容器啟動之后，我們在容器里通過執行 "ls /" 查看根目錄下的內容，就是 Ubuntu 16.04 的所有目錄和文件

而這個掛載在容器根目錄上、用來為容器進程提供隔離后執行環境的文件系統，就是所謂的“容器鏡像”。它還有一個更為專業的名字，叫作：rootfs（根文件系統）

由于 rootfs 里打包的不只是應用，而是整個操作系統的文件和目錄，也就意味著，應用以及它運行所需要的所有依賴，都被封裝在了一起。這種深入到操作系統級別的運行環境一致性，打通了應用在本地開發和遠端執行環境之間難以逾越的鴻溝

Network Namespace

通過 open() 系統調用打開了指定的 Namespace 文件，并把這個文件的描述符 fd 交給 setns() 使用。在 setns() 執行后，當前進程就加入了這個文件對應的 Linux Namespace 當中了

Docker 還專門提供了一個參數，可以讓你啟動一個容器并“加入”到另一個容器的Network Namespace 里，這個參數就是 -net，比如:

docker run -it --net container:4ddf4638572d busybox ifconfig

我們新啟動的這個容器，就會直接加入到 ID=4ddf4638572d 的容器的 Network Namespace 中

而如果我指定–net=host，就意味著這個容器不會為進程啟用 Network Namespace。這就意味著，這個容器拆除了 Network Namespace 的“隔離墻”，所以，它會和宿主機上的其他普通進程一樣，直接共享宿主機的網絡棧。這就為容器直接操作和使用宿主機網絡提供了一個渠道

實際上是在創建容器進程時，指定了這個進程所需要啟用的一組 Namespace 參數。Namespace 技術實際上修改了應用進程看待整個計算機“視圖”，這樣容器就只能“看”到當前 Namespace所限定的資源、文件、設備、狀態，或者配置。而對于宿主機以及其他不相關的程序，它就完全看不到了

容器化后的用戶應用，卻依然還是一個宿主機上的普通進程，這就意味著這些因為虛擬化而帶來的性能損耗都是不存在的；而另一方面，使用 Namespace 作為隔離手段的容器并不需要單獨的 Guest OS，這就使得容器額外的資源占用幾乎可以忽略不計

基于 Linux Namespace 的隔離機制相比于虛擬化技術也有很多不足之處，其中最主要的問題就是：隔離得不徹底

首先，既然容器只是運行在宿主機上的一種特殊的進程，那么多個容器之間使用的就還是同一個宿主機的操作系統內核

其次，在 Linux 內核中，有很多資源和對象是不能被 Namespace 化的，最典型的例子就是：時間。如果你的容器中的程序使用 settimeofday(2) 系統調用修改了時間，整個宿主機的時間都會被隨之修改

盡管在實踐中我們確實可以使用 Seccomp 等技術，對容器內部發起的所有系統調用進行過濾和甄別來進行安全加固，但這種方法因為多了一層對系統調用的過濾，一定會拖累容器的性能

Kubernetes Linux 容器

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。