Организации часто хотят как можно скорее интегрировать новейшие функции Kubernetes или обновления безопасности. Однако анализ ReveCom показывает задержку от 2 до примерно 7 месяцев между выпуском обновлений Kubernetes Cloud Native Computing Foundation (CNCF) и их общей доступностью на платформах Kubernetes от поставщиков локальной облачной инфраструктуры или гиперскейлеров. Это означает, что организациям придется ждать критических обновлений безопасности, повышения производительности и часто важных новых функций. Эту разницу в частоте кадров ReveCom называет «лаговым разрывом». Размер разрыва значительно варьируется между различными поставщиками платформ и гипермасштабирующими компаниями.
Статус «Соответствующий Kubernetes» относится к дистрибутиву Kubernetes, который прошел официальные тесты на соответствие, гарантируя, что он соответствует основным спецификациям API Kubernetes и ведет себя согласованно с исходным Kubernetes. CNCF управляет сертификацией, предоставляя пользователям уверенность в совместимости, переносимости и надежности различных дистрибутивов Kubernetes. Поставщики должны пройти эти тесты, чтобы претендовать на статус «Сертифицированный Kubernetes».
Время, необходимое поставщику для того, чтобы сделать новую версию Kubernetes общедоступной (GA), напрямую влияет на доступ к новым функциям, включая улучшения безопасности и отказоустойчивости. Значительная задержка означает пропуск инноваций CNCF. На этой диаграмме показано среднее время разработки для последних трех выпусков K8:
Источник: РевеКом
Числа
Анализ призван быть кратким и включает наглядную диаграмму, иллюстрирующую конкурентную среду. При анализе задержки поддержки последних трех основных версий CNCF Kubernetes (1.33, 1.32, 1.31) выделяются две отдельные группы. Первая группа — лидеры — состоит из гипермасштабировщиков: Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS) и Amazon Elastic Kubernetes Service (EKS). Они демонстрируют впечатляющую гибкость, обычно делая новые версии доступными для клиентов в течение короткого периода от 41 до 87 дней.
Ключевой конкурент, VMware Cloud Foundation (VCF), приводит свои выпуски vSphere Kubernetes Service (VKS) в соответствие с этим тестом гипермасштабирования, в среднем 57 дней. Напротив, Red Hat OpenShift (RHOS) значительно отстает: средняя задержка поддержки составляет 192 дня.
Это отставание вызвано не пренебрежением, оно варьируется, потому что управляемые платформы должны превращать каждый исходный выпуск Kubernetes в защищенный интегрированный сервис. Поставщикам приходится отслеживать изменения в исходном коде и интегрировать свои собственные компоненты: etcd, среды выполнения контейнеров (CRI), CoreDNS, kube-proxy, флаги плоскости управления, а также базовые образы ядра и узлов. Необходимо перестроить и проверить стеки сетей и систем хранения данных (реализации CNI и драйверы CSI), а также облачные контроллеры, балансировщики нагрузки, наборы инструментов графических процессоров/драйверов и образы ОС.
Исправления безопасности часто доставляются быстрее через резервные порты, но для них по-прежнему требуются сборки с поддержкой FIPS, настройки по умолчанию, соответствующие CIS, подписанные образы и SBOM, а также сортировка CVE для всех поддерживаемых версий. Все это должно работать в масштабе, поддерживая мультитенантные плоскости управления, различные типы экземпляров и чрезвычайно большое количество модулей, а также обновления с нулевым временем простоя, безопасные откаты и гарантии отклонения версий. Затем выпуски проходят проверку соответствия и канареечное развертывание перед глобальной доступностью, после чего выпускаются обновленные интерфейсы командной строки, документация, материалы для выставления счетов и поддержки.
Короче говоря, внедрение «последней версии Kubernetes, совместимой с CNCF» на управляемой платформе — это серьезная инженерная и эксплуатационная работа. Это то, что обеспечивает еще один уровень надежности, безопасности и совместимости, за который организации платят.
Столь быстрые темпы могут вызвать вопрос о том, сохраняется ли безопасность и соответствие требованиям во время такого быстрого цикла выпуска. Однако, несмотря на более высокую частоту выпусков, гиперскейлеры и VMware заявляют, что по-прежнему поддерживают высокую надежность, безопасность и совместимость благодаря автоматизации, модульной архитектуре и широкому тестированию. Их услуги предназначены для непрерывного обновления и непрерывной проверки в масштабе. Идея состоит в том, чтобы безопасно поставлять совместимые версии без тяжелых циклов интеграции монолитных платформ, таких как OpenShift.
В случае OpenShift большой разрыв сводится к его архитектурной философии. OpenShift — это не просто дистрибутив Kubernetes; это весьма самоуверенная универсальная платформа как услуга (PaaS). Хотя такой высокий уровень интеграции обеспечивает единообразный пользовательский интерфейс, он также требует значительных инженерных затрат. Каждый новый выпуск Kubernetes должен быть тщательно протестирован, модифицирован и проверен на соответствие всему проприетарному стеку OpenShift — от сервисной сетки и инструментов мониторинга до уникальной операционной системы.
Эта сложность действует как якорь, замедляющий интеграцию вышестоящих инноваций, в то время как более модульная архитектура гиперскейлеров и VMware позволяет им гораздо быстрее сертифицировать и выпускать новые версии Kubernetes.
Влияние на предприятие: реальная цена шестимесячной задержки
Для инженеров платформ и архитекторов решений задержка в 192 дня превращается в ощутимые бизнес- и технические проблемы. Команды не могут использовать новые функции Kubernetes, которые могут решить критические бизнес-проблемы, такие как улучшенное управление дополнительными контейнерами, расширенная маршрутизация трафика с помощью Gateway API или повышенная безопасность с помощью новых стандартов безопасности Pod.
Эта задержка также способствует увеличению технического долга, поскольку как платформы, так и пользовательские развертывания еще больше отстают от исходного проекта, что увеличивает риск значительных критических изменений или сложных будущих миграций. В конечном итоге это создает конкурентное преимущество. Пока команды ходят по пятам в ожидании новой версии от своего поставщика, конкуренты на более гибких платформах уже используют новейшие инструменты и открывают критическое преимущество во времени выхода на рынок.
Для технологических лидеров данные очевидны: способность быстро и безопасно использовать инновации Kubernetes теперь является важнейшим критерием успеха платформы.
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. BC Gain — основатель и главный аналитик ReveCom Media. Его одержимость компьютерами началась, когда в начале 1980-х он взломал консоль Space Invaders, чтобы играть весь день за 25 центов в местном игровом зале. Затем он… Подробнее от Б. Кэмерона Гейна.
