Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to use the sysctl command in kubernetes1.4

2025-02-25 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/01 Report--

This article mainly explains "how to use the sysctl command in kubernetes1.4". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn how to use the sysctl command in kubernetes1.4.

Sysctl is an interface that allows you to change the kernel parameters of a running Linux system. You can modify the advanced options of the TCP/IP stack and virtual memory system in the Linux kernel through sysctl, and you can optimize the Linux system and improve the performance of application processes without restarting the Linux system.

The Linux system kernel parameters are dynamically configured through the / proc virtual file system in the Linux system. There are most of the kernel parameters of the Linux system in the / proc/sys directory. These kernel parameters can be modified while the Linux system is running and can take effect immediately without restarting the Linux system, but this modification will become invalid after restarting the Linux system, if you want to take effect permanently. The corresponding kernel parameter configuration item in the configuration file / etc/sysctl.conf needs to be changed.

You can get all the kernel parameter configuration items and configured values that sysctl can manipulate with the following command:

# sysctl-a these kernel parameters mainly include the following types of configuration items: global kernel configuration items: with "kernel." To prefix the configuration item, for example: kernel.shmmax = 33554432 (maximum size of shared memory segment in bytes) kernel.threads-max = 139264 (maximum number of threads that can be used by the Linux kernel) network configuration item: with "net." To prefix the configuration item, for example: net.ipv4.ipfrag_low_thresh = 196608 (minimum amount of memory used for IP part aggregation) net.ipv4.ipfrag_high_thresh = 262144 (maximum amount of memory used for IP part aggregation) Virtual memory configuration item: with "vm." To prefix the configuration item, for example: vm.swappiness = 60 (reducing frequent writes to swap by the system will speed up the switching between applications and help improve system performance) vm.dirty_ratio = 40 (this file indicates that if the process generates waste data as a percentage of the overall memory of the system, the process is confident to write the waste data back to disk) device-specific configuration item: with "dev." To prefix the configuration item, for example: dev.raid.speed_limit_max = 200000 (maximum speed limit of synchronization that requires initialization of synchronization RAID) dev.raid.speed_limit_min = 1000 (minimum speed limit of synchronization that requires initialization of synchronization RAID) file system specific configuration item: with "fs." To configure the item prefix fs.file-max = 779703 (maximum number of file handles that can be allocated) fs.file-nr = 3930 0 779703 (number of allocated file handles, number of file handles used, maximum number of file handles, read-only, used for displaying information only) container-related kernel parameters

It was described above that Linux system kernel parameters can be manipulated through sysctl, and some of these kernel parameters are not only operating system global-level kernel parameters, but also namespace-level kernel parameters. For containers, isolation is achieved through namespaces, which means that these namespace-level parameters are container-related kernel parameters.

The Linux system namespaces are classified as follows:

Kernel parameters at the namespace level include: kernel.shm* (parameters related to shared memory in the kernel) For example: kernel.shmall = 3774873 (total shared memory that can be used) kernel.shmmax = 15461882265 (maximum value of a single shared memory segment) kernel.msg* (SystemV message queue related parameters in the kernel) kernel.msgmnb = 16384 (maximum byte limit per message queue) kernel.msgmni = 128 (maximum number of message queues running at the same time) kernel.sem (semaphore parameters in the kernel) kernel.sem = 250 32000 100128 (the maximum number of semaphores per signal set, The total number of system-wide maximum semaphores, the maximum number of system operations when each signal occurs, and the maximum total number of system-wide signal sets) fs.mqueue.* (POSIX message queue related parameters in the kernel) fs.mqueue. Msg_max = 32678 (maximum number of soft messages cached in the queue) fs.mqueue. Msgsize_max = 8192 (maximum message length limit) net.* (parameters related to network configuration items in the kernel) net.ipv4.ipfrag_low_thresh = 196608 (minimum memory usage for IP shard aggregation) net.ipv4.ipfrag_high_thresh = 262144 (maximum memory usage for IP shard aggregation) New feature

Because sysctl can modify kernel parameters at the namespace level, you can configure Linux kernel parameters in POD through sysctl in Kubernetes1.4. By modifying Linux kernel parameters in POD, you can optimize POD performance and improve the efficiency of containers in POD. This is still an alpha feature in Kubernetes1.4.

There is a security risk in modifying Linux kernel parameters, and modification errors are likely to degrade system performance and even cause system crashes, so it needs to be treated with caution. Kernel parameters at the namespace level are divided into two categories in Kubernetes1.4, one is secure kernel parameters and the other is insecure kernel parameters. The so-called secure namespace-level kernel parameters should be able to achieve complete isolation between different POD on the same node, and the following conditions must be met:

Cannot have any impact on other POD on the same node cannot affect the health of the operating system on the node can not obtain more CPU and memory resources beyond the POD resource limit, according to the above three conditions, it can be found that most namespace-level kernel parameters are not secure. In Kubernetes1.4, the following namespace-level kernel parameters are considered safe: kernel.shm_rmid_forced = 1 (indicates whether to force shared memory to be associated with a process, so that shared memory can be freed by killing the process) net.ipv4.ip_local_port_range = 1024 65000 (indicates the range of ports allowed to be used) net.ipv4.tcp_syncookies = 1 (indicates whether to open the TCP synchronization tag Synchronization tags can prevent a socket from overloading when there are too many attempts to connect)

In future versions of Kubernetes, secure namespace-level kernel parameters will continue to be expanded. In Kubernetes, all secure namespace-level kernel parameters are enabled by default, and all insecure namespace-level kernel parameters are disabled by default. If you want to set unsafe kernel parameters, you need to enable them manually by Kubernetes administrator. If the administrator does not manually enable unsafe kernel parameters, Kubernetes will still schedule these POD with insecure kernel parameters to the node, but these POD will fail at startup.

Enable unsafe namespace-level kernel parameters by adding the parameter "experimental-allowed-unsafe-sysctls" when starting kubelet:

You can set the namespace-level kernel parameters that have been enabled in the POD configuration file:

The above configuration file sets the secure namespace-level kernel parameter kernel.shm_rmid_forced in POD and two unsafe namespace-level kernel parameters net.ipv4.route.min_pmte and kernet.msgmax in POD.

Set secure namespace-level kernel parameters on the "security.alpha.kubernetes.io/sysctls" parameter in annotations and unsafe namespace-level kernel parameters on the "security.alpha.kubernetes.io/unsafe-sysctls" parameter in annotations.

Thank you for your reading, the above is the content of "how to use sysctl commands in kubernetes1.4". After the study of this article, I believe you have a deeper understanding of how to use sysctl commands in kubernetes1.4, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report