引言

著名雜志《經(jīng)濟(jì)學(xué)人》曾經(jīng)評(píng)價(jià)“沒(méi)有集裝箱，就沒(méi)有全球化”，可以說(shuō)集裝箱的出現(xiàn)重塑了現(xiàn)代貨運(yùn)體系，實(shí)現(xiàn)了交通運(yùn)輸行業(yè)的標(biāo)準(zhǔn)化，有效降低物流運(yùn)輸成本，極大提升了貨物轉(zhuǎn)運(yùn)效率。而在云原生領(lǐng)域，容器就相當(dāng)于集裝箱，它使得軟件發(fā)布以及軟件運(yùn)行隔離實(shí)現(xiàn)標(biāo)準(zhǔn)化，引領(lǐng)了云原生基礎(chǔ)設(shè)施的跨越式發(fā)展。從某種意義上來(lái)說(shuō)，容器技術(shù)重塑了整個(gè)軟件供應(yīng)鏈。今天就和大家聊聊各個(gè)大廠(chǎng)都在玩的容器技術(shù)到底是什么。

為什么需要容器技術(shù)

在正式介紹容器技術(shù)之前，我們先來(lái)看下軟件領(lǐng)域?yàn)槭裁葱枰萜骷夹g(shù)。一項(xiàng)新技術(shù)的出現(xiàn)必定是為了解決當(dāng)下遇到的的某項(xiàng)具體問(wèn)題或者說(shuō)更加提高現(xiàn)有軟件運(yùn)行效率。那我們就來(lái)分析下在容器技術(shù)出現(xiàn)之前，軟件領(lǐng)域到底面臨什么樣的問(wèn)題。

在很早很早之前，我們部署服務(wù)的時(shí)候都是直接部署在硬件服務(wù)器上。如果想對(duì)服務(wù)進(jìn)行擴(kuò)容就必須要購(gòu)買(mǎi)服務(wù)器，然后再進(jìn)行應(yīng)用部署以及各種繁瑣的環(huán)境配置以及服務(wù)配置，由于都是人工操作所以還特別容易出錯(cuò)，不僅浪費(fèi)時(shí)間還很費(fèi)程序猿，因此服務(wù)部署以及遷移效率都極其低下。在互聯(lián)網(wǎng)早期的時(shí)候，用戶(hù)數(shù)以及業(yè)務(wù)體量還不是很大，人工操作還能夠應(yīng)付得過(guò)來(lái)。但是隨著業(yè)務(wù)規(guī)模不斷發(fā)展以及用戶(hù)數(shù)的爆炸式增長(zhǎng)，這樣的軟件服務(wù)生產(chǎn)方式已經(jīng)無(wú)法滿(mǎn)足業(yè)務(wù)高速發(fā)展的需求。將應(yīng)用服務(wù)直接部署在服務(wù)器上主要有以下三方面的問(wèn)題。

服務(wù)互干擾

一臺(tái)服務(wù)器一般不會(huì)只部署一個(gè)服務(wù)應(yīng)用，都是部署多個(gè)服務(wù)應(yīng)用。但是由于這些服務(wù)都是公用服務(wù)器中的CPU、內(nèi)存、硬盤(pán)以及網(wǎng)絡(luò)IO等服務(wù)器資源，那么必定就會(huì)存在資源互相爭(zhēng)用、服務(wù)互相影響的情況。

資源利用低

業(yè)務(wù)是存在高峰期和低谷期的，對(duì)于電商平臺(tái)來(lái)說(shuō)，一般深夜的屬于業(yè)務(wù)低谷期，這個(gè)時(shí)候的服務(wù)器的資源利用率相比業(yè)務(wù)高峰期的時(shí)候要低很多。因此在業(yè)務(wù)低谷期，實(shí)際服務(wù)器的資源利用率比較低，不能物盡其用。

遷移擴(kuò)展難

原有的服務(wù)器數(shù)量不足以應(yīng)對(duì)高速發(fā)展的業(yè)務(wù)時(shí)，就需要不斷的進(jìn)行服務(wù)器實(shí)例擴(kuò)充，但是由于服務(wù)直接部署在服務(wù)器中，在進(jìn)行服務(wù)遷移擴(kuò)展的時(shí)候，需要各種依賴(lài)庫(kù)、環(huán)境配置以及網(wǎng)絡(luò)配置等，步驟復(fù)雜，擴(kuò)展困難。

正是軟件領(lǐng)域面臨這么多問(wèn)題，因此大神們才會(huì)發(fā)揮他們的聰明才智不斷推進(jìn)技術(shù)發(fā)展。因此大神們就設(shè)想如果有一種部署方式可以實(shí)現(xiàn)差別的服務(wù)構(gòu)建，那就可以解決服務(wù)部署的各種配置問(wèn)題。如果有一種技術(shù)可實(shí)現(xiàn)真正的資源隔離，進(jìn)程之間互相不影響，這樣就可以解決互相影響的問(wèn)，那將是多么美好的一件事情。這些美好的技術(shù)設(shè)想實(shí)際就是容器技術(shù)發(fā)展的原動(dòng)力。當(dāng)然技術(shù)的發(fā)展并不是一蹴而就的，總是隨著時(shí)間的推移不斷進(jìn)行完善。

容器技術(shù)的思想最早可以追溯到1979年，這一年Unix版本V7發(fā)布，在這個(gè)版本中作者發(fā)明了chroot系統(tǒng)調(diào)用，通過(guò)它可以實(shí)現(xiàn)改變一個(gè)進(jìn)程及其子進(jìn)程的根目錄到另外一個(gè)目錄下，為進(jìn)程指定一個(gè)單獨(dú)的、新的文件系統(tǒng)上下文環(huán)境，可見(jiàn)在很早的時(shí)候Unix的大神們已經(jīng)有了進(jìn)行進(jìn)程隔離的意識(shí)和思想了。

那么到底什么叫進(jìn)程隔離呢？舉個(gè)栗子大家一看就明白，相信很多同學(xué)都使用過(guò)tomcat這個(gè)web容器，我們可以在tomcat中部署war服務(wù)。假設(shè)我們有3 個(gè)服務(wù)都部署在了1個(gè)tomcat實(shí)例中，假如我們需要重啟其中的某個(gè)服務(wù)，我們就需要重啟整個(gè)tomcat，那么tomact中的3個(gè)服務(wù)都會(huì)被重啟。重啟一個(gè)服務(wù)影響其他2個(gè)服務(wù)，服務(wù)操作存在高度的耦合。但是如果我們把三個(gè)服務(wù)部署到三個(gè)不同的tocmat容器實(shí)例中，那么重啟任何一個(gè)服務(wù)都不會(huì)影響到其他兩個(gè)服務(wù)，實(shí)現(xiàn)了服務(wù)的獨(dú)立管理。

通過(guò)部署多個(gè)實(shí)例，我們實(shí)現(xiàn)了服務(wù)之間的進(jìn)程隔離，而進(jìn)程擁有獨(dú)立的地址空間以及執(zhí)行上下文。但是這種形式的獨(dú)立管理并不是真正意義上的獨(dú)立管理，為什么這么說(shuō)呢？因?yàn)閷?shí)際上他們還是共用服務(wù)器的CPU、內(nèi)存以及IO等服務(wù)器資源。假如Tomcat1占用的服務(wù)器內(nèi)存高了，那么剩余給Tomcat2以及Tomcat2的內(nèi)存分配就相對(duì)來(lái)說(shuō)會(huì)變少。因此實(shí)際上這三個(gè)Tomcat雖然是獨(dú)立的進(jìn)程但還是會(huì)相互影響。有沒(méi)有辦法實(shí)現(xiàn)真正的獨(dú)立，不互相影響呢？

實(shí)際上實(shí)現(xiàn)資源隔離的方式大概有硬件虛擬化、OS虛擬化以及硬件分區(qū)等幾種常見(jiàn)的實(shí)現(xiàn)方式。但是綜合各方面的表現(xiàn)，OS虛擬化成為后期容器技術(shù)發(fā)展的主流技術(shù)路線(xiàn)。

容器技術(shù)的解決的核心問(wèn)題就是實(shí)現(xiàn)軟件運(yùn)行時(shí)的環(huán)境隔離，通過(guò)容器構(gòu)建一個(gè)標(biāo)準(zhǔn)的、無(wú)差別的服務(wù)運(yùn)行環(huán)境，這樣就不會(huì)因?yàn)榄h(huán)境、配置以及依賴(lài)等原因造成的在這臺(tái)服務(wù)器上好好的，在另外的一臺(tái)服務(wù)器上又不行的尷尬問(wèn)題。2008年的時(shí)候，通過(guò)將Cgroups的資源管理能力以及Namespace的視圖隔離能力糅合在一起，Linux Container被合入linux主線(xiàn)，Linux Container是Linux系統(tǒng)提供的容器技術(shù)，能提供輕量級(jí)的虛擬化能力，能夠進(jìn)行隔離進(jìn)程和資源。通過(guò)這種OS層面的虛擬化技術(shù)，實(shí)際上也就是解決了容器的核心問(wèn)題即為如何實(shí)現(xiàn)服務(wù)運(yùn)行時(shí)的隔離。因此可以說(shuō)Linux Container是后期實(shí)現(xiàn)Docker技術(shù)的基礎(chǔ)。

在2013年，Docker正式發(fā)布。Docker是基于Linux Container技術(shù)發(fā)展而來(lái)的，它的口號(hào)是：“Build，Ship and Run Any App，Anywhere”。Docker創(chuàng)新構(gòu)建了一種全新的軟件打包、軟件分發(fā)以及軟件運(yùn)行的機(jī)制，它通過(guò)容器鏡像，將應(yīng)用服務(wù)本身以及運(yùn)行服務(wù)所需要的環(huán)境、配置、資源文件以及依賴(lài)庫(kù)等都打包成一個(gè)唯一版本的軟件鏡像包。往后在任何地方運(yùn)行的服務(wù)都是基于這個(gè)軟件鏡像包來(lái)進(jìn)行構(gòu)建和運(yùn)行的，真正解決了如何高效發(fā)布軟件以及如何高效運(yùn)行軟件的兩大核心問(wèn)題。關(guān)于Docker，后面會(huì)有專(zhuān)門(mén)的文章進(jìn)行介紹。

 類(lèi)似下圖這種虛擬機(jī)與容器的對(duì)比圖相信大家都看過(guò)，左邊的部分就是虛擬機(jī)的大致原理，實(shí)際上是通過(guò)Hypervisor實(shí)現(xiàn)服務(wù)器硬件資源的虛擬化，從而在服務(wù)器中模擬出來(lái)具備CPU、內(nèi)存、硬盤(pán)等完整計(jì)算機(jī)硬件基礎(chǔ)設(shè)施同時(shí)還有Guest OS，簡(jiǎn)單理解就是在服務(wù)器中派生出了新的虛擬服務(wù)器。用戶(hù)的應(yīng)用服務(wù)進(jìn)程都是運(yùn)行在這些虛擬出來(lái)的計(jì)算機(jī)資源當(dāng)中的。同一臺(tái)服務(wù)器可以同時(shí)運(yùn)行多個(gè)操作系統(tǒng)，各個(gè)操作系統(tǒng)之間是相互隔離的，雖然安全性隔離性都很完備，但是大家應(yīng)該能看得出來(lái)，硬件虛擬化需要額外的性能開(kāi)銷(xiāo)，因此它是一種非常重的資源隔離技術(shù)。

容器技術(shù)原理

前面和大家簡(jiǎn)要介紹了容器技術(shù)的發(fā)展，我們都知道了容器最核心的是實(shí)現(xiàn)了應(yīng)用服務(wù)資源隔離。那么到底容器是如何實(shí)現(xiàn)資源隔離的呢？實(shí)際上它依賴(lài)了Namespace（命名空間）、Cgroups（控制組）底層Linux內(nèi)核技術(shù)。

Namespace?

我們先來(lái)看下wiki中關(guān)于Linux Namespace的描述：

Namespaces are a feature of the Linux kernel that partitions kernel resources such that one set of processes sees one set of resources while another set of processes sees a different set of resources. The feature works by having the same namespace for a set of resources and processes, but those namespaces refer to distinct resources。

這描述看上去就很繞，總結(jié)一下就是Linux Namespace是Linux kernel提供的一種進(jìn)行資源隔離的底層能力。通過(guò)Namespace實(shí)現(xiàn)對(duì)服務(wù)器全局資源的封裝隔離，使得不同Namespace中的進(jìn)程互相獨(dú)立，彼此透明。

如下圖所示，在一臺(tái)宿主服務(wù)器當(dāng)中，Linux的Namespace實(shí)際就是Linux內(nèi)核中資源隔離的實(shí)現(xiàn)方式。玩過(guò)Docker的同學(xué)都知道，到我們r(jià)un了一個(gè)docker鏡像之后，在服務(wù)器中就會(huì)產(chǎn)生一個(gè)docker容器，當(dāng)我們進(jìn)入到容器里面去之后，使用ps命令查看，我們會(huì)驚奇的發(fā)現(xiàn)容器中運(yùn)行的服務(wù)pid=1。相當(dāng)于這個(gè)服務(wù)是容器內(nèi)的第一號(hào)進(jìn)程。而如果我們?cè)诜?wù)器中運(yùn)行這個(gè)服務(wù)，操作系統(tǒng)會(huì)給這個(gè)服務(wù)進(jìn)程分配一個(gè)全局唯一的進(jìn)程號(hào)，假設(shè)是34134。同樣是這個(gè)程序在服務(wù)器中運(yùn)行pid是34134，但是在Docker容器中的pid卻是1。這是怎么回事呢？

這種隔離技術(shù)就是Namspace機(jī)制，通過(guò)Namespace構(gòu)建了一個(gè)全新的運(yùn)行環(huán)境，與其他運(yùn)行環(huán)境互相透明，讓服務(wù)在這個(gè)小空間里面自封為王。實(shí)際上是Linux kernel內(nèi)核提供的系統(tǒng)調(diào)用函數(shù)clone(）。通過(guò)clone函數(shù)創(chuàng)建的新進(jìn)程會(huì)在一個(gè)全新的進(jìn)程空間當(dāng)中。因此實(shí)際上容器的本質(zhì)還是進(jìn)程，只不過(guò)是一種特殊的進(jìn)程，在創(chuàng)建它的時(shí)候指定了一些參數(shù)，使得容器只能訪(fǎng)問(wèn)到當(dāng)前Namespace內(nèi)的文件、IO等資源。

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

Namespace除了PID還實(shí)現(xiàn)了其他不同資源級(jí)別的隔離。

名稱(chēng)        宏定義             隔離內(nèi)容
IPC         CLONE_NEWIPC      System V IPC, POSIX message queues (since Linux 2.6.19)
Network     CLONE_NEWNET      Network devices, stacks, ports, etc. (since Linux 2.6.24)
Mount       CLONE_NEWNS       Mount points (since Linux 2.4.19)
PID         CLONE_NEWPID      Process IDs (since Linux 2.6.24)
User        CLONE_NEWUSER     User and group IDs (started in Linux 2.6.23 and completed in Linux 3.8)
UTS         CLONE_NEWUTS      Hostname and NIS domain name (since Linux 2.6.19)

Cgroups

Namespace機(jī)制幫助我們解決了資源隔離的問(wèn)題，那么僅僅只是隔離對(duì)于容器運(yùn)行來(lái)說(shuō)就夠了嗎？雖然在容器內(nèi)部應(yīng)用服務(wù)可能是個(gè)王者，資源都是他獨(dú)享的，但是映射到服務(wù)器內(nèi)核當(dāng)中的真實(shí)的進(jìn)程后它就是個(gè)各個(gè)普普通通的青銅，需要和其他青銅共享計(jì)算機(jī)各類(lèi)資源。顯然這不是我們想要的容器的效果。而Linux Cgroups技術(shù)就是幫助我們?cè)O(shè)置資源限制的功能。Linux Cgroups即Linux Control Group就是限制一個(gè)進(jìn)程組能夠使用的資源上限，包括 CPU、內(nèi)存、磁盤(pán)、網(wǎng)絡(luò)帶寬等等。

在Linux操作系統(tǒng)中，Cgroups的能力通過(guò)內(nèi)核的文件系統(tǒng)操作接口暴露出來(lái)的，它是以文件和目錄的方式組織在操作系統(tǒng)的/sys/fs/cgroup路徑下。在Linux服務(wù)器中輸入mount -t cgroup，可以看到如下的目錄文件結(jié)構(gòu)。

從上圖中我們可以看到，在/sys/fs/cgroup目錄下有很多關(guān)于資源的子目錄或者說(shuō)子系統(tǒng)，如cpucet、cpu以及memory等。這些目錄都是當(dāng)前服務(wù)器可以被Cgroups進(jìn)行限制的資源類(lèi)別。而在子系統(tǒng)對(duì)應(yīng)的資源種類(lèi)下，你就可以看到該類(lèi)資源具體可以被限制的方法。我們可以查看memory下面的配置文件，ls /sys/fs/cgroup/memory。

我們?cè)倏聪翫ocker的源碼：

// New creates and initializes a new containerd server
func New(ctx context.Context, config *Config) (*Server, error) {
    //...
    if err := apply(ctx, config); err != nil {
        return nil, err
    }
    //...
}
// apply sets config settings on the server process
func apply(ctx context.Context, config *Config) error {
    if config.OOMScore != 0 {
        log.G(ctx).Debugf("changing OOM score to %d", config.OOMScore)
        if err := sys.SetOOMScore(os.Getpid(), config.OOMScore); err != nil {
            log.G(ctx).WithError(err).Errorf("failed to change OOM score to %d", config.OOMScore)
        }
    }
    if config.Cgroup.Path != "" {
        cg, err := cgroups.Load(cgroups.V1, cgroups.StaticPath(config.Cgroup.Path))
        if err != nil {
            if err != cgroups.ErrCgroupDeleted {
                return err
            }
            if cg, err = cgroups.New(cgroups.V1, cgroups.StaticPath(config.Cgroup.Path), &specs.LinuxResources{}); err != nil {
                return err
            }
        }
        if err := cg.Add(cgroups.Process{
            Pid: os.Getpid(),
        }); err != nil {
            return err
        }
    }
    return nil
}

通過(guò)代碼我么可以看得出來(lái)在創(chuàng)建一個(gè)Docker容器的時(shí)候，調(diào)用了apply函數(shù)，在這個(gè)apply函數(shù)中會(huì)進(jìn)行cgourp的加載，而后通過(guò)cg.Add將創(chuàng)建的容器id添加到控制組的task文件中。

總結(jié)

本文主要對(duì)容器技術(shù)的發(fā)展進(jìn)行了簡(jiǎn)單回顧，從很早之前服務(wù)部署以及應(yīng)用方面存在的不足出發(fā)，闡述了容器技術(shù)的出現(xiàn)到底解決了什么問(wèn)題，同時(shí)和大家分享了容器技術(shù)的本質(zhì)以及原理，相信通過(guò)本文大家可以對(duì)容器技術(shù)有一個(gè)基本的感受，后續(xù)再和大家繼續(xù)分享云原生技術(shù)體系。