内核管理

kernel 概述

  • 单内核体系设计，但充分借鉴了微内核设计体系的优点，为内核引入模块化机制

组成部分

  • kernel：内核核心，一般为bzlmage，通常在/boot目录下，名称为：
    • vmlinuxz-VERSION-RELEASE
  • kernel object：内核对象，一般放置于：
    • /lib/modules/VERSION-RELEASE/
  • 辅助文件：ramdisk
    • initrd：centos 5 以前
    • initramfs：centos 6 以后

功能

  • kernel 主要实现对进程、内存、IO、网络、驱动程序、文件系统、安全等功能的管理

kernel version

uname -a #显示内核相关的所有信息
uname -r #显示内核版本
uname -n #显示节点名称

kernel modules

lsmod 命令

  • 显示由核心已经装载的内核模块

  • 显示的内容来自于：/proc/modules 文件

  • 范例：

  • #模块名称、大小、使用次数、被哪些模块所依赖
[root@centos8 ~]# lsmod 
Module                  Size  Used by
binfmt_misc            20480  1
crct10dif_pclmul       16384  1
crc32_pclmul           16384  0
vmw_balloon            24576  0
btusb                  53248  0
ghash_clmulni_intel    16384  0
btrtl                  20480  1 btusb
btbcm                  20480  1 btusb
btintel                24576  1 btusb
snd_ens1371            32768  0
snd_ac97_codec        143360  1 snd_ens1371
bluetooth             675840  5 btrtl,btintel,btbcm,btusb

modinfo 命令

  • 功能：管理内核模块、显示模块详细的描述信息
  • 配置文件：/etc/modprobe.conf、/etc/modprobe.d/*.conf

modprobe 命令

  • 装载或卸载内核模块

depmod 命令

  • 内核模块依赖关系文件及系统信息映射文件的生成工具

insmod 命令

  • 可以安装模块，需要指定模块文件路径，不能自动解决依赖模块

rmmod 命令

  • 卸载模块

kernel 相关文件和目录

内核主文件

  • 只存放了内核的核心功能
[root@centos8 ~]# ll -h /boot/vmlinuz-4.18.0-240.el8.x86_64
-rwxr-xr-x. 1 root root 9.1M Sep 26  2020 /boot/vmlinuz-4.18.0-240.el8.x86_64

内核子配置目录

  • 防止全部功能和内容都集中到内核 从而导致内核过于臃肿

  • 方便管理，单一功能改动无需重构内核

[root@centos ~]# ll /lib/modules/4.18.0-240.el8.x86_64/
total 17220
-rw-r--r--.  1 root root     289 Sep 26  2020 bls.conf
lrwxrwxrwx.  1 root root      38 Sep 26  2020 build -> /usr/src/kernels/4.18.0-240.el8.x86_64
-rw-r--r--.  1 root root  189494 Sep 26  2020 config
drwxr-xr-x. 12 root root     128 Sep 26  2020 kernel
-rw-r--r--.  1 root root  888260 Jan 24  2021 modules.alias
-rw-r--r--.  1 root root  848865 Jan 24  2021 modules.alias.bin
-rw-r--r--.  1 root root     488 Sep 26  2020 modules.block
...

其他相关文件

/boot/config-4.18.0-240.el8.x86_64 #内核编译时指定的选项文件

#y表示写入到内核主文件中、=m表示写入到内核subject目录中、#开头表示不启用
[root@centos8 ~]# cat /boot/config-4.18.0-240.el8.x86_64
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_SERPENT_AVX2_X86_64=m
# CONFIG_CRYPTO_SM4 is not set

/proc 目录

  • 记录进程的相关信息 以及 内核的内部状态信息及统计信息
  • 帮助：man proc

/sys 目录

  • 使用 tmpfs 文件系统，为用户使用的伪文件系统
  • 输出内核识别出的各硬件设备的相关属性信息，也有内核对硬件特性的设定信息
  • 有些参数是可以修改的，用于调整硬件工作特性
  • udev通过此路径下输出的信息动态为各设备创建所需要的设备文件
    • udev是运行用户空间程序
    • 专用工具：udevadmin、hotplug
  • udev为设备创建文件设备时，会读取其事先定义好的规则文件，一般在：
    • /etc/udev/rules.d/ 及 /usr/lib/udev/rules.d/ 目录下

kernel 参数管理

sysctl

  • 此命令可以实现对内核参数的临时或永久修改以及查看
  • 本质上就是更改配置文件中的内容
  • 修改的参数都是以：/proc/sys/ 目录为基准，修改的是此目录下的内容

配置文件

/etc/sysctl.conf   #主配置文件
/etc/sysctl.d/*.conf     #子配置目录，添加子配置文件要以.conf结尾

使用范例

sysctl -w  kernel.hostname=centos8          # 临时修改内核参数方法一
echo 'centos88' > /proc/sys/kernel/hostname # 临时修改内核参数方法二

sysctl -a  # 查看目前所有已生效的内核参数

sysctl -p [/path/to/conf_file]   # 使配置文件立即生效，如修改的是主配置文件则后面无需加配置文件路径

kernel 参数说明

常用内核参数

mem

proc

  • 帮助：man proc

net.ipv4.tcp_fifin_timeout

  • 表示套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间，默认值是60秒。 该参数对应系统路径为：/proc/sys/net/ipv4/tcp_fifin_timeout 60

net.ipv4.tcp_tw_reuse

  • 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认值为0，表示关闭。 该参数对应系统路径为：/proc/sys/net/ipv4/tcp_tw_reuse 0

net.ipv4.tcp_tw_recycle

  • 表示开启TCP连接中TIME-WAIT sockets的快速回收。 该参数对应系统路径为：/proc/sys/net/ipv4/tcp_tw_recycle，默认为0，表示关闭。 提示：reuse和recycle这两个参数是为防止生产环境下Web、Squid等业务服务器time_wait网络状态数量过多设置的。

net.ipv4.tcp_syncookies

  • 表示开启SYN Cookies功能。当出现SYN等待队列溢出时，启用Cookies来处理，可防范少量SYN攻击，这个参数也可以不添加。 该参数对应系统路径为：/proc/sys/net/ipv4/tcp_syncookies,默认值为1

net.ipv4.tcp_keepalive_time

  • 表示当keepalive启用时，TCP发送keepalive消息的频度。默认是2小时，建议改为10分钟。 该参数对应系统路径为：/proc/sys/net/ipv4/tcp_keepalive_time,默认为7200秒。

net.ipv4.ip_local_port_range

  • 该选项用来设定允许系统打开的端口范围，即用于向外连接的端口范围。 该参数对应系统路径为：/proc/sys/net/ipv4/ip_local_port_range 32768 61000

net.ipv4.tcp_max_syn_backlog

  • 表示SYN队列的长度，即半连接队列长度，默认为1024，建议加大队列的长度为8192或更多，这样可以容纳更多等待连接的网络连接数。 该参数为服务器端用于记录那些尚未收到客户端确认信息的连接请求最大值。 该参数对象系统路径为：/proc/sys/net/ipv4/tcp_max_syn_backlog

net.ipv4.tcp_max_tw_buckets

  • 表示系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数值，TIME_WAIT套接字将立刻被清除并打印警告信息。 默认为180000，对于Apache、Nginx等服务器来说可以将其调低一点，如改为5000~30000，不通业务的服务器也可以给大一点，比如LVS、Squid。 此项参数可以控制TIME_WAIT套接字的最大数量，避免Squid服务器被大量的TIME_WAIT套接字拖死。 该参数对应系统路径为：/proc/sys/net/ipv4/tcp_max_tw_buckets

net.ipv4.tcp_synack_retries

  • 参数的值决定了内核放弃连接之前发送SYN+ACK包的数量。 该参数对应系统路径为：/proc/sys/net/ipv4/tcp_synack_retries,默认值为5

net.ipv4.tcp_syn_retries

  • 表示在内核放弃建立连接之前发送SYN包的数量。 该参数对应系统路径为：/proc/sys/net/ipv4/tcp_syn_retries,默认值为6

net.ipv4.tcp_max_orphans

  • 用于设定系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。 如果超过这个数值，孤立连接将被立即被复位并打印出警告信息。 这个限制只有为了防止简单的DoS攻击。不能过分依靠这个限制甚至认为减少这个值，更多的情况是增加这个值。该参数对应系统路径为：/proc/sys/net/ipv4/tcp_max_orphans ，默认值8192

net.core.somaxconn

  • 同时发起的TCP的最大连接数，即全连接队列长度，在高并发请求中，可能会导致链接超时或重传，一般结合并发请求数来调大此值。 该参数对应系统路径为：/proc/sys/net/core/somaxconn ，默认值是128
  • net.core.somaxconn是Linux中的一个内核(kernel)参数，表示socket监听(listen)的backlog上限。什么是backlog？backlog就是socket的监听队列，当一个请求(request)尚未被处理或者建立时，它就会进backlog。而socket server可以一次性处理backlog中的所有请求，处理后的请求不再位于监听队列中。当Server处理请求较慢时，导致监听队列被填满后，新来的请求就会被拒绝。对应三次握手结束，还没有 accept 队列时的 establish 状态。accept 队列较多则说明服务端 accept 效率不高，或短时间内突发了大量新建连接。该值过小会导致服务器收到 syn 不回包，是由于 somaxconn 表满而删除新建的 syn 连接引起。若为高并发业务，则可尝试增大该值，但有可能增大延迟。
  • 可以改为 如：20480

net.core.netdev_max_backlog

  • 表示当每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许发送到队列的数据包最大数。 该参数对应系统路径为：/proc/sys/net/core/netdev_max_backlog，默认值为1000

net.ipv4.icmp_echo_ignore_all

  • 是否禁ping，0为默认值 即允许ping 、1表示禁止ping

net.ipv4.ip_nonlocal_bind

  • 是否允许应用程序可以监听本地不存在的IP，0不允许、1允许，应用场景有keepalived等

vm.max_map_count

  • 限制一个进程可以拥有的VMA(虚拟内存区域)的数量

net.ipv4.tcp_timestamps

  • xxx

vm.overcommit_memory

  • 0，默认设置，当应用进程尝试申请内存时，内核会做一个检测。内核将检查是否有足够的可用内存供 应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。
    • 例：比如 1G 的机器，A 进程已经使用了 500M，当有另外进程尝试 malloc 500M 的内存时，内核就会进行 check，发现超出剩余可用内存，就会提示失败。
  • 1，对于内存的申请请求，内核不会做任何 check，直到物理内存用完，触发 OOM 杀用户态进程。
    • 例：同样是上面的例子， 1G 的机器，A 进程 500M，B 进程尝试 malloc 500M，会成功，但是一旦 kernel 发现内存使用率接 近 1 个 G( 内核有策略 )， 就触发 OOM，杀掉一些用户态的进程 ( 有策略的杀 )。
  • 2，当请求申请的内存 >= SWAP 内存大小 + 物理内存 * N，则拒绝此次内存申请（N 是一个百分比， 根据 overcommit_ratio/100 来确定，比如 overcommit_ratio=50，那么 N 就是 50%。 ）
    • vm.overcommit_ratio 只有当 vm.overcommit_memory = 2 的时候才会生效，内存可申请内存为 SWAP 内存大小 + 物理内存 * overcommit_ratio/100

tcp

man tcp

TCP的内核相关参数主要用于配置TCP协议栈的行为和性能。以下是一些常见的TCP内核参数：

  • tcp_keepalive_time：指定TCP keepalive（保活）定时器开始发送探测报文之前的空闲时间。默认值是7200秒（2小时）。
  • tcp_keepalive_intvl：指定TCP keepalive探测报文之间的发送间隔时间。默认值是75秒。
  • tcp_keepalive_probes：指定TCP keepalive探测报文的最大重试次数。默认值是9次。
  • tcp_syn_retries：指定TCP连接的SYN报文的最大重试次数。默认值是5次。
  • tcp_synack_retries：指定TCP连接的SYN+ACK报文的最大重试次数。默认值是5次。
  • tcp_fin_timeout：指定TCP连接中最后一个报文发送后等待关闭连接的超时时间。默认值是60秒。
  • tcp_max_syn_backlog：指定TCP SYN队列的最大长度。默认值是128。
  • tcp_max_tw_buckets：指定TCP TIME-WAIT（等待）状态的最大数量。默认值是180000。
  • tcp_tw_reuse：启用或禁用TCP TIME-WAIT状态的端口重用。默认值是0（禁用）。
  • tcp_tw_recycle：启用或禁用TCP TIME-WAIT状态的快速回收机制。默认值是0（禁用）。

参数优化参考

#vim /etc/sysctl.conf
net.ipv4.tcp_fin_timeout = 2
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_keepalive_time = 600
net.ipv4.ip_local_port_range = 2000 65000
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_max_tw_buckets = 36000
net.ipv4.route.gc_timeout = 100
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_max_orphans = 16384
net.core.somaxconn = 16384
net.core.netdev_max_backlog = 16384
vm.max_map_count = 262144
#net.ipv4.tcp_timestamps = 1 #此参数在负载均衡时慎用，有可能会出现网站无法访问等问题，0表示关闭。1

编译安装 kernel

  • 编译升级内核可以更个性化的定制，支持更多的功能、驱动程序等

  • 官网：https://www.kernel.org/

安装依赖包

[root@centos8 ~]# yum -y install gcc make ncurses-devel flex bison openssl-devel elfutils-libelf-devel

拷贝编译选项模板文件

[root@centos8 ~]# cp /boot/config-4.18.0-240.el8.x86_64 /usr/local/src/linux-5.15.13/.config


#修改编译选项模板文件
[root@centos8 ~]# vim /usr/local/src/linux-5.15.13/.config
CONFIG_SYSTEM_TRUSTED_KEYS=""   #将此行中间文件删除
#CONFIG_MODULE_SIG=y   #将此行注释

开启编译菜单

[root@centos8 ~]# cd /usr/local/src/linux-5.15.13/
[root@centos8 linux-5.15.13]# make help
[root@centos8 linux-5.15.13]# make menuconfig

开始编译安装

[root@centos8 linux-5.15.13]# make [-j #]

cgroup & namespace

cgroup（control groups）和namespace（命名空间）是Linux内核中的功能，用于实现容器化和资源管理。

cgroup和namespace是实现容器化和虚拟化的重要基础技术。它们通过资源管理和隔离，使得在同一个Linux系统上可以同时运行多个相互隔离的应用环境，每个环境都拥有独立的资源和命名空间，相互之间不会产生冲突。这为容器技术（如Docker）和虚拟化技术提供了强大的支持。

cgroup

cgroup是一种用于管理和限制进程组的机制。它允许将一组进程放在一个或多个cgroup中，并为每个cgroup分配系统资源（如CPU、内存、磁盘IO等）的限额。这样可以对进程组进行资源隔离和管理，防止资源的滥用和冲突。cgroup在Linux中的实现是通过在文件系统中创建特殊的目录结构来表示cgroup，并通过文件接口进行配置和控制。

cgroup（control groups）是Linux内核中的一个功能，用于对进程组进行资源管理和限制。它可以将一组相关的进程放入一个cgroup中，并为该cgroup分配特定的资源配额和限制。cgroup提供了一种层次化的资源管理机制，使得系统管理员可以对进程组进行细粒度的资源控制。

以下是cgroup的一些关键概念和功能：

  1. 层次结构：cgroup采用层次化的结构，可以创建多级的cgroup层次。每个cgroup可以包含其他cgroup，形成父子关系。这种层次结构允许更灵活地组织和管理进程组，并且可以在不同层次上为不同的进程组分配资源。
  2. 资源控制：cgroup可以为每个cgroup分配资源限额，如CPU使用时间、内存、磁盘IO等。通过设置资源限额，系统管理员可以控制进程组对系统资源的使用情况，防止资源的滥用和冲突。资源限额可以以硬限制（hard limit）和软限制（soft limit）的方式设置，超过硬限制会导致进程被终止，而超过软限制则会触发警告。
  3. 统计和监控：cgroup还提供了统计和监控功能，可以实时监测进程组的资源使用情况。系统管理员可以通过查看cgroup相关的文件接口或使用专门的工具，如cgroup-tools或Docker Stats，获取有关CPU、内存、磁盘IO等方面的统计信息，以便进行性能分析和优化。
  4. 灵活性：cgroup可以根据需要对进程组进行动态调整和重组。管理员可以随时创建、删除、合并或分割cgroup，以适应不同的资源管理需求。这种灵活性使得cgroup非常适用于动态环境下的资源管理，如云计算、容器化和虚拟化等场景。

总结来说，cgroup是Linux内核中的一个功能强大的资源管理机制，通过对进程组的分组和资源限制，实现了对系统资源的精细控制和隔离。它为容器技术和虚拟化技术提供了重要的基础支持，并在实际应用中发挥着重要作用。

Linux 支持的 cgroup 驱动有哪些

Linux支持多种cgroup驱动，不同的驱动提供了不同的功能和特性。以下是一些常见的cgroup驱动：

  1. cgroup v1（legacy）：cgroup v1是最早引入的cgroup驱动，通过在文件系统中创建特定的目录结构来表示cgroup。它提供了基本的资源控制和限制功能，如CPU、内存、磁盘IO等。cgroup v1的接口比较底层，使用起来较为复杂。
  2. cgroup v2（unified）：cgroup v2是对cgroup v1的改进和扩展。它提供了更简化的接口和更灵活的资源控制能力。与cgroup v1不同，cgroup v2使用了虚拟文件系统（virtual filesystem）来表示cgroup，而不再依赖于特定的目录结构。cgroup v2支持更多的资源控制选项，并引入了层级控制和更细粒度的资源配额。
  3. systemd cgroup（systemd slices）：systemd是一种系统初始化和服务管理的工具，在一些Linux发行版中被广泛采用。systemd使用自己的cgroup驱动来进行资源管理，称为systemd cgroup或systemd slices。systemd cgroup提供了更高级的资源控制和管理功能，如系统单位（system units）的优先级和资源配额。

这些是Linux中常见的cgroup驱动，每个驱动有其特定的用途和适用场景。在选择使用cgroup驱动时，应考虑操作系统版本、使用需求和所支持的功能。需要注意的是，cgroup v2被认为是未来的主流，提供了更强大和灵活的资源管理能力，因此在新的系统中推荐使用cgroup v2。

docker 如何配置 cgroup 驱动

要配置Docker的cgroup驱动，您可以按照以下步骤进行操作：

  1. 检查当前的cgroup驱动：运行以下命令来检查当前Docker的cgroup驱动：

    docker info | grep -i cgroup

    输出中的"Cgroup Driver"字段将显示当前正在使用的cgroup驱动。

  2. 配置Docker Daemon的cgroup驱动：打开Docker Daemon的配置文件（通常为/etc/docker/daemon.json），如果文件不存在，则创建一个新文件。确保在编辑之前备份该文件。

  3. 在配置文件中添加cgroup驱动设置：将以下内容添加到配置文件中：

    {
  "exec-opts": ["native.cgroupdriver=<driver-name>"]
}

    其中<driver-name>是您要使用的cgroup驱动名称，例如"cgroupfs"（cgroup v1）或"systemd"（systemd cgroup）。如果您希望使用cgroup v2，请确保系统内核和Docker版本都支持cgroup v2。

  4. 保存并关闭配置文件。

  5. 重启Docker服务：根据您的操作系统，运行以下命令来重启Docker服务：

    • 对于Systemd管理的系统：

      sudo systemctl restart docker

    • 对于其他系统（如Ubuntu 14.04）：

      sudo service docker restart

  6. 验证cgroup驱动：运行以下命令来验证Docker是否使用了您配置的cgroup驱动：

    docker info | grep -i cgroup

    确认输出中的"Cgroup Driver"字段显示了您配置的cgroup驱动。

请注意，配置Docker的cgroup驱动可能涉及到系统和Docker版本的特定要求。确保您已经仔细了解和理解所使用的驱动及其与系统的兼容性。在更改配置之前，最好备份相关的配置文件以防止意外情况。

kubelet 如何配置 cgroup 驱动

要配置Kubelet的cgroup驱动，您可以按照以下步骤进行操作：

  1. 打开Kubelet配置文件：Kubelet的配置文件通常位于/etc/kubernetes/kubelet.conf（如果使用kubelet配置文件）或/etc/default/kubelet（如果使用系统d配置文件）。根据您的部署方式选择相应的文件进行编辑。

  2. 在配置文件中添加cgroup驱动设置：在配置文件中找到或添加KUBELET_EXTRA_ARGS参数，并设置cgroup驱动选项。将以下内容添加到参数值中：

    --cgroup-driver=<driver-name>

    其中<driver-name>是您要使用的cgroup驱动名称，例如"cgroupfs"（cgroup v1）或"systemd"（systemd cgroup）。如果您希望使用cgroup v2，请确保系统内核和Kubelet版本都支持cgroup v2。

    注意：如果已经存在KUBELET_EXTRA_ARGS参数，请确保在现有参数值的末尾添加空格，然后再添加--cgroup-driver=<driver-name>。

  3. 保存并关闭配置文件。

  4. 重启Kubelet服务：根据您的操作系统和启动管理器，运行以下命令来重启Kubelet服务：

    • Systemd管理的系统：

      sudo systemctl restart kubelet

    • 其他启动管理器（如SysV init）：

      sudo service kubelet restart

  5. 验证cgroup驱动：运行以下命令来验证Kubelet是否使用了您配置的cgroup驱动：

    kubectl describe node <node-name> | grep -i cgroup

    将<node-name>替换为您的节点名称。确认输出中的"Cgroup Driver"字段显示了您配置的cgroup驱动。

请注意，配置Kubelet的cgroup驱动可能涉及到系统和Kubelet版本的特定要求。确保您已经仔细了解和理解所使用的驱动及其与系统的兼容性。在更改配置之前，最好备份相关的配置文件以防止意外情况。

Jul 10 16:59:45 k8s-worker-1 kubelet[30012]: E0710 16:59:45.595625 30012 server.go:294] “Failed to run kubelet” err=“failed to run Kubelet: misconfiguration: kubelet cgroup driver: "cgroupfs" is different from docker cgroup driver: "systemd"”

根据错误消息显示，Kubelet的cgroup驱动与Docker的cgroup驱动不匹配，导致Kubelet无法运行。要解决此问题，您可以通过以下步骤之一进行操作：

  1. 将Kubelet的cgroup驱动与Docker的cgroup驱动保持一致：根据错误消息，Kubelet的cgroup驱动配置为"cgroupfs"，而Docker的cgroup驱动配置为"systemd"。您可以选择将Kubelet的cgroup驱动配置与Docker的cgroup驱动保持一致，以解决此错误。修改Kubelet的配置文件，将--cgroup-driver选项的值设置为与Docker相同的驱动（“systemd”），保存并重启Kubelet服务。
  2. 更改Docker的cgroup驱动以与Kubelet匹配：如果您无法更改Kubelet的cgroup驱动，您可以尝试更改Docker的cgroup驱动以与Kubelet匹配。要更改Docker的cgroup驱动，您需要修改Docker的配置文件。具体操作可能因不同的Linux发行版而异，您可以查找有关如何更改Docker cgroup驱动的相关文档和指南。在更改Docker的cgroup驱动后，确保重启Docker服务和Kubelet服务以使更改生效。

无论您选择哪种方法，确保Kubelet和Docker的cgroup驱动保持一致，以解决错误并使Kubelet能够成功运行。请注意，更改cgroup驱动可能涉及到系统和组件版本的特定要求，请确保您了解和理解所使用的驱动及其与系统的兼容性。

root@k8s-worker-1:~# cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS="--cgroup-driver=cgroupfs --network-plugin=cni --pod-infra-container-image=registry.cn-beijing.aliyuncs.com/kubesphereio/pause:3.5"




root@k8s-worker-2:~# cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS="--cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=registry.cn-beijing.aliyuncs.com/kubesphereio/pause:3.5"

不同的cgroup驱动间有什么区别

不同的cgroup驱动在功能和实现方式上存在一些区别。下面是一些常见的cgroup驱动及其主要区别：

  1. cgroupfs（cgroup v1）：
    • 功能较为基本：cgroupfs是cgroup v1的默认驱动，提供了基本的资源控制和限制功能，如CPU、内存、磁盘IO等。但相对较为简单，没有cgroup v2提供的一些高级功能。
    • 使用文件系统表示：cgroupfs通过在文件系统中创建特定的目录结构来表示cgroup，通过操作文件来配置和控制资源。
  2. systemd cgroup（systemd）：
    • 集成了cgroup管理：systemd是一种系统初始化和服务管理的工具，它使用自己的cgroup驱动来进行资源管理，称为systemd cgroup或systemd slices。
    • 提供更高级的资源控制：systemd cgroup提供了一些额外的资源控制和管理功能，如优先级和资源配额，以及与systemd单位（units）集成。
  3. cgroup v2（unified）：
    • 功能更为强大和灵活：cgroup v2是对cgroup v1的改进和扩展，提供了更多的资源控制选项和更细粒度的资源配额。它被认为是cgroup的未来。
    • 使用虚拟文件系统：cgroup v2使用了虚拟文件系统（virtual filesystem）来表示cgroup，不再依赖于特定的目录结构。这种改变使得cgroup v2更加灵活，并且支持层级控制，允许更细粒度的资源配额和管理。

这些cgroup驱动在功能和实现方式上有所不同，而选择适合您的驱动取决于您的需求和使用环境。通常来说，cgroup v2提供了更强大和灵活的资源管理能力，建议在支持cgroup v2的环境中使用它。但请注意，每个驱动可能在不同的Linux发行版和内核版本中的支持程度有所差异，因此在进行选择和配置时请参考相关文档和指南，并确保了解所使用的驱动的特定要求和限制。

namespace

namespace是一种隔离和虚拟化的机制，它将一个系统资源的全局视图分割成多个独立的部分，每个部分都有自己的命名空间。不同的命名空间中的进程看到的系统资源（如进程、网络、文件系统等）是不同的，它们之间相互隔离，互不干扰。Linux提供了多种类型的namespace，如PID namespace、Network namespace、Mount namespace等，每种namespace都提供了不同的隔离级别和功能。

命名空间（namespace）是Linux内核中的一项功能，用于隔离和虚拟化系统资源，使得不同的进程在各自的命名空间中运行，相互之间互不干扰。

以下是命名空间的一些关键概念和功能：

  1. 进程隔离：命名空间通过将系统资源划分为多个独立的命名空间，使得每个命名空间中的进程只能看到自己所属的命名空间中的资源。这种隔离机制有效地防止了不同命名空间中的进程之间的资源冲突和干扰。常见的命名空间类型包括PID namespace（进程隔离）、Network namespace（网络隔离）、Mount namespace（文件系统隔离）等。
  2. 资源虚拟化：命名空间使得每个命名空间中的进程拥有独立的资源视图。例如，每个进程在PID namespace中看到的进程ID是独立的，同样，在Network namespace中每个进程拥有独立的网络接口和IP地址。这种资源虚拟化使得在同一台机器上可以运行多个互相隔离的应用环境，每个环境都具有独立的资源和网络配置。
  3. 安全性增强：命名空间提供了一种增强安全性的机制。通过将不同的进程置于不同的命名空间中，可以有效地限制进程的权限和资源访问范围。这有助于减少恶意进程对系统的影响，并提高系统的整体安全性。
  4. 容器化支持：命名空间为容器技术提供了基础支持。容器化平台（如Docker）利用命名空间将应用程序及其依赖的资源隔离在一个独立的运行环境中。每个容器拥有自己的命名空间，包括PID、网络、文件系统等，从而实现了隔离、独立和可移植的应用程序部署。

总结来说，命名空间是Linux内核提供的一种隔离和虚拟化机制，通过将系统资源分割为独立的命名空间，实现了进程的隔离、资源虚拟化和安全性增强。命名空间为容器化和虚拟化等技术提供了基础支持，为多租户环境和动态资源管理提供了灵活而强大的工具。