容器化

namespace

作用：充分地利用系统的资源，在同一台宿主机上可以运行多个用户的容器；保证了安全性，不同用户之间不能访问对方的资源

cgroups

对指定的进程做各种计算机资源的限制

容器进程

1号进程与信号

僵尸进程

两个系统调用可以回收掉僵尸进程：

进程停止

Docker 停止一个容器，会向容器的 init 进程发送一个 SIGTERM 信号，在 init 进程退出之后，容器内的其他进程也都立刻退出，其他进程收到的是 SIGKILL 信号

当 Linux 进程收到 SIGTERM 信号并且使进程退出，这时 Linux 内核对处理进程退出的入口点就是 do_exit() 函数，do_exit() 函数中会释放进程的相关资源，比如内存，文件句柄，信号量等，做完这些工作之后，它会调用一个 exit_notify() 函数，用来通知和这个进程相关的父子进程等

为了让子进程也能收到 SIGTERM 信号，init进程可以捕获 SIGTERM 信号，然后调用kill转发给子进程

容器CPU

CPU usage

20221222181330

类型 具体含义
us User,用户态CPU时间，不包括低优先级进程的用户态时间(nice值 1-19 )
sys System，内核态CPU时间
ni Nice, nice 值1 -19的进程用户态CPU时间
id ldle，系统空闲CPU时间
wa lowait,系统等待I/O的CPU时间，这个时间不计入进程CPU时间
hi Hardware irq，处理硬中断的时间，这个时间不计入进程CPU时间
si Softirq,处理软中断的时间，这个时间不计入进程CPU时间
st Steal,表示同一个宿主机上的其他虚拟机抢走的CPU时间

在 k8s 中，通过limit可以限制CPU的使用

CPU cgroup：

cpu.cfs_quota_us 和 cpu.cfs_period_us 这两个值决定了每个控制组中所有进程的可使用 CPU 资源的最大值，cpu.shares 这个值决定了 CPU Cgroup 子系统下控制组可用 CPU 的相对比例

每个进程的 CPU Usage 只包含用户态（us 或 ni）和内核态（sy）两部分，其他的系统 CPU 开销并不包含在进程的 CPU 使用中

CPU使用率

在 /proc/[pid]/stat 下有 utime 和 stime：

$$进程的 ticks = 时间点2(utime + stime) - 时间点1(utime + stime)$$

$$进程的 CPU 使用率 =（进程的 ticks/ 单个 CPU 总 ticks）*100.0$$

对于系统的 CPU 使用率，需要读取 /proc/stat 文件，得到瞬时各项 CPU 使用率的 ticks 值，相加得到一个总值，单项值除以总值就是各项 CPU 的使用率

也可以从每个容器的 CPU Cgroup 控制组里的 cpuacct.stat 的统计值中得到整个容器的 CPU 使用率

load average

统计了这两种情况的进程：

  1. Linux 进程调度器中可运行队列（Running Queue）一段时间（1 分钟，5 分钟，15 分钟）的进程平均数
  2. Linux 进程调度器中休眠队列（Sleeping Queue）里的一段时间的 TASK_UNINTERRUPTIBLE 状态下的进程平均数

Load Average = 可运行队列进程平均数 + 休眠队列中不可打断的进程平均数

处于 D 状态（主要集中在 disk I/O 的访问和信号量（Semaphore）锁的访问）的进程即休眠队列中不可打断的进程过多就会增加负载，这是性能下降的表现

容器内存

OOM

在 Linux 系统里如果内存不足时，就需要杀死一个正在运行的进程来释放一些内存，内核里有一个 oom_badness() 函数用来计算进程被杀死的几率：

系统总的可用页面数乘以进程的 OOM 校准值 oom_score_adj，再加上进程已经使用的物理页面数

oom_score_adj 保存在 /proc/[pid]/oom_score_adj

memeroy cgroup

RSS与PageCache

Memory Cgroup 控制组里 RSS 内存和 Page Cache 内存的和，正好是 memory.usage_in_bytes 的值

要判断容器真实的内存使用量，不能用Memory Cgroup 里的 memory.usage_in_bytes，而需要用 memory.stat 里的 rss 值

memory.usage_in_bytes = memory.stat[rss] + memory.stat[cache] + memory.kmem.usage_in_bytes

swap

值为 100 的时候系统平等回收匿名内存和 Page Cache 内存；一般缺省值为 60，就是优先回收 Page Cache；即使 swappiness 为 0，也不能完全禁止 Swap 分区的使用，就是说在内存紧张的时候，也会使用 Swap 来回收匿名内存

在 memory cgroup 中，当 memory.swappiness = 0 的时候，对匿名页的回收是始终禁止的，也就是始终都不会使用 Swap 空间

容器存储

容器文件系统

为了减少相同镜像文件在同一个节点上的数据冗余，可以节省磁盘与下载带宽开销，使用容器文件系统，UnionFS：主要功能是把多个目录（处于不同的分区）一起挂载（mount）在一个目录下

OverlayFS是UnionFS的一种实现：

2022122413485

在merged做文件操作：

  1. 新建文件，这个文件会出现在 upper/ 目录中
  2. 删除文件，如果删除upper目录里的文件，文件会直接消失，如果删除lower里，会通过在upper目录中增加了一个特殊文件来告诉 OverlayFS 文件已被删除
  3. 修改文件同删除文件，如果修改upper里的文件，就可以直接修改，如果修改lower里的，则会在upper中创建一个新的替代旧的

Docker 容器镜像文件可以分成多个层（layer），每层可以对应 OverlayFS 里 lowerdir 的一个目录，lowerdir 支持多个目录，也就可以支持多层的镜像文件

容量限制

在容器中对于 OverlayFS 中写入数据，其实就是往宿主机的一个目录（upperdir）里写数据

Linux 系统里的 XFS 文件系统缺省都有 Quota 的特性，可以用来限制写入文件系统的文件总量

Docker 可以通过加上一个参数 --storage-opt size=xxx 使用这个特性

blkio cgroup v1

IOPS 是 Input/Output Operations Per Second 的简称，也就是每秒钟磁盘读写的次数，吞吐量（Throughput）是指每秒钟磁盘中数据的读取量，一般以 MB/s 为单位

吞吐量 = 数据块大小 *IOPS

v1的blkio cgroup只能限制direct IO，即直接IO读写的场景，无法限制buffered IO读写经过内存缓冲的场景，Linux 里，由于考虑到性能问题，绝大多数的应用都会使用 Buffered I/O 模式

cgroup v2

v2 相比 v1 做的最大的变动就是一个进程属于一个控制组，而每个控制组里可以定义自己需要的多个子系统

打开 v2 的方法就是配置一个 kernel 参数"cgroup_no_v1=blkio,memory"，这表示把 Cgroup v1 的 blkio 和 Memory 两个子系统给禁止，这样 Cgroup v2 的 io 和 Memory 这两个子系统就打开了

IO与PageCache

如果容器在做内存限制的时候，Cgroup 中 memory.limit_in_bytes 设置得比较小，而容器中的进程又有很大量的 I/O，这样申请新的 Page Cache 内存的时候，又会不断释放老的内存页面，这些操作就会带来额外的系统开销

对于控制page cache 有如下参数：

容器网络

docker 可以通过在启动容器时传递 –sysctl 参数来修改 / proc/sys/net 里面的配置参数

docker exec、kubectl exec、ip netns exec、nsenter 等命令原理相同，都是基于 setns 系统调用，切换至指定的一个或多个 namespace(s)

network namespace

资源，不同的namspace是隔离的：

操作：

容器网络配置

想让数据从容器 Netowrk Namespace 发送到 Host Network Namespace，可以用配置一对 veth 虚拟网络设备的方法实现。而让数据包从宿主机的 eth0 发送出去，就用可 bridge+nat 的方式完成

容器通常缺省使用 veth 虚拟网络接口，不过 veth 接口会有比较大的网络延时，在对外发送数据的时候，peer veth 接口都会 raise softirq 来完成一次收包操作，这样就会带来数据包处理的额外开销

如果要降低处理开销，使用ipvlan/macvlan 的网络接口，这两个直接在物理网络接口上虚拟出接口，在发送对外数据包的时候可以直接通过物理接口完成，没有节点内部类似 veth 的那种 softirq 的开销，但对于需要使用 iptables 规则的容器就不能工作了

通过 veth 接口从容器向外发送数据包，会触发 peer veth 设备去接收数据包，这个接收的过程就是一个网络的 softirq 的处理过程，在缺省的状况下（也就是没有 RPS 的情况下），enqueue_to_backlog() 把数据包放到了“当前运行的 CPU”（get_cpu()）对应的数据队列中，这回增加发送数据出现乱序的几率导致 TCP 的快速重传

为了解决这个问题，如果配置网卡的RSS（Receive Side Scaling），get_cpu()就会变成get_rps_cpu()，每个硬件中断可以由一个 CPU 来处理，可以保证一个 TCP 流的数据始终在一个 RX 队列中

2022122716223

RPS（Receive Packet Steering）其实就是在软件层面实现类似的功能，通过对数据包四元素计算hash值，决定要分配到哪个CPU上，但RPS 的配置还是会带来额外的系统开销

容器安全

Linux capabilities

Linux capabilities 把 Linux root 用户原来所有的特权做了细化，可以更加细粒度地给进程赋予不同权限

对于任意一个进程，在做任意一个特权操作的时候，都需要有这个特权操作对应的 capability，普通 Linux 节点上，非 root 用户启动的进程缺省没有任何 Linux capabilities，而 root 用户启动的进程缺省包含了所有的 Linux capabilities

文件中可以设置 capabilities 参数值，并且这个值会影响到最后运行它的进程

容器 root 用户默认只赋予了 15 个 capabilities，启动时如果加上 privileged 参数则会包含所有的 Linux capabilities

容器指定用户

在启动时可以指定一个 -u 参数来指定容器的用户的uid

由于用户 uid 是整个节点中共享的，那么在容器中定义的 uid，也就是宿主机上的 uid，这样就很容易引起 uid 的冲突，每个用户下的资源是有限制的，共享的资源如果使用共享的用户很快就会消耗光这个uid下的资源

user namespace

Namespace 中的 uid/gid 的值与宿主机上的 uid/gid 值建立了一个映射关系。经过 User Namespace 的隔离，我们在 Namespace 中看到的进程的 uid/gid，就和宿主机 Namespace 中看到的 uid 和 gid 不一样

Docker 通过配置 daemon 使其创建默认的用户用于 user namespace

这样可以把容器中 root 用户（uid 0）映射成宿主机上的普通用户，同时对于用户在容器中自己定义普通用户 uid 的情况，我们只要为每个容器在节点上分配一个 uid 范围，就不会出现在宿主机上 uid 冲突的问题了

rootless container

指容器中以非 root 用户来运行进程，还指以非 root 用户来创建容器，管理容器。也就是说，启动容器的时候，Docker 或者 podman 是以非 root 用户来执行的