建议参考官方文档 https://istio.io/latest/zh/docs/setup/install/virtual-machine/  ，这里提醒大家对于命令中文版部分命令与英文版不一致，请以 英文版 为准。

对于istio在vm上的安装教程主要分为三部分。首先是在k8s的master节点生成vm连接主节点的一些配置信息，其实是在vm上应用这些配置信息，最后也就是验证连接是否成功。

本篇主要介绍“单网络”的情况， 对于”多网络“请自行参考官方文档。

vm环境准备

生成vm通讯配置信息

这里主要介绍一些新手迷惑的部分。如环境变量设置及vm注册的方式

设置环境变量

在设置变量时，对于”单网络“来讲 CLUSTER_NETWORK 和 VM_NETWORK 保留空值即可。如我这里设置如下

$ VM_APP="myapp"
$ VM_NAMESPACE="vm"
$ WORK_DIR="/root/myapp"
$ SERVICE_ACCOUNT="vm-sa"
$ CLUSTER_NETWORK=""
$ VM_NETWORK=""
$ CLUSTER="Kubernetes"

每个环境变量的解释： VM_APP 表示vm上应用的名称 VM_NAMESPACE 表示应用所在的namespace WORK_DIR 生成vm配置信息保留的目录，任何位置即可 SERVICE_ACCOUNT 服务运行的账号 ，即yaml文件中的 ServiceAccount 字段 CLUSTER 集群名称，默认为 Kubernetes 即可。

安装 Istio 控制平面

1 为安装创建 IstioOperator 空间

cat <<EOF > ./vm-cluster.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    enableEnvoyAccessLogService: true
    defaultConfig.envoyAccessLogService.address: skywalking-oap.istio-system:11800
  values:
    global:
      meshID: mesh1
      multiCluster:
        clusterName: "${CLUSTER}"
      network: "${CLUSTER_NETWORK}"
EOF

spec.meshConfig.accessLogFile 表示启用日志功能，这样流量经过envoy 时将在日志 /var/log/istio/istio.log 中输出；其余三个是启用skywaling链路追踪服务所需要的配置，如果不启用将其删除即可；第四个是链路追踪服务的地址。如果仅仅是想输出日志没有启用流量追踪服务的话，则只配置前两项即可。

什么是 docker buildx

Docker Buildx是一个CLI插件，它扩展了Docker命令，完全支持Moby BuildKit builder toolkit提供的功能。它提供了与docker build相同的用户体验，并提供了许多新功能，如创建作用域生成器实例和针对多个节点并发构建。

Docker Buildx包含在Docker 19.03中，并与以下Docker Desktop版本捆绑在一起。请注意，必须启用“实验特性”选项才能使用Docker Buildx。

Docker Desktop Enterprise version 2.1.0 Docker Desktop Edge version 2.0.4.0 or higher

用法

Usage:  docker buildx [OPTIONS] COMMAND

Extended build capabilities with BuildKit

Options:
      --builder string   Override the configured builder instance

Management Commands:
  imagetools  Commands to work on images in registry

Commands:
  bake        Build from a file
  build       Start a build
  create      Create a new builder instance
  du          Disk usage
  inspect     Inspect current builder instance
  ls          List builder instances
  prune       Remove build cache
  rm          Remove a builder instance
  stop        Stop builder instance
  use         Set the current builder instance
  version     Show buildx version information

Run 'docker buildx COMMAND --help' for more information on a command

一般用到 create、ls 和 rm 就可以了

在使用kubenetes的过程中，如何将服务开放到集群外部访问是一个重要的问题。当使用云平台（阿里云、腾讯云、AWS等）的容器服务时，我们可以通过配置 service 为 LoadBalancer 模式来绑定云平台的负载均衡器，从而实现外网的访问。但是，如果对于自建的 kubernetes裸机集群，这个问题则要麻烦的多。

祼机集群不支持负载均衡的方式，可用的不外乎NodePort、HostNetwork、ExternalIPs等方式来实现外部访问。但这些方式并不完美，他们或多或少都存在的一些缺点，这使得裸机集群成为Kubernetes生态系统中的二等公民。

MetalLB 旨在通过提供与标准网络设备集成的Network LB实施来解决这个痛点，从而使裸机群集上的外部服务也尽可能“正常运行”，减少运维上的管理成本。它是一种纯软件的解决方案，参考 https://kubernetes.github.io/ingress-nginx/deploy/baremetal/。

从 v0.13.0 版本开始，官方对解决方案进行了部分调整，操作步骤简洁一些，建议使用最新版本，参考官方教程 https://metallb.universe.tf/installation/

部署

1. 创建namespace

$ kubectl create namespace metallb-system

2. 新建 secret

$ kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"

参数 from 前面是两个-

3. 部署

root@sxf-virtual-machine:~# kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.12.1/manifests/metallb.yaml
Warning: policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
podsecuritypolicy.policy/controller created
podsecuritypolicy.policy/speaker created
serviceaccount/controller created
serviceaccount/speaker created
clusterrole.rbac.authorization.k8s.io/metallb-system:controller created
clusterrole.rbac.authorization.k8s.io/metallb-system:speaker created
role.rbac.authorization.k8s.io/config-watcher created
role.rbac.authorization.k8s.io/pod-lister created
role.rbac.authorization.k8s.io/controller created
clusterrolebinding.rbac.authorization.k8s.io/metallb-system:controller created
clusterrolebinding.rbac.authorization.k8s.io/metallb-system:speaker created
rolebinding.rbac.authorization.k8s.io/config-watcher created
rolebinding.rbac.authorization.k8s.io/pod-lister created
rolebinding.rbac.authorization.k8s.io/controller created
daemonset.apps/speaker created
deployment.apps/controller created

查看部署结果

使用服务入口（Service Entry） 来添加一个服务入口到 Istio 内部维护的服务注册中心。添加了服务入口后，Envoy 代理可以向服务发送流量，就好像它是网格内部的服务一样，可参考 https://istio.io/latest/zh/docs/concepts/traffic-management/#service-entries。

简单的理解就是允许内网向外网服务发送流量请求，但你可能会说正常情况下在pod里也是可以访问外网的，这两者有什么区别呢?

确实默认情况下，Istio 配置 Envoy 代理可以将请求传递给外部服务。但是无法使用 Istio 的特性来控制没有在网格中注册的目标流量。这也正是 ServiceEntry 真正发挥的作用，通过配置服务入口允许您管理运行在网格外的服务的流量。

此外，可以配置虚拟服务和目标规则，以更精细的方式控制到服务条目的流量，就像为网格中的其他任何服务配置流量一样。

为了更好的理解这一块的内容，我们先看一下普通POD发送请求的流程图普通 Pod 请求

创建 ServiceEntry 资源

举例来说：

svc-entry.yaml

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: svc-entry
spec:
  hosts:
  - "www.baidu.com"
  ports:
  - number: 80
    name: http
    protocol: HTTP
  - number: 443
    name: https
    protocol: HTTPS
  location: MESH_EXTERNAL
  resolution: DNS

该 ServiceEntry 资源定义了一个外部网站 www.baidu.com 服务，并将它纳入到 Istio 内部维护的服务注册表（服务网格）中。

创建资源

$ kubectl apply -f svc-entry.yaml
serviceentry.networking.istio.io/svc-entry created

现在我们已经创建了一个 ServiceEntry, 默认在 default 命名空间。

root@vm:/home/sxf/service-entry# kubectl get se
NAMESPACE   NAME        HOSTS               LOCATION        RESOLUTION   AGE
default     svc-entry   ["www.baidu.com"]   MESH_EXTERNAL   DNS          13s

为了测试这个效果，我们再创建一个pod，然后在pod里访问上面创建的 ServiceEntry。

环境 ubuntu18.04 64位

Kubernetes v1.21.3

这里需要注意，本教程安装的k8s版本号 <- v1.24.0，主要是因为从v1.24.0以后移除了 Dockershim，无法继续使用 Docker Engine，后续将默认采用 containerd ，它是一个从 CNCF 毕业的项目。如果仍想使用原来 Docker Engine 的方式可以安装  cri-dockerd ，它是 Dockershim 的替代品。

如果你想将现在 Docker Engine 的容器更换为 containerd，可以参考官方迁移教程 将节点上的容器运行时从 Docker Engine 改为 containerd

为了解决国内访问一些国外网站慢的问题，本文使用了国内阿里云的镜像。

更换apt包源

这里使用aliyun镜像 , 为了安全起见，建议备份原来系统默认的 /etc/apt/sources.list 文件

编辑文件 /etc/apt/sources.list，将默认网址  或  替换为

更新缓存

$ sudo apt-get clean all
$ sudo apt-get update

安装Docker

参考官方文档  或 aliyun 文档

安装 docker

1. 安装基础工具

$ sudo apt update
$ sudo apt-get install
    apt-transport-https
    ca-certificates
    curl
    gnupg
    lsb-release

2. 安装GPG证书

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

3: 写入软件源信息

• The SPIFFE Workload API

• Envoy spiffe spire

• 简而言之SPIFFE

• SPIFFE信任域

• 使用SPIRE（自动）提供TLS证书给Envoy以进行更强大的身份验证

• 谁使用SPIFFE？

• Securing the Service Mesh with SPIRE 0.3

在runtime中有 [runtime.LockOSThread](https://github.com/golang/go/blob/go1.16.3/src/runtime/proc.go#L4248-L4278) 和 [runtime.UnlockOSThread](https://github.com/golang/go/blob/go1.16.3/src/runtime/proc.go#L4302-L4323) 两个函数，这两个函数有什么作用呢？我们看一下标准库中对它们的解释。

runtime.LockOSThread

// LockOSThread wires the calling goroutine to its current operating system thread.
// The calling goroutine will always execute in that thread,
// and no other goroutine will execute in it,
// until the calling goroutine has made as many calls to
// UnlockOSThread as to LockOSThread.
// If the calling goroutine exits without unlocking the thread,
// the thread will be terminated.
//
// All init functions are run on the startup thread. Calling LockOSThread
// from an init function will cause the main function to be invoked on
// that thread.
//
// A goroutine should call LockOSThread before calling OS services or
// non-Go library functions that depend on per-thread state.

调用 LockOSThread 将 绑定 当前 goroutine 到当前 操作系统 线程，此 goroutine 将始终在此线程执行，其它 goroutine 则无法在此线程中得到执行，直到当前调用线程执行了 UnlockOSThread 为止（也就是说 LockOSThread 可以指定一个goroutine 独占 一个系统线程）；

无锁队列是 lock-free 中最基本的数据结构，一般应用在需要一款高性能队列的场景下。

对于多线程用户来说，无锁队列的入队和出队操作是线程安全的，不用再加锁控制

什么是无锁队列

队列每个开发者都知道，那么什么又是无锁队列呢？字面理解起来就是一个无锁状态的队列，多个线程（消费者）同时操作数据的时候不需要加锁，因为加/解锁都是一个很消耗资源的动作。

实现原理

我们先看一下无锁队列的底层实现数据结构。

数据结构

无锁队列底层的数据结构实现方式主要有两种：数组 和 链接。

数组

在首次初始化时，需要申请一块连接的大的内存。读写数据直接从数据的指定位置操作即可，时间复杂度为O(1)。

缺点：数组长度有限，一旦数组索引位置写满，则无法继续写入，即队列有上限。

链表

不用像数组一样，刚开始就申请一块连接的大的内存空间。只有在每次写时数据的时候，申请这个数据节点大小的内存即可，这样就可以实现无限的写入，没有长度限制问题。

缺点：每次写数据都要申请内存，在写的场景，最差的情况是多少个数据就申请多少次内存，而每次申请都是一个消耗资源的动作。

可以看到无锁底层的实现的不同各有优势。多数据情况下，我们都采用链表来实现无锁队列，主要原因就是写入可以没有长度的限制。相比每次申请都要费时来说，满足前面的条件是我们最基本的要求。当然主要还是真正的使用场景。

CAS

CAS 是 Compare And Swap 的简称, 属于 乐观锁，这是一个并发同步原语. 伪代码如下:

bool compare_and_swap(int *reg, int oldval, int newval)
{
    int reg_val = *reg;
    if(reg_val == oldval)
    {
        *reg = newval;
        return true;
    }
    return false;
}

CAS操作有三个参数，分别表示 内存值V、旧的预期值A 和 修改后的更新值B。

判断变量内存某个位置的值是否为预期值，如果是则更改为新的值，并返回true，这个过程是原子性操作。如果修改失败，可能需要重试再次执行CAS操作，直到修改成功，一般称此过程为自旋。可以看到每次调用 CAS 命令前需要先读取旧值 oldval。

现在几乎所有的CPU指令都支持CAS的原子操作，X86下对应的是 CMPXCHG 汇编指令。有了这个操作，我们就可以用其来实现各种无锁的数据结构。

使用场景

无锁队列也属于队列的一种，所以大部分队列的使用场景都可以使用它来代替其它有锁队列,无锁队列通过不加锁的方式提高队列性能。

参考资料

• https://zhuanlan.zhihu.com/p/336912752
• 无锁队列是否不适用于大容量应用场景？
• https://www.dazhuanlan.com/2019/12/16/5df6622b4f46b/
• https://blog.codingnow.com/2014/12/skynet_spinlock.html
• https://blog.csdn.net/yishizuofei/article/details/78353722
• 一文彻底搞懂CAS实现原理 & 深入到CPU指令
• 无锁队列的分析与设计
• Golang中的CAS原子操作 和 锁

上一节《 GC 对根对象扫描实现的源码分析》中，我们提到过在GC的时候，在对一些goroutine 栈进行扫描时，会在其扫描前触发 G 的暂停([suspendG](https://github.com/golang/go/blob/go1.16.2/src/runtime/preempt.go#L76-L254))和恢复([resumeG](https://github.com/golang/go/blob/go1.16.2/src/runtime/preempt.go#L256-L280))。

// markroot scans the i'th root.
//
// Preemption must be disabled (because this uses a gcWork).
//
// nowritebarrier is only advisory here.
//
//go:nowritebarrier
func markroot(gcw *gcWork, i uint32) {
	baseFlushCache := uint32(fixedRootCount)
	baseData := baseFlushCache + uint32(work.nFlushCacheRoots)
	baseBSS := baseData + uint32(work.nDataRoots)
	baseSpans := baseBSS + uint32(work.nBSSRoots)
	baseStacks := baseSpans + uint32(work.nSpanRoots)
	end := baseStacks + uint32(work.nStackRoots)

	// Note: if you add a case here, please also update heapdump.go:dumproots.
	switch {
		......

	default:
		var gp *g
		if baseStacks <= i && i < end {
			gp = allgs[i-baseStacks]
		} else {
			throw("markroot: bad index")
		}

		status := readgstatus(gp) // We are not in a scan state
		if (status == _Gwaiting || status == _Gsyscall) && gp.waitsince == 0 {
			gp.waitsince = work.tstart
		}

		// scanstack must be done on the system stack in case
		// we're trying to scan our own stack.
		systemstack(func() {
			userG := getg().m.curg
			selfScan := gp == userG && readgstatus(userG) == _Grunning
			if selfScan {
				casgstatus(userG, _Grunning, _Gwaiting)
				userG.waitreason = waitReasonGarbageCollectionScan
			}

			// TODO: suspendG blocks (and spins) until gp
			// stops, which may take a while for
			// running goroutines. Consider doing this in
			// two phases where the first is non-blocking:
			// we scan the stacks we can and ask running
			// goroutines to scan themselves; and the
			// second blocks.
			stopped := suspendG(gp)
			if stopped.dead {
				gp.gcscandone = true
				return
			}
			if gp.gcscandone {
				throw("g already scanned")
			}
			scanstack(gp, gcw)
			gp.gcscandone = true
			resumeG(stopped)

			if selfScan {
				casgstatus(userG, _Gwaiting, _Grunning)
			}
		})
	}
}

那么它在暂停和恢复一个goroutine时都做了些什么工作呢，今天我们通过源码来详细看一下。 go version 1.16.2

对于提高对 stack 的使用效率，避免重复从heap中分配与释放，对其使用了 pool 的概念，runtime 里为共提供了两个pool, 分别为 stackpool ，另一个为 stackLarge。stack pool

stackpool: 16b~32k 对应通用的大小的stack。获取时通过调用 stackpoolalloc(), 释放时调用 stackpoolfree()。

stackLarge：对应 > 32K 的 stack

在程序全局调度器 初始化 时会通过调用 stackinit() 实现对 stack 初始化。

当我们执行一个 go func() 语句的时候，runtime 会通过调用 newproc() 函数来创建G。而内部真正创建G的函数为 [newproc1()](https://github.com/golang/go/blob/go1.16.3/src/runtime/proc.go#L3990-L4098)，在没有G可以复用的情况下，会通过 newg = malg(_StackMin) 语句创建一个包含stack的G。

// Allocate a new g, with a stack big enough for stacksize bytes.
func malg(stacksize int32) *g {
	newg := new(g)
	if stacksize >= 0 {
		stacksize = round2(_StackSystem + stacksize)
		systemstack(func() {
			newg.stack = stackalloc(uint32(stacksize))
		})
		newg.stackguard0 = newg.stack.lo + _StackGuard
		newg.stackguard1 = ^uintptr(0)
		// Clear the bottom word of the stack. We record g
		// there on gsignal stack during VDSO on ARM and ARM64.
		*(*uintptr)(unsafe.Pointer(newg.stack.lo)) = 0
	}
	return newg
}

对于新创建的g，需要通过调用 [stackalloc()](https://github.com/golang/go/blob/go1.16.3/src/runtime/stack.go#L321-L419) 函数为其分配 stacksize 大小stack，那么分配操作它又是如何工作的呢？

现状

目前在网络编程中，golang采用的是一种 goroutine-per-connection 的模式，即为每一个连接都分配一个goroutine，一个连接就是一个goroutine，多个连接之间没有关系。

package main

import (
	"fmt"
	"io/ioutil"
	"net"
	"time"
)

//模拟server端
func main() {
	tcpServer, _ := net.ResolveTCPAddr("tcp4", ":8080")
	listener, _ := net.ListenTCP("tcp", tcpServer)

	for {
		//当有新客户端请求时拿到与客户端的连接
		conn, err := listener.Accept()
		if err != nil {
			fmt.Println(err)
			continue
		}

		// 处理逻辑 goroutine-per-connection
		go handle(conn)
	}
}

func handle(conn net.Conn) {
	defer conn.Close()

	//读取客户端传送的消息
	go func() {
		response, _ := ioutil.ReadAll(conn)
		fmt.Println(string(response))
	}()

	//向客户端发送消息
	time.Sleep(1 * time.Second)
	now := time.Now().String()
	conn.Write([]byte(now))
}

这种模式看起来非常的舒服，简单易懂，大大减少了开发者的心智负担，深受开发者的喜爱。

Linux 内核仓库 https://github.com/torvalds/linux

Linux 内核文档： https://www.kernel.org/doc/html/latest/index.html（ 中文）

开发工具参考： https://www.kernel.org/doc/html/latest/dev-tools/index.html

也可以使用 VSCode + 插件C/C++ GNU Global

通过前面三个博客可以得知 select，** poll， eventpoll** 的详细实现，现在来总结对比下它们之间的不同:

1. select 流程图
2. poll 流程图
3. eventpoll 流程图
4. 优缺点总结 <1> 监控文件最大数不同：select和poll都是以数组形式传入药监控的文件句柄，而这个数组是有大小限制的1024个左右(不是很清楚).而epoll则是每add一个文件句柄会new一个新epi出来，挂载在ep的红黑树中，监控的文件个数没有明确限制(可能会受限于系统最大打开文件句柄数)从这点上看，epoll是优于select和poll. <2> copy参数次数不同：无论是select/poll/epoll都是有对应的系统调用，其参数都会从userspace拷贝到kernelspace,如果监控的文件句柄数很大，select/poll在这方面的耗时会明显多于epoll,因为每次调用select/poll都要重新拷贝一次所有的监控句柄，而epoll则在sys_epoll_ctrl的时候添加一次存储在内核数据结构中，后续的sys_epoll_wait会通过内核数据找到监控的文件句柄对应的file和监控得到的event. <3> 轮询方式的差异：select 会传入监控句柄的最大句柄，从而监控查询0 ~~ max_fd之间的所有file的驱动状态来获取想要的文件句柄中想要的event，而poll则只会轮询用户传入的文件句柄集，相比select会少轮询很多file的状态，这点上poll明显优于select.而epoll则是完全异步的方式，哪个有更新会添加到ep->rdlist中,epoll_wait来取走.当连接数不是很多且每个client都非常活跃的情况下,poll > select > epoll,而当连接数巨大且大多数client都是潜水状态的情况下，epoll > poll > select。

本文摘自： https://blog.csdn.net/weixin_38537730/article/details/104100468

上一节 《Runtime: Golang 之 sync.Pool 源码分析》 我们介绍了sync.Pool 的源码分析，本节介绍一个 fasthttp 中引用的一缓存池库 [bytebufferpool](https://github.com/valyala/bytebufferpool)，这两个库是同一个开发者。对于这个缓存池库与同类型的几个库的对比，可以参考 https://omgnull.github.io/go-benchmark/buffer/。

建议大家了解一下[fasthttp](https://github.com/valyala/fasthttp) 这个库，性能要比直接使用内置的 net/http 高出很多，其主要原因是大量的用到了缓存池 sync.Pool 进行性能提升。

用法

// https://github.com/valyala/bytebufferpool/blob/18533face0/bytebuffer_example_test.go
package bytebufferpool_test

import (
	"fmt"

	"github.com/valyala/bytebufferpool"
)

func ExampleByteBuffer() {
	// 从缓存池取 Get()
	bb := bytebufferpool.Get()

	// 用法
	bb.WriteString("first linen")
	bb.Write([]byte("second linen"))
	bb.B = append(bb.B, "third linen"...)

	fmt.Printf("bytebuffer contents=%q", bb.B)

	// 使用完毕，放回缓存池 Put()
	// It is safe to release byte buffer now, since it is no longer used.
	bytebufferpool.Put(bb)
}

全局变量

我们先看一下与其相关的一些常量

对于一个刚刚接触 kubernetes(k8s)的新手来说，想好更好的学习它，首先就要对它有一个大概的认知，所以本文我们先以全局观来介绍一个 kubernetes。

kubernetes 架构 kubernetes 架构图

kubernets 整体可以分为两大部分，分别为 Master 和 Node ，我们一般称其为节点，这两种角色分别对应着控制节点和计算节点，根据我们的经验可以清楚的知道 Master 是控制节点。

Master 节点

控制节点 Master 节点由三部分组成，分别为 Controller Manager 、 API Server 和 Scheduler ，它们相互紧密协作，每个部分负责不同的工作职责。

• controller-manager 全称为 kube-controler-manager 组件，主要用来负责容器编排。如一个容器(实际上是 pod，pod 是最基本的调度单元。一般一个 pod 里会部署一个容器服务)服务可以指定副本数量，如果实际运行的副本数据与期望的不一致，则会自动再启动几个容器副本，最终实现期望的数量。这个组件，就是一系列控制器的集合。我们可以查看一下 Kubernetes 项目的 pkg/controller 目录, 伪代码如下：

for {
  实际状态 := 获取集群中对象X的实际状态（Actual State）
  期望状态 := 获取集群中对象X的期望状态（Desired State）
  if 实际状态 == 期望状态{
    什么都不做
  } else {
    执行编排动作，将实际状态调整为期望状态
  }
}

• api server 对外提供 api 服务，用来接收命令进行集群管理。对内负责与 etcd 注册中心进行通讯，进行一些配置信息的存储与读取
• scheduler 负责调度。如一个容器存放到 k8s 集群中的哪个 node 节点最为合适

实际上这三个组件的功能远远多于我们这里描述的。

在容器里有两个非常重要的概念，一个是 namespace 用来实现对容器里所有进程进行隔离；另一个就是 cgroup，用来对容器进程内使用资源进行限制。那 cgroup 又是如何实现对资源进行限制的呢，今天我们来了解一下它的实现原理。

什么是cgroup

cgroup 是 Control Groups 的缩写，是 Linux 内核提供的一种可以限制、记录、隔离 进程组 所使用的物理资源(如 cpu、memory、磁盘IO等等) 的机制，被 LXC、docker 等很多项目用于实现进程资源控制。cgroup 是将任意进程进行分组化管理的 Linux 内核功能。 cgroup 本身是提供将进程进行分组化管理的功能和接口的基础结构，I/O 或内存的分配控制等具体的资源管理功能是通过这个功能来实现的。 一定要切记，这里的限制单元为 进程组，而不是进程。

子系统

上面提到的具体的资源管理功能统称为 cgroup 子系统，所有子系统列表可以通过 cat /proc/cgroups 命令查看，主要有以下几大子系统：

# cat /proc/cgroups
#subsys_name	hierarchy	num_cgroups	enabled
cpuset	        4	        7	        1
cpu	        2	        89	        1
cpuacct	        2	        89	        1
blkio	        3	        86	        1
memory	        7	        150	        1
devices	        6	        84	        1
freezer	        5	        7	        1
net_cls	        10	        7	        1
perf_event	    12	        7	        1
net_prio	    10	        7	        1
hugetlb	        8	        7	        1
pids	        9	        94      	1
rdma	        11	        1	        1

• cpuset：如果是多核心的CPU, 这个子系统会为 cgroup 任务分配单独的CPU和内存。
• cpu：使用调度程序为cgroup任务提供CPU的访问。
• cpuacct：产生cgroup 任务的CPU资源报告
• blkio：设置限制每一个块设备的输入输出控制。例如:磁盘，光盘以及usb 等等。
• memory: 设置每一个cgroup 的内存限制以及产生内存资源报告。
• devices：容许或拒绝cgroup任务对设备的访问。
• freezer：暂停和恢复cgroup任务。
• net_cls: 标记每一个网络包以供cgroup 方便使用。
• ns：命名空间子系统,能够设置一个子系统的上限配额。
• perf_event: 增加了对每一个group 的监测跟踪的能力，能够监测属于某个特定的group 的全部线程以及运行在特定,监控能力超出限制则进行终止。
• net_prio 设置cgroup中进程产生的网络流量的优先级
• hugetlb 限制使用的内存页数量
• pids 限制任务的数量

目前 docker 只是用了其中一部分子系统，实现对资源配额和使用的控制。如可以使用 `freezer` 子系统对 `进行组` 进行挂起和恢复。