«Меняем коней на переправе»: опыт замены компонентов Kubernetes на работающем кластере

Fix by MacRebisz

Привет, я Андрей Квапил, Solution Architect в компании «Флант». Моя специализация — архитектурные решения на базе Kubernetes, в том числе на bare metal, а также разработка и эксплуатация облачных платформ и software-defined storage. 

В Kubernetes часто можно столкнуться с ограничениями, immutable-полями и прочими особенностями. Я хочу показать, что при необходимости такие ограничения можно обходить, а также познакомить вас с паттерном controller и наглядно продемонстрировать работу CNI-, CSI- и CRI-плагинов.

Статья написана на основе моего выступления на VK Kubernetes Conference, вы можете посмотреть его в записи. 

Начнем с базы: составляющие Kubernetes и принципы его работы

Kubernetes — расширяемая платформа для управления контейнеризированными рабочими нагрузками и сервисами, которая облегчает декларативную настройку и автоматизацию. 


Компоненты Kubernetes 

Kubernetes построен на микросервисной архитектуре, в которой каждый компонент играет отдельную роль. Разберем подробнее его устройство.

Kubernetes API — сердце нашего кластера, он состоит из двух компонентов:

• kube-apiserver — главный компонент, в котором хранятся все ресурсы;
  
• etcd — key-value-база данных, в которой kube-apiserver хранит информацию и состояние созданных ресурсов.
  

Еще в Kubernetes есть контроллеры, которые взаимодействуют с API:

• kube-scheduler — основной шедулер ресурсов;
  
• kube-controller-manager — контроллер, который обслуживает логику для всех стандартных ресурсов кластера;
  
• kubelet — работает на каждой ноде и  запускает контейнеры.
  

Разумеется, контроллеров может быть и больше. По сути, любой компонент, который подписывается и следит за изменениями ресурсов в Kubernetes API, называют контроллером.

Контроллеры взаимодействуют с ресурсами Kubernetes, причем с одним типом ресурсов могут работать сразу несколько контроллеров. Вы можете посмотреть, как выглядит их работа, подписавшись на изменения соответствующих типов ресурсов:

$ kubectl get pod -w

Эта команда поддерживает также настройки формата -o json или -o yaml. Так что вы можете увидеть, как изменился весь ресурс целиком, или только факт его обновления в API. В выводе мы видим каждую итерацию объектов кластера — это и есть так называемый reconciliation loop.

Например, так выглядит процесс создания и запуска пода на ноде, где два разных контроллера (kubelet и scheduler) работают с одним и тем же ресурсом (Pod), попутно обновляя и добавляя в него различные поля.



Также нужно понимать, что Kubernetes не решает все задачи самостоятельно, а частично делегирует их внешним компонентам. Например, управление сетью, провижининг томов, запуск контейнеров — всем этим занимаются внешние компоненты, которые в идеале должны быть взаимозаменяемыми.

Для этого в Kubernetes придумали и определили три стандартизированных интерфейса. Через них и осуществляется все взаимодействие с этими компонентами:

• CNI (Container Network Interface, контейнерный сетевой интерфейс);
  
• CSI (Container Storage Interface, интерфейс хранения контейнеров);
  
• CRI (Container Runtime Interface, интерфейс среды выполнения контейнеров).
  

В Kubernetes не предусмотрена прямая замена CNI-, CSI- и CRI-компонентов. Но при необходимости сделать это все-таки можно, если детально изучить работу ресурсов и ответственных за них контроллеров. 

Внимание. Все сказанное в этой статье отражает мой собственный опыт, его не стоит воспринимать как руководство к действию. Надеюсь, что описанные здесь трюки вам вообще никогда не пригодятся