Блог

Я пытаюсь использовать пользовательскую сеть CNI на EKS, чтобы убедиться, что IP-адреса Pod выделены из альтернативных подмножеств (чтобы предотвратить нехватку IP-адресов в подсетях, в которых работают узлы моего кластера). Для этого мне нужно создать некоторые ENIConfigs и аннотировать каждый узел.

Как я могу гарантировать, что каждый узел аннотируется до того, как для него будут запланированы какие-либо модули, чтобы гарантировать, что IP-адреса Pod не выделяются из подсетей, в которых работают мои узлы?

РЕДАКТИРОВАТЬ: единственное решение, которое я могу придумать на данный момент, это:

• Добавьте ошибку NoSchedule ко всем узлам по умолчанию
• Разверните пользовательский контроллер, который допускает заражение
• Попросите контроллер аннотировать все узлы по мере необходимости и удалить заражение

Однако, если вышеупомянутое является единственным обходным путем, который требует больших усилий для управляемой службы

Как насчет:

• Добавьте ENIConfigComplete: false заражение ко всем узлам по умолчанию
• Разверните DaemonSet, который допускает ENIConfigComplete: false
• DaemonSet создает модуль на каждом новом узле, который
• создает некоторые ENIConfigs на узле (скрипт bash ??)
• аннотирует каждый узел с ENIConfigComplete: true
• DaemonSet больше не поддерживает узел, поэтому
• Модуль удален с узла.

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

В Salesforce рассказывают об этом методе подготовки дисков на своих новых узлах:

• https://engineering.salesforce.com/provisioning-kubernetes-local-persistent-volumes-61a82d1d06b0

Это позволило бы избежать длительного процесса контроллера.