У цьому документі описано, як налаштовувати та використовувати параметри ядра в межах кластера Kubernetes, використовуючи інтерфейс sysctl.
/ або . як роздільники для назв sysctl. Починаючи з версії Kubernetes 1.25, налаштування Sysctls для контейнера підтримує встановлення sysctl зі слешами. Наприклад, ви можете представити ту саму назву sysctl як kernel.shm_rmid_forced, використовуючи крапку як роздільник, або як kernel/shm_rmid_forced, використовуючи слеш як роздільник. Для отримання додаткових відомостей щодо методу конвертації параметра sysctl див. сторінку sysctl.d(5) проєкту Linux man-pages.sysctl — це інструмент командного рядка, специфічний для Linux, який використовується для налаштування різних параметрів ядра, і він недоступний в операційних системах, що не базуються на Linux.Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Для деяких кроків вам також потрібно мати змогу змінювати параметри командного рядка для kubelet, що працюють на вашому кластері.
У Linux інтерфейс sysctl дозволяє адміністратору змінювати параметри ядра під час виконання. Параметри доступні через віртуальну файлову систему /proc/sys/. Параметри охоплюють різні підсистеми, такі як:
kernel.)net.)vm.)dev.)Щоб отримати список всіх параметрів, ви можете виконати команду:
sudo sysctl -a
Kubernetes класифікує sysctl як безпечні або небезпечні. Крім належного просторового розмежування, безпечний sysctl повинен бути належним чином ізольованим між Podʼами на тому ж вузлі. Це означає, що встановлення безпечного sysctl для одного Podʼа
Наразі більшість просторово розмежованих (по просторах імен) sysctl не обовʼязково вважаються безпечними. До набору безпечних sysctl входять наступні параметри:
kernel.shm_rmid_forced;net.ipv4.ip_local_port_range;net.ipv4.tcp_syncookies;net.ipv4.ping_group_range (починаючи з Kubernetes 1.18);net.ipv4.ip_unprivileged_port_start (починаючи з Kubernetes 1.22);net.ipv4.ip_local_reserved_ports (починаючи з Kubernetes 1.27, потрібне ядро 3.16+);net.ipv4.tcp_keepalive_time (починаючи з Kubernetes 1.29, потрібне ядро 4.5+);net.ipv4.tcp_fin_timeout (починаючи з Kubernetes 1.29, потрібне ядро 4.6+);net.ipv4.tcp_keepalive_intvl (починаючи з Kubernetes 1.29, потрібне ядро 4.5+);net.ipv4.tcp_keepalive_probes (починаючи з Kubernetes 1.29, потрібне ядро 4.5+).net.ipv4.tcp_rmem (починаючи Kubernetes 1.32, потрібне ядро 4.15+).net.ipv4.tcp_wmem (починаючи Kubernetes 1.32, потрібне ядро 4.15+).net.ipv4.tcp_slow_start_after_idle (починаючи з Kubernetes 1.37, потрібне ядро 4.15+).net.ipv4.tcp_notsent_lowat (починаючи з Kubernetes 1.37, потрібне ядро 4.6+).Є деякі винятки зі списку безпечних sysctl:
net.* не дозволені з увімкненою мережею вузла.net.ipv4.tcp_syncookies не має просторового розмежування в ядрах Linux версії 4.5 або нижче.Цей список буде розширюватися у майбутніх версіях Kubernetes, коли kubelet буде підтримувати кращі механізми ізоляції.
Всі безпечні sysctl є типово увімкненими.
Всі небезпечні sysctl типово вимкнені та повинні бути дозволені вручну адміністратором кластера на кожному вузлі окремо. Podʼи з вимкненими небезпечними sysctl будуть заплановані, але їх не вдасться запустити.
З врахуванням попередження вище, адміністратор кластера може дозволити певні небезпечні sysctl для дуже спеціальних ситуацій, таких як налаштування високопродуктивних або застосунків реального часу. Небезпечні sysctl вмикаються на основі вузла з прапорцем kubelet; наприклад:
kubelet --allowed-unsafe-sysctls \
'kernel.msg*,net.core.somaxconn' ...
Для Minikube, це можна зробити за допомогою прапорця extra-config:
minikube start --extra-config="kubelet.allowed-unsafe-sysctls=kernel.msg*,net.core.somaxconn"...
Таким чином можна увімкнути лише просторово розмежовані sysctl.
Численні sysctl просторово розмежовані в сучасних ядрах Linux. Це означає, що їх можна налаштовувати незалежно для кожного Pod на вузлі. Лише просторово розмежовані sysctl можна налаштовувати через securityContext Podʼа в межах Kubernetes.
Відомо, що наступні sysctl мають просторове розмежування. Цей список може змінитися в майбутніх версіях ядра Linux.
kernel.shm*kernel.msg*kernel.semfs.mqueue.*net.*, які можна налаштувати в просторі імен мережі контейнера. Однак є винятки (наприклад, net.netfilter.nf_conntrack_max та net.netfilter.nf_conntrack_expect_max можуть бути налаштовані в просторі імен мережі контейнера, але не мають просторового розмежування до Linux 5.12.2).Sysctl без просторового розмежування називають вузловими sysctl. Якщо вам потрібно налаштувати їх, ви повинні вручну налаштувати їх в операційній системі кожного вузла або за допомогою DaemonSet з привілейованими контейнерами.
Використовуйте securityContext Podʼа для налаштування просторово розмежованих sysctl. securityContext застосовується до всіх контейнерів у тому ж Podʼі.
У цьому прикладі використовується securityContext Podʼа для встановлення безпечного sysctl kernel.shm_rmid_forced та двох небезпечних sysctl net.core.somaxconn та kernel.msgmax. В специфікації немає розрізнення між безпечними та небезпечними sysctl.
apiVersion: v1
kind: Pod
metadata:
name: sysctl-example
spec:
securityContext:
sysctls:
- name: kernel.shm_rmid_forced
value: "0"
- name: net.core.somaxconn
value: "1024"
- name: kernel.msgmax
value: "65536"
...
Хорошою практикою є вважати вузли з особливими налаштуваннями sysctl як позначені taint в межах кластера і планувати на них лише ті Podʼи, яким потрібні ці налаштування sysctl. Рекомендується використовувати функцію Заплямованість та Толерантність кластера Kubernetes, щоб реалізувати це.
Pod з небезпечними sysctl не вдасться запустити на будь-якому вузлі, на якому не були явно увімкнені ці два небезпечні sysctl. Як і з вузловими sysctl, рекомендується використовувати функцію Заплямованість та Толерантність або заплямованість вузлів для планування цих Podʼів на відповідні вузли.
Щоб скористатися цією функцією, вам (або адміністратору кластера) потрібно увімкнути функціональну можливість DefaultPodSysctls для всіх відповідних компонентів у вашому кластері.
Перегляньте Увімкнення або вимкнення функціональних можливостей для отримання додаткової інформації.
Ви можете налаштувати типовий набір параметрів ядра (sysctl), які kubelet застосовує до всіх Podʼів, що працюють на вузлі Linux, включно з статичними Podʼами. Це корисно, коли адміністраторам вузлів потрібно забезпечити узгоджене налаштування параметрів ядра для всіх робочих навантажень на вузлі або в межах групи вузлів (наприклад, налаштування розмірів буферів TCP для високопродуктивних мереж) без необхідності, щоб кожна специфікація Podʼа окремо встановлювала securityContext.sysctls.
Щоб використовувати цю функцію, увімкніть функціональну можливість DefaultPodSysctls для kubelet та вкажіть пари ключ-значення у полі defaultPodSysctls вашого KubeletConfiguration.
Поле defaultPodSysctls підтримує всі просторово розмежовані sysctl (kernel.shm*, kernel.msg*, kernel.sem, kernel.domainname, fs.mqueue.*, net.* та user.*), охоплюючи як безпечні, так і небезпечні sysctl. Оскільки ці типові значення налаштовуються безпосередньо адміністратором вузла на kubelet, вам не потрібно додавати небезпечні sysctl до списку дозволених у allowedUnsafeSysctls.
Наступний приклад налаштовує kubelet застосовувати типові sysctl у кількох просторово розмежованих підсистемах (мережа, IPC та простори імен користувача) до всіх Podʼів на вузлі:
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
DefaultPodSysctls: true
defaultPodSysctls:
# Sysctl простору імен мережі (пропускаються, якщо Pod використовує hostNetwork: true)
net.ipv4.ip_forward: "1"
net.ipv4.tcp_rmem: "4096 87380 16777216"
net.ipv4.tcp_wmem: "4096 65536 16777216"
net.core.somaxconn: "1024"
# Sysctl простору імен IPC (пропускаються, якщо Pod використовує hostIPC: true)
kernel.shmall: "1048576"
kernel.msgmax: "65536"
kernel.sem: "250 32000 32 128"
fs.mqueue.msg_max: "1024"
# Sysctl простору імен користувача (пропускаються, якщо Pod поділяє простір імен користувача хоста)
user.max_user_namespaces: "1000"
Значення, явно встановлені у spec.securityContext.sysctls Podʼа, завжди перевизначають відповідні типові значення, вказані у defaultPodSysctls kubelet. Перевизначення застосовуються індивідуально на основі кожного ключа: якщо Pod вказує значення для sysctl, яке також визначене у defaultPodSysctls, налаштування на рівні Podʼа має пріоритет для цього конкретного sysctl, тоді як інші типові значення продовжують застосовуватися. Зверніть увагу, що не існує груп повʼязаних налаштувань sysctl; якщо ваше робоче навантаження перевизначає sysctl, який є частиною повʼязаної групи (наприклад, розміри мережевих буферів), специфікація Podʼа повинна враховувати всі повʼязані налаштування за потреби.
kubelet застосовує типові sysctl під час створення пісочниці Podʼа лише якщо Pod працює в окремому просторі імен для відповідної підсистеми. Якщо Pod поділяє простір імен хосту, типові sysctl для цього простору імен пропускаються для цього Podʼа:
net.* пропускаються, якщо Pod використовує мережу хосту (hostNetwork: true).kernel.sem, kernel.msg*, kernel.shm*, fs.mqueue.*) пропускаються, якщо Pod використовує IPC хосту (hostIPC: true).user.* пропускаються, якщо Pod поділяє простір імен користувача хосту (hostUsers: true або не встановлено).kernel.domainname) пропускаються, якщо Pod використовує мережу хосту (hostNetwork: true).kubelet перевіряє defaultPodSysctls під час запуску. Непросторово розмежовані sysctl, недійсні назви sysctl або дублікати ключів перешкоджатимуть запуску kubelet.
Крім того, певні sysctl net.* можуть бути непросторово розмежованими залежно від вашої версії ядра. Вказання непросторово розмежованого sysctl net.* у defaultPodSysctls призведе до збою створення пісочниці Podʼа з помилкою FailedCreatePodSandBox. Pod продовжуватиме повторювати спроби створення пісочниці нескінченно. Переконайтеся, що всі вказані sysctl є просторово розмежованими на ядрі вашого вузла.
Зміни до defaultPodSysctls застосовуються лише до новостворених Podʼів. kubelet не переналаштовує динамічно наявні Podʼи (див. Що відбувається після перезапуску вузла). Наявні Podʼи продовжують працювати з sysctl, застосованими під час створення їхньої пісочниці. Якщо ви хочете, щоб наявні Podʼи застосували оновлені типові sysctl, ви повинні перестворити ці Podʼи (наприклад, позначивши вузол як cordon та drain).