容器的发展史

技术迸发期

• 容器镜像打包了整个容器运行依赖的环境，以避免依赖运行容器的服务器的操作系统，从而实现 “build once，run anywhere”。
• 容器镜像一旦构建完成，就变成 read only，成为不可变基础设施的一份子。
• 操作系统发行版无关，核心解决的是容器进程对操作系统包含的库、工具、配置的依赖，但是容器镜像无法解决容器进程对内核特性的特殊依赖。这个在实际使用容器的过程中也经常跳进这个大坑：

商用探索期

• 通用容器编排服务**：在容器编排系统三国杀结果出来以前，基于多方下注策略构建的容器编排服务系统。其中 AWS 是自研的编排系统，Azure 的 ACS 同时支持 Docker Swarm、DC/OS 和 Kubernetes，阿里云 ACS 则是支持 Docker swarm 和 Kubernetes。Google 和华为则是坚定支持 Kubernetes 而未推出支持其它容器编排系统的容器服务。随着 Kubernetes 一统容器编排江湖，这条路线的容器服务日渐式微，Azure 更是在今年初直接终止了 ACS 服务。**
• Kubernetes容器编排服务**：Google 是理所当然最早试水 Kubernetes 容器编排服务的大厂，也较早开展了 K8s 容器编排服务。随着 2017 年各大厂在 CNCF 这张谈判桌上达成了 Kubernetes 兼容性认证流程，Kubernetes 编排服务市场迎来一轮大爆发，到 2018 年各大云厂商的 K8s 容器编排服务就完整就位了。**
• Serverless容器实例服务**：从 2017 年开始，行业开始试水 Serverless 容器实例服务，把用户从维护容器基础设施的繁重任务中解放出来从而聚焦业务本身。Google Cloud Run 核心目标是支持 Knative，所以其使用形态上附加了不少约束条件。**

• 行业对容器化的接受程度已经很高，容器化普及率也是逐年提升。
• 容器编排系统已经一战定江山，K8s 成为事实上的容器编排之王。
• Serverless 容器实例服务受到市场的欢迎，客户群体日益扩大。
• 长期看托管容器编排服务和 Serverless 容器实例服务将长期共存，协同满足客户对服务成本和弹性能力的需求。

1. Container on VM。也就是按照分层设计思路，通过 IaaS + PaaS 的架构构建容器服务，这个是商用探索阶段的典型架构。基于各大云厂商成熟的 IaaS 基础设施生产虚拟机，在虚拟机里面部署容器服务组件。这种架构采用的是 lift and shift 策略，把容器服务的运维责任从用户转移到云厂商。采用和用户相同的软件组件，只是转移运维责任，有利于引导客户逐步上云、接受云原生思维。但是这个时期云厂商提供的服务是单纯的运维托管，相对用户自建容器服务并没有太明显的技术优势，甚至受多租户隔离的限制部分使用体验还不如用户自建容器服务。
2. Container with hardware virtualization。如果沿用 Container on VM 的分层设计架构，云厂商很难构建独有的技术优势。对于 Serverless 容器实例服务，服务交付平面已经从 IaaS 的硬件接口上移到 OS Syscall，所以不要遵循 VM + 容器的分层设计思路。我们需要从需求本源出发，容器服务需要高性能、强隔离、够安全和低成本的容器引擎。

1. 技术萌芽期：解决了容器运行环境的隔离问题
2. 技术迸发期：解决了软件分发及容器编排问题
3. 商用探索期：确认了容器的商用服务形态
4. 商用拓展期：扩大适用场景和部署规模，通过技术创新提升产品竞争力

Docker

为什么要用Docker

• 开发将编译好的制品上传到共享仓库
• 运维从共享仓库下载制品，上传到运行服务
• 运维启停服务，比如启停Tomcat
• 如果需要新服务，还需要创建虚拟机，安装基础环境，比如JDK，Tomcat等

• 开发通过Dockerfile将应用打包成镜像，上传到镜像仓库
• 运维从镜像仓库下载镜像，通过Docker run启动服务

• 更高效的利用系统资源
• 更快的启动时间
• 一致的运行环境
• 更轻松的迁移、维护和扩展

Docker的架构

• 主机**：用于承载Docker运行的底座**
• 镜像仓库**：存放镜像制品的地方**

Docker的技术底座

• CLONE_NEWCGROUP
• CLONE_NEWIPC
• CLONE_NEWNET
• CLONE_NEWNS
• CLONE_NEWPID
• CLONE_NEWUSER
• CLONE_NEWUTS

int clone(int (*fn) (void *)，void *child stack,
          int flags， void *arg， . . .
         /* pid_ t *ptid, void *newtls, pid_ t *ctid */ ) ;

• The pid namespace: 管理 PID 命名空间 (PID: Process ID).
• The net namespace: 管理网络命名空间(NET: Networking).
• The ipc namespace: 管理进程间通信命名空间(IPC: InterProcess Communication).
• The mnt namespace: 管理文件系统挂载点命名空间 (MNT: Mount).
• The uts namespace: Unix 时间系统隔离. (UTS: Unix Timesharing System).
• The user namespace: 管理系统用户.

PID Namespace

# ps -ef 
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 Mar05 ?        04:50:01 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
root         2     0  0 Mar05 ?        00:00:02 [kthreadd]
root         4     2  0 Mar05 ?        00:00:00 [kworker/0:0H]
root         6     2  0 Mar05 ?        00:13:29 [ksoftirqd/0]
root         7     2  0 Mar05 ?        00:02:39 [migration/0]
root         8     2  0 Mar05 ?        00:00:00 [rcu_bh]
root         9     2  0 Mar05 ?        01:08:08 [rcu_sched]
root        10     2  0 Mar05 ?        00:00:00 [lru-add-drain]
root        11     2  0 Mar05 ?        00:00:19 [watchdog/0]
root        12     2  0 Mar05 ?        00:00:15 [watchdog/1]
root        13     2  0 Mar05 ?        00:02:38 [migration/1]
root        14     2  0 Mar05 ?        00:11:02 [ksoftirqd/1]
root        16     2  0 Mar05 ?        00:00:00 [kworker/1:0H]
root        18     2  0 Mar05 ?        00:00:00 [kdevtmpfs]
root        19     2  0 Mar05 ?        00:00:00 [netns]
......

# docker run -d --name busybox busybox sleep 3000
b776c8105860a5d46046365ca03b71ec13dac9e1dbe4b8d392e468d49a42020f
# docker exec busybox ps -ef
PID   USER     TIME  COMMAND
    1 root      0:00 sleep 3000
    7 root      0:00 ps -ef

• 不同的用户进程就是通过**Pid Namespace**进行隔离的，且不同的Namespace中可以有相同的Pid。
• 有了**Pid Namespace**，每个Namespace中的Pid能够相互隔离。

# ps -ef | grep b776c8105860
root     2862574    3699  0 16:20 ?        00:00:00 containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/b776c8105860a5d46046365ca03b71ec13dac9e1dbe4b8d392e468d49a42020f -address /var/run/docker/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
root     2866529 2861401  0 16:21 pts/0    00:00:00 grep --color=auto b776c8105860

systemd─┬
        ├─dockerd─┬─containerd─┬
        │         │            ├─containerd-shim─┬─sleep
        │         │            │                 └─10*[{containerd-shim}]

• Host：主机模式，使用主机网络
• Container：容器模式，和某个容器共享网络
• None：拥有自己的网络空间，但是不配置任何网络信息
• Bridge：桥接模式，通过veth桥接到主机上

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 52:54:00:e3:77:24 brd ff:ff:ff:ff:ff:ff
    inet 10.0.4.9/22 brd 10.0.7.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fee3:7724/64 scope link 
       valid_lft forever preferred_lft forever
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:6f:d4:33:49 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:6fff:fed4:3349/64 scope link 
       valid_lft forever preferred_lft forever

# ping 172.17.0.3
PING 172.17.0.3 (172.17.0.3) 56(84) bytes of data.
64 bytes from 172.17.0.3: icmp_seq=1 ttl=64 time=0.056 ms
64 bytes from 172.17.0.3: icmp_seq=2 ttl=64 time=0.056 ms
64 bytes from 172.17.0.3: icmp_seq=3 ttl=64 time=0.041 ms

# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DOCKER     all  --  anywhere             anywhere             ADDRTYPE match dst-type LOCAL
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
DOCKER     all  --  anywhere            !loopback/8           ADDRTYPE match dst-type LOCAL
Chain DOCKER (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere

MNT Namespace

IPC Namespace

UTS Namespace

USER Namespace

CGroups

# lssubsys -m
cpuset /sys/fs/cgroup/cpuset
cpu,cpuacct /sys/fs/cgroup/cpu,cpuacct
memory /sys/fs/cgroup/memory
devices /sys/fs/cgroup/devices
freezer /sys/fs/cgroup/freezer
net_cls,net_prio /sys/fs/cgroup/net_cls,net_prio
blkio /sys/fs/cgroup/blkio
perf_event /sys/fs/cgroup/perf_event
hugetlb /sys/fs/cgroup/hugetlb
pids /sys/fs/cgroup/pids

• cpuset：如果是多核心CPU，这个子系统会为CGroup任务分配单独的CPU
• cpu：使用调度程序为CGroup提供CPU访问
• cpuacct：产生CGroup任务的CPU资源报告
• memory：设置每个CPU的内存限制以及产生内存资源报告
• devices：允许或拒绝CGroup任务对设备的访问
• freezer：暂停或恢复CGroup任务
• net_cls：标记每个网络包以供CGroup使用
• net_prio：针对每个网络接口设置cgroup的访问优先级
• blkio：设置限制每个块的输入输出，例如磁盘、光盘以及USB等
• perf_event：对CGroup进行性能监控
• hugetlb：限制cgroup的huge pages的使用量
• pids：限制一个cgroup及其子孙cgroup中的总进程数

CPU子系统

软限制

• 如果A不忙，没有使用到66%的CPU时间，那么剩余的CPU时间将会被系统分配给B，即B的CPU使用率可以超过33%
• 如果添加了一个新的cgroup C，且它的shares值是1024，那么A的限额变成了1024/(1204+512+1024)=40%，B的变成了20%

• 在闲的时候，shares基本上不起作用，只有在CPU忙的时候起作用，这是一个优点。
• 由于shares是一个绝对值，需要和其它cgroup的值进行比较才能得到自己的相对限额，而在一个部署很多容器的机器上，cgroup的数量是变化的，所以这个限额也是变化的，自己设置了一个高的值，但别人可能设置了一个更高的值，所以这个功能没法精确的控制CPU使用率。

硬限制

• cpu.cfs_period_us：用来配置时间周期长度，单位微秒，默认是100000微妙。
• cpu.cfs_quota_us：用来配置当前cgroup在设置的周期长度内所能使用的CPU时间数，单位微秒，取值大于1ms，-1代表不受限制。

# 创建工程
mkdir busyloop
cd busyloop
go mod init busyloop

package main
func main(){
        for{}
}

go build
./busyloop

# 进入cpu 子系统
cd /sys/fs/cgroup/cpu
# 创建一个busyloop的目录
mkdir busyloop
# 该目录下会自动生成如下文件
ll
total 0
-rw-r--r-- 1 root root 0 Jun  9 17:19 cgroup.clone_children
--w--w--w- 1 root root 0 Jun  9 17:19 cgroup.event_control
-rw-r--r-- 1 root root 0 Jun  9 17:19 cgroup.procs
-r--r--r-- 1 root root 0 Jun  9 17:19 cpuacct.stat
-rw-r--r-- 1 root root 0 Jun  9 17:19 cpuacct.usage
-r--r--r-- 1 root root 0 Jun  9 17:19 cpuacct.usage_percpu
-rw-r--r-- 1 root root 0 Jun  9 17:19 cpu.cfs_period_us
-rw-r--r-- 1 root root 0 Jun  9 17:19 cpu.cfs_quota_us
-rw-r--r-- 1 root root 0 Jun  9 17:19 cpu.rt_period_us
-rw-r--r-- 1 root root 0 Jun  9 17:19 cpu.rt_runtime_us
-rw-r--r-- 1 root root 0 Jun  9 17:19 cpu.shares
-r--r--r-- 1 root root 0 Jun  9 17:19 cpu.stat
-rw-r--r-- 1 root root 0 Jun  9 17:19 notify_on_release
-rw-r--r-- 1 root root 0 Jun  9 17:19 tasks
# 首先在cgroup.procs中记录busyloop的进程
echo 13817 > cgroup.procs
# 这时候还并为做任何限制，所以CPU使用还是1颗
# 给cpu.cfs_quota_us配置50000微妙，也就是使用0.5个CPU
echo 50000 > cpu.cfs_quota_us

补充：Linux进程调度

• Stop调度器：stop_sched_class，优先级最高的调度类，可以抢占其他所有进程，不能被其他进程抢占。
• Deadline调度器：dl_sched_class，使用红黑树，把进程按绝对截止期限进行排序，选择最小进程进行调度允许。
• RT调度器：rt_sched_class，实时调度器，为每个优先级维护一个队列。
• CFS调度器：cfs_sched_class，完全公平调度器，采用完全公平调度算法，引入虚拟运行时间的概念。
• IDLE-TASK调度器：idle_sched_class，空闲调度器，每个CPU都有一个idle线程，当没有其他进程可以调度时，运行idle线程。

CFS调度器

• 自平衡，树上没有一条路径会比其他路径长出两倍
• O(log n) 时间复杂度，能够在树上进行快速高效地插入或删除进程。

UnionFS

• lower和upper两个目录存在同名文件时，lower的文件将会被隐藏，用户只能看到upper的文件。
• lower低优先级的同目录同名文件将会被隐藏。
• 如果存在同名目录，那么lower和upper目录中的内容将会合并。
• 当用户修改merge中来自upper的数据时，数据将直接写入upper中原来目录中，删除文件也同理。
• 当用户修改merge中来自lower的数据时，lower中内容均不会发生任何改变。因为lower是只读的，用户想修改来自lower数据时，overlayfs会首先拷贝一份lower中文件副本到upper中。后续修改或删除将会在upper下的副本中进行，lower中原文件将会被隐藏。
• 如果某一个目录单纯来自lower或者lower和upper合并，默认无法进行rename系统调用。但是可以通过mv重命名。如果要支持rename，需要CONFIG_OVERLAY_FS_REDIRECT_DIR。

# # mkdir lower upper work merge

• lower**目录用于存放lower层文件**
• upper**目录用于存放upper层文件**
• work**目录用于存放临时或者间接文件**
• merge**目录就是挂载目录**

# echo "From lower." > lower/common-file
 # echo "From upper." > upper/common-file
 # echo "From lower." > lower/lower-file
 # echo "From upper." > upper/upper-file
 # tree 
.
├── lower
│   ├── common-file
│   └── lower-file
├── merge
├── upper
│   ├── common-file
│   └── upper-file
└── work

# mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work overlay merge

# tree 
.
├── lower
│   ├── common-file
│   └── lower-file
├── merge
│   ├── common-file
│   ├── lower-file
│   └── upper-file
├── upper
│   ├── common-file
│   └── upper-file
└── work
    └── work
# cat merge/common-file 
From upper.

# echo "Add file from merge" > merge/merge-file
# tree 
.
├── lower
│   ├── common-file
│   └── lower-file
├── merge
│   ├── common-file
│   ├── lower-file
│   ├── merge-file
│   └── upper-file
├── upper
│   ├── common-file
│   ├── merge-file
│   └── upper-file
└── work
    └── work

# echo "update lower file from merge" > merge/lower-file 
# tree 
.
├── lower
│   ├── common-file
│   └── lower-file
├── merge
│   ├── common-file
│   ├── lower-file
│   ├── merge-file
│   └── upper-file
├── upper
│   ├── common-file
│   ├── lower-file
│   ├── merge-file
│   └── upper-file
└── work
    └── work
# cat upper/lower-file 
update lower file from merge
# cat lower/lower-file 
From lower.

Docker镜像怎么实现的

• 基础L1层有file1和file2两个文件，这两个文件都有具体的内容。
• 到L2层的时候需要修改file2的文件内容并且增加file3文件。在修改file2文件的时候，系统会先判定这个文件在L1层有没有，从上图可知L1层是有file2文件，这时候就会把file2复制一份到L2层，然后修改L2层的file2文件，这就是用到了联合文件系统**写时复制**机制，新增文件也是一样。
• 到L3层修改file3的时候也会使用**写时复制**机制，从L2层拷贝file3到L3层 ，然后进行修改。
• 然后我们在视图层看到的file1、file2、file3都是最新的文件。

Docker的常见操作

Docker的常见指令

• docker build
• docker ps
• docker pull
• docker push
• docker image
• docker login
• docker logs
• docker exec
• docker version

Docker镜像的最佳实践

认识Dockerfile

FROM docker.io/centos
LABEL "auth"="joker" \
      "mail"="unclejoker520@163.com"
ENV TIME_ZOME Asia/Shanghai
RUN yum install -y gcc gcc-c++ make openssl-devel prce-devel
ADD nginx-1.14.2.tar.gz /opt/
RUN cd /opt/nginx-1.14.2 && \
    ./configure --prefix=/usr/local/nginx && \
    make -j 4 && \
    make install
RUN rm -rf /opt/nginx* && \
    yum clean all && \
    echo "${TIME_ZOME}" > /etc/timezone && \
    ln -sf /usr/share/zoneinfo/${TIME_ZOME} /etc/localtime
COPY nginx.conf /usr/local/nginx/conf/
WORKDIR /usr/local/nginx/
EXPOSE 80
CMD ["./sbin/nginx","-g","daemon off;"]

Dockerfile常用指令

最佳实践

优化构建上下文

合理利用缓存

合理的优化镜像体积

合理优化镜像层数

合理选择初始化进程

• 能够捕获SIGTERM信号，并完成子进程的优雅终止
• 能够完成子进程的清退，避免产生僵尸进程

Containerd

• 如果是docker作为容器运行时，则调用关系是kubelet—>docker-shim—>dockerd—>containerd
• 如果是containerd作为容器运行时，则调用关系是kubelet—>cri-plugin—>containerd

镜像相关

容器相关

Pod相关

总结

参考

• https://developer.aliyun.com/article/775778
• https://blog.csdn.net/crazymakercircle/article/details/120747767
• https://github.com/krallin/tini