Это вторая часть в нашей серии Anti-Patterns Kubernetes. См. Также часть 1 для предыдущей части и часть 3 для следующей части.
Антипаттерн 6 — Использование kubectl в качестве инструмента отладки
Хотя мы все еще находимся на теме Kubectl, важно ли упомянуть его второй по величине недостаток. Kubectl не является инструментом отладки и не должен использоваться как таковой.
Каждая компания, которая начала усыновить Kubernetes, в конечном итоге столкнулась с проблемой, которая вызвала «10-Question-Game» с Kubectl. Если у вас есть критическая проблема в вашем производственном кластере, ваш первый импульс не должен открывать терминал с kubectl. Если вы делаете это, вы уже проиграли битву, особенно если это 3 часа ночи, производство снижается, и вы на вызове.
kubectl get ns kubectl get pods -n sales kubectl describe pod prod-app-1233445 -n sales kubectl get svc - n sales kubectl describe...
Все ваши кластеры Kubernetes должны иметь надлежащие системы мониторинга/отслеживания/регистрации, которые можно своевременно использовать для определения проблем. Если вам нужно запустить Kubectl, чтобы проверить что -то, это означает, что у вас есть пробел в инструментах наблюдения, и то, что вам нужно для проверки, должна быть добавлена в ваши инструменты мониторинга.
Даже если вы просто хотите проверить кластер, с которым вы не знакомы, вы должны использовать выделенный инструмент для этой цели. Сегодня есть много инструментов для осмотра кластеров Kubernetes.
Кубевиус Например, это комплексная панель управления Kubernetes со встроенным двигателем правил, который позволяет искать и отмечать ресурсы Kubernetes в соответствии с пользовательскими правилами.
Метрики и отслеживание настолько важны, что будут обсуждаться в другом анти-паттерне позже в нашем списке.
Anti-Pattern 7-недоразумение концепций сети Kubernetes
Прошли те дни, когда один балансировщик нагрузки был всем необходимым для вашего приложения. Kubernetes представляет свою собственную сетевую модель, и вы обязаны изучать и понимать основные концепции. По крайней мере, вы должны быть знакомы с балансировщиками нагрузки, кластерами, Nodeports и Вход (и как они отличаются).
Мы видели оба конца спектра, где организации создают настройку излишнего значения с контроллером проникновения в тяжелом положении (когда будет достаточно простого балансировщика нагрузки) или создание нескольких балансировщиков нагрузки (тратить деньги на облачный провайдер) вместо установки в вход Анкет
Понимание различных вариантов обслуживания является одним из самых запутанных аспектов для людей, начинающих с сети Kubernetes. Услуги кластера являются внутренними по отношению к кластеру, Nodeports являются как внутренними, так и внешними, а балансировщики нагрузки являются внешними по отношению к кластеру, поэтому убедитесь, что вы понимаете последствия каждого типа службы.
И это только для того, чтобы получить трафик внутри вашего кластера. Вы также должны обратить внимание на то, как работает трафик в самом кластере. DNS, сертификаты безопасности, виртуальные сервисы — это все аспекты, с которыми следует подробно обрабатывать для производственного кластера Kubernetes.
Вы также должны потратить некоторое время на понимание Что такое сервисная сетка И какие проблемы он решает. Мы не выступаем за то, чтобы в каждом кластере была сервисная сетка. Но вы должны понимать, как это работает и почему вам это нужно.
Вы можете утверждать, что разработчик не должен учиться об этих сетевых концепциях, чтобы развернуть приложение, и вы будете правы. Нам нужна абстракция на вершине Kubernetes для разработчиков, но у нас ее еще нет.
Даже будучи разработчиком, вы должны знать, как трафик достигает вашего приложения. Если запрос должен выполнить 5 хмелей между стручками, узлами и сервисами, и каждый прыжок имеет возможную задержку 100 мс, то ваши пользователи сталкиваются с возможной задержкой на 500 мс при посещении веб -страницы. Вы должны знать об этом, чтобы тратить усилия на оптимизацию времени отклика сосредоточено на истинных узких местах.
Также как разработчик вы должны знать, что Kubectl Proxy делает за кулисами и когда использовать его.
Anti-Pattern 8-Использование постоянных стажирующих среде вместо динамических средств
С виртуальными машинами (и тем более с голой металлических серверов) для команды программного обеспечения можно иметь несколько предварительно определенных испытательных сред, которые используются для проверки приложения, прежде чем оно достигнет производства.
Одним из наиболее распространенных моделей является не менее 3 среда (QA/постановка/производство) и в зависимости от размера компании, которую у вас может быть больше. Наиболее важным из этих среда является «интеграция» (или что бы ни называла компания), которая собирает все функции разработчиков после того, как они объединены с основным филиалом.
Оставив в стороне аспекты затрат (если у вас предопределенные тестовые среды, вы всегда платите за них с точки зрения вычислительной мощности, даже если они не используются), наиболее насущной проблемой является изоляция функций.
Если вы используете одну среду для интеграции, то, когда несколько разработчиков объединяют функции и что -то разбиваются, не сразу же, какая из функций вызвала проблему. Если 3 разработчики объединяют свои функции в стадии, а развертывание не удается (либо сбоя сборки, либо интеграционные тесты не сняты, либо взорвались метрики), тогда есть несколько сценариев:
- Особенность A проблематично, B и C в порядке
- Функция B проблематична, A и C в порядке
- Особенность C проблематична, B и C в порядке
- Все функции сами по себе, но сочетание A и B проблематично
- Все функции сами по себе, но сочетание A и C является проблематичным
- Все функции сами по себе, но сочетание B и C проблематично
- Все функции сами по себе, но сочетание всех 3 проблематично
В зависимости от размера вашей команды по программированию и сложности вашего программного обеспечения, различие между этими сценариями является длительным процессом. Если кнопка GUI меняет положение, вероятно, легко выяснить, какой разработчик несет ответственность за коммит. Но если ваш двигатель рекомендаций внезапно стал в 5 раз медленнее, насколько быстро вы можете определить ответственную функцию, если все 3 разработчика работали над двигателем рекомендаций для этого спринта?
Чтобы преодолеть эту проблему, компании почти всегда принимают «парадигму бронирования»:
- Постановка «забронирована» каждым отдельным разработчиком, чтобы они могли проверить свою функцию в изоляции.
- Компания создает несколько «постановленных» сред, которые разработчики используют для тестирования своих функций (поскольку одна среда может быстро стать узким местом).
Эта ситуация по -прежнему проблематична, потому что разработчики должны не только координировать между собой для выбора среды, но и потому, что вы должны отслеживать действия по чистке каждой среды. Например, если нескольким разработчикам нужен набор изменений в базе данных вместе с их функцией, им необходимо убедиться, что база данных каждой стадии содержит только свои собственные изменения, а не изменения предыдущего разработчика, который использовал эту среду.
Кроме того, множественные постоянные среды для постановки могут быстро пострадать от известной проблемы дрейфа конфигурации, где среды должны быть одинаковыми, но после нескольких специальных изменений это не так.
Решение, конечно, состоит в том, чтобы отказаться от ручного обслуживания статических сред и перейти в динамические среды, которые создаются и уничтожаются по требованию. С Kubernetes это очень легко сделать:
Существует много способов достичь этого сценария, но, по крайней мере, каждый запрос на открытый притяжение должно создать динамическую среду, которая содержит только этот запрос на притяжение и ничего больше. Окружающая среда автоматически разрушается, когда запрос на тягу объединяется/закрыт или после указанного количества времени.
Большая сила автоматической среды, однако, является полной свободой разработчиков. Если я разработчик и только что закончил с функцией A, а мой коллега закончил функцию B, я смогу сделать:
git checkout master git checkout -b feature-a-b-together git merge feature-a git merge feature-b git push origin feature-a-b-together
И тогда волшебным образом динамичная среда должна присутствовать по адресу: feature-a-b-together.staging.company.com
или Staging.company.com/feature-a-b-together
Анкет
За кулисами вы можете использовать пространства имен Kubernetes и правила входа для этой изоляции.
Обратите внимание, что это нормально, если в вашей компании есть постоянные стажируемые среды для специальных потребностей, таких как тестирование нагрузки, анализ проникновения в безопасность, развертывание A/B и т. Д. Но для основного сценария «Я разработчик и хочу, чтобы моя функция работала и запустила интеграционные тесты против него», динамическая среда — это путь.
Если вы все еще используете постоянные среды для тестирования функций, вы затрудняете жизнь для своих разработчиков, а также тратят системные ресурсы, когда ваши среды не используются активно.
Anti-Pattern 9-смешивание производства и непроизводственных кластеров
Несмотря на то, что Kubernetes специально разработан для кластерной оркестровки, вы не должны попадать в ловушку создания одного большого кластера для всех ваших потребностей. По крайней мере, у вас должно быть два кластера, производственный один и непроизводственный.
Прежде всего, смешивание производства и непроизводства является очевидной плохой идеей для голода ресурсов. Вы не хотите, чтобы версия разработки Rogue преувеличивала ресурс производственной версии чего -либо.
Но что касается разработчиков, самая большая проблема связана с безопасностью. Если вы не предпринимаете активных шагов против этого, все общение внутри кластера Kubernetes разрешено по умолчанию. И вопреки распространенному мнению, стручок из одного пространства имен может свободно общаться с стручком в другом пространстве имен. Есть также некоторые ресурсы Kubernetes, которые вообще не заполнены именами.
Компания имен Kubernetes — это не мера безопасности. Если ваша команда имеет продвинутые знания в Kubernetes, то действительно возможно поддерживать многоцелевое место в кластере и обеспечить все рабочие нагрузки друг против друга. Но это требует значительных усилий, и в большинстве случаев гораздо проще создать второй кластер исключительно для производства.
Если вы объедините этот анти-паттерн со вторым (конфигурация выпечки внутри контейнеров), должно быть очевидно, что может произойти много плохих сценариев.
Самый классический:
- Разработчик создает пространство имен функций на кластере, в котором также находится производство
- Они развертывают свой код функции в пространстве имен и начинают запускать интеграционные тесты
- Интеграционные тесты записывают фиктивные данные или очистите БД, или вмешивается в бэкэнд в разрушительном виде
- К сожалению, в контейнерах были производственные URL -адреса и конфигурацию внутри них, и, таким образом, все интеграционные тесты фактически повлияли на производственные рабочие нагрузки!
Чтобы не попасть в эту ловушку, гораздо проще просто назначить производственные и непроизводственные кластеры. К сожалению, несколько учебных пособий подразумевают, что пространства имен можно использовать для разделения окружающей среды и Даже официальная документация в Kubernetes имеет примеры с Prod/Dev Spaces Анкет
Обратите внимание, что в зависимости от размера вашей компании у вас может быть больше кластеров, чем два, таких как:
- Производство
- Тень/клон производства, но с меньшим количеством ресурсов
- Кластеры разработчиков для тестирования функций (см. Предыдущий раздел)
- Специализированный кластер для тестирования нагрузки/безопасности (см. Предыдущий раздел)
- Кластер для внутренних инструментов
Anti-Pattern 10-развертывание без памяти и пределов процессора
По умолчанию приложение, развернутое в Kubernetes, не имеет указанных пределов ресурсов. Это означает, что ваше приложение может потенциально захватить весь кластер. Это было бы проблематично в кластере -кластере и катастрофическим в производственном кластере, поскольку малейшая утечка памяти или икота ЦП нанесет ущерб остальным приложениям.
Это означает, что все ваши приложения (независимо от целевого кластера) должны иметь связанные пределы ресурсов.
Возможно, как разработчик, вам не нужно знать все детали о том, как устанавливаются пределы, но вы обязаны дать некоторые подсказки и советы человеку, который управляет вашим кластером о том, каковы ожидания приложения.
К сожалению, простой просмотр средней памяти и использования процессора приложения недостаточно. Средние ресурсы просто это — средние. Вам необходимо изучить свое приложение и увидеть с помощью всплесков трафика и загрузки и понять, каково поведение ресурсов в экстремальных условиях. В конце концов, это именно то условие, которое вы не хотите, чтобы ваше приложение было перезагружено без причины.
Одним из преимуществ Kubernetes является эластичность ресурсов. Если кластер убивает/перезагружает ваше приложение именно тогда, когда он начинает обрабатывать значительную нагрузку (потому что, скажем, ваш Eshop забивает трафиком), вы в первую очередь потеряли преимущество в использовании кластера.
С другой стороны, установление слишком высоких пределов является пустой тратой ресурсов и делает ваш кластер менее эффективным.
Вам также необходимо изучить языки программирования на наличие конкретных моделей использования и того, как ресурсы используются базовой платформой. Например, устаревшие приложения Java имеют печально известные проблемы с ограничениями памяти.
Обратите внимание, что, как только вы получите уверенность в своем приложении и то, как оно использует ресурсы Kubernetes, вы также можете автоматизировать всю игру ресурса с Вертикальный кластер автоматически масштаб Анкет
Независимо от размера вашей компании, у вас всегда должно быть как минимум 2 (производство и все остальное, что не является производством)
Продолжение в части 3.
Фотография обложки от Неспособный .
Оригинал: «https://dev.to/codefreshio/kubernetes-deployment-antipatterns-part-2-3odh»