《自己动手写Docker》书摘之五: 增加容器资源限制

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 增加容器资源限制 上一节中,我们已经可以通过命令行mydocker run -ti的方式创建并启动容器,这一节我们将通过Cgroup对容器的资源进行控制。 这一节中我们将实现通过mydocker run -ti -m 100m -cpuset 1 -cpushare 512 /bin/sh的方式控制容器容器的内存和CPU配置。

增加容器资源限制

上一节中,我们已经可以通过命令行mydocker run -ti的方式创建并启动容器,这一节我们将通过Cgroup对容器的资源进行控制。
这一节中我们将实现通过mydocker run -ti -m 100m -cpuset 1 -cpushare 512 /bin/sh的方式控制容器容器的内存和CPU配置。

定义Cgroups的数据结构

上一章中我们介绍了Cgroups包含的三个概念: 

  • cgroup hierarchy中的节点,用于管理进程和subsystem的控制的关系。
  • subsystem 作用于hierarchy上的cgroup节点,并控制节点中进程的资源占用。
  • hierarchy 将cgroup通过树状的结构串起来,并通过虚拟文件系统的方式暴漏给用户。

根据上面三个概念的关系,我们先创建出下面的数据结构:

package subsystems

// 资源限制配置,包含内存限制,CPU时间片权重,CPU核心数
type ResourceConfig struct {
    MemoryLimit string
    CpuShare    string
    CpuSet      string
}
// Subsystem接口,每个Subsystem实现下面的4个接口
// 这里我们将cgroup抽象成了path,原因是cgroup在hierarchy的路径,便是虚拟文件系统中的虚拟路径。
type Subsystem interface {
    // 返回Subsystem的名字,比如cpu memory
    Name() string
    // 设置某个Cgroup在这个Subsystem中的资源限制
    Set(path string, res *ResourceConfig) error
    // 将进程添加到某个cgroup中
    Apply(path string, pid int) error
    // 移除某个cgroup
    Remove(path string) error
}

// 通过不同Subsystem的实现创建资源限制处理链
var (
    SubsystemsIns = []Subsystem{
        &CpusetSubSystem{},
        &MemorySubSystem{},
        &CpuSubSystem{},
    }
)

上面我们定义了Subsystem的模型,下面我们以memory的subsystem为例介绍下要怎么实现Subsystem的操作:

package subsystems

import(
    "fmt"
    "io/ioutil"
    "os"
    "path"
    "strconv"
)
// memory Subsystem的实现
type MemorySubSystem struct {
}

// 设置cgroupPath对应的cgroup的内存资源限制
func (s *MemorySubSystem) Set(cgroupPath string, res *ResourceConfig) error {
    // GetCgroupPath是获取当前Subsystem的在虚拟文件系统中的路径, GetCgroupPath这个函数我们下面会介绍
    if subsysCgroupPath, err := GetCgroupPath(s.Name(), cgroupPath, true); err == nil {
        if res.MemoryLimit != "" {
            // 设置这个cgroup的内存限制,即将限制写入到cgroup对应的目录的memory.limit_in_bytes文件中
            if err := ioutil.WriteFile(path.Join(subsysCgroupPath, "memory.limit_in_bytes"), []byte(res.MemoryLimit), 0644); err != nil {
                return fmt.Errorf("set cgroup memory fail %v", err)
            }
        }
        return nil
    } else {
        return err
    }

}
// 删除cgroupPath对应的cgroup
func (s *MemorySubSystem) Remove(cgroupPath string) error {
    if subsysCgroupPath, err := GetCgroupPath(s.Name(), cgroupPath, false); err == nil {
        // 删除cgroup便是删除对应的cgroupPath的目录
        return os.Remove(subsysCgroupPath)
    } else {
        return err
    }
}

// 将一个进程加入到cgroupPath对应的cgroup中
func (s *MemorySubSystem) Apply(cgroupPath string, pid int) error {
    if subsysCgroupPath, err := GetCgroupPath(s.Name(), cgroupPath, false); err == nil {
        // 把进程的Pid写到cgroup的虚拟文件系统对应目录下的"task"文件中
        if err := ioutil.WriteFile(path.Join(subsysCgroupPath, "tasks"),  []byte(strconv.Itoa(pid)), 0644); err != nil {
            return fmt.Errorf("set cgroup proc fail %v", err)
        }
        return nil
    } else {
        return fmt.Errorf("get cgroup %s error: %v", cgroupPath, err)
    }
}

// 返回cgroup的名字
func (s *MemorySubSystem) Name() string {
    return "memory"
}

上面我们以memorySubsystem为例介绍了如何实现Subsystem的限制cgroup资源,其中的GetCgroupPath函数是找到对应subsystem的挂载的hierarchy相对路径对应的cgroup在虚拟文件系统的路径,然后通过这个目录的读写去操作cgroup,那么是如何找到挂载了subsystemhierarchy的挂载目录的呢?我们先熟悉下"/proc/pid/mountinfo"文件:

  ~ cat /proc/self/mountinfo
.
.
.
24 18 0:12 / /sys/kernel/security rw,nosuid,nodev,noexec,relatime shared:8 - securityfs securityfs rw
25 20 0:19 / /dev/shm rw,nosuid,nodev shared:4 - tmpfs tmpfs rw
26 22 0:20 / /run/lock rw,nosuid,nodev,noexec,relatime shared:6 - tmpfs tmpfs rw,size=5120k
27 18 0:21 / /sys/fs/cgroup ro,nosuid,nodev,noexec shared:9 - tmpfs tmpfs ro,mode=755
28 27 0:22 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime shared:10 - cgroup cgroup rw,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd
29 18 0:23 / /sys/fs/pstore rw,nosuid,nodev,noexec,relatime shared:11 - pstore pstore rw
30 27 0:24 / /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime shared:13 - cgroup cgroup rw,memory
31 27 0:25 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime shared:14 - cgroup cgroup rw,freezer
32 27 0:26 / /sys/fs/cgroup/hugetlb rw,nosuid,nodev,noexec,relatime shared:15 - cgroup cgroup rw,hugetlb
33 27 0:27 / /sys/fs/cgroup/blkio rw,nosuid,nodev,noexec,relatime shared:16 - cgroup cgroup rw,blkio
34 27 0:28 / /sys/fs/cgroup/devices rw,nosuid,nodev,noexec,relatime shared:17 - cgroup cgroup rw,devices
35 27 0:29 / /sys/fs/cgroup/perf_event rw,nosuid,nodev,noexec,relatime shared:18 - cgroup cgroup rw,perf_event
36 27 0:30 / /sys/fs/cgroup/pids rw,nosuid,nodev,noexec,relatime shared:19 - cgroup cgroup rw,pids
37 27 0:31 / /sys/fs/cgroup/net_cls,net_prio rw,nosuid,nodev,noexec,relatime shared:20 - cgroup cgroup rw,net_cls,net_prio
38 27 0:32 / /sys/fs/cgroup/cpu,cpuacct rw,nosuid,nodev,noexec,relatime shared:21 - cgroup cgroup rw,cpu,cpuacct
39 27 0:33 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime shared:22 - cgroup cgroup rw,cpuset
40 19 0:34 / /proc/sys/fs/binfmt_misc rw,relatime shared:23 - autofs systemd-1 rw,fd=22,pgrp=1,timeout=0,minproto=5,maxproto=5,direct
.
.
.

通过/proc/self/mountinfo我们可以找出与当前进程相关的mount信息,上一章介绍的时候我们讲过Cgroupshierarchy的虚拟文件系统是通过cgroup类型的mount挂载上去,option中加上subsystem代表挂载的subsystem,那么我们就可以在mountinfo中找到对应的subsystem的挂载目录,比如memory的:

30 27 0:24 / /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime shared:13 - cgroup cgroup rw,memory

可以看出这一条的挂载的subsystemmemory,那么我们在/sys/fs/cgroup/memory中创建文件夹创建的cgroup就可以用来做内存的限制。下面便是我们的实现:

// 通过/proc/self/mountinfo找出挂载了某个subsystem的hierarchy根cgroup节点所在的目录FindCgroupMountpoint("memory")
func FindCgroupMountpoint(subsystem string) string {
    f, err := os.Open("/proc/self/mountinfo")
    if err != nil {
        return ""
    }
    defer f.Close()

    scanner := bufio.NewScanner(f)
    for scanner.Scan() {
        txt := scanner.Text()
        fields := strings.Split(txt, " ")
        for _, opt := range strings.Split(fields[len(fields)-1], ",") {
            if opt == subsystem {
                return fields[4]
            }
        }
    }
    if err := scanner.Err(); err != nil {
        return ""
    }

    return ""
}

// 得到cgroup在文件系统中的绝对路径
func GetCgroupPath(subsystem string, cgroupPath string, autoCreate bool) (string, error) {
    cgroupRoot := FindCgroupMountpoint(subsystem)
    if _, err := os.Stat(path.Join(cgroupRoot, cgroupPath)); err == nil || (autoCreate && os.IsNotExist(err)) {
        if os.IsNotExist(err) {
            if err := os.Mkdir(path.Join(cgroupRoot, cgroupPath), 0755); err == nil {
            } else {
                return "", fmt.Errorf("error create cgroup %v", err)
            }
        }
        return path.Join(cgroupRoot, cgroupPath), nil
    } else {
        return "", fmt.Errorf("cgroup path error %v", err)
    }
}

最后,我们需要把这些不同的Subsystems中的cgroup管理起来,并与容器建立关系:

type CgroupManager struct {
    // cgroup在hierarchy中的路径 相当于创建的cgroup目录相对于各root cgroup目录的路径
    Path     string
    // 资源配置
    Resource *subsystems.ResourceConfig
}

func NewCgroupManager(path string) *CgroupManager {
    return &CgroupManager{
        Path: path,
    }
}

// 将进程pid加入到每个cgroup中
func (c *CgroupManager) Apply(pid int) error {
    for _, subSysIns := range(subsystems.SubsystemsIns) {
        subSysIns.Apply(c.Path, pid)
    }
    return nil
}

// 设置各个subsystem挂载中的cgroup资源限制
func (c *CgroupManager) Set(res *subsystems.ResourceConfig) error {
    for _, subSysIns := range(subsystems.SubsystemsIns) {
        subSysIns.Set(c.Path, res)
    }
    return nil
}

// 释放各个subsystem挂载中的cgroup
func (c *CgroupManager) Destroy() error {
    for _, subSysIns := range(subsystems.SubsystemsIns) {
        if err := subSysIns.Remove(c.Path); err != nil {
            logrus.Warnf("remove cgroup fail %v", err)
        }
    }
    return nil
}

通过CgroupManager,将资源限制的配置,以及将进程移动到cgroup中的操作交给各个subsystem去处理。

在启动容器的时候增加资源限制的配置

我们在上一节的时候介绍了github.com/urfave/cli的工具可以方便的创建出命令行的程序,现在我们把资源限制的标签也加上,并在容器创建出来初始化之后将容器的进程加到各Subsystem挂载的cgroup中。

func Run(tty bool, comArray []string, res *subsystems.ResourceConfig) {
    parent, writePipe := container.NewParentProcess(tty)
    if parent == nil {
        log.Errorf("New parent process error")
        return
    }
    if err := parent.Start(); err != nil {
        log.Error(err)
    }
    // use mydocker-cgroup as cgroup name
    // 创建cgroup manager,并通过调用set和apply设置资源限制和使限制在容器上生效
    cgroupManager := cgroups.NewCgroupManager("mydocker-cgroup")
    defer cgroupManager.Destroy()
    cgroupManager.Set(res)
    cgroupManager.Apply(parent.Process.Pid)
    // 对容器设置完限制之后初始化容器
    sendInitCommand(comArray, writePipe)
    parent.Wait()
}

到此为止,我们的对容器的资源控制已经完工了,下面我们测试下: 

-m 100m限制内存 

  mydocker git:(2.2) sudo ./mydocker run -ti -m 100m stress --vm-bytes 200m --vm-keep -m 1
{"level":"info","msg":"command all is stress --vm-bytes 200m --vm-keep -m 1","time":"2016-12-03T20:37:11+08:00"}
{"level":"info","msg":"init come on","time":"2016-12-03T20:37:11+08:00"}
{"level":"info","msg":"Find path /usr/bin/stress","time":"2016-12-03T20:37:11+08:00"}
stress: info: [1] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd

可以看到占用内存被限制到了100MB

top - 20:41:49 up 16:28,  3 users,  load average: 1.18, 0.96, 0.43
Tasks: 122 total,   2 running, 120 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.4 us,  5.3 sy,  0.0 ni,  0.0 id, 90.4 wa,  0.0 hi,  3.9 si,  0.0 st
KiB Mem :  2048416 total,  1592804 free,   171912 used,   283700 buff/cache
KiB Swap:  2097148 total,  1892232 free,   204916 used.  1715080 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 2874 root      20   0  212284 102352    276 R  7.6  5.0   0:03.84 stress

-cpushare 512限制限制下CPU的时间片分配比例,我们启动两个占用cpustress进程,一个容器设置-cpushare 512

  mydocker git:(2.2) nohup stress --vm-bytes 200m --vm-keep -m 1 &
[1] 3000
nohup: ignoring input and appending output to 'nohup.out'
  mydocker git:(2.2) sudo ./mydocker run -ti -cpushare 512 stress --vm-bytes 200m --vm-keep -m 1
{"level":"info","msg":"command all is stress --vm-bytes 200m --vm-keep -m 1","time":"2016-12-03T21:00:28+08:00"}
{"level":"info","msg":"init come on","time":"2016-12-03T21:00:28+08:00"}
{"level":"warning","msg":"stress --vm-bytes 200m --vm-keep -m 1","time":"2016-12-03T21:00:28+08:00"}
{"level":"info","msg":"Find path /usr/bin/stress","time":"2016-12-03T21:00:28+08:00"}
stress: info: [1] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd

上面的没有设置cpushare的进程的默认的值是1024,我们通过设置容器的-cpushare 512,所以能看到容器中的进程的CPU占用只有默认的一半。

%Cpu(s): 99.7 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
KiB Mem :  2048416 total,  1284324 free,   479940 used,   284152 buff/cache
KiB Swap:  2097148 total,  2097148 free,        0 used.  1407116 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 3290 bingshe+  20   0  212284 205000    212 R 66.4 10.0   0:04.49 stress
 3273 root      20   0  212284 205004    212 R 33.2 10.0   0:16.01 stress

小结

我们通过这一节在容器上增加了可配置的资源的控制,后面我们会继续丰富这个容器引擎的能力。

相关图书推荐<<自己动手写docker>>

_Docker_01_


相关链接:
《自己动手写Docker》书摘之一: Linux Namespace
《自己动手写Docker》书摘之二: Linux Cgroups  
《自己动手写Docker》书摘之三: Linux UnionFS  
《自己动手写Docker》书摘之四: 构造简单容器  
《自己动手写Docker》书摘之五: 增加容器资源限制

目录
相关文章
|
17天前
|
监控 NoSQL 时序数据库
《docker高级篇(大厂进阶):7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括:原生命令、是什么、compose容器编排,一套带走
《docker高级篇(大厂进阶):7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括:原生命令、是什么、compose容器编排,一套带走
157 77
|
25天前
|
监控 Docker 容器
在Docker容器中运行打包好的应用程序
在Docker容器中运行打包好的应用程序
|
3天前
|
存储 Kubernetes 开发者
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
Docker 是一种开源的应用容器引擎,允许开发者将应用程序及其依赖打包成可移植的镜像,并在任何支持 Docker 的平台上运行。其核心概念包括镜像、容器和仓库。镜像是只读的文件系统,容器是镜像的运行实例,仓库用于存储和分发镜像。Kubernetes(k8s)则是容器集群管理系统,提供自动化部署、扩展和维护等功能,支持服务发现、负载均衡、自动伸缩等特性。两者结合使用,可以实现高效的容器化应用管理和运维。Docker 主要用于单主机上的容器管理,而 Kubernetes 则专注于跨多主机的容器编排与调度。尽管 k8s 逐渐减少了对 Docker 作为容器运行时的支持,但 Doc
30 5
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
|
9天前
|
关系型数据库 应用服务中间件 PHP
实战~如何组织一个多容器项目docker-compose
本文介绍了如何使用Docker搭建Nginx、PHP和MySQL的环境。首先启动Nginx容器并查看IP地址,接着启动Alpine容器并安装curl测试连通性。通过`--link`方式或`docker-compose`配置文件实现服务间的通信。最后展示了Nginx配置文件和PHP代码示例,验证了各服务的正常运行。
30 3
实战~如何组织一个多容器项目docker-compose
|
3天前
|
Unix Linux Docker
CentOS停更沉寂,RHEL巨变限制源代:Docker容器化技术的兴起助力操作系统新格局
操作系统是计算机系统的核心软件,管理和控制硬件与软件资源,为用户和应用程序提供高效、安全的运行环境。Linux作为开源、跨平台的操作系统,具有高度可定制性、稳定性和安全性,广泛应用于服务器、云计算、物联网等领域。其发展得益于庞大的社区支持,多种发行版如Ubuntu、Debian、Fedora等满足不同需求。
17 4
|
19天前
|
数据建模 应用服务中间件 nginx
docker替换宿主与容器的映射端口和文件路径
通过正确配置 Docker 的端口和文件路径映射,可以有效地管理容器化应用程序,确保其高效运行和数据持久性。在生产环境中,动态替换映射配置有助于灵活应对各种需求变化。以上方法和步骤提供了一种可靠且易于操作的方案,帮助您轻松管理 Docker 容器的端口和路径映射。
60 3
|
25天前
|
Prometheus 监控 Cloud Native
如何使用Prometheus监控Docker Swarm集群的资源使用情况?
还可以根据实际需求进行进一步的配置和优化,如设置告警规则,当资源使用超出阈值时及时发出警报。通过这些步骤,能够有效地使用 Prometheus 对 Docker Swarm 集群的资源进行监控和管理。
43 8
|
25天前
|
存储 缓存 监控
Docker容器性能调优的关键技巧,涵盖CPU、内存、网络及磁盘I/O的优化策略,结合实战案例,旨在帮助读者有效提升Docker容器的性能与稳定性。
本文介绍了Docker容器性能调优的关键技巧,涵盖CPU、内存、网络及磁盘I/O的优化策略,结合实战案例,旨在帮助读者有效提升Docker容器的性能与稳定性。
66 7
|
25天前
|
存储 Prometheus 监控
Docker容器内进行应用调试与故障排除的方法与技巧,包括使用日志、进入容器检查、利用监控工具及检查配置等,旨在帮助用户有效应对应用部署中的挑战,确保应用稳定运行
本文深入探讨了在Docker容器内进行应用调试与故障排除的方法与技巧,包括使用日志、进入容器检查、利用监控工具及检查配置等,旨在帮助用户有效应对应用部署中的挑战,确保应用稳定运行。
32 5
|
25天前
|
开发框架 安全 开发者
Docker 是一种容器化技术,支持开发者将应用及其依赖打包成容器,在不同平台运行而无需修改。
Docker 是一种容器化技术,支持开发者将应用及其依赖打包成容器,在不同平台运行而无需修改。本文探讨了 Docker 在多平台应用构建与部署中的作用,包括环境一致性、依赖管理、快速构建等优势,以及部署流程和注意事项,展示了 Docker 如何简化开发与部署过程,提高效率和可移植性。
55 4