# Використання sysctl в кластері Kubernetes

LLMS index: [llms.txt](/llms.txt)

---

<!-- overview -->








  <div class="feature-state-notice feature-stable">
      <span class="feature-state-name">СТАН ФУНКЦІОНАЛУ:</span>
      <code>Kubernetes v1.21 [stable]</code>
    </div>
  



У цьому документі описано, як налаштовувати та використовувати параметри ядра в межах кластера Kubernetes, використовуючи інтерфейс <a class='glossary-tooltip' title='Інтерфейс для отримання та встановлення параметрів ядра Unix.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/tasks/administer-cluster/sysctl-cluster/' target='_blank' aria-label='sysctl'>sysctl</a>.


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4>Починаючи з версії Kubernetes 1.23, kubelet підтримує використання <code>/</code> або <code>.</code> як роздільники для назв sysctl. Починаючи з версії Kubernetes 1.25, налаштування Sysctls для контейнера підтримує встановлення sysctl зі слешами. Наприклад, ви можете представити ту саму назву sysctl як <code>kernel.shm_rmid_forced</code>, використовуючи крапку як роздільник, або як <code>kernel/shm_rmid_forced</code>, використовуючи слеш як роздільник. Для отримання додаткових відомостей щодо методу конвертації параметра sysctl див. сторінку <a href="https://man7.org/linux/man-pages/man5/sysctl.d.5.html">sysctl.d(5)</a> проєкту Linux man-pages.</div>


## Перш ніж ви розпочнете


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4><code>sysctl</code> — це інструмент командного рядка, специфічний для Linux, який використовується для налаштування різних параметрів ядра, і він недоступний в операційних системах, що не базуються на Linux.</div>


<p>Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою <a href="https://minikube.sigs.k8s.io/docs/tutorials/multi_node/">minikube</a> або використовувати одну з цих пісочниць:</p>
<ul>
<li><a href="https://labs.iximiuz.com/playgrounds?category=kubernetes&filter=all">iximiuz Labs</a></li>
<li><a href="https://killercoda.com/playgrounds/scenario/kubernetes">Killercoda</a></li>
<li><a href="https://kodekloud.com/public-playgrounds">KodeKloud</a></li>
</ul>


Для деяких кроків вам також потрібно мати змогу змінювати параметри командного рядка для kubelet, що працюють на вашому кластері.

<!-- steps -->

## Перелік всіх параметрів Sysctl {#listing-all-sysctl-parameters}

У Linux інтерфейс sysctl дозволяє адміністратору змінювати параметри ядра під час виконання. Параметри доступні через віртуальну файлову систему `/proc/sys/`. Параметри охоплюють різні підсистеми, такі як:

- ядро (загальний префікс: `kernel.`)
- мережа (загальний префікс: `net.`)
- віртуальна памʼять (загальний префікс: `vm.`)
- MDADM (загальний префікс: `dev.`)
- Більше підсистем описано у [документації ядра](https://www.kernel.org/doc/Documentation/sysctl/README).

Щоб отримати список всіх параметрів, ви можете виконати команду:

```shell
sudo sysctl -a
```

## Безпечні та Небезпечні Sysctl {#safe-and-unsafe-sysctls}

Kubernetes класифікує sysctl як _безпечні_ або _небезпечні_. Крім належного просторового розмежування, _безпечний_ sysctl повинен бути належним чином _ізольованим_ між Podʼами на тому ж вузлі. Це означає, що встановлення _безпечного_ sysctl для одного Podʼа

- не повинно мати жодного впливу на інші Podʼи на вузлі
- не повинно дозволяти шкодити справності вузла
- не повинно дозволяти отримувати CPU або ресурси памʼяті поза межами обмежень ресурсів 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+).


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4><p>Є деякі винятки зі списку безпечних sysctl:</p>
<ul>
<li>Параметри sysctl <code>net.*</code> не дозволені з увімкненою мережею вузла.</li>
<li>Параметр sysctl <code>net.ipv4.tcp_syncookies</code> не має просторового розмежування в ядрах Linux версії 4.5 або нижче.</li>
</ul></div>


Цей список буде розширюватися у майбутніх версіях Kubernetes, коли kubelet буде підтримувати кращі механізми ізоляції.

### Увімкнення небезпечних Sysctl {#enabling-unsafe-sysctls}

Всі _безпечні_ sysctl є типово увімкненими.

Всі _небезпечні_ sysctl типово вимкнені та повинні бути дозволені вручну адміністратором кластера на кожному вузлі окремо. Podʼи з вимкненими небезпечними sysctl будуть заплановані, але їх не вдасться запустити.

З врахуванням попередження вище, адміністратор кластера може дозволити певні _небезпечні_ sysctl для дуже спеціальних ситуацій, таких як налаштування високопродуктивних або застосунків реального часу. _Небезпечні_ sysctl вмикаються на основі вузла з прапорцем kubelet; наприклад:

```shell
kubelet --allowed-unsafe-sysctls \
  'kernel.msg*,net.core.somaxconn' ...
```

Для <a class='glossary-tooltip' title='Інструмент для локального запуску Kubernetes.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/tasks/tools/#minikube' target='_blank' aria-label='Minikube'>Minikube</a>, це можна зробити за допомогою прапорця `extra-config`:

```shell
minikube start --extra-config="kubelet.allowed-unsafe-sysctls=kernel.msg*,net.core.somaxconn"...
```

Таким чином можна увімкнути лише _просторово розмежовані_ sysctl.

## Налаштування Sysctl для Podʼа {#setting-sysctls-for-a-pod}

Численні sysctl _просторово розмежовані_ в сучасних ядрах Linux. Це означає, що їх можна налаштовувати незалежно для кожного Pod на вузлі. Лише _просторово розмежовані_ sysctl можна налаштовувати через securityContext Podʼа в межах Kubernetes.

Відомо, що наступні sysctl мають просторове розмежування. Цей список може змінитися в майбутніх версіях ядра Linux.

- `kernel.shm*`
- `kernel.msg*`
- `kernel.sem`
- `fs.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.

<div class="alert alert-danger" role="note"><h4 class="alert-heading">Попередження:</h4>Змінюйте параметри sysctl лише після розуміння їхніх наслідків, щоб уникнути дестабілізації вашої операційної системи.</div>


```yaml
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"
  ...
```

<!-- discussion -->

<div class="alert alert-danger" role="note"><h4 class="alert-heading">Попередження:</h4>Через їхню природу бути <em>небезпечними</em>, використання <em>небезпечних</em> sysctl здійснюється на ваш власний ризик і може призвести до серйозних проблем, таких як неправильна поведінка контейнерів, нестача ресурсів або повний розлад вузла.</div>


Хорошою практикою є вважати вузли з особливими налаштуваннями sysctl як позначені _taint_ в межах кластера і планувати на них лише ті Podʼи, яким потрібні ці налаштування sysctl. Рекомендується використовувати функцію [_Заплямованість та Толерантність_ кластера Kubernetes](/docs/reference/generated/kubectl/kubectl-commands/#taint), щоб реалізувати це.

Pod з _небезпечними_ sysctl не вдасться запустити на будь-якому вузлі, на якому не були явно увімкнені ці два _небезпечні_ sysctl. Як і з _вузловими_ sysctl, рекомендується використовувати [функцію _Заплямованість та Толерантність_](/docs/reference/generated/kubectl/kubectl-commands/#taint) або
[заплямованість вузлів](/docs/concepts/scheduling-eviction/taint-and-toleration/) для планування цих Podʼів на відповідні вузли.