Каждый выпуск Kubernetes приносит хорошее, плохие и слепые пятна, которые вы обнаруживаете только в производстве. Последняя версия (1.34) не является исключением. От планирования графических процессоров до обмена поддержкой, последние функции обеспечивают реальную ценность, но также вводят новые сложности, которые инженеры платформы не могут позволить себе игнорировать.
Соблазн состоит в том, чтобы включить эти функции и двигаться вперед. Но сначала давайте распаковываем новые риски, пробелы в наблюдении и эксплуатационные накладные расходы, которые они создают, чтобы вы могли настроить свои пьесы, прежде чем развернуть их в масштабе.
Динамическое распределение ресурсов
Одним из наиболее заметных изменений в V1.34 является выпуск DRA в GA. Это дает кластерам Kubernetes больше гибкости при планировании графических процессоров, TPU и других специализированных устройств. Это явная победа для рабочих нагрузок ИИ и ML, которые требуют ускорителей для масштабирования.
Но эта гибкость также добавляет сложность. Большая логика планирования означает больше мест для неправильных конфигураций. Приложение может запрашивать ресурсы, которые не могут быть выполнены, что может привести к задержкам планирования или сценариям отступления, которые ведут себя иначе, чем ожидалось. Что касается финансовой стороны, чрезмерно распределяющие графические процессоры могут тратить десятки тысяч долларов в месяц.
Практический вывод состоит в том, чтобы тщательно проверить сценарии распределения при постановке, прежде чем перевернуть их в производство. Инженеры также должны обеспечить использование мониторинга для отслеживания запросов и использования акселератора. Без видимости преимущества DRA могут легко превратиться в стоимость и обязательства по производительности.
Поддержка обмена узлами Linux
Еще одним серьезным изменением является выпуск GA о поддержке Swap Node Linux. Swap-это давняя особенность, которая помогает узлам оставаться стабильными под давлением памяти. Вместо того, чтобы сбоевать стручки, когда память исчерпана, узлы теперь могут сдвинуть часть этого давления на диск.
На бумаге это звучит как защита от событий вне памяти, но на практике Swap представляет новые проблемы с производительностью. Тяжелая зависимость от обмена может маскировать рабочую нагрузку с плохим поведением памяти, создавая иллюзию стабильности, в то время как задержка -шипы монтируются. Настройка поведения свопа требует тщательного внимания, и устранение неполадок в памяти может быть сложным, поскольку инженеры теперь должны различать физическое давление памяти и замедление, связанное с обменом.
Обращение следует рассматривать как сеть безопасности, а не стратегия производительности. Инженеры, принимающие его, должны обновлять панели мониторинга, чтобы отслеживать замены и смены деятельности и рассматривать любое устойчивое использование как сигнал для исправления запросов и ограничений ресурсов на уровне рабочей нагрузки.
Запросы и ограничения ресурсов на уровне POD
С V1.34 Kubernetes теперь позволяет определять запросы и ограничения на уровне POD вместо только на уровне контейнера. Для рабочих нагрузок с несколькими контейнерами это облегчает управление квотой и снижает риск чрезмерного компенсации ресурсов.
Тем не менее, эта функция может скрывать чрезмерное использование. Если один контейнер монополизирует ресурсы, проблема может быть не видна, когда ограничения установлены на уровне POD. Horizontal Pod Autoscalers (HPA) также могут плохо себя вести, поскольку их предположения привязаны к показателям уровня контейнеров.
Перед тем, как внедрить ограничения на уровне стручков в целом, инженеры должны вернуться к тому, как AutoScaling настроена в их кластерах. Инструменты наблюдения также могут также нуждаться в обновлении, чтобы убедиться, что они захватывают потребление для каждого контейнера, даже если введены запросы на уровне стручков. Без этой видимости становится все труднее привлекать команды к ответственности за сбежавшие контейнеры или устранение неполадок в регрессиях производительности.
Улучшения безопасности
Выпуск также вводит важные улучшения безопасности. Кратков, связанные сдачи, внешнее подписание и сертификаты уровня POD, усиливают позы соответствия и снижают долгосрочный риск учетных данных. Эти изменения являются шагами в правильном направлении, но они добавляют эксплуатационные накладные расходы.
Интеграция с внешними модулями управления ключами или оборудования обеспечивает новые зависимости, которые должны быть надежными в любое время. Если внешняя система подписания снижается, развертывание может выйти из строя. Частое вращение сертификата требует автоматизации и предупреждения, чтобы избежать отключений, вызванных истекшим сроком учета.
Для команд платформ урок состоит в том, чтобы рассматривать эти новые функции как критические зависимости, которые нуждаются в полной наблюдении и автоматизации. Жизненные циклы токена и сертификатов должны контролироваться, как и любая другая часть системы, с режимами сбоя четко задокументированы в Runbooks.
Улучшения хранения и планирования
Несколько меньших, но важных изменений завершают релиз. Восстановление расширения объема и введение VolumeatTributesclass дают рабочую нагрузку более динамический контроль над хранением. Замена модулей более умной работы и неблокирующие вызовы API уменьшают узкие места для больших кластеров.
Эти функции обеспечивают гибкость и масштабируемость, но они также расширяют диапазон возможных режимов отказа. Например, когда рабочие нагрузки могут изменить атрибуты громкости на лету, устранение неполадок ввода/вывода становится все труднее. Неблокирующие API и потоковые ответы снижают давление API-сервера, но повышают зависимость от состояний кэша, что может создать тонкие проблемы с согласованностью.
При принятии этих функций расширяйте мониторинг для отслеживания IOPS, попытки расширения хранения и поведение кеша. Преимущества реальны, но и новые сценарии отладки, которые они представляют.
Что это значит для инженеров платформы
Взятые вместе, v1.34 дает командам платформ лучшие инструменты для управления современными рабочими нагрузками. Но ни одно из этих улучшений не уменьшает работу. Вместо этого они сдвигают это. Прежде чем развернуть каждую новую инженеры платформы функций, должны задать себе три вопроса:
Создавая ответы на эти вопросы в стеки наблюдений, политики и runbooks, инженеры могут получить преимущества V1.34 без создания скрытых обязательств.
Kubernetes v1.34 — напоминание о том, что прогресс часто идет по цене. Выпуск приносит возможности, которые делают кластеры более устойчивыми и адаптируемыми, но каждый из них вводит оперативные слепые пятна, если они приняты без подготовки.
Инженеры платформы, которые рассматривают обновления как простые переключения функций, будут застигнуты врасплох новых задач отладки, компромисса производительности и пробелов в управлении. Те, кто подходит к V1.34 с дисциплиной, тестированием в проведении, расширении мониторинга, автоматизации управления и обновлением моделей владения, смогут обеспечить как скорость, так и стабильность
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Итиэль Шварц, технический директор и соучредитель Komodor, является экспертом в области Kubernetes, облачных технологий и инфраструктуры. Он занимал технические руководящие должности на eBay, Forter и Nebout. Подробнее от Итиэля Шварца
