CentOS升級核心與容器執行時核心引數的關係
背景
還是最近一些詭異的問題
想能夠根因分析一下.
所以繼續總結和驗證
CentOS7升級核心
rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
檢視可以升級的核心
yum --disablerepo="*" --enablerepo="elrepo-kernel" list available
2024.6 的展示結果為:
可安裝的軟體包
elrepo-release.noarch 7.0-6.el7.elrepo elrepo-kernel
kernel-lt.x86_64 5.4.277-1.el7.elrepo elrepo-kernel
kernel-lt-devel.x86_64 5.4.277-1.el7.elrepo elrepo-kernel
kernel-lt-doc.noarch 5.4.277-1.el7.elrepo elrepo-kernel
kernel-lt-headers.x86_64 5.4.277-1.el7.elrepo elrepo-kernel
kernel-lt-tools.x86_64 5.4.277-1.el7.elrepo elrepo-kernel
kernel-lt-tools-libs.x86_64 5.4.277-1.el7.elrepo elrepo-kernel
kernel-lt-tools-libs-devel.x86_64 5.4.277-1.el7.elrepo elrepo-kernel
kernel-ml.x86_64 6.9.4-1.el7.elrepo elrepo-kernel
kernel-ml-devel.x86_64 6.9.4-1.el7.elrepo elrepo-kernel
kernel-ml-doc.noarch 6.9.4-1.el7.elrepo elrepo-kernel
kernel-ml-headers.x86_64 6.9.4-1.el7.elrepo elrepo-kernel
kernel-ml-tools.x86_64 6.9.4-1.el7.elrepo elrepo-kernel
kernel-ml-tools-libs.x86_64 6.9.4-1.el7.elrepo elrepo-kernel
kernel-ml-tools-libs-devel.x86_64 6.9.4-1.el7.elrepo elrepo-kernel
perf.x86_64 5.4.277-1.el7.elrepo elrepo-kernel
python-perf.x86_64 5.4.277-1.el7.elrepo elrepo-kernel
yum --disablerepo="*" --enablerepo=elrepo-kernel install kernel-lt.x86_64 -y
yum --disablerepo="*" --enablerepo=elrepo-kernel install kernel-ml.x86_64 -y
ml 版本是 main line 的含義 主線一般是大家都在開發的不太穩定.
lt 是超期支援的版本.
如果是生產, 建議使用lt 如果是測試可以選擇mt.
grub2-set-default 0 && grub2-mkconfig -o /etc/grub2.cfg
grubby --args="user_namespace.enable=1" --update-kernel="$(grubby --default-kernel)"
CentOS7 可以手工更換不同核心.
cat /boot/grub2/grub.cfg | grep ^menuentry
grub2-set-default '4.19.12-1.el7.elrepo.x86_64'
grub2-editenv list
CentOS8 切換核心的方法:
# 檢視當前
grubby --default-kernel
# 檢視所有
grubby --info=ALL |grep ^kernel
# 設定
grubby --set-default /boot/vmlinuz-4.19.0-80.11.2.el8_0.x86_64
比如我這邊的核心版本列表為:
kernel=/boot/vmlinuz-6.9.4-1.el7.elrepo.x86_64
kernel=/boot/vmlinuz-5.4.277-1.el7.elrepo.x86_64
kernel=/boot/vmlinuz-4.19.12-1.el7.elrepo.x86_64
kernel=/boot/vmlinuz-3.10.0-1160.el7.x86_64
檢視部分內容:
sysctl -a |wc -l
docker run -it --rm grafana/grafana-image-renderer sysctl -a |wc -l
核心引數數量資訊
| 核心版本 |
虛擬機器 |
容器 |
差值 |
| 3.10 |
1303 |
878 |
425 |
| 4.19 |
1482 |
1038 |
444 |
| 5.4 |
1423 |
978 |
445 |
| 6.9 |
1436 |
959 |
477 |
對部分引數的驗證
grep -ir net.ipv4.tcp_sack :
3.10.vm____.info:net.ipv4.tcp_sack = 1
4.19.docker.info:net.ipv4.tcp_sack = 1
4.19.vm____.info:net.ipv4.tcp_sack = 1
5.4.docker.info:net.ipv4.tcp_sack = 1
5.4.vm____.info:net.ipv4.tcp_sack = 1
6.9.docker.info:net.ipv4.tcp_sack = 1
6.9.vm____.info:net.ipv4.tcp_sack = 1
grep -ir net.ipv4.tcp_max_tw :
3.10.vm____.info:net.ipv4.tcp_max_tw_buckets = 5000
4.19.docker.info:net.ipv4.tcp_max_tw_buckets = 262144
4.19.vm____.info:net.ipv4.tcp_max_tw_buckets = 5000
5.4.docker.info:net.ipv4.tcp_max_tw_buckets = 262144
5.4.vm____.info:net.ipv4.tcp_max_tw_buckets = 5000
6.9.docker.info:net.ipv4.tcp_max_tw_buckets = 262144
6.9.vm____.info:net.ipv4.tcp_max_tw_buckets = 5000
grep -ir net.ipv4.ip_local_port :
3.10.docker.info:net.ipv4.ip_local_port_range = 32768 60999
3.10.vm____.info:net.ipv4.ip_local_port_range = 9000 65500
4.19.docker.info:net.ipv4.ip_local_port_range = 32768 60999
4.19.vm____.info:net.ipv4.ip_local_port_range = 9000 65500
5.4.docker.info:net.ipv4.ip_local_port_range = 32768 60999
5.4.vm____.info:net.ipv4.ip_local_port_range = 9000 65500
6.9.docker.info:net.ipv4.ip_local_port_range = 32768 60999
6.9.vm____.info:net.ipv4.ip_local_port_range = 9000 65500
感悟
net.ipv4.tcp_max_tw_buckets
net.ipv4.tcp_sack
部分引數在 3.10 的版本沒有傳遞到容器內, 的確是存在bug
容器自己執行不會將配置好的核心引數傳遞進容器內
需要自己進行指定.
關於
net.ipv4.tcp_max_tw_buckets 和 net.ipv4.ip_local_port_range
應該是跟廠商有關係.
廠商編譯的時候會選擇一個特定的核心引數值
銀河麒麟的 tw_bucket 就是 13萬. 繼承在openeuler
紅帽就比較保守一些.
所以核心有bug 核心還有自己的脾氣性格.