Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 <ul><li><a>1. Автообновление configmap</a></li>

2 <li><a>2. Квотирование ресурсов</a></li>

3 <li><a>3. Шедулим немспейсы на ноды!</a></li>

4 <li><a>4. Бесшовно обновляем кластер</a></li>

5 <li><a>5. Шедулинг v2.0</a></li>

6 </ul><p>Всем привет! Меня зовут Маша и я являюсь ментором и преподавателем на курсе<a>"Инфраструктурная платформа на основе Kubernetes"</a>. Задачей курса стоит не просто знакомство с Kubernetes как с системой для оркестрации, но также и построение экосистемы вокруг него. Начиная от выбора райнтайма для контейнера и заканчивая тем, как можно протестировать нашу систему на прочность - так называемый Chaos Engineering. Так как в Kubernetes достаточно много неочевидных и порой даже скрытых возможностей, я хотела бы познакомить с моим личным топ-5 интересных фич.</p>

7 <h3>1. Автообновление configmap</h3>

8 <p>Если кто-то из вас уже встречался с Kubernetes, то вы наверняка знаете о таком объекте, как конфигмап (Configmap). На самом деле цель его достаточно простая - хранение конфигурации. Неважно, отдельные это<a>переменные</a>или целые файлы. Для Kubernetes конфигмап может обновляться независимо от приложения, использующего его, при этом, приложению в большинстве случаев важно получить самую последнюю версию конфигурации. Автоматическое обновление конфигмап возможно получить только в двух случаях: </p>

9 <ul><li>Приложение умеет ходить в Kubernetes API и постоянно отслеживать изменения и забирать свежую конфигурацию</li>

10 <li>Вы смонтировали конфигмап как<a>вольюм</a>и тогда за автообновление будет отвечать kubelet. Минус этого способа - задержка между обновлениями может быть критична и она определяется несколькими параметрами (подробнее по ссылке выше).</li>

11 </ul><p>Но все не так плохо! Если вы используете helm для шаблонизации и деплоя ваших приложений, то можете воспользоваться воркэраундом из<a>best-practice</a>. Добавление аннотации, которая вычисляет чексумму указанных файлов приведет к обновлению деплоймента. Ну а если хелм не ваш выбор, то можно попробовать<a>Reloader</a>, который позволяет более гибко управлять обновлением секретов и конфигмап и их зависимостью от объектов с приложением - Deployment, ReplicaSet и тд.</p>

12 <h3>2. Квотирование ресурсов</h3>

13 <p>Администрирование Kubernetes само по себе не самая тривиальная задача, особенно, если кластер разрастается и им пользуется большое количество различных команд. Для того, чтобы контролировать потребление ресурсов, есть два объекта:<a>ResourceQuota</a>и<a>LimitRange</a>.Используя ResourceQuota мы можем ограничить суммарное количество ресурсов, которое могут запросить все объекты в немспейсе (изолированное виртуальное окружение в рамках кластера. Это может выглядеть так:</p>

14 hard: cpu: "10" memory: 20Gi pods: "10"<p>Здесь мы ограничиваем количество CPU, памяти и объектов типа Pod на немспейс. ResourceQuota поддерживает селекторы, поэтому мы можем гибко настроить политику для работы с различными типа приложений, например по их важности.</p>

15 <p>LimitRange помогает отслеживать выставление значений реквестов/лимитов по ресурсам для всех подов в немспейсе. </p>

16 limits: - default: cpu: 1 defaultRequest: cpu: 0.5 type: Container<p>В примере мы задаем значение реквест/лимит по CPU по умолчанию для всех контейнеров в немспейсе.</p>

17 <h3>3. Шедулим немспейсы на ноды!</h3>

18 <p>Как я уже упоминала, немспейс - это виртуальное окружение, которое есть только в виде ключа в ETCD (key-value база данных для Kubernetes) и определяет принадлежность объекта к тому или иному окружению. Но если мы хотим поды из некоторых немспейсов зашедулить на конкретный пул нод (например, чтобы изолировать нагрузку), возникают проблемы. Если мы используем nodeSelector / affinity / anti-affinity / tolerations - все это добавляет большое количество неудобств с точки зрения шаблонизации и поддержки конфигурации. Так как для всех этих опций нужна дополнительная конфигурация в манифесте Deployment / ReplicaSet и т.д.Но если покопаться в документации Kubernetes, можно найти фичу под названием <a>PodNodeSelector</a>, которая позволяет отметить немспейс доступным для шедулинга только на ноды с определенным лейблом. </p>

19 <h3>4. Бесшовно обновляем кластер</h3>

20 <p>Процесс обновления кластера Kubernetes включает несколько этапов. И этапом 0 я бы поставила выставление<a>PodDistruptionBudget</a>на все объекты<a>в кластере</a>.Зачем это нужно? Все просто - в процессе обновления кластера вам необходимо очистить ноду от находящихся на ней подах. Для того, чтобы быть уверенным, что вы не удаляете сразу 2 из 2 реплики вашего приложения, можно сконфигурировать PodDistruptionBudget и тогда уже Kubernetes будет отслеживать этот момент в процессе дрейнинга (очищения) ноды.Есть несколько вариантов<a>конфигурирования</a>- исходя из минимального количества доступых подов или из максимального количества недоступных подов. Примеры:</p>

21 minAvailable: 2 selector: matchLabels: app: zookeeper maxUnavailable: 1 selector: matchLabels: app: zookeeper<h3>5. Шедулинг v2.0</h3>

22 <p>Про шедулинг можно говорить очень долго, да и возможностей для различных сценариев в Kubernetes уже предостаточно. Помимо простых возможностей по деплою подов только на разрешенные ноды, мы можем создавать так называемые топологии. Например, размазывать наши поды по AZ (availability-zones) или по дацацентрам или запретить размещать некоторые приложения на одних нодах. Со всем этим нам поможет affinity / anti-affinity.Вот как это может выглядеть:</p>

23 affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - store topologyKey: "kubernetes.io/hostname"<p>В этом примере мы хотим, чтобы поды с нашим стораджем располагались обязательно (requiredDuringSchedulingIgnoredDuringExecution) на разных нодах(topologyKey).</p>

24 <p>По теме шедулинга рекомендую к ознакомлению официальную<a>документацию</a>.</p>