Тим Гудвин, аспирант Калифорнийского университета в Санта-Крус, много размышлял о будущем Kubernetes. И он видит мир за пределами кластеров, где Kubernetes может быть универсальной плоскостью управления практически для чего угодно.
Это возможно благодаря волшебству контроллеров, построенных на среде выполнения контроллера Kubernetes. Возможность составлять контроллеры и объединять их вместе — это то, что дает Kubernetes большую мощь.
Однако контроллерами действительно сложно управлять и отлаживать. Поэтому Гудвин создал программное обеспечение для моделирования контроллеров под названием Kamera, которое предоставляет целевые инструменты для отслеживания поведения отдельных контроллеров и взаимодействия между ними с помощью моделирования и проверки моделей.
Kamera работает с реальным кодом контроллера, и для ее запуска не нужен кластер — более того, она отлично работает на ноутбуке разработчика.
Гудвин представил эту технологию на KubeCon + CloudNativeCon NA 2025 в начале этого месяца.
Kubernetes как универсальная плоскость управления
Kubernetes был создан как способ запуска контейнерных приложений в кластерах, и с тех пор он был расширен для управления другими ресурсами.
Базы данных, системы CI/CD, такие как Argo CD, внешние инфраструктурные платформы, такие как Crossplane, и, с недавних пор, системы машинного обучения (ML) — все это сегодня контролируется Kubernetes.
Kubernetes потенциально может стать «универсальной плоскостью управления всем, что мы захотим», сказал Гудвин. «Практически всем, что можно описать декларативно и постоянно согласовывать, мы можем управлять с помощью Kubernetes».
В Kubernetes пользователь описывает на декларативном языке желаемое состояние своей системы с точки зрения ресурсов. Именно контроллеры будут постоянно согласовывать фактическое состояние с желаемым через контур управления. Они отслеживают серию событий изменений, которые отправляются с сервера API, и отвечают необходимыми изменениями обратно на сервер.
Вы также можете написать контроллеры для запуска ресурсов, отличных от Kubernetes, с помощью пользовательского определения ресурса (CRD) для определения ресурса.
Контроллеры также можно объединять и управлять ими коллективно, открывая путь к еще невиданным платформам.
«Именно эта техника композиции позволяет нам поднять уровень абстракции», — сказал Гудвин.
Проблемы управления и отладки контроллеров
Контроллерами, однако, сложно управлять, особенно в больших количествах. Они попадают в состояние гонки. Они работают на основе устаревших данных и могут давать недетерминированные результаты, если они плохо написаны.
Что касается циклов управления, «бизнес-логика довольно проста, но есть много вещей, на которые нужно обратить внимание, чтобы эта бизнес-логика работала правильно в рамках цикла согласования», — сказал Гудвин.
Написание цикла управления может быть трудным. Первое условие может быть выполнено (т. е. создать StatefulSet), но тогда контроллер выйдет из строя до того, как будут инициализированы последующие состояния (загрузка автономного сервера), в результате чего контроллер получит ложный сигнал о том, что приложение запущено. Поэтому операции создания должны быть отдельными. (Гудвин)
По словам Гудвина, помимо отдельных контроллеров, их сборка в совокупности также принесет проблемы, поскольку разработчикам также необходимо учитывать составную логику нескольких контроллеров.
Обеспечение того, чтобы каждый отдельный контроллер работал по плану, не гарантирует, что при совместном запуске они не причинят какого-либо ущерба. Два контроллера, управляющие одним ресурсом, могут соперничать за контроль, вызывая состояние гонки.
«Когда что-то идет не так в этих взаимодействиях, отладка может стать огромной головной болью», — сказал он.
Подобные ошибки могут возникать при изменении кода, конфигурации или ресурсах. И эти состояния гонки могут случаться постоянно или только изредка, если вам действительно не повезло.
Сегодня существует мало инструментов, которые могли бы помочь. Во многих случаях лучшее, что может сделать разработчик, — это просмотреть файлы журналов контроллера и угадать состояние кластера в тот момент, когда что-то пошло не так.
«Поскольку подобные проблемы могут воспроизводиться в очень специфических и, возможно, мимолетных условиях, это еще больше усложняет наш общий процесс отладки, когда возникает проблема воспроизводимости», — сказал он.
Добро пожаловать в ад отладки распределенных программ.
Исследование пространства выполнения с помощью Kamera
Гудвин написал Kamera, чтобы помочь разработчику лучше понять состояние кластера.
«Для конкретного процесса сверки Kamera собирается показать все действия контролера, которые участвовали в этом процессе», — сказал он. «Поэтому, если есть какая-то проблема, мы можем точно понять, что происходит, чтобы ее создать».
В целях экономии времени Kamera моделирует кластер. Обычно контроллеры взаимодействуют с системой через API-сервер Kubernetes; Kamera имитирует сервер с помощью имитированного клиентского интерфейса API.
«Если у вас есть реализации контроллера во время выполнения, вы можете подключить их к этому инструменту без каких-либо дополнительных изменений кода», — сказал Гудвин.
Программное обеспечение, написанное на Golang, работает в одном потоке процессора и может быть запущено на ноутбуке. Кластер не нужен.
Для работы программное обеспечение представляет собой кластер (или, в более общем смысле, систему) и выполняет создание ReplicaStates — следуя за любыми другими вызываемыми контроллерами — и продолжает до тех пор, пока все состояния контроллера не сойдутся и не останется ожидающих согласований.
«Итак, это означает, что мы находимся в каком-то состоянии, где каждый контролер, заинтересованный в содержимом этого состояния, наблюдал за этим содержимым и решил, что в нем ничего не нужно менять», — объяснил он.
Если это работает, это означает, что логика вашей плоскости управления верна.
Распределенная отладка программ Blues
Если симуляция зациклилась, это означает, что что-то не так. Возможно, возникла проблема гонки или неидемпотентная операция, дающая каждый раз другой результат. Или, может быть, существует какая-то другая недетерминированная операция, которая постоянно переводит состояние в какое-то другое (предположительно) конвергентное состояние.
Если вы выполняете эти операции на реальном кластере, вы рискуете опрокинуть его с помощью серии действий, описанных для всех контроллеров. Хорошо, что это симуляция.
«Это действительно здорово, что мы можем создавать подобные сценарии в моделировании», — сказал Гудвин.
Моделирование пространства выполнения
Kamera может не только моделировать действия компонентов, но также моделировать все пространство выполнения, чтобы убедиться, что ни одна из упомянутых выше ошибок никогда не произойдет.
«Мы можем использовать нашу модель выполнения для всестороннего поиска всех возможных путей выполнения и проверки интересующих свойств, таких как стабильная сходимость», — сказал Гудвин.
Этот процесс, называемый проверкой модели, «тщательно исследует пространство всех возможных состояний, в которые может войти наша система, чтобы убедиться, что определенные свойства, которые нас интересуют, всегда сохраняются».
Каждый путь выполнения каждого контроллера тщательно тестируется, фактически создавая граф всех возможных состояний системы (на любой указанной вами глубине). Каждое полученное конвергентное пространство отслеживается и сравнивается. Каждое конвергентное состояние можно изучить с помощью шагового механизма действий, чтобы увидеть, какие пути выполнения были выбраны.
«Итак, это позволяет нам поэтапно выполнять каждую сверку и детально проверять, как развивается состояние кластера», — сказал он.
Чтобы протестировать камеру на реальном облачном программном обеспечении, Гудвин использовал это программное обеспечение, чтобы посмотреть, как различные сервисы в бессерверном программном обеспечении Knative согласовываются друг с другом. Неудивительно, что он нашел программу работоспособной.
Kamera использует другой подход, чем SimKube, который действует скорее как механизм воспроизведения действий, которые уже произошли в кластере.
Kamera имеет открытый исходный код, но Гудвин предупредил, что программное обеспечение «готово только для исследований» и ожидает дополнительных отзывов от сообщества Kubernetes.
Несмотря на все неровности, это программное обеспечение может стать очень удобным инструментом для устранения упорно неуловимых нарушений поведения в кластерах Kubernetes.
Или планирование систем управления Kubernetes, о которых раньше никогда не думали.
Посмотреть весь разговор можно здесь:
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Джоаб Джексон — старший редактор The New Stack, специализирующийся на облачных вычислениях и системных операциях. Он освещал вопросы ИТ-инфраструктуры и ее развития более 30 лет, в том числе работал в IDG и Government Computer News. До этого он… Подробнее от Джоава Джексона
