Довідкова інформація про вузли

• 1: Kubelet Checkpoint API
• 2: Вимоги до версії ядра Linux
• 3: Статті про видалення dockershim та використання сумісних з CRI середовищ виконання
• 4: Мітки вузлів, які заповнює kubelet
• 5: Локальні файли та шляхи, які використовує Kubelet
• 6: Версії API Kubelet Device Manager
• 7: Обʼєднання конфігураційних тек Kubelet
• 8: Kubelet Systemd Watchdog
• 9: Seccomp та Kubernetes
• 10: Стан вузла

1 - Kubelet Checkpoint API

Контрольна точка контейнера — це функціонал для створення копії контейнера зі станом запущеного контейнера. Після того, як у вас є копія контейнера з його станом, ви можете перенести його на інший компʼютер для налагодження або подібних цілей.

Якщо перемістити дані такої копії контейнера на компʼютер, здатний їх відновити, відновлений контейнер продовжить працювати точно з того самого місця, де він був зупинений. Також можна переглянути збережені дані, за умови, що є відповідні інструменти для цього.

Створення копії контейнера зі станом може мати наслідки для безпеки. Зазвичай така копія містить усі сторінки памʼяті всіх процесів у контейнері. Це означає, що все, що колись було в памʼяті, тепер доступне на локальному диску. Це включає всі приватні дані та можливі ключі, які використовувались для шифрування. Реалізації CRI повинні створювати архів копії зі збереженням стану таким чином, щоб до нього міг мати доступ лише користувач root. Важливо памʼятати, що якщо архів копії зі збереженням стану передається в іншу систему, усі сторінки памʼяті будуть доступні власнику архіву копії.

Операції

post створення копії зі збереженням стану вказаного контейнера

Дайте команду kubelet створити копію зі збереженням стану конкретного контейнера з вказаного Pod.

Для отримання додаткової інформації щодо керування доступом до інтерфейсу контролю kubelet дивіться довідку з автентифікації/авторизації kubelet.

Kubelet запитає контрольну точку у відповідного CRI. У запиті до контрольної точки kubelet вкаже імʼя архіву контрольної точки у вигляді checkpoint-<podFullName>-<containerName>-<timestamp>.tar, а також попросить зберігати архів контрольних точок у теці checkpoints в його кореневій теці (як визначено параметром --root-dir). Типово це буде /var/lib/kubelet/checkpoints.

Архів копії зі збереженням стану має формат tar і може бути переглянутий за допомогою реалізації tar. Вміст архіву залежить від реалізації CRI (інтерфейс запуску контейнерів на вузлі).

HTTP-запит

POST /checkpoint/{namespace}/{pod}/{container}

Параметри

• namespace (в шляху): string, обовʼязково

  Namespace

• pod (в шляху): string, обовʼязково

  Pod

• container (в шляху): string, обовʼязково

  Контейнер

• timeout (в запиті): integer

  Тайм-аут у секундах для очікування завершення створення копії зі збереженням стану. Якщо вказано нуль або тайм-аут не вказано, буде використане стандартне значення тайм-ауту для CRI. Час створення копії зі збереженням стану залежить безпосередньо від використаної памʼяті контейнера. Чим більше памʼяті використовує контейнер, тим більше часу потрібно для створення відповідної копії зі збереженням стану.

Відповідь

200: OK

401: Unauthorized

404: Not Found (якщо функціональні можливості ContainerCheckpoint відключено)

404: Not Found (якщо вказаний namespace, pod або container не може бути знайдено)

500: Internal Server Error (якщо реалізація CRI стикається з помилкою під час створення копії зі збереженням стану (див. повідомлення про помилку для деталей))

500: Internal Server Error (якщо реалізація CRI не реалізує API створення контейнера (див. повідомлення про помилку для деталей))

2 - Вимоги до версії ядра Linux

Багато функцій залежать від певних можливостей ядра і мають мінімальні вимоги до версії ядра. Однак покладатися лише на номери версій ядра може бути недостатньо для деяких операційних систем, оскільки підтримувачі дистрибутивів таких як RHEL, Ubuntu та SUSE часто зворотно переносять вибрані функції до старіших версій ядра (залишаючи старішу версію ядра).

Pod sysctls

У Linux системний виклик sysctl() налаштовує параметри ядра під час виконання. Є інструмент командного рядка з назвою sysctl, який можна використовувати для налаштування цих параметрів, і багато з них доступні через файлову систему proc.

Деякі sysctls доступні лише за наявності достатньо нової версії ядра.

Наступні sysctls мають мінімальні вимоги до версії ядра і підтримуються в безпечному наборі:

• 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_syncookies (з ізоляцією в просторі імен з ядра 4.6+);
• net.ipv4.tcp_rmem (з Kubernetes 1.32, потребує ядро 4.15+).
• net.ipv4.tcp_wmem (з Kubernetes 1.32, потребує ядро 4.15+).
• net.ipv4.vs.conn_reuse_mode (використовується в режимі проксі ipvs, потребує ядро 4.1+);

Режим проксі nftables в kube-proxy

Для Kubernetes 1.32, режим nftables у kube-proxy вимагає версії 1.0.1 або новішої версії інструменту командного рядка nft, а також ядра 5.13 або новішого.

Для тестування та розробки можна використовувати старіші ядра, аж до 5.4, якщо встановити опцію nftables.skipKernelVersionCheck у конфігурації kube-proxy. Але це не рекомендується в операційній діяльності, оскільки це може викликати проблеми з іншими користувачами nftables у системі.

Контрольні групи версії 2

Підтримка cgroup v1 у Kubernetes перебуває в режимі супроводу, починаючи з версії Kubernetes v1.31; рекомендовано використовувати cgroup v2. У Linux 5.8, файл системного рівня cpu.stat був доданий до кореневої cgroup для зручності.

У документації runc, ядра старіші за 5.2 не рекомендуються через відсутність підтримки freezer.

Інші вимоги до ядра

Деякі функції можуть залежати від нових можливостей ядра і мати конкретні вимоги до ядра:

1. Рекурсивне монтування в режимі тільки для читання: Реалізується шляхом застосування атрибута MOUNT_ATTR_RDONLY із прапором AT_RECURSIVE, використовуючи mount_setattr(2), доданий у ядрі Linux v5.12.
2. Підтримка простору імен користувачів в Pod вимагає мінімальної версії ядра 6.5+, згідно з KEP-127.
3. Для swap на рівні вузлів не підтримується tmpfs, встановлений як noswap, до версії ядра 6.3.

Довгострокова підтримка ядра Linux

Актуальні випуски ядра можна знайти на kernel.org.

Зазвичай існує кілька випусків ядра з довгостроковою підтримкою, які забезпечують зворотне перенесення виправлень для старіших версій ядра. До таких ядер застосовуються лише важливі виправлення помилок, і вони зазвичай виходять не дуже часто, особливо для старіших версій. Перегляньте список випусків на вебсайті ядра Linux в розділі Longterm.

Що далі

• Перегляньте sysctls для отримання додаткової інформації.
• Дозвольте запуск kube-proxy у режимі nftables.
• Дізнайтесь більше про cgroups v2.

3 - Статті про видалення dockershim та використання сумісних з CRI середовищ виконання

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

Проєкт Kubernetes

• Блог Kubernetes: Часті запитання щодо видалення Dockershim (оригінал опубліковано 2020/12/02)

• Блог Kubernetes: Оновлено: Часті запитання щодо видалення Dockershim (оновлення опубліковано 2022/02/17)

• Блог Kubernetes: Kubernetes переходить від Dockershim: Зобовʼязання та наступні кроки (опубліковано 2022/01/07)

• Блог Kubernetes: Видалення dockershim наближається. Чи готові ви? (опубліковано 2021/11/12)

• Документація Kubernetes: Міграція з dockershim

• Документація Kubernetes: Середовища виконання контейнерів

• Пропозиція щодо покращення Kubernetes: KEP-2221: Видалення dockershim з kubelet

• Проблема пропозиції щодо покращення Kubernetes: Видалення dockershim з kubelet (k/enhancements#2221)

Можна надати відгуки через тікет GitHub Відгуки та проблеми видалення Dockershim (k/kubernetes/#106917).

Зовнішні джерела

• Документація Amazon Web Services EKS: Amazon EKS закінчує підтримку Dockershim

• Відео конференції CNCF: Навчальні заняття з Kubernetes від Google — Міграція з Dockershim на Containerd (Ana Caylin, на KubeCon Europe 2019)

• Блог Docker.com: Що потрібно знати розробникам про Docker, Docker Engine і Kubernetes v1.20 (опубліковано 2020/12/04)

• Канал "Google Open Source" на YouTube: Вивчення Kubernetes з Google — Міграція з Dockershim на Containerd

• Блог Microsoft Apps on Azure: Завершення підтримки dockershim і AKS (опубліковано 2022/01/21)

• Блог Mirantis: Майбутнє Dockershim — cri-dockerd (опубліковано 2021/04/21)

• Mirantis: Mirantis/cri-dockerd Офіційна документація

• Tripwire: Як майбутнє видалення Dockershim впливає на ваш Kubernetes (опубліковано 2021/07/01)

4 - Мітки вузлів, які заповнює kubelet

Вузли Kubernetes мають попередньо встановлений набір міток.

Ви також можете встановлювати власні мітки на вузлах, як через конфігурацію kubelet, так і використовуючи API Kubernetes.

Попередньо встановлені мітки

Попередньо встановлені мітки, які Kubernetes встановлює на вузли:

• kubernetes.io/arch
• kubernetes.io/hostname
• kubernetes.io/os
• node.kubernetes.io/instance-type (якщо відомо kubelet, Kubernetes може не мати цієї інформації для встановлення мітки)
• topology.kubernetes.io/region (якщо відомо kubelet, Kubernetes може не мати цієї інформації для встановлення мітки)
• topology.kubernetes.io/zone (якщо відомо kubelet, Kubernetes може не мати цієї інформації для встановлення мітки)

Що далі

• Дивіться Відомі мітки, анотації та позначення для списку загальних міток.
• Дізнайтеся, як додати мітку на вузол.

5 - Локальні файли та шляхи, які використовує Kubelet

kubelet — це переважно процес без збереження стану, який працює на вузлі Kubernetes. У цьому документі описані файли, які kubelet читає та записує.

Зазвичай, kubelet використовує панель управління як джерело істини про те, що повинно запускатися на вузлі, і середовище виконання контейнерів для отримання поточного стану контейнерів. За наявності kubeconfig (конфігурації клієнта API), kubelet підключається до панелі управління; інакше вузол працює в автономному режимі.

На Linux-вузлах kubelet також читає cgroups та різні системні файли для збору метрик.

На Windows-вузлах kubelet збирає метрики іншим механізмом, що не спирається на шляхи.

Є також кілька інших файлів, які використовуються kubelet, і kubelet спілкується за допомогою локальних сокетів Unix-домену. Деякі з них — це сокети, на яких слухає kubelet, а інші — сокети, які kubelet виявляє та підключається до них як клієнт.

Конфігурація

Конфігураційні файли kubelet

Шлях до конфігураційного файлу kubelet можна налаштувати за допомогою командного аргументу --config. Kubelet також підтримує доповнювані конфігураційні файли для розширення налаштувань.

Сертифікати

Сертифікати та приватні ключі зазвичай розташовані в /var/lib/kubelet/pki, але цей шлях можна налаштувати за допомогою командного аргументу kubelet --cert-dir. Імена файлів сертифікатів також можна налаштувати.

Маніфести

Маніфести для статичних Podʼів зазвичай розташовані в /etc/kubernetes/manifests. Місце розташування можна налаштувати за допомогою опції конфігурації kubelet staticPodPath.

Налаштування юнітів systemd

Коли kubelet працює як юніт systemd, деякі налаштування kubelet можуть бути визначені в файлі налаштувань systemd. Зазвичай це включає:

• командні аргументи для запуску kubelet
• змінні середовища, що використовуються kubelet або для налаштування середовища golang

Стан

Файли контрольних точок для менеджерів ресурсів

Усі менеджери ресурсів зберігають відповідність між Podʼами та виділеними ресурсами у файлах стану. Ці файли розташовані в базовій теці kubelet, також відомій як root directory (але це не те саме, що /, коренева тека вузла). Ви можете налаштувати базову теку для kubelet за допомогою аргументу командного рядка --root-dir.

Назви файлів:

• memory_manager_state для менеджера пам’яті
• cpu_manager_state для менеджера процесорів
• dra_manager_state для DRA

Файл контрольної точки для менеджера пристроїв

Менеджер пристроїв створює контрольні точки в тій самій теці, що й сокет-файли: /var/lib/kubelet/device-plugins/. Назва файлу контрольної точки — kubelet_internal_checkpoint для менеджера пристроїв.

Збереження стану Podʼів

Якщо ваш кластер має вертикальне масштабування Podʼа на місці увімкнено (функціональна можливість з назвою InPlacePodVerticalScaling), тоді kubelet зберігає локальний запис про виділені Podʼу ресурси.

Імʼя файлу — pod_status_manager_state у базовій теці kubelet (/var/lib/kubelet стандартно в Linux; налаштовується за допомогою --root-dir).

Середовище виконання контейнерів

Kubelet спілкується з середовищем виконання контейнерів за допомогою сокета, налаштованого через такі параметри конфігурації:

• containerRuntimeEndpoint для операцій із середовищем виконання
• imageServiceEndpoint для операцій з управління образами

Фактичні значення цих точок доступу залежать від середовища виконання контейнерів, яке використовується.

Втулки пристроїв

Kubelet відкриває сокет за шляхом /var/lib/kubelet/device-plugins/kubelet.sock для різних втулків пристроїв, які реєструються.

Коли втулок пристрою реєструється, він надає шлях до свого сокета, щоб kubelet міг підʼєднатися.

Сокет втулка пристрою повинен знаходитися в теці device-plugins у базовій теці kubelet. На типовому Linux-вузлі це означає /var/lib/kubelet/device-plugins.

API ресурсів Podʼів

API ресурсів Podʼів буде доступний за шляхом /var/lib/kubelet/pod-resources.

DRA, CSI та втулки пристроїв

Kubelet шукає сокет-файли, створені втулками пристроїв, керованими через DRA, менеджер пристроїв або втулки зберігання, а потім намагається приєднатись до цих сокетів. Текою, у якій kubelet шукає, є plugins_registry у базовій теці kubelet, тобто на типовому Linux-вузлі це — /var/lib/kubelet/plugins_registry.

Зверніть увагу, що для втулків пристроїв є два альтернативні механізми реєстрації. Тільки один із них повинен використовуватися для певного втулка.

Типи втулків, які можуть розміщувати сокет-файли в цій теці:

• втулки CSI
• втулки DRA
• втулки менеджера пристроїв

(зазвичай /var/lib/kubelet/plugins_registry).

Профілі безпеки та конфігурація

Seccomp

Файли профілів seccomp, на які посилаються Podʼи, мають бути розміщені стандартно у /var/lib/kubelet/seccomp. Дивіться довідку Seccomp для деталей.

AppArmor

Kubelet не завантажує і не звертається до профілів AppArmor за специфічним для Kubernetes шляхом. Профілі AppArmor завантажуються через операційну систему вузла, а не посилаються за їх шляхом.

Блокування

Файл блокування для kubelet зазвичай знаходиться за адресою /var/run/kubelet.lock. Kubelet використовує цей файл для того, щоб два різні екземпляри kubelet не намагалися працювати у конфлікті одна одної. Ви можете налаштувати шлях до файлу блокування, використовуючи аргумент командного рядка kubelet --lock-file.

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

Що далі

• Дізнайтеся більше про аргументи командного рядка kubelet.
• Ознайомтеся з довідником з налаштування Kubelet (v1beta1).

6 - Версії API Kubelet Device Manager

Ця сторінка надає інформацію про сумісність між API втулків пристроїв Kubernetes та різними версіями самого Kubernetes.

Матриця сумісності

Позначення:

• ✓ Точно такі ж функції / обʼєкти API в обох, API втулка пристроїв та версії Kubernetes.
• + API втулка пристроїв має функції або обʼєкти API, яких може не бути в кластері Kubernetes, або через те, що API втулка пристроїв додало додаткові нові виклики API, або через те, що сервер видалив старий виклик API. Однак, все, що у них є спільного (більшість інших API), працюватиме. Зверніть увагу, що альфа-версії API можуть зникнути або значно змінитися між незначними релізами.
• - Кластер Kubernetes має функції, які не може використовувати API втулка пристроїв, або через те, що сервер додав додаткові виклики API, або через те, що API втулка пристроїв видалило старий виклик API. Однак, все, що у них є спільного (більшість API), працюватиме.

7 - Обʼєднання конфігураційних тек Kubelet

Коли використовується прапорець kubelet --config-dir для вказівки теки для конфігурації, існує певна специфічна поведінка для обʼєднання різних типів.

Ось кілька прикладів того, як різні типи даних поводяться під час обʼєднання конфігурації:

Поля структур

У YAML структурі є два типи полів структури: одиничні (або скалярні типи) та вбудовані (структури, що містять скалярні типи). Процес обʼєднання конфігурацій обробляє заміну одиничних та вбудованих полів структур для створення кінцевої конфігурації kubelet.

Наприклад, ви можете хотіти мати базову конфігурацію kubelet для всіх вузлів, але налаштувати поля address і authorization. Це можна зробити наступним чином:

Зміст основного файлу конфігурації kubelet:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
port: 20250
authorization:
  mode: Webhook
  webhook:
    cacheAuthorizedTTL: "5m"
    cacheUnauthorizedTTL: "30s"
serializeImagePulls: false
address: "192.168.0.1"

Зміст файлу у теці --config-dir:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authorization:
  mode: AlwaysAllow
  webhook:
    cacheAuthorizedTTL: "8m"
    cacheUnauthorizedTTL: "45s"
address: "192.168.0.8"

Кінцева конфігурація буде виглядати наступним чином:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
port: 20250
serializeImagePulls: false
authorization:
  mode: AlwaysAllow
  webhook:
    cacheAuthorizedTTL: "8m"
    cacheUnauthorizedTTL: "45s"
address: "192.168.0.8"

Списки

Ви можете замінити значення списків конфігурації kubelet. Однак весь список буде замінений під час процесу обʼєднання. Наприклад, ви можете замінити список clusterDNS наступним чином:

Зміст основного файлу конфігурації kubelet:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
port: 20250
serializeImagePulls: false
clusterDNS:
  - "192.168.0.9"
  - "192.168.0.8"

Зміст файлу у теці --config-dir:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
clusterDNS:
  - "192.168.0.2"
  - "192.168.0.3"
  - "192.168.0.5"

Кінцева конфігурація буде виглядати наступним чином:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
port: 20250
serializeImagePulls: false
clusterDNS:
  - "192.168.0.2"
  - "192.168.0.3"
  - "192.168.0.5"

Map, включаючи вкладені структури

Індивідуальні поля в map, незалежно від їх типів значень (булеві, рядкові тощо), можуть бути вибірково замінені. Однак для map[string][]string весь список, повʼязаний з певним полем, буде замінений. Розглянемо це детальніше на прикладі, зокрема для таких полів, як featureGates і staticPodURLHeader:

Зміст основного файлу конфігурації kubelet:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
port: 20250
serializeImagePulls: false
featureGates:
  AllAlpha: false
  MemoryQoS: true
staticPodURLHeader:
  kubelet-api-support:
  - "Authorization: 234APSDFA"
  - "X-Custom-Header: 123"
  custom-static-pod:
  - "Authorization: 223EWRWER"
  - "X-Custom-Header: 456"

Зміст файлу у теці --config-dir:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  MemoryQoS: false
  KubeletTracing: true
  DynamicResourceAllocation: true
staticPodURLHeader:
  custom-static-pod:
  - "Authorization: 223EWRWER"
  - "X-Custom-Header: 345"

Кінцева конфігурація буде виглядати наступним чином:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
port: 20250
serializeImagePulls: false
featureGates:
  AllAlpha: false
  MemoryQoS: false
  KubeletTracing: true
  DynamicResourceAllocation: true
staticPodURLHeader:
  kubelet-api-support:
  - "Authorization: 234APSDFA"
  - "X-Custom-Header: 123"
  custom-static-pod:
  - "Authorization: 223EWRWER"
  - "X-Custom-Header: 345"

8 - Kubelet Systemd Watchdog

На вузлах Linux, Kubernetes 1.32 підтримує інтеграцію з systemd, щоб дозволити супервізору операційної системи відновити несправний kubelet. Стандартно цю інтеграцію не увімкнено. Її можна використовувати як альтернативу періодичним запитам до точки доступу kubelet /healthz для перевірки працездатності. Якщо протягом тайм-ауту kubelet не відповість на запит сторожового таймера, сторожовий таймер вбʼє kubelet.

Сторожовий таймер systemd працює, вимагаючи від сервісу періодично надсилати сигнал keep-alive процесу systemd. Якщо сигнал не отримано протягом визначеного тайм-ауту, служба вважається такою, що не реагує, і припиняє свою роботу. Після цього службу можна перезапустити відповідно до конфігурації.

Конфігурація

Використання сторожового таймера systemd вимагає налаштування параметра WatchdogSec у розділі [Service] файлу сервісного блоку kubelet:

[Service]
WatchdogSec=30s

Встановлення WatchdogSec=30s вказує на тайм-аут службового сторожового тайм-ауту у 30 секунд. Усередині kubelet функція d_notify() викликається з інтервалом WatchdogSec ÷ 2, щоб відправити WATCHDOG=1 (повідомлення про те, що він живий). Якщо сторожовий таймер не буде запущено протягом тайм-ауту, kubelet буде вбито. Встановлення Restart у значення "always", "on-failure", "on-watchdog" або "on-abnormal" забезпечить автоматичний перезапуск сервісу.

Дещо про конфігурацію systemd:

1. Якщо ви встановите значення systemd для параметра WatchdogSec рівним 0 або не встановите його, сторожовий таймер systemd буде вимкнено для цього пристрою.
2. Kubelet підтримує мінімальний період роботи сторожового таймера 1.0 секунди; це необхідно для запобігання несподіваного завершення роботи kubelet. Ви можете встановити значення WatchdogSec у визначенні системного блоку на період, менший за 1 секунду, але Kubernetes не підтримує коротший інтервал. Тайм-аут не обовʼязково має бути цілим числом секунд.
3. Проєкт Kubernetes пропонує встановити WatchdogSec на період приблизно 15 с. Періоди довші за 10 хвилин підтримуються, але явно не рекомендуються.

Приклад конфігурації

[Unit]
Description=kubelet: The Kubernetes Node Agent
Documentation=https://kubernetes.io/docs/home/
Wants=network-online.target
After=network-online.target

[Service]
ExecStart=/usr/bin/kubelet
# Налаштування таймауту watchdog
WatchdogSec=30s
Restart=on-failure
StartLimitInterval=0
RestartSec=10

[Install]
WantedBy=multi-user.target

Що далі

Більш детальну інформацію про конфігурацію systemd можна знайти у документації до systemd.

9 - Seccomp та Kubernetes

Seccomp (secure computing mode) — це функція ядра Linux, яка існує з версії 2.6.12. Її можна використовувати для обмеження привілеїв процесу шляхом ізоляції, обмежуючи системні виклики, які він може здійснювати з простору користувача в ядро. Kubernetes дозволяє автоматично застосовувати профілі seccomp, завантажені на вузол, до ваших Podʼів і контейнерів.

Поля Seccomp

Існує чотири способи вказати профіль seccomp для Podʼа:

• для всього Podʼа, використовуючи spec.securityContext.seccompProfile
• для окремого контейнера, використовуючи spec.containers[*].securityContext.seccompProfile
• для (перезапускного / sidecar) init-контейнера, використовуючи spec.initContainers[*].securityContext.seccompProfile
• для ефемерного контейнера, використовуючи spec.ephemeralContainers[*].securityContext.seccompProfile

pods/security/seccomp/fields.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod
spec:
  securityContext:
    seccompProfile:
      type: Unconfined
  ephemeralContainers:
  - name: ephemeral-container
    image: debian
    securityContext:
      seccompProfile:
        type: RuntimeDefault
  initContainers:
  - name: init-container
    image: debian
    securityContext:
      seccompProfile:
        type: RuntimeDefault
  containers:
  - name: container
    image: docker.io/library/debian:stable
    securityContext:
      seccompProfile:
        type: Localhost
        localhostProfile: my-profile.json

Pod у прикладі вище працює як Unconfined, тоді як ephemeral-container та init-container конкретно визначають RuntimeDefault. Якби ефемерний або init-контейнер не встановили явно поле securityContext.seccompProfile, тоді значення успадковується від Pod. Це ж стосується і контейнера, який використовує локальний профіль my-profile.json.

Загалом, поля контейнерів (включаючи ефемерні) мають вищий пріоритет, ніж значення на рівні Pod, а контейнери, які не задають поле seccomp, успадковують профіль від Pod.

Наступні значення можливі для поля seccompProfile.type:

Unconfined

Навантаження працює без будь-яких обмежень seccomp.

RuntimeDefault

Застосовується стандартний профіль seccomp, визначений середовищем виконання контейнерів. Стандартні профілі прагнуть забезпечити надійний набір параметрів безпеки, зберігаючи функціональність навантаження. Можливо, що стандартні профілі відрізняються між різними середовищами виконання контейнерів та їх версіями, наприклад, порівнюючи профілі CRI-O та containerd.

Localhost

Застосовується localhostProfile, який має бути доступний на диску вузла (у Linux це /var/lib/kubelet/seccomp). Доступність профілю seccomp перевіряється середовищем виконання контейнерів під час створення контейнера. Якщо профіль не існує, то створення контейнера завершиться з помилкою CreateContainerError.

Профілі Localhost

Профілі Seccomp — це JSON-файли, що відповідають схемі, визначеній специфікацією середовища виконання OCI. Профіль, як правило, визначає дії на основі відповідних системних викликів, але також дозволяє передавати конкретні значення як аргументи до системних викликів. Наприклад:

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "defaultErrnoRet": 38,
  "syscalls": [
    {
      "names": [
        "adjtimex",
        "alarm",
        "bind",
        "waitid",
        "waitpid",
        "write",
        "writev"
      ],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

defaultAction у профілі вище визначено як SCMP_ACT_ERRNO і буде повернуто як резервне для дій, визначених у syscalls. Помилка визначена як код 38 через поле 'defaultErrnoRet'.

Наступні дії зазвичай можливі:

SCMP_ACT_ERRNO

Повернення вказаного коду помилки.

SCMP_ACT_ALLOW

Дозвіл на виконання системного виклику.

SCMP_ACT_KILL_PROCESS

Завершення процесу.

SCMP_ACT_KILL_THREAD і SCMP_ACT_KILL

Завершення тільки потоку.

SCMP_ACT_TRAP

Генерація сигналу SIGSYS.

SCMP_ACT_NOTIFY і SECCOMP_RET_USER_NOTIF

Сповіщення простору користувача.

SCMP_ACT_TRACE

Сповіщення процесу трасування з вказаним значенням.

SCMP_ACT_LOG

Дозвіл на виконання системного виклику після того, як дія була зареєстрована в syslog або auditd.

Деякі дії, такі як SCMP_ACT_NOTIFY або SECCOMP_RET_USER_NOTIF, можуть бути не підтримувані залежно від середовища виконання контейнера, середовища виконання OCI або версії ядра Linux. Можуть бути також додаткові обмеження, наприклад, що SCMP_ACT_NOTIFY не може використовуватися як defaultAction або для певних системних викликів, таких як write. Усі ці обмеження визначаються або середовищем виконання OCI (runc, crun) або libseccomp.

Масив JSON syscalls містить список об’єктів, що посилаються на системні виклики за їхніми відповідними names. Наприклад, дія SCMP_ACT_ALLOW може бути використана для створення білого списку дозволених системних викликів, як показано у прикладі вище. Також можна визначити інший список, використовуючи дію SCMP_ACT_ERRNO, але з іншим значенням повернення (errnoRet).

Також можливо вказати аргументи (args), що передаються до певних системних викликів. Більше інформації про ці розширені випадки використання можна знайти в специфікації середовища виконання OCI та документації ядра Linux щодо Seccomp.

Додаткове читання

• Обмеження системних викликів контейнера за допомогою seccomp
• Стандарти безпеки Pod

10 - Стан вузла

Стан вузла у Kubernetes є критичним аспектом управління кластером Kubernetes. У цій статті ми розглянемо основи моніторингу та підтримки стану вузлів, щоб забезпечити справний та стабільний кластер.

Поля стану вузла

Стан вузла містить наступну інформацію:

• Адреси
• Стани
• Місткість та Доступність
• Інформація

Ви можете використовувати команду kubectl для перегляду стану вузла та інших деталей:

kubectl describe node <insert-node-name-here>

Кожен розділ вихідних даних описано нижче.

Адреси

Використання цих полів варіюється залежно від вашого постачальника хмарних послуг або конфігурації на голому залізі.

• HostName: Імʼя хосту, яке повідомляється ядром вузла. Може бути перевизначене за допомогою параметра kubelet --hostname-override.
• ExternalIP: Як правило, це IP-адреса вузла, яка доступна ззовні кластера.
• InternalIP: Як правило, це IP-адреса вузла, яка доступна лише всередині кластера.

Стани

Поле conditions описує стан усіх Running вузлів. Прикладами умов є:

В API Kubernetes стан вузла представлений як частина .status ресурсу Node. Наприклад, наступна структура JSON описує справний вузол:

"conditions": [
  {
    "type": "Ready",
    "status": "True",
    "reason": "KubeletReady",
    "message": "kubelet is posting ready status",
    "lastHeartbeatTime": "2019-06-05T18:38:35Z",
    "lastTransitionTime": "2019-06-05T11:41:27Z"
  }
]

Коли на вузлах виникають проблеми, панель управління Kubernetes автоматично створює taints, які відповідають станам, що впливають на вузол. Прикладом цього є ситуація, коли status стану Ready залишається Unknown або False довше, ніж налаштований інтервал NodeMonitorGracePeriod у kube-controller-manager, який стандартно становить 50 секунд. Це спричинить додавання на вузол taint node.kubernetes.io/unreachable для статусу Unknown або taint node.kubernetes.io/not-ready для статусу False.

Ці taints впливають на Podʼи, що перебувають в очікуванні, оскільки планувальник враховує taints вузла при призначенні Podʼів на вузол. Наявні Podʼи, заплановані на вузол, можуть бути виселені через застосування taints типу NoExecute. Podʼи також можуть мати tolerations, що дозволяє їм бути запланованими та продовжувати працювати на вузлі, навіть якщо на ньому є певний taint.

Дивіться Виселення на основі taint та Taint вузлів за станами для отримання додаткової інформації.

Місткість та Доступність

Описує ресурси, доступні на вузлі: процесор, памʼять та максимальну кількість Podʼів, які можуть бути заплановані на вузлі.

Поля у блоці місткості вказують на загальну кількість ресурсів, які має вузол. Блок доступності вказує на кількість ресурсів на вузлі, які доступні для використання звичайними подами.

Ви можете дізнатися більше про місткість та доступність ресурсів, дізнаючись, як зарезервувати обчислювальні ресурси на вузлі.

Інформація

Описує загальну інформацію про вузол, таку як версія ядра, версія Kubernetes (kubelet і kube-proxy), деталі контейнерного середовища та яка операційна система використовується на вузлі. Kubelet збирає цю інформацію з вузла та публікує її в API Kubernetes.

Пульс

Пульс, що надсилається вузлами Kubernetes, допомагають вашому кластеру визначити доступність кожного вузла та вжити заходів у разі виявлення збоїв.

Для вузлів існує дві форми пульсу:

• оновлення .status вузла
• обʼєкти Lease у просторі імен kube-node-lease. Кожен вузол має повʼязаний обʼєкт Lease.

Порівняно з оновленнями .status вузла, Lease є легким ресурсом. Використання Lease для пульсу знижує вплив цих оновлень на продуктивність для великих кластерів.

Kubelet відповідає за створення та оновлення .status вузлів, а також за оновлення їх повʼязаних Lease.

• Kubelet оновлює .status вузла або коли стан змінюється, або якщо не було оновлень протягом налаштованого інтервалу. Стандартний інтервал для оновлень .status вузлів становить 5 хвилин, що значно довше, ніж типових 40 секунд для вузлів, що стали недоступними.
• Kubelet створює та оновлює свій обʼєкт Lease кожні 10 секунд (стандартний інтервал оновлення). Оновлення Lease відбуваються незалежно від оновлень .status вузла. Якщо оновлення Lease не вдається, Kubelet повторює спробу, використовуючи експоненціальне збільшення інтервалу з початкового 200 мілісекунд до максимально 7 секунд.