Kubernetes articles
В данной статье собираются полезные статьи по k8s с описанием.
Как Kubernetes создает и запускает контейнеры.
Здесь собрана информация о работе Container Manager (containerd), container runtime (runc). О том, что container manager скачивает и хранит имиджи, а runc создаёт на их основе контейнеры.
CRI - container runtime interface. CRI это общая модель создания container manager, который может запускаться под Kubernetes. Это программный интерфейс, написанный для protocol buffer и gRPC, разделенный на две части. Первая - ImageService, вторая - RuntimeService.
OCI - это open source организация, которая имеет "явную цель создания открытых отраслевых стандартов в отношении форматов контейнеров и runtime".
https://habr.com/ru/articles/657641/
Политика как код Kubernetes + Kyverno. (Slurm)
Здесь есть базовое описание Kyverno и пара примеров применения политик.
О работе kubectl exec.
Он создаёт процесс, который можно посмотреть через
ps aux. Можно посмотреть как идут запросы к апишке через ss -tulpn
Лучшие практики Kubernetes. Настройка запросов и лимитов ресурсов
Когда дело доходит до ограничений процессора, то он считается сжимаемым ресурсом. Если приложение начинает приближаться к лимиту процессорной мощности, Kubernetes начнет притормаживать контейнер, используя CPU Throttling — снижение частоты процессора. Это означает, что процессор будет искусственно ограничен, предоставляя приложению потенциально худшую производительность, однако процесс не будет прекращен или вынесен.
Ресурсы cpu определяются в милиядрах. Это части одного ядра процессора. Использовать больше одного ядра рекомендуется только в приложениях, работающих с БД и специально оптимизированным для работы с несколькими ядрами.
Если сделать запрос на количество ресурсов, превышающих их реальное наличие, то такой под не будет зашедулен и будет висеть в Pending.
Память - несжимаемый ресурс. Поэтому выполнение контейнера будет остановлено, как только он выйдет за пределы выделенной ему памяти.
По умолчанию контейнеры в кластере Kubernetes работают с неограниченными вычислительными ресурсами.
С помощью квот ресурсов администраторы кластера могут ограничить потребление ресурсов и их создание на основе пространства имен.
Однако существует опасение, что один под или контейнер может монополизировать все имеющиеся ресурсы. Для предотвращения такой ситуации используется предельный диапазон limit Range – политика ограничения распределения ресурсов (для подов или контейнеров) в пространстве имен.
LimitRange используется в том случае, если не установлены значения requests/limits на каждый контейнер. Но приоритет у установленных с его помощью значений меньше, чем если устанавливать их вручную на каждый контейнер.
В отличие от ResourceQuota, которая распространяется на все пространство имен, Limit Range используется для отдельных контейнеров. Это может предотвратить создание пользователями совсем крохотных или наоборот, гигантских контейнеров внутри пространства имен.
Давайте представим себе сценарий, в котором у вас имеется машина, исчерпавшая лимит памяти – как при этом поступит Kubernetes?
Kubernetes будет искать поды, которые используют больше ресурсов, чем запрашивали. Так что если у ваших контейнеров вообще нет запросов Requests, это означает, что по умолчанию они используют больше, чем просили, просто потому что они не просили вообще ничего! Такие контейнеры становятся главными кандидатами на отключение. Следующими кандидатами являются контейнеры, которые удовлетворили все свои запросы, но все еще находятся ниже максимального лимита.
Подробнее тут: https://habr.com/ru/companies/ua-hosting/articles/502614/
Статья kvaps о виртуальных сетях. Описаны технологии: VirtIO, VHost, vFIO, vDPA, vDUSE.
https://habr.com/ru/companies/flant/articles/751746/
Лучшие практики Kubernetes. Создание имиджей минимального размера.
https://habr.com/ru/companies/ua-hosting/articles/502052/