Команды платформы стремятся создать «Золотые пути» для инженеров и продвигать общие стандарты по всей организации с эффективными внутренними платформами разработчиков (ВПЛ). Тем не менее, эти усилия часто противоречат ускорению инноваций. Строители платформы должны учитывать, как реализовать последовательность, не жертвуя разработчикам автономии, чтобы раздвигать границы и предоставлять действительно инновационные решения.
В контексте развития Kubernetes-коренного развития напряженность между общими стандартами и свободой разработчика часто сводится к архитектурным решениям, которые команды платформы принимают при определении того, как работают рабочие нагрузки их команд на Kubernetes. Инженеры платформы должны рассмотреть архитектуру мультилента Kubernetes с виртуальными кластерами для сохранения автономии при соблюдении стандартов. Для этого они должны смотреть за пределы типичных решений платформы «строительные блоки», которые устраняют необходимость выбора между настройкой и стандартизацией.
Почему инженерные цели платформы терпят неудачу с Kubernetes
В настоящее время организации используют два подхода к согласованности и соблюдению автономии и инноваций. Первая-это единоличная архитектура, в которой администраторы создают много кластеров-по одному на команду, на каждого клиента и так далее. Часто компании имеют сотни или даже тысячи кластеров. Каждый кластер добавляет значительную стоимость и требует непрерывного обслуживания; Сам кластер Kubernetes не является функциональным без нескольких инструментов и услуг, работающих на нем. Во многих случаях этот стек платформы больше и дороже, чем рабочая нагрузка, которая запускается им! Хуже того, эти кластеры обычно работают, даже когда никто не использует их, например, по выходным.
Команды выбирают этот маршрут с однородом, чтобы сохранить автономию разработчика и повысить безопасность, разделяя каждую рабочую нагрузку на свой специальный кластер. По иронии судьбы, это очень дорого и не обеспечивает желаемую автономию. Центральная ИТ -команда обычно сохраняет полный контроль над стеком платформ в каждом кластере. Таким образом, несмотря на передачу целого кластера, разработчик или команда, получившая его, вероятно, не будет администратором. RBAC по -прежнему ограничит их и будет иметь доступ только к конкретным пространствам имен.
Другим распространенным методом является принятие многопользовательства Kubernetes, которое может снизить затраты и оптимизировать операции с помощью общих кластеров. Многопользовательство привлекательно, потому что она устраняет дублирование дорогостоящих стеков платформ, что делает сохранение автономии очень сложной. Как правило, администраторы в многопользовательском сценарии дают разработчикам доступ к отдельным пространствам имен в кластере Kubernetes. Поскольку у них больше нет кластера, и они ограничены пространством имен, команды сталкиваются с серьезными препятствиями для самообслуживания и производительности. Например, если один арендатор-это внутренняя команда предварительного производства, которая хочет установить ArgoCD, чтобы проверить его для своего нового рабочего процесса доставки, они не могут, потому что ArgoCD требует, чтобы они установили CRD. Они должны вернуться к кластерному администратору и попросить его установить argocd, но что, если уже есть другая версия ArgoCD?
Команды платформы нуждаются в компромисс между отдельными отдельными кластерами и изоляцией пространства имен. В 2021 году мы изучили эту проблему и разработали решение: виртуализация Kubernetes, чтобы дать строителям платформы мощный «строительный блок» для пользовательских ВПЛ.
Успех инженерии платформы с виртуальными кластерами
Поскольку мы искали решение для множества, нашим первым прорывом было понимание, что Kubernetes почти как хост Linux. У Kubernetes есть пользователи, разрешения, RBAC и пространства имен, как и у хоста Linux, есть пользователи, папки и разрешения, но обмен хостом Linux сложно без виртуализации. Что если мы добавим виртуализацию в Kubernetes? Помимо узлов и контейнеров, что, если мы виртуализируем саму плоскость управления? Это когда мы изобрели виртуальные кластеры, которые по существу помещали плоскость управления в контейнер, внутри пространства имен другого кластера, и ИТ -команды могут раздать этот виртуальный кластер арендатору. Это означает, что kubeContext арендатора указывает на сервер API, работающий в контейнере, моделируя реальную кластер.
Арендатор обладает полной автономией и может служить кластерным администратором без отрицательного влияния на организационную последовательность и стандарты. Это связано с тем, что компоненты стека платформ — Manager Cert, ISTIO, агент OpenPolicy и т. Д. — работают в базовом кластере «хост», в то время как виртуальные кластеры запускаются в пространствах имен арендатора. Команды платформы могут поднять привилегии арендатора и разблокировать самообслуживание, фактически не поднимая свои привилегии в кластере хоста.
Таким образом, виртуальная кластерная многомерность играет ключевую роль в успехах в инженерии платформы, позволяя использовать многопользовательские изолированные кластеры. Это сочетает в себе стандартизацию и безопасность с максимальной автономией; Команды имеют изолированную среду, адаптированную к их потребностям, но при этом придерживаются организационной политики. В целом, организации требуется меньше традиционных кластеров, что снижает сложность и облегчает бремя управления. Команды платформы должны настраивать и управлять инструментами, такими как Cert Manager или контроллер Ingress на небольшом количестве кластеров хоста, а затем могут поделиться этими инструментами в своем парке виртуальных кластеров.
Тем временем инженеры также получают полную автономию и место для безопасного эксперимента. Они имеют полный доступ внутри виртуального кластера, но нет за его пределами, за исключением общего инструмента, которые команда платформы предоставила. Это неуловимая средняя земля: легкая и экономически эффективная, как пространства имен, но с свободой разработчика и строгой изоляцией отдельных кластеров. Безопасность становится меньше озабоченностью, потому что даже если один арендатор запускает неисправный контроллер или вводит другую уязвимость, это повлияет только на виртуальный кластер. Напротив, традиционно такая ошибка может снизить реальную кластеру Kubernetes.
Расширение прав и возможностей разработчиков при содействии последовательности
Виртуальные кластеры являются одним из примеров необходимого сдвига в платформных инженерных инициативах. Чтобы добиться успеха в повышении производительности разработчиков и обеспечении соблюдения согласованности, поскольку системы становятся все более сложными, строители платформы должны проявлять творческий подход и смотреть за пределы типичных решений. Вместо того, чтобы искать всеобъемлющий ВПЛ, они должны искать гибкие «строительные блоки», которые решают реальные, насущные проблемы, с которыми сталкиваются их команды сегодня. Этот подход в конечном итоге приводит к повышению производительности и более инновационным, безопасным приложениям.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Lukas Gentele является генеральным директором и соучредителем Loft Labs, ведущего поставщика строительных блоков для команд платформ, которые позволяют компаниям более эффективно управлять своей облачной инфраструктурой, используя кластеры виртуальных Kubernetes. Гентеле обладает глубоким опытом в архитектуре предприятия, … Подробнее от Lukas Gentle
