Цикл заметок о сетях в Kubernetes от Mark Betz переводился на хабре несколькими участниками. Поэтому в нормальный единый цикл заметки не объединены, но поиском по имени оригинального автора их можно найти. А можно воспользоваться этим списком:

• https://habr.com/ru/companies/ruvds/articles/441576/
• https://habr.com/ru/companies/southbridge/articles/346314/
• https://habr.com/ru/companies/ruvds/articles/442646/

По ходу прохождения курса (и во многом в попытках успеть за лектором) наработал сокращения для типовых операций с k8s, сильно убыстряющих всю эту вашу компьлюктерную магию с буковками на чорном фоне. В отличие от гита, сокращения для которого в неизменном виде повторяются в тысячах статей, для кубера такого общепринятого стандарта я не встретил. Пока непонятно почему, буду пользоваться, возможно что-то всплывёт.

alias kgn="kubectl get nodes -o wide"
alias ka="kubectl apply -f"
alias kd="kubectl delete -f"
alias kgp="kubectl get po -o wide -n"
alias kgpa="kubectl get po -A"
alias kgs="kubectl get svc -n"
alias kge="kubectl get ep -n"
alias kgi="kubectl get ing -o wide -n"
alias kns="kubectl run --generator=run-pod/v1 tmp-shell --rm -i --tty --image nicolaka/netshoot -- /bin/bash"

Закончил курс по Кubernetes от DataLine

• немножко научился в Докер — скачивать, модифицировать, запускать, заливать на свой репозиторий контейнеры, настраивать в докере сеть и постоянные хранилища
• немножко научился в k8s — узнал про архитектуру и компоненты, научился скачивать контейнеры и запускать их в систему с помощью разных контроллеров, пошуршал в системах управления доступом и управления ресурсами, разобрался с сетями (дико навороченная там штука) и постоянными хранилищами, узнал и пощупал руками логирование, мониторинг и пакетный менеджмент.

В целом технология и методология термоядерные, для продуктовых компаний например страшно полезные. Программно-определяемые сети вообще огонь. Впечатлен и заинтересован, буду разбираться дальше.

Чуть позже у DataLine должна пройти ещё одна часть курса, с глубоким погружением в практику, куда обещают взять лучших по итогам теста. Тест уже сдан вполне успешно, рассчитываю на приглашение.

Огромный плюс курса — предоставляемый преднастроенный кластер, где можно и входящую в состав занятий практику повыполнять, и глубже (дальше) в тему продвинуться. Преподаватели мастеровитые, практики, в теме разбираются, объясняют внятно, проведена большая подготовительная работа — от слайдов и презентаций до манифестов и готовых образов с нужным для занятий функционалом. И это всё ещё плюсом к тому — бесплатно.

Удобно, что лекции пишутся, и есть возможность после сесть и вдумчиво сделать практику — материал непростой, сразу вникнуть удавалось не всегда.

Курс ведут Станислав Миллер и Сергей Старицын (в его лекциях также активное участие принимают коты). Это был уже четвёртый поток, анонсы следующих (и занятий на другие темы) — в телеграм канале Даталайн, отчаянно рекомендую.

Прохожу очень полезный курс о Kubernetes от DataLine, долго вникал в тему управления ресурсами, вот краткий конспект словами, понятными мне. Возможно, пригодится и вам.

Знаменитый мем «Миграция контейнеров в облако»

Что вообще можно сделать для управления ресурсами

По умолчанию в k8s поды(контейнеры) могут потреблять столько ресурсов, сколько хотят (из физически доступных на ноде). Но можно активировать механизмы k8s, управляющие этим.

k8s здесь может действовать в двух ролях :

• во время работы системы k8s может следить за контейнерами (подами) и карать те, что потребляют ресурсов больше чем обещали максимально потреблять

• на запуске пода (контейнера) k8s может решать, запускать ли объект (и где именно его запускать), исходя из того сколько ресурсов он требует для работы в норме и сколько обещает потреблять в максимальном случае

Что для надо для управления ресурсами

• В правилах системы управления должны быть описаны принципы (политики), по которым системе эти требования и обещания контейнера проверяются на то, подходят они или нет k8s

• свойствах контейнера (пода) должны быть прописаны его потребности при работе в норме (requests), они же минимальные требования для старта. Также в свойствах контейнера (пода) должны быть прописаны его максимально допустимые аппетиты (limits): сколько он обещает пожирать в самом-самом плохом случае. Если контейнер не сообщает свои требования и обещания, но они нужны для работы политик — они будут назначены этими политиками принудительно сверху (сам виноват).

Не даем запущенному пожрать сверх договорённостей

Этот функционал реализуется на основе мониторинга процессов. Здесь необходимы значения максимально допустимых аппетитов (limits) объекта — они должны быть описаны в свойствах, либо должны быть заданы принудительно политиками Limit Ranges (про них чуть дальше).

Если контейнер (под) пережирает сверх обещанного, k8s может тротлить процессор (при нарушении лимитов CPU) или останавливать\перезапускать под, если идет перебор по памяти. Таким образом, гарантируется что контейнер будет во время работы есть от 0 до limits ресурсов процессора и памяти.

Не запускаем объекты, если нам это не подходит

Второй механизм управления работает в момент запуска объекта. В каждом namespace может быть использованы две политики, и при запуске пода(контейнера) будут проверяться его запросы (минимальные и максимальные), а также состояние системы после его запуска, на соответствие этим политикам. Если принято решение что в результате политика(и) не будет нарушена — старт разрешен. Далее соответствие политике не контролируется.

Политика Limit Range. Задает в namespace ограничения на запросы и лимиты подов(контейнеров). Если pod (контейнер) просит (requests) меньше, чем нижний лимит (min limits) политики, или обещает максимальное потребление (limits) больше, чем верхний лимит (max limits) политики — он запущен не будет. Здесь может возникнуть путаница из-за несогласованного использования термина limits, важно не запутаться.

Нюансы:

• Если под не сообщает свой лимит или запрос, они задаются принудительно значениями из политики по умолчанию (default [это шаблон для limits] и DefaultRequest [это шаблонное значение для requests]) — и в дальнейшем эти значения могут влиять на ограничения при работе pod, описанные ранее (с ними будет сравниваться его реальное потребление).

• Limit Range может быть задан для подов или контейнеров. В случае, если Limit Range задан на контейнеры, и хотя бы один контейнер в поде не подходит под значения политики, не стартанёт весь pod.

иллюстрация Limit Range от НИИ Быстрых Иллюстраций

• В отличие от мониторинга уже запущенных контейнеров, здесь принимается решение в том числе на базе минимально запрошенных требований (requests). Это дает k8s возможность распределять ресурсы равномерней а также не запускать объекты, которые уже точно не влазят в мощности инфраструктуры. Следует стараться задавать эти значения, чтобы не оказаться в ситуации когда контейнер запущен в среде с нехваткой ресурсов (не сказал сколько надо — получи минимальный минимум)

Политика Resource Quotas. Задает в namespace максимальный предел ресурсов, которые могут быть запрошены суммарно всеми подами или контейнерами этого namespace, на основании указанных в конфигурации подов(контейнеров) данных (важно, не фактически потребляемых, а именно запрашиваемых в манифесте). Политика не дает зарезервировать больше ресурсов или создать больше сущностей, чем админ готов потратить на все объекты namespace. Нюансы:

• для cpu и ram политика может задавать верхний предел для любых значений — и requests (что фактически значит «не позволить назапускать объектов которые захотят жрать все вместе как мимимум столько то»), и limits (что фактически значит «не позволить назапускать объектов, которые все вместе при фиговом раскладе в максимуме сожрут столько то»).

• также здесь могут быть заданы ограничения для суммарного количества других сущностей в namespace (секреты итп).

Ссылочки

Материалы по теме:
https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
https://kubernetes.io/docs/concepts/policy/

Канал DataLine в телеге (где бывают в том числе анонсы их учебных программ) — https://t.me/unidataline