云硬盘（Cloud Block Storage）是腾讯云提供的用于CVM实例的持久性数据块级存储。每个云硬盘在其可用区内自动复制，云硬盘中的数据在可用区内以多副本冗余方式存储，避免数据的单点故障风险。云硬盘为您提供处理工作所需的稳定可靠低延迟存储，通过云硬盘，您可在几分钟内调整存储容量，且所有这些您只需为配置的资源量支付低廉的价格。
归档存储（Cloud Archive Storage）是面向企业和个人开发者提供的高可靠、低成本的云端离线存储服务。您可以将任意数量和形式的非结构化数据放 入CAS，实现数据的容灾和备份。
文件存储（Cloud File Storage）提供了可扩展的共享文件存储服务，可与腾讯云的 CVM 等服务搭配使用。CFS 提供了标准的 NFS 文件系统访问协议，为多个 CVM 实例提供共享的数据源，支持无限容量和性能的扩展，现有应用无需修改即可挂载使用，是一种高可用、高可靠的分布式文件系统，适合于大数据分析、媒体处理和内容管理等场景。
对象存储（Cloud Object Storage）是面向企业和个人开发者提供的高可用，高稳定，强安全的云端存储服务。您可以将任意数量和形式的非结构化数据放入COS，并在其中实现数据的管理和处理。COS支持标准的Restful API接口，您可以快速上手使用，按实际使用量计费，无最低使用限制。
存储网关（Cloud Storage Gateway）是一种混合云存储方案，旨在帮助企业或个人实现本地存储与公有云存储的无缝衔接。您无需关心多协议本地存储设备与云存储的兼容性，只需要在本地安装云存储网关即可实现混合云部署，并拥有媲美本地性能的海量云端存储。 n腾讯云私有云存储 CSP（Cloud Storage on Private）是面向企业提供可扩展、高可靠、强安全、低成本的 PB 级海量数据存储能力。提供客户机房私有部署、腾讯云机房专区部署两种方式，满足客户多种场景需求，并保障客户对系统 100% 可控。
云数据迁移（Cloud Data Migration）是腾讯云提供的 TB ~ PB 级别的数据迁移上云服务。本服务提供了多种线下离线迁移的专用设备，满足本地办公网络或数据中心的大规模数据迁移上云的需求，解决大量数据通过网络传输时间长、成本高、安全性低的问题。 n日志服务（Cloud Log Service）提供一站式的日志数据解决方案。您无需关注扩缩容等资源问题，五分钟快速便捷接入，即可享受从日志采集、日志存储到日志内容搜索、统计分析等全方位稳定可靠的日志服务。帮助您轻松解决业务问题定位，指标监控、安全审计等日志问题。大大降低日志运维门槛。Namespace帮助容器来实现各种计算资源的隔离,Cgroups主要限制的是容器能够使用的某种资源量。
init进程创建的过程:
打开电源--> 执行BIOS/boot-loader--->boot-loader加载Linux内核(内核文件存放在/boot目录,文件名类似vmliunz)--> 执行的第一个用户态程序就是init进程。
1号进程就是第一个用户态的进程,有它直接或者间接创建了namespace中的其他进程。
特权信号就是Linux为kernel和超级用户去删除任意进程所保留的,不能被忽略也不能被捕获。
由于SIGKILL是一个特例，因为SIGKILL是不允许注册用户handler的，那么它只有SIG_DFL handler，init进程是永远不能被SIGKILL所杀,但是可以被SIGTERM杀死。
进程处理信号的选择：
1Linux内核里其实都是用task_struct这个接口来表示的。Linux里基本的调度单位是任务。任务的状态有两个TASK_RUNNING(运行态)和睡眠态(TASK_INTERRUPTIBLE,TASK_UNINTERRUPTIBLE)
运行态是无论进程是正在运行中，还是进程在run queue队列里随时可以运行,都处于这个状态。
睡眠是指进程需要等待某个资源而进入的状态，要等待的资源可以是一个信号量,或者是磁盘IO,这个状态的进程会被放入到wait queue队列里。
TASK_INTERRUPTIBLE是可以被打断的,显示为S stat,TASK_UNINTERRUPTIBLE 是不能被打断的,显示的进程为D stat。
在调用do_exit()的时候，有两个状态,EXIT_DEAD,就是进程在真正结束退出的那一瞬间的状态;EXIT_ZOMBIE状态,是在EXIT_DEAD之前的一个状态。
可以通过/proc/sys/kernel/pid_max设置进程最大的数量。如果机器中CPU数目小于等于32，pid_max设置为32768(32K),如果CPU数目大于32，pid_max的数目为N1024
在创建容器成功之后, 创建容器的服务会在/sys/fs/cgroups/pids下建立一个字目录，就是一个控制组,控制组里最关键的一个文件是pidsmax。
父进程在创建完子进程就不管了，这就是子进程变成僵尸进程的原因。
在主进程里,就是不断在调用带WHOHANG参数的waitpid(),通过这个方式清理容器中所有的僵尸进程。
Containerd在停止容器的时候，就会向容器的init进程发送一个SIGTERM信号,其他进程收到的是SIGKILL信号。
kill()这个系统调用,输入两个参数:进程号和信号,就把特定的信号发送给指定的进程了。
signal调用，决定了进程收到特定的信号如何来处理,SIG_DFL参数把对应信号恢复为缺省handler, 也可以用自定义的函数作为handler,或者用SIG_IGN参数让进程忽略信号。
如何解决停止容器的时候，容器内应用程序被强制杀死的问题:
在容器的init进程中对收到的信号做转发,发送到容器中的其他子进程,这样容器中的所有进程在停止时,都会收到SIGTERM，而不是SIGKILL信号了。
在/sys/fs/cgroup/cpu这个目录看到cpu的数据
Linux普通的调度的算法是CFS（完全公平调度器）
cpucfs_period_us,cfs算法的一个调度周期，是以位秒为单位。
cpucfs_quota_us,在一个调度周期里这个控制组被允许的运行时间。
cpushares，cpu cgroup对于控制组之间的cpu分配比例，缺省值为1024
由于/proc/stat文件是整个节点全局的状态文件,不属于任何一个Namespace,因此在容器中无法通过读取/proc/stat文件来获取单个容器的CPU使用率。
单个容器CPU使用率=((utime_2 - utime_1)+(stime_2 - stime_1)) 1000/(HZ et1)
无法通过CPU Cgroup来控制Load Average的平均负载。
Load Average是一种CPU资源需求的度量:
平均负载统计了这两种情况的进程:
Load Average = 可运行队列进程平均数 + 休眠队列中不可打断的进程平均数
OOM Killer是在Linux系统里如果内存不足时,就需要杀死一个正在有耐性的进程来释放一些内存。
Linux允许进程在申请内存的时候是overcommit，就是允许进程申请超过实际物理内存上线的内存。
malloc()申请的是内存虚拟地址,系统只是程序一个地址范围,由于没有写入数据,所以程序没有得到真正的物理内存。
oom_badness()函数,判断条件:
1进程已经使用的物理内存页面数;
2每个进程的OOM校准值oom_scire_adj。在/proc文件系统中,每个进程都有一个/proc/<pid>/oom_score_adj的接口文件。
用系统总的可用页面数,乘以OOM校准值oom_score_adj,再加上进程已经使用的物理页面数, 计算出来的值越大,那么这个进程被OOM Killer的几率也越大。
Memory Cgroup是对一组进程的Memory做限制,挂在/sys/fs/cgroup/memory目录下。
journalctl -k查看/var/log/message，看到的信息如下:
1容器中每一个进程使用的内存页面数量。
2oom-kill: 可以看到那个容器发生
3Killed process7445 那个进程被杀死。
Linux内存模型:RSS和Page Cache。
RSS:进程真正申请到物理页面的内存大小。
判断容器实际使用的内存量需要使用memorystat里的rss值。free获取到的内存值，需要去掉available字段下的值。
Page Cache是进程在运行中读写磁盘文件后，作为Cache而继续保留在内存中，它的目的是为了提高磁盘文件的读写性能。
内存使用量计算公式(memorykmemusage_in_bytes表示该memcg内核内存使用量)：memoryusage_in_bytes=memorystat[rss]+memorystat[cache]+memorykmemusage_in_bytes
Memory Cgroup OOM不是真正依据内存使用量memoryusage_in_bytes，而是依据working set,working set的计算公式: working_set = memoryusage_in_bytes - total_inactive_file。
swappiness(/proc/sys/vm/swapiness)可以决定系统将会有多频繁地使用交换分区。取值范围为0-100，缺省值为60。
memoryswapiness(Cgroup中的参数)可以控制这个Memory Cgroup控制组下面匿名内存和page cache的回收。
当memoryswapiness=0的时候,对匿名页的回收是始终禁止的,也就是始终不会使用Swap空间。
为了有效地减少磁盘上冗余的镜像数据,同时减少冗余的镜像数据在网络上的传输,选择一种针对容器的文件系统是很有必要的,这类的文件系统被称为UnionFS。
UnionFS实现的主要功能是把多个目录一起挂载在同一目录下。
OverlayFS是Liunx发行版本里缺省使用的容器文件系统。
OverlayFS也是把多个目录合并挂载,被挂载的目录分为两大类:lowerdir和upperdir。
lowerdir允许有多个目录,在被挂载后,这些目录里的文件都是不会被修改或者删除,也就是只读的;upper只有一个,不过这个目录是可读写的，挂载点目录中的所有文件修改都会在upperdir中反映出来。
OverlayFS建立2个lowerdir目录，并且在目录中建立相同文件名的文件,然后一起做一个overlay mount，为将文件合并成为一个。
为了避免容器把宿主机的磁盘写满，对OverlayFS的upper目录做XFS Quota的限流。
docker run --storage-opt size=10M,就能限制容器OverlayFS文件系统可写入的最大数据量。
限制文件大小分为两步:
第一步:给目标目录打上一个Project ID;
第二步:为这个Project ID在XFS文件系统中,设置一个写入数据块的限制。
setProjectID()是调用ioctl()，setProjectQuota()调用quotactl()来修改内核中XFS的数据结构,从而完成project ID的设置和quota的设置。
如何判断是对那个目录做了限制:
根据/proc/mounts中容器的OverlayFS Mount信息，可以知道限制的目录/var/lib/docker2/<docker_id>，目录下的diff目录就是限制目录。
IOPS就是每秒钟磁盘读写的次数,这个数值越大,性能越好。
吞吐量是每秒钟磁盘中数据的读取量。
吞吐量 = 数据块大小 IOPS。
在Cgroup v1里,bulkio Cgroup的虚拟文件系统挂载点一半在/sys/fs/cgroup/blkio/。
Direct I/O模式,用户进程如果要写磁盘文件,就会通过Linux内核的文件系统层(fileSystem)-->块设备层(block layer)-->磁盘驱动-->磁盘硬件。
Buffer I/O模式,用户进程只是把文件写到内存中就返回,Linux内核自己有线程会被内存中的数据写入到磁盘中Cgroup v1 blkio的子系统独立于memory系统,无法统计到有Page Cache刷入到磁盘的数据量。Linux中绝大多数使用的是Buffered I/O模式。
Direct I/O可以通过blkio Cgroup来限制磁盘I/O。Cgroup V2从架构上允许一个控制组里只要同时有IO和Memory子系统,就可以对Buffered I/O做磁盘读写的限速。
dirty_backgroud_ratio和dirty_ratio,这两个值都是相对于节点可用内存的百分比值。
当dirty pages数量超过dirty_backgroud_ratio对应的内存量的时候,内核flush线程就会开始把dirty page写入磁盘;当dirty pages数量超过dirty_ratio对应的内存量,这时候程序写文件的函数调用write()就会被阻塞住,知道这次调用的dirty pages全部写入到磁盘。
在节点是大内存容量,并且dirty_ratio为系统缺省值为20%,dirty_backgroud_ratio是系统缺省值10%的情况下,通过观察/proc/vmstat中的nr_dirty数值可以发现,dirty pages不会阻塞进程的Buffered I/O写文件 *** 作。
修改网络参数的有两种方法:一种方法是直接到/proc文件系统下的/proc/sys/net目录对参数做修改；还有就是使用sysctl来修改。
创建新的network namespace的方法:系统调用clone()或者unshare()。
Network Namespace工具包:
runC也在对/proc/sys目录做read-only mount之前,预留出了修改接口,就是用来修改容器里/proc/sys下参数的,同样也是sysctl的参数。
在容器启动之前修改网络相关的内容，是可以的，如果启动之后,修改网络相关内容的是不生效的。
docker exec、kubectl exec、ip netns exec、nsenter等命令原理相同,都是基于setns系统调用,切换至指定的一个或多个namespace。
解决容器与外界通讯的问题,一共需要两步完成。
对于macvlan,每个虚拟网络接口都有自己独立的mac地址,而ipvlan的虚拟网络接口是和物理网络接口共享一个mac地址。
veth对外发送数据的时候,peer veth接口都会raise softirq来完成一次收报 *** 作,这样就会带来数据包处理的额外开销。
容器使用ipvlan/macvlan的网络接口,网络延时可以非常接近物理网络接口的延时。
对于需要使用iptables规则的容器,Kubernetes使用service的容器,就不能工作:
docker inspect lat-test-1 | jq[0]statePid
Linux capabilities就是把Linux root用户原来所有的特权做了细化,可以更加细粒度地给进程赋予不同权限。
Privileged的容器也就是允许容器中的进程可以执行所有的特权 *** 作。
容器中root用户的进程,系统也只允许了15个capabilities。
使用不同用户执行程序:
xfs quota功能
centos7 xfs 文件系统配置quota 用户磁盘配额
quota磁盘配额（xfs）
xfs_quota 磁盘配额
xfs_quota 磁盘配额限制篇
XFS文件系统中quota的使用
xfs文件系统quota
Linux学习—CentOS7磁盘配额工具quota
linux磁盘配额详解（EXT4和XFS）
容器技术的核心功能，就是通过约束和修改进程的动态表现，从而为其创造出一个“边界” 。对于 Docker 等大多数 Linux 容器来说， Cgroups 技术 是用来制造约束的主要手段，而 Namespace 技术 则是用来修改进程视图的主要方法。
其实只是 Linux 创建新进程的一个可选参数。我们知道，在 Linux 系统中创建线程的系统调用是 clone()，比如：
这个系统调用就会为我们创建一个新的进程，并且返回它的进程号 pid。而当我们用 clone() 系统调用创建一个新进程时，就可以在参数中指定 CLONE_NEWPID 参数，比如：
这时，新创建的这个进程将会“看到”一个全新的进程空间，在这个进程空间里，它的 PID 是 1。之所以说“看到”，是因为这只是一个“障眼法”，在宿主机真实的进程空间里，这个进程的 PID 还是真实的数值，比如 100。
而 除了 PID Namespace，Linux *** 作系统还提供了 Mount、UTS、IPC、Network 和 User 这些 Namespace，用来对各种不同的进程上下文进行“障眼法” *** 作。
比如，Mount Namespace，用于让被隔离进程只看到当前 Namespace 里的挂载点信息；Network Namespace，用于让被隔离进程看到当前 Namespace 里的网络设备和配置。
这，就是 Linux 容器最基本的实现原理了。所以说，容器，其实是一种特殊的进程而已。Namespace 技术实际上修改了应用进程看待整个计算机“视图”，即它的“视线”被 *** 作系统做了限制，只能“看到”某些指定的内容 。
优势：更加的轻量且没有损耗资源。弊端：隔离不彻底
Cgroups（Linux Control Group） 就是 Linux 内核中用来为进程设置资源限制的一个重要功能。它最主要的作用，就是限制一个进程组能够使用的资源上限，包括 CPU、内存、磁盘、网络带宽等等
Cgroups 给用户暴露出来的 *** 作接口是文件系统
比如，向 container 组里的 cfs_quota 文件写入 20 ms（20000 us）：
意味着在每 100 ms 的时间里，被该控制组限制的进程只能使用 20 ms 的 CPU 时间，也就是说这个进程只能使用到 20% 的 CPU 带宽。
把被限制的进程的 PID 写入 container 组里的 tasks 文件，上面的设置就会对该进程生效了：
除 CPU 子系统外，Cgroups 的每一项子系统都有其独有的资源限制能力，比如：
Linux Cgroups 的设计还是比较易用的，简单粗暴地理解呢，它就是一个子系统目录加上一组资源限制文件的组合。容器是一个“单进程”模型。
Mount Namespace 修改的，是容器进程对文件系统“挂载点”的认知。Mount Namespace 跟其他 Namespace 的使用略有不同的地方：它对容器进程视图的改变，一定是伴随着挂载 *** 作（mount）才能生效。实际上，Mount Namespace 正是基于对 chroot 的不断改良才被发明出来的，它也是 Linux *** 作系统里的第一个 Namespace。
而这个挂载在容器根目录上、用来为容器进程提供隔离后执行环境的文件系统，就是所谓的“容器镜像”。它还有一个更为专业的名字，叫作：rootfs（根文件系统）。
对 Docker 项目来说，它最核心的原理实际上就是为待创建的用户进程：
rootfs 只是一个 *** 作系统所包含的文件、配置和目录，并不包括 *** 作系统内核。在 Linux *** 作系统中，这两部分是分开存放的， *** 作系统只有在开机启动时才会加载指定版本的内核镜像。
容器的 rootfs 由如下图所示的三部分组成：
第一部分，只读层 ：它是这个容器的 rootfs 最下面的五层，对应的正是 ubuntu:latest 镜像的五层，挂载方式都是只读的（ro+wh，即 readonly+whiteout）
这些层，都以增量的方式分别包含了 Ubuntu *** 作系统的一部分
第二部分，可读写层。 (rw)
在没有写入文件之前，这个目录是空的。而一旦在容器里做了写 *** 作，你修改产生的内容就会以增量的方式出现在这个层中。如果要删除AuFS 会在可读写层创建一个 whiteout 文件，把只读层里的文件“遮挡”起来。
专门用来存放你修改 rootfs 后产生的增量，原先的只读层里的内容则不会有任何变化
第三部分，Init 层。
有些文件本来属于只读的 Ubuntu 镜像的一部分，但是用户往往需要在启动容器时写入一些指定的值比如 hostname，所以就需要在可读写层对它们进行修改。可是，这些修改往往只对当前的容器有效，我们并不希望执行 docker commit 时，把这些信息连同可读写层一起提交掉。所以，Docker 做法是，在修改了这些文件之后，以一个单独的层挂载了出来。而用户执行 docker commit 只会提交可读写层，所以是不包含这些内容的。可以参考git ignore的思想。
Dockerfile ：
ENTRYPOINT：entrypoint才是正统地用于定义容器启动以后的执行体的，其实我们从名字也可以理解，这个是容器的“入口”。
CMD：cmd给出的是一个容器的默认的可执行体。也就是容器启动以后，默认的执行的命令。如果docker run没有指定任何的执行命令或者dockerfile里面也没有entrypoint，那么，就会使用cmd指定的默认的执行命令执行如果你不额外指定，那么就执行cmd的命令，否则呢？只要你指定了，那么就不会执行cmd，也就是cmd会被覆盖。
docker commit，实际上就是在容器运行起来后，把最上层的“可读写层”，加上原先容器镜像的只读层，打包组成了一个新的镜像。当然，下面这些只读层在宿主机上是共享的，不会占用额外的空间。
而由于使用了联合文件系统，你在容器里对镜像 rootfs 所做的任何修改，都会被 *** 作系统先复制到这个可读写层，然后再修改。这就是所谓的：Copy-on-Write。
一个进程的每种 Linux Namespace，都在它对应的 /proc/[进程号]/ns 下有一个对应的虚拟文件，并且链接到一个真实的 Namespace 文件上。
这也就意味着：一个进程，可以选择加入到某个进程已有的 Namespace 当中，从而达到“进入”这个进程所在容器的目的，这正是 docker exec 的实现原理。
Volume 机制，允许你将宿主机上指定的目录或者文件，挂载到容器里面进行读取和修改 *** 作。
当容器进程被创建之后，尽管开启了 Mount Namespace，但是在它执行 chroot（或者 pivot_root）之前，容器进程一直可以看到宿主机上的整个文件系统。所以在 rootfs 准备好之后，在执行 chroot 之前，把 Volume 指定的宿主机目录（比如 /home 目录），挂载到指定的容器目录（比如 /test 目录）在宿主机上对应的目录（即 /var/lib/docker/aufs/mnt/[可读写层 ID]/test）上，这个 Volume 的挂载工作就完成了。
由于执行这个挂载 *** 作时，“容器进程”已经创建了，也就意味着此时 Mount Namespace 已经开启了。所以，这个挂载事件只在这个容器里可见。你在宿主机上，是看不见容器内部的这个挂载点的。这就 保证了容器的隔离性不会被 Volume 打破 。
而这里要使用到的挂载技术，就是 Linux 的 绑定挂载（bind mount）机制 。它的主要作用就是，允许你将一个目录或者文件，而不是整个设备，挂载到一个指定的目录上。并且，这时你在该挂载点上进行的任何 *** 作，只是发生在被挂载的目录或者文件上，而原挂载点的内容则会被隐藏起来且不受影响。绑定挂载实际上是一个 inode 替换的过程。在 Linux *** 作系统中，inode 可以理解为存放文件内容的“对象”，而 dentry，也叫目录项，就是访问这个 inode 所使用的“指针”。
所以，在一个正确的时机，进行一次绑定挂载，Docker 就可以成功地将一个宿主机上的目录或文件，不动声色地挂载到容器中。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）