1.华为openEuler21.03版本怎么样
2.sysctl 参数防篡改 - 基于 ebpf 的源码实现 [一]
3.Linux内核源码解析---cgroup实现之整体架构与初始化
4.df- h命令什么意思
5.Linux 中断( IRQ / softirq )基础:原理及内核实现
6.å¦ä½å¦ä¹ Docker
华为openEuler21.03版本怎么样
华为 openEuler .是华为发布的全新创新桌面选择。该版本属于全新的分析创新版本而不是 LTS (Long Term Support) 版本。全新的源码创新桌面为用户们带来的是更强的虚拟化功能和更多桌面选择支持。
华为 openEuler .介绍
全新的分析5.内核
1、深度优化调度、源码IO、分析java 过滤器源码内存管理,源码提供Arm、分析x、源码RISC-V等更多计算能力支持。分析
2、源码对调度程序进行了优化,分析以优化CFS任务的源码公平性,并添加了感知numa的分析异步调用机制,这在NVDIMM初始化方面有了显著的源码改进;优化了SCHED_IDLE的调度策略,显著提高了高优先级任务的调度延迟,降低了其他任务干扰的成本。
3、numa平衡机制的优化带来了更好的亲和性、更高的利用率和更少的无效迁移。
4、增强CPU隔离机制,支持中断隔离,支持非绑定线程隔离,增强CPU内核隔离,更好地避免业务间相互干扰。
5、优化了cgroup单线程迁移的性能,消除了对线程组读写信号量的依赖;时间名称空间的引入使得容器迁移更加方便。
6、系统容器支持限制容器中使用的文件句柄的数量。文件句柄包括普通的文件句柄和网络套接字。在启动容器时,可以指定——files-limit参数来限制容器中打开句柄的最大数量。
7、PSI能力支持。PSI (Pressure Stall Information)提供了一种评估系统资源(如CPU、内存和IO)压力的方法。准确的检测方法可以帮助资源用户确定合适的工作量,也可以帮助系统制定高效的资源调度策略,最大限度地利用系统资源,最大限度地提高用户体验。
8、进程间通信优化,pipe/epoll_wait唤醒机制优化,解决唤醒多个等待线程的性能问题。
9、增强内存管理、细化内存控制、统计、异构内存、热插拔、内存初始化等功能得到了改进,并提供了更有效的用户控制界面;热点锁和信号量优化,激进的遇敌自动开枪源码内存调节和碎片整理,优化、vmap/vmalloc机制,显著提高内存应用效率;KASAN, kmemleak, slub_debug, oom和其他内存维护功能都得到了增强,以提高内存问题的定位和解决效率。
、提前发包时间模式开关解决了原有TCP框架在报文发送过程中的局限性。根据调度策略,为数据包设置EDT时间戳,避免了队列缓冲区过大造成的延迟,从而大大提高了TCP的性能。
、支持多路径TCP,可以提高移动和数据场景下的性能和可靠性,支持负载均衡场景下多个子流并行传输。
、引入了log fast commit方法,而EXT4引入了一种新的、更轻量级的日志记录方法——fast commit,它可以极大地加快耗时的操作,比如fsync,并带来更好的性能。
、支持dm写cache特性,提高SSD大容量顺序写性能,提高DDR持久化内存性能。
、io_uring是一个新的异步IO框架和实现,支持轮询模式。在轮询模式下,性能得到了与spdk类似的显著提高,队列深度越高,性能越好。
、支持ILP,在鲲鹏 Arm环境下支持位应用程序。
、IMA商业增强,基于开源IMA解决方案,增强安全性,提高性能,提高易用性,并帮助商业实现。
、支持单任务栈巡检,增强对ROP攻击的防范能力。
、MPAM资源管理和控制,支持Arm架构的缓存QoS和内存带宽控制技术。
、支持基于sedim的NMI机制和基于pmu的NMI机制,实现硬锁检测;启用perf nmi可以实现更准确的性能分析。
、Arm平台支持虚拟机CPU热插拔,提高了资源配置的深度解析dubbo源码灵活性。
、Arm kdump得到了增强,支持4G以上地址的内存预留,这样kdump可以预留更多的内存空间,并支持具有更大内存的机器。
、支持树莓派系列板。Raspberry Pi的支持已经集成到本地的openEuler .内核中,可以直接使用openEuler .内核源代码进行调试。
、RISC-V平台支持KVM虚拟化。
、支持智能网卡。
热内核升级
1、热内核升级是修复和升级操作系统漏洞的解决方案。实现了无服务意识的内核快速热替换。
2、Cpu Park和Quick Kexec的功能加速系统启动和停止,减少停机时间,提高系统可用性。
3、Pin存储器和Pmem功能可确保快速准确地恢复业务流程,并提高业务灵活性。
4、内核热升级控制器提供gRPC通讯接口,使用方便。
内存分层扩展
1、支持多内存和存储介质的统一管理,支持系统容量的平滑扩展。
2、冷热页识别,通过内核态内存页的空闲和空闲统计机制,准确识别进程内存页访问的冷热分布。
3、可以配置淘汰策略,提供配置界面,自定义内存页面冷热分类策略。
4、平滑扩展,冷页自动切换到扩展内存,其上部署的软件兼容运行,无需改变或调整编程模式。
5、支持多媒体扩展,支持单片机、XL Flash、NVMe SSD等介质作为扩展内存,并根据介质本身的访问速度指定冷热内存分层方案,以达到扩展内存、降低性能损失的目的。
6、增强的虚拟化能力和可维护的测量能力。
7、增加了热迁移Pro的echarts gl实例源码能力扩展,提高了可维护性和可测性。
8、热迁移专业版功能,增强热迁移多功能支持TLS,确保迁移过程中的数据安全;支持热迁移数据的并行压缩,提高迁移性能;增加数据页面访问频率的统计,支持热迁移数据的早期预测。
9、vmtop性能调试工具可以实时动态查看虚拟机的资源使用情况,包括CPU占用率、内存占用率等信息。增加了支持x_架构的扩展。
、支持IO挂起。默认情况下,当发生io错误时,IO会自动重试,超时后会报告警报。
、RISC-V架构支持虚拟化热迁移。
轻量级虚拟运行时
1、添加灵活的内存,大页面功能,系统调用过滤功能,增强IO子系统,提高性能和稳定性。
2、灵活的内存支持,根据工作负载的内存需求实现内存分配和恢复,virtio-balloon的内存恢复速度可达3GB/s。
3、大页面支持。在轻量级框架中提供大页面支持,可以为轻量级虚拟机提供连续的物理内存页面,提高虚拟机的内存访问效率。
4、系统调用过滤简化了设备模型,增加了对系统调用过滤的支持,只需要最简单配置的个系统调用,有效减少了系统攻击面。
5、输入输出子系统得到增强,以支持多通道并发输入输出能力并提高性能。支持IO- qos能力,增强虚拟机IO流量管理的灵活性和稳定性。open stack 维多利亚集成。
6、简单、可扩展、丰富、统一的云管理操作系统。更多功能见OpenStack Victoria官方发行说明。
7、通过集成openStack Vicoria版本实现IaaS(基础设施即服务)解决方案。spi总线驱动源码
8、增强数据块存储的服务能力,并添加容量扩展、快照和虚拟机映像克隆等高级功能。
9、增强集装箱化部署和网络能力,以便更好地与集装箱集成。
、添加扩展服务支持,并支持扩展服务,如控制面板管理、裸机部署和云资源跟踪。
Kubernetes 1.集成
1、有关云本机操作系统自动部署、扩展和管理容器化应用程序的更多功能,请参考Kubernetes 1.的官方发行说明。
2、自动联机和回滚。Kubernetes会自动将应用程序或其配置更改的实例联机,并监控应用程序的运行状态。如果失败,将回滚以前的更改。
3、服务发现和负载均衡,支持基于容器IP和DNS名称的服务发现和负载均衡。
4、存储业务流程支持自动挂载多个存储后端,如本地存储、NFS、iSCSI、Gluster、Ceph等网络存储系统。
5、水平扩展,支持命令行扩展,用户界面手动扩展,根据CPU占用率自动扩展。
sysctl 参数防篡改 - 基于 ebpf 的实现 [一]
系统调用参数防篡改 - 基于ebpf的实现
本文基于内核代码版本5..0进行讨论。
ebpf能够修改某些函数的返回值,但仅限于允许错误注入的函数,这限制了其应用范围。系统tap能够作用于几乎任何函数,但由于内核API的不稳定,它在不同内核上可能无法运行。
ebpf的优势在于其与内核交互的API保持稳定,特别是用于“系统调用参数防篡改”的一组helper函数。在阅读代码实现时,发现中段插入了一个“BPF_CGROUP_RUN_PROG_SYSCTL”。
这一功能源于v5.2-rc1的commit,旨在限制容器对sysctl的错误写入,要求内核版本不低于5.2,且配置项包含“CONFIG_CGROUP_BPF”。
配套的4个helper函数记录在内核文档“Documentation/bpf/prog_cgroup_sysctl.rst”中,用于读取sysctl参数名称和值、在参数修改时获取写入的值以及覆盖准备写入的值。这些helper与内核原生路径中的过滤函数交互。
使用示例
通过Linux内核源码中的“tools/testing/selftests/bpf”目录下的测试用例可以学习ebpf的使用。在源码根目录下执行make命令编译。
针对sysctl部分,测试用例主体为“test_sysctl.c”,用于将ebpf程序加载至内核,并在对应的点位上附加。ebpf程序可以是直接以ebpf汇编语法写的,也可以是C文件编译成.o二进制文件的形式。
当判断为write操作时,返回0,内核源码中决定sysctl参数读写结果的点位返回“-EPERM”,使得修改不成功。
ebpf prog源文件中的“SEC”宏定义用于指示编译器将函数/变量放在特定的section中,便于用户态loader查找和解析。
为了实现加载和附加程序,使用了“sysctl_write_deny_prog.o”作为附加程序,类型为“BPF_CGROUP_SYSCTL”,方式为“BPF_F_ALLOW_OVERRIDE”。借助“fd”这样的整形数字,用户态程序可以深入内核态获取对应的结构体实例。
最终通过libbpf封装系统调用接口,用户态程序可以通过“bpf”系统调用入口与内核交互。使用strace工具可以追踪这一过程。
了解ebpf helper函数的使用,可以借助现成的工具进行学习,更多详情请参考后续文章。
Linux内核源码解析---cgroup实现之整体架构与初始化
cgroup在年由Google工程师开发,于年被融入Linux 2.6.内核。它旨在管理不同进程组,监控一组进程的行为和资源分配,是Docker和Kubernetes的基石,同时也被高版本内核中的LXC技术所使用。本文基于最早融入内核中的代码进行深入分析。
理解cgroup的核心,首先需要掌握其内部的常用术语,如子系统、层级、cgroupfs_root、cgroup、css_set、cgroup_subsys_state、cg_cgroup_link等。子系统负责控制不同进程的行为,例如CPU子系统可以控制一组进程在CPU上执行的时间占比。层级在内核中表示为cgroupfs_root,一个层级控制一批进程,层级内部绑定一个或多个子系统,每个进程只能在一个层级中存在,但一个进程可以被多个层级管理。cgroup以树形结构组织,每一棵树对应一个层级,层级内部可以关联一个或多个子系统。
每个层级内部包含的节点代表一个cgroup,进程结构体内部包含一个css_set,用于找到控制该进程的所有cgroup,多个进程可以共用一个css_set。cgroup_subsys_state用于保存一系列子系统,数组中的每一个元素都是cgroup_subsys_state。cg_cgroup_link收集不同层级的cgroup和css_set,通过该结构可以找到与之关联的进程。
了解了这些概念后,可以进一步探索cgroup内部用于结构转换的函数,如task_subsys_state、find_existing_css_set等,这些函数帮助理解cgroup的内部运作。此外,cgroup_init_early和cgroup_init函数是初始化cgroup的关键步骤,它们负责初始化rootnode和子系统的数组,为cgroup的使用做准备。
最后,需要明确Linux内一切皆文件,cgroup基于VFS实现。内核启动时进行初始化,以确保系统能够正确管理进程资源。cgroup的初始化过程分为早期初始化和常规初始化,其中早期初始化用于准备cpuset和CPU子系统,确保它们在系统运行时能够正常工作。通过这些步骤,我们可以深入理解cgroup如何在Linux内核中实现资源管理和进程控制。
df- h命令什么意思
df -h命令代表什么意思呢?我们一起了解一下吧!
df -h是df命令加上参数h,日常普遍用该命令可以查看磁盘被占用了多少空间、还剩多少空间等信息。
Linux 是一种自由和开放源码的类 UNIX 操作系统。df命令是Linux命令之一,df命令的英文全称即“Disk Free”,顾名思义功能是用于显示系统上可使用的磁盘空间,默认显示单位为KB。“df -h”命令的参数组合,是可以根据磁盘容量自动变换合适的容量单位,更利于阅读和查看。
参考实例:
[root@linux ~]# df -h
文件系统 容量 已用 可用 已用% 挂载点
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 2.0G 1.1M 2.0G 1% /run
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
/dev/mapper/fedora_linuxhell-root G 2.0G G % /
tmpfs 2.0G 4.0K 2.0G 1% /tmp
/dev/sda1 M M M % /boot
tmpfs M 0 M 0% /run/user/0
显示的单词分别代表的具体含义如下。
Filesystem:表示该文件系统位于哪个分区,因此该列显示的是设备名称;
Used:表示用掉的磁盘空间大小;
Available:表示剩余的磁盘空间大小;
Use%:磁盘空间使用率;
Mounted on:文件系统的挂载点,也就是磁盘挂载的目录位置
Filesystem:表示该文件系统位于哪个分区,因此该列显示的是设备名称;
Used:表示用掉的磁盘空间大小;
Available:表示剩余的磁盘空间大小;
Use%:磁盘空间使用率;
Mounted on:文件系统的挂载点,也就是磁盘挂载的目录位置。
关于df -h命令,我们就了解到这啦!
Linux 中断( IRQ / softirq )基础:原理及内核实现
中断(IRQ),尤其是软中断(softirq)的广泛用途之一是网络数据包的接收与发送,但其应用场景并非单一。本文将全面整理中断(IRQ)与软中断(softirq)的基础知识,这些内容与网络数据包处理虽无直接联系,但整理本文旨在更深入地理解网络数据包处理机制。
什么是中断?
CPU 通过时分复用处理多任务,其中包括硬件任务,如磁盘读写、键盘输入,以及软件任务,如网络数据包处理。CPU 在任何时刻只能执行一个任务。当某个硬件或软件任务当前未被执行,但希望CPU立即处理时,会向CPU发送中断请求——希望CPU暂停手头工作,优先服务“我”。中断以事件形式通知CPU,因此常看到“在XX条件下会触发XX中断事件”的表述。
中断分为两类:
管理中断的设备:Advanced Programmable Interrupt Controller(APIC)。
硬中断的中断处理流程
中断随时发生,处理流程如下:
Maskable and non-maskable
Maskable interrupts 在x_上可以通过sti/cli指令来屏蔽(关闭)和恢复:
在屏蔽期间,这种类型的中断不会触发新的中断事件。大部分IRQ都属于这种类型。例如,网卡的收发包硬件中断。
Non-maskable interrupts 不可屏蔽,因此属于更高优先级的类型。
问题:执行速度与逻辑复杂性之间的矛盾
IRQ处理器的两个特点如下:
存在内在矛盾。
解决方式:中断的推迟处理(deferred interrupt handling)
传统解决方式是将中断处理分为两部分:
这种方式称为中断的推迟处理或延后处理。现在已是一个通用术语,涵盖各种推迟执行中断处理的方式。中断分为两部分处理:
在Linux中,有三种推迟中断(deferred interrupts):
具体细节将在后续介绍。
软中断与软中断子系统
软中断是内核子系统的一部分:
每个CPU上会初始化一个ksoftirqd内核线程,负责处理各种类型的softirq中断事件;
使用cgroup ls或ps -ef都能看到:
软中断事件的handler提前注册到softirq子系统,注册方式为open_softirq(softirq_id, handler)
例如,注册网卡收发包(RX/TX)软中断处理函数:
软中断占用了CPU的总开销:可以使用top查看,第三行倒数第二个指标是系统的软中断开销(si字段):
Linux内核源码分析学习地址:ke.qq.com/course/...
文章福利小编推荐自己的Linux内核源码分析交流群:点击加入整理了一些个人觉得比较好的学习书籍、视频资料共享在群文件里面,有需要的可以自行添加哦!
主处理
smpboot.c类似于事件驱动的循环,会调度ksoftirqd线程执行pending的软中断。ksoftirqd内部会进一步调用到__do_softirq,
避免软中断占用过多CPU
软中断的潜在影响:推迟执行的部分(如softirq)可能会占用较长时间,在这段时间内,用户空间线程只能等待。反映在top中,si占比。
不过softirq调度循环对此有所改进,通过budget机制来避免softirq占用过多CPU时间。
硬中断-软中断调用栈
softirq是一种推迟中断处理机制,将IRQ的大部分处理逻辑推迟在这里执行。有两条路径都会执行到softirq主处理逻辑__do_softirq():
1、CPU调度到ksoftirqd线程时,会执行到__do_softirq();
2、每次IRQ handler退出时:do_IRQ()->...
do_IRQ是内核中主要的IRQ处理方式。它执行结束时,会调用exiting_irq(),这会展开成irq_exit()。后者会检查是否pending有softirq,如果有,则唤醒:
进而会使CPU执行到__do_softirq。
软中断触发执行的步骤
总结,每个软中断会经过以下阶段:
以收包软中断为例,IRQ handler并不执行NAPI,只是触发它,在内部会执行到raiseNET_RX_SOFTIRQ;真正的执行在softirq,会调用网卡的poll()方法收包。IRQ handler中会调用napi_schedule(),然后启动NAPI poll()。
需要注意的是,虽然IRQ handler所做的工作很少,但处理这个包的softirq和IRQ在同一CPU上运行。这意味着,如果大量的包都放在同一个RX队列,虽然IRQ开销可能不多,但该CPU仍然会非常繁忙,都花费在softirq上。解决方式:RPS。它不会降低延迟,只是将包重新分配:RXQ->CPU。
三种推迟执行方式(softirq/tasklet/workqueue)
提到,Linux中的三种推迟中断执行方式:
其中:
前面已经看到,Linux在每个CPU上创建了一个ksoftirqd内核线程。
softirqs是在Linux内核编译时确定的,例如网络收包对应的NET_RX_SOFTIRQ软中断。因此是一种静态机制。如果想添加一种新softirq类型,需要修改并重新编译内核。
内部组织
内部由一个数组(或称为向量)管理,每个软中断号对应一个softirq handler。数组与注册:
在5.中所有类型的softirq:
也就是在cat /proc/softirqs看到的哪些。
触发(唤醒)softirq
以收包软中断为例,IRQ handler并不执行NAPI,只是触发它,在内部会执行到raiseNET_RX_SOFTIRQ;真正的执行在softirq,会调用网卡的poll()方法收包。IRQ handler中会调用napi_schedule(),然后启动NAPI poll()。
如果对内核源码有一定了解,会发现softirq使用非常有限,原因之一是它是静态编译的,依赖内置的ksoftirqd线程来调度内置的9种softirq。如果想添加一种新功能,就得修改并重新编译内核,开发成本很高。
实际上,实现推迟执行的更常用方式是tasklet。它构建在softirq机制之上,具体来说就是使用了两种softirq:
换句话说,tasklet是在运行时(runtime)创建和初始化的softirq,
内核软中断子系统初始化了两个per-cpu变量:
tasklet再执行针对list的循环:
tasklet在内核中的使用非常广泛。不过,后面又出现了第三种方式:workqueue。
这也是一种推迟执行机制,与tasklet有些相似,但有显著不同。
使用场景
简而言之,workqueue子系统提供了一个接口,通过该接口可以创建内核线程来处理从其他地方enqueue过来的任务。这些内核线程称为worker threads,内置的per-cpu worker threads:
结构体
kworker线程调度workqueues,原理与ksoftirqd线程调度softirqs类似。然而,我们可以为workqueue创建新的线程,而softirq则不行。
参考资料引用链接
[1]
中断与中断处理:0xax.gitbooks.io/linux-...
作者:赵亚楠 原文:arthurchiao.art/blog/li...来源:云原生实验室
å¦ä½å¦ä¹ Docker
å¦ä½å¦ä¹ Docker
对äºå¨æ ¡å¦çèè¨ï¼åºè¯¥å¦ä½å»å¦ä¹ dockerï¼æ¯ç«å¦æ ¡æ²¡æå ·ä½çåºç¨éæ±ä½ä¸ºå¼å¯¼ï¼æ以åºè¯¥å¦ä½å»ç 究Dockerï¼è¿æï¼Dockerçæºä»£ç æ没æå¿ è¦å»ç 究ï¼
é¦å æ说æä¸ï¼ææ¯ä¸ä½å¨æµæ±å¤§å¦VLISå®éªå®¤äºè®¡ç®é¡¹ç®ç»çå¦çï¼ä½¿ç¨è¿Dockerï¼ç 究è¿Dockeråå ¶æºç ï¼ä¹å®å¶è¿Dockerã
对äºå¦çå¦ä½å¦ä¹ Dockerï¼æ认为é¦å è¦çä¸ä¸å¦ç个人çç¥è¯èæ¯ãè½å©ç¨çèµæºèµæºã以åä¸ªäººå ´è¶£ååå±æ¹åã
1.å¦ä¹ Dockerï¼å¦æ没æäºè®¡ç®çåºæ¬ç¥è¯ï¼ä»¥åå æ ¸çåºæ¬ç¥è¯ï¼é£ä¹å¦ä¹ 并ç解起æ¥ä¼ç¨ååãä½ä¸ºå®¹å¨ï¼Docker容å¨çä¼å¿å¨åªï¼ä¸è¶³å¨åªï¼æ好äºè§£å®¹å¨çå®ç°æ¯ææ ·çï¼ç®åäºè§£ï¼ï¼æ¥æéå管çï¼Dockerå该å¦ä½ä½ç°è½¯ä»¶å¼åï¼éæï¼é¨ç½²ï¼åå¸ï¼åè¿ä»£ç软件çå½å¨æ管çä¼å¿ã以ä¸ä¸¤ç¹æ认为æä¸ºå ³é®ï¼æè¿ä¸¤æ¹é¢ç认è¯å¿å¿ ä¼å¯¹ä¹åçå·¥ä½å¸®å©å·¨å¤§ã
2.å ³äºå¦ä¹ èµæºï¼èµ·ç ç硬件设æ½æ»æ¯è¦æçãDockeråå ¶çæçåå±å¾å¿«ï¼ä¸ä½¿ç¨çº¯ç论è¯å®æ¶æçå¾®ãå¦å¤ï¼èµæºè¿å æ¬Dockerå®æ¹ï¼å大çµååªä½å¹³å°ï¼ææ¯è®ºåï¼å¼æºç¤¾åºçï¼å¾å¾å¤§æ¿çè§ç¹è½ç¹ç ´èªå·±çå°æï¼æè 让èªå·±ç¥éåªæ¹é¢ç认è¯è¿å¾æ¬ 缺ï¼ä»¥å让èªå·±å°èµ°å¾å¤ç弯路ã
3.ä¸ªäººå ´è¶£çè¯ï¼å½ç»ä¸ºå¼ºæççä¸çãèµ·ç åºè¯¥è®¤åDockerç设计价å¼ï¼ä»¥åDockerçæªæ¥æ½åï¼å½ç¶æä¾æ®çæ¹å¤Docker并带å¨å¤§å®¶çæèï¼ä¹æ¯æ·±åå ³æ³¨ç表ç°ã
4.个人åå±æ¹åï¼æ认为å¦æéè¦æDockerå½ä½è½¯ä»¶çå½å¨æ管çå·¥å ·çè¯ï¼é£ç¨å¥½Dockeræ为éè¦ï¼APIåå½ä»¤çç解ä¸ä½¿ç¨æ¯å¿ éçãå¦æä¸æ³¨ç³»ç»è®¾è®¡æ¹é¢ï¼é£ä¹é¤Docker以ä¸çç¥è¯ä¸ç»éªä¹å¤ï¼è¥æDockeræºç çå¦ä¹ ä¸ç解ï¼é£ä¹è¿äºè¯å®ä¼è®©ä½ çDockeræ°´å¹³æé«ä¸ä¸ªå±æ¬¡ã
-- 8 0
xds
å¦ä¹ Dockerï¼æ大ç好å¤æ¯è·è¿æ°ææ¯åå±æ¹åãæè§å¾å¨æ ¡çåºè¯¥æ²¡æå¤å°ç¡¬æ§éæ±å¨Dockerçç 究ä¸ï¼è¿ä¹æ¯ä¸ºä»ä¹å¦æ ¡æ²¡åå ·ä½åºç¨è¦æ±çåå ãæå®é çåæ³æ¯çä¸äºDocker使ç¨æ¡ä¾ï¼èªå·±å®è·µåºä¸äºç»éªåºè¯¥ä¼å以åç社ä¼å®è·µä¸èµ·å°ä½ç¨ã
ç 究dockerçæºä»£ç ï¼åºè¯¥å°ä½ ä¸å®å³å¿ä»äºäºè®¡ç®æ¹é¢çäºä¸æè ç 究ï¼é£ä¹ä½ å°±éè¦ä»¥ç 究è ç身份å»åä»ç»çæºç åæçå·¥ä½ã
-- 3 0
ååGTDer
æä½ä¸ºåå å·¥ä½çè¿æ¥äººæ¥è¯´ï¼æ认为åªæä½ çæ£åå å·¥ä½åï¼å¨å·¥ä½ä¸å¦ä¹ è·ææä¹ï¼æ¯ç«Dockerç¥è¯äºè®¡ç®å ¶ä¸çä¸ä¸ªè½¯ä»¶å¹³å°èå·²ï¼è¯´ä¸æ¥çä½ æ¯ä¸äºï¼æ°çææ¯åºç°Dockerä¸ä¸å®æ¯å¯ä¸éæ©ã
ä½ä¸ºå¦çäºè§£æ°ææ¯ç¡®å®æ å¯åéï¼ä¸å®è¦è½æç论转å为ç产åææ¯æ£éã
-- 3 0
9lives - ç±çæ´»ï¼ç±äºè®¡ç®ã
å¦ä¹ ä»»ä½ä¸ä¸ªå¼æºæ°ææ¯ï¼é¦å é®èªå·±å 个é®é¢ï¼
1. 为ä»è¦å¦ä¹ å®ï¼
2. å¦ä¹ å®éè¦äºè§£åªäºç¸å ³ç¥è¯ç¹ï¼
3. å¦ä½å¿«éå¦ä¹ ï¼
4. 该ææ¯ç使ç¨åºæ¯æ¯ä»ä¹ï¼
æ¿æ个人çå¦ä¹ ç»éªæ¥ä¸¾ä¾ï¼æ¬äººä¹åæ¯è¾äºè§£OpenStackï¼
为ä»è¦å¦ä¹ dockerï¼
åçï¼
dockeræ¯è½»é级èæåææ¯ï¼docker使linux容å¨ææ¯çåºç¨æ´å ç®ååæ åå
dockerçé度å¾å¿«,容å¨å¯å¨æ¶æ¯«ç§çº§ç
dockerå°å¼ååè¿ç»´èè´£åæ¸
docker解å³äºä¾èµå°ç±é®é¢
dockeræ¯æå ä¹æææä½ç³»ç»
dockeræçé£éåå±ççæå
å¾å¤IT巨头éæ¸å å ¥åæ¯æ
å¦ä¹ å®éè¦äºè§£åªäºç¸å ³ç¥è¯ç¹ï¼
åçï¼
äºè®¡ç®æ¦å¿µç¸å ³ï¼restapi, å¾®æå¡ï¼OpenStackï¼
Linux ç³»ç»ç®¡çï¼è½¯ä»¶å 管çï¼ç¨æ·ç®¡çï¼è¿ç¨ç®¡ççï¼
Linux å æ ¸ç¸å ³ï¼Cgroup, namespace çï¼
Linux æ件系ç»ååå¨ç¸å ³ï¼AUFSï¼BRFS,devicemapper çï¼
Linux ç½ç»ï¼ç½æ¡¥ï¼veth,iptablesçï¼
Linuxå®å ¨ç¸å ³ï¼Appmor,Selinux çï¼
Linuxè¿ç¨ç®¡çï¼Supervisord,Systemd etc)
Linux容å¨ææ¯ï¼LXCçï¼
å¼åè¯è¨ï¼Python, GO,Shell çï¼
3.å¦ä½å¿«éå¦ä¹ ï¼
åçï¼ä¸ªäººä½ä¼æ好æä¸ä¸ªå®é çéæ±æ项ç®æ¥è¾¹å®è·µè¾¹å¦ä¹ ï¼å ¥é¨å¯ä»¥åèï¼ç¬¬ä¸æ¬docker书ï¼åçä¸éï¼é常éåå ¥é¨ãé¤æ¤ä¹å¤ï¼é 读ç人çblogæ¯å¦å®æ¹blog /
BTW: ç读dockerææ¡£
-- 0 0
tuxknight
楼ä¸åä½è¯´çé½å¾å¥½ï¼æåè¡¥å ä¸ç¹ï¼
æ¾ä»½ç¸å ³çå®ä¹ å·¥ä½
-- 0 0
lancer
å·¥ä½åç 究æ¯ä¸¤ä¸ªæ¹åæ个人认为ï¼å·¥ä½éè¦éè¿ä½ çå®é æè½ä¸ºä¼ä¸å¸¦æ¥ç»æµæçï¼èç 究çè¯å¯ä»¥ä¸æ³¨æ个ç¹ãä½æ¯ç 究离ä¸å¼å·¥ä½ï¼å 为工ä½å¯ä»¥è®©ä½ æ´å¥½ççä¼ææ¯å¸¦æ¥çä»·å¼ï¼ä»¥åå¦ä½æä¾æ´å¥½çæå¡ï¼ç¨æ·ä½¿ç¨åºæ¯éè¦é£äºææ¯ççªç ´ãæäºè¿äºè®¤è¯ï¼ç¶åæ´å ä¸æ³¨çç 究æ个ææ¯ç¹ï¼è¿æ ·æ许å¯ä»¥è¯´ææ¯ååä¸æ¯åä¸å¼çã
-- 0 0
绿åè²å½±
dockerç°å¨ååç«çï¼å¼å¾å¦ä¹ ä¸ä¸ã
eBPF 程序编写 - libbpf
eBPF程序编写通过内核的bpf系统调用加载ebpf二进制,实现对MAP的增删改操作。ebpf源代码使用C语言编译生成bpf字节码。eBPF程序能够访问MAP,调用内核函数,访问内核与用户态内存,并进行计算与分支控制,但需避免死循环。
eBPF程序在加载后,与内核的特定hook点结合,被动执行,如tracepoint、kprobe、uprobe、cgroup等,提供高效的数据通信机制,如输出数据到perf_buffer或ringbuffer。
eBPF程序还能通过修改hook函数的返回值,实现函数劫持。但此功能仅适用于标有ERR_INJECT的函数。
libbpf作为辅助工具简化bpf编程,用户态与内核态逻辑分离,框架负责通信、加载与卸载bpf程序。它提供丰富的helper函数,并实现CO-RE,确保bpf程序跨内核版本运行。
libbpf通过记录relocation信息于bpf程序的.BTF section,配合clang编译bpf后端增加的builtin函数,实现程序跨内核版本运行。编译后,bpf程序以用户态可执行二进制形式存在,内核态程序作为ro数据段嵌入其中,形成独立可部署的文件。
libbpf的CORE方式相较于其他工具集有显著优势,例如bcc-tools工具集合采用libbpf重写。编写eBPF程序时,参照libbpf-bootstrap/examples/c模板,通常需要两个文件:BTF记录数据结构信息,确保程序在不同内核版本上运行的兼容性。