Настройка и использование AWS EKS в производстве

Прошло уже несколько недель, как наша миграция на Amazon EKS ( рабочее место) завершена, и кластеры находятся в производстве. В прошлом я написал краткое изложение некоторых основных моментов, вы можете найти его здесь . С некоторой дополнительной уверенностью, пока система обслуживает реальный трафик, я решил вернуться за более конкретным и полным списком шагов и набором заметок, которые я собрал в этом путешествии. Очевидно, что есть несколько компаний, которые используют сервис Amazon Kubernetes , поэтому этот пост призван стать еще одним ориентиром для случаев миграции и использования EKS.

Платформа — веб-платформа

Общая платформа обеспечивает питание веб-сайта (интернет-магазина), кластеры EKS работают в активно-активном режиме, что означает, что они распределяют нагрузку и соответственно используются на основе взвешенного распределения нагрузки. Балансировка нагрузки кластера — если мы можем назвать это так, выполняется на `edge`, так что пока нет никаких концепций федерации kubernetes. Общий объем накопленных вычислений с точки зрения процессоров находится где-то между 400-600 ядрами (в зависимости от нагрузки). Общее количество микросервисов, обеспечивающих платформу, находится в диапазоне 20-30, в основном полезные нагрузки Java и набор узлов (на основе Js Node). Платформа находится в расширении состояния. Энтропия системы увеличивается, добавляя больше частей в головоломку, чтобы охватить больше функций или отказаться от устаревших / старых систем.

Сайт обслуживает уникальные просмотры страниц в диапазоне от полумиллиона в день (накоплено 15 рынков по всей Европе, Великобритании и APAC), трафик сильно варьируется в зависимости от характера бизнеса. В дни, когда художники продаются или объявляют о новых событиях, скачки трафика способствуют увеличению количества уникальных отрисовок страниц на 50-70% по сравнению с не занятым днем. Платформа также является объектом и целью непредвиденного (злонамеренного?) Трафика, очистки целого ряда открытых API или атак на определенные области.

Инфраструктура, обеспечивающая работу вышеуказанного сайта, должна обеспечивать:

• эластичность — сокращается и растет в зависимости от спроса — также дает возможность сделать это на основе ручного вмешательства, в тех случаях, когда мы заранее знаем, когда у нас будут всплески напряжения.
• стабильность — всегда в наличии, всегда обслуживать страницы и ответы API
• Терпимость к сбоям, обычно с учетом возможных сбоев в различных сетях AWS или целых регионах.
• Экономическая эффективность, снижение эксплуатационных расходов с течением времени (стоимость использования AWS)
• Безопасный
• Довольно открыт для команд разработчиков. Развертывание и понимание kubernetes — это задача команды разработчиков, а не экзотическая операция для отдельной команды.

Kubernetes

Kubernetes уже более 2 лет является нашей целевой платформой развертывания. Единственное, что изменилось с течением времени, это различные инструменты, используемые для вращения новых кластеров. У нас уже был опыт работы, и мы столкнулись с рядом проблем, связанных с различными версиями и возможностями kubernetes. Несмотря на трудности, принятие kubernetes считается успехом. Мы никогда не сталкивались с полными перебоями, кластеры и реализованные концепции никогда не отклонялись от того, что указано в руководстве (мы получили эластичность, стабильность, контроль над процессом развертывания и, наконец, что не менее важно — принятие kubernetes ускорило путь к производству и доставке ценность бизнеса.

Никогда прежде у разработчиков не было такой тесной связи с инфраструктурой, в нашем случае. Эти отношения развивались со временем и способствовали повышению осведомленности между двумя разделенными задачами: стороной, которая пишет программное обеспечение, и стороной, которая работает и запускает код в производстве. Самой большой победой был в основном процесс предоставления разработчикам большей осведомленности об инфраструктуре, что постепенно приводит к потенциальному улучшению способа разработки программного обеспечения. Очевидно, что те же концепции применимы к любой команде и любой облачной инициативе. Абстрагирование проблем инфраструктуры понижает барьер трансформации традиционного разработчика, который был полностью отключен от операций в этом мире. После этого небо — это предел с точки зрения углубления в детали и очевидного понимания инфраструктуры. Этот процесс требует времени и людей, которые хотят изменить свое мышление.

ЭКС почему?

Первый очевидный ответ — потому что AWS. Если AWS является вашим основным облаком, то вы постоянно стараетесь максимально использовать возможности своего облака, если только вы не на ином пути (например, вы хотите хеджировать автономность облака, смешивая разные решения или думая, что можете разрабатывать все на Вы владеете, если можете себе это позволить). Интеграция EKS с миром AWS достаточно созрела, чтобы вы могли насладиться довольно ванильной установкой Kubernetes (не подвергнутой обескураживанию) и за кулисами воспользоваться преимуществом интеграционного клея, предлагаемого AWS / ESK, для остальной части экосистемы AWS.

Второй ответ — обновления кластера и исправления безопасности. До EKS нам приходилось разбираться со спецификой различных инструментов (инсталляторов), когда появлялись новые версии. Во многих случаях, особенно если ваша облачная установка имеет настраиваемую конфигурацию, попытка согласовать кластеры в средах с настраиваемой сетью или специальной семантикой VPC становилась все более сложной задачей. Несмотря на участие в обновлениях кластеров в прошлом, связанный с этим риск становился все больше и больше, и вскоре мы столкнулись с обычной дилеммой, с которой сталкиваются многие люди и компании (многие не хотят признавать) — если вы хотите обновить существующий кластер, просто откажитесь от него. и создать новый. Будучи решением, потребовалось много дополнительной работы с нашей стороны, чтобы перестроить нашу платформу поверх новых кластеров. Очевидно, что нам предстоит еще много работы по переходу на более автоматизированную платформу.

Третий ответ — политика обновления EKS. Если вы хотите играть по правилам EKS, вы будете автоматически обновлять своих мастеров при небольших ревизиях, и вас будут подталкивать к активному обновлению ваших кластеров до основных версий. Несмотря на то, что по-прежнему есть возможность сидеть сложа руки и ничего не делать, эта модель поощряет и ускоряет разработку средств автоматизации для обновления кластера. Это также вопрос доверия — чем чаще вы обновляете и контролируете процесс обновления, тем более уверенным вы становитесь.

Команда

2 человека. Самое важное в этой настройке — это не размер команды (2), а сочетание навыков. Поскольку мы хотим быть как можно ближе к фактическим потребностям разработчиков в конечном итоге служить бизнесу, мы поняли, что подобные изменения не могут происходить в вакууме навыков. Вы не можете настраивать и вращать инфраструктуру, думая только как разработчик, но в то же время вы не можете построить инфраструктуру, в которой разработчики будут развиваться и создавать платформу, имея в виду только операционную сторону вещей. Вы должны иметь и то, и другое, когда разработчики недостаточно осведомлены о таких вещах, как безопасность или производительность инфраструктуры или тщательный мониторинг. Навыки и опыт Ops обеспечат все вышеперечисленное и обеспечат обучение одновременно, так что в следующий раз они улучшатся.

С другой стороны, когда разработчики не легко используют инфраструктуру, недоступны или существует невидимый барьер, который отключает производителя программного обеспечения от его производственной системы — это то, где точка зрения разработчиков может помочь в поиске среднего уровня. Итерация и прогрессивные изменения — это область, в которой разработчики программного обеспечения часто работают лучше, чем другие функции.

В настоящее время это одна из самых запретных вещей на рынке, где обе стороны борются за контроль и влияние. Я не уверен, каково правильное определение DevOps, но, на мой взгляд, это путешествие было путешествием DevOps, и я хотел бы испытать его и в других местах на протяжении всей моей карьеры. Объедините навыки в команде и поощряйте поток знаний вместо того, чтобы вводить организационные барьеры или переборки.

Побочное беспокойство — EKS работник сети

Поскольку мы впервые внедрили EKS, мы решили, что самым безопасным и гибким подходом является полное принятие сетевой модели AWS CNI. Это было большим изменением по сравнению с нашими предыдущими кластерами, которые были перегружены сетью наложения. Стручки теперь намного легче диагностировать и выявлять проблемы с сетью, поскольку они имеют маршрутизируемые IP-адреса. Смотрите здесь Вслед за ванильным подходом возникнут опасения по поводу размеров VPC CDIR, мы выбрали чистое решение, изолирующее наши кластеры от общих VPC, и запустили новые и чистые новые VPC с довольно большим диапазоном.

В случаях, когда вторичные -hot-IP-адреса начинают исчерпываться, или у вас ограничены возможности ваших работников (Num of ENI) См. Здесь . Также приятно читать
здесь

инструменты

Нашей главной целью было не нарушить рабочие процессы и семантику существующих групп разработчиков, а сделать так, чтобы наши кластеры EKS выглядели примерно так же, как наши существующие кластеры. Это не означает, что наша существующая установка была идеальной или мы не хотели модернизироваться. Опять же, приоритет № 1 заключался в том, что кластеры должны удовлетворять потребности групп, развертывающих поверх них сервисы, а не наше стремление постоянно пробовать новые технологии. Очевидно, что многие вещи будут новыми и разными, но изменения конфигурации и смены инструментов следует вводить итеративно. Основной поток был следующим:

1. Создайте кластеры и установите кластеры
2. Внедряйте более или менее одинаковую семантику и конфигурации — упростите для команд перемещение своих полезных нагрузок (приложений)
3. стабилизироваться
4. Постепенно обучайте и начинайте вносить больше изменений в кластеры, будь то новые политики, новые способы развертывания или новые правила. Первым приоритетом является продуктивность разработчиков с хорошим балансом передового опыта и очевидным упрощением .

Чтобы настроить / обновить и настроить кластеры, мы пришли к решению, которое использует следующие инструменты

• Terraform (мастера и рабочие / asg)
• Упаковщик для поддержки новых AMI на основе ссылки EKS
• bash (обычно вызывается как шаг после запуска) в течение жизненного цикла terraform
• шлем / кубектл

Рабочий процесс следующий:

• Используйте Packer, если хотите испечь новый рабочий AMI (при необходимости или пропустить)
• Планируйте и применяйте стек terraform, который контролирует состояние мастеров и рабочих групп автоматического масштабирования, IAM и другие особенности, чтобы сформировать кластер. У нас есть собственный модуль terraform, хотя теперь найденная здесь эталонная модель EKS довольно солидна.
• Начните вызывать kubectl или helm после формирования кластера для установки некоторых базовых сервисов.

Установка сервисов поверх кластера

Когда кластер настроен на AWS, то есть мастера могут общаться с различными рабочими узлами, мы развернем и настроим следующие компоненты сверху.

1. Установить руль (румпель)
2. Настройка aws-auth на основе наших ролей RBAC / AWS для предоставления доступа пользователям — патч kubectl
3. Установите metrics-сервер (модифицированный рулевой график)
4. Установите кластер-автоскалер aws (диаграмма Хелма )
5. Установить kubernetes-приборную панель (рулевой график)
6. Установить метрики состояния системы / promeheus (диаграмма руля)
7. Установите набор deamons для Fluentd-bit (предварительно настроенный для отправки журналов в ES) (рулевой график)
8. Установите или измените правильные версии для Kube-прокси см. Здесь
9. Установите или измените правильные версии для aws-cni, смотрите здесь.
10. Установите модифицированную правильную версию для CoreDNS + масштабируйте coreDNS
11. Расширьте coreDNS
12. Создать или обновить пространства имен
13. Установите — ambident -proxy, в некоторых случаях — гибридный Ingress.
14. Заполните кластер и определенные пространства имен секретами — уже хранятся в Vault

В целом вся оркестровка контролируется Terraform. Структурные изменения в кластере, например размер рабочих узлов, семантика масштабирования и т. Д., Обновляются на уровне терраформ. Некоторые из указанных выше схем управления рулем динамически настраиваются с помощью terraform во время инициализации — поэтому применяемые схемы управления рулем уже синхронизированы и имеют правильные значения. Идея состоит в том, что терраформные переменные могут передаваться как переменные отдельным вызовам kubectl или helm — всю мощь и простоту local_exec и поставщика bash см.
здесь

Автомасштабирование групп и сегментация работников

Вернемся к фактической настройке кластера и очень важному моменту автоматического масштабирования групп, раскручивая рабочих кластеров. Есть несколько моделей и методов, и, найдя соответствующие материалы в Интернете, вы найдете разные подходы или советы.

Мы выбрали простую настройку, где наши работники будут разделены на 2 отдельные группы (группы автоматического масштабирования / шаблоны запуска).

• system — рабочие : мы будем устанавливать материал kube-system на этих рабочих, которые всегда будут иметь жизненный цикл: экземпляры OnDemand или Reserve . Полезные грузы, такие как прометей , кластерный автоскалер, стручки сердечников или иногда прокси-послы (если мы тоже выберем).
• Нормальные работники : будут размещать наши приложения в различных пространствах имен. Ожидается, что эта цифра будет расти быстрее с точки зрения количества.

Вышеуказанная настройка на terraform — должна быть отражена и сопоставлена ​​с одним kubernetes, который мы определили выше — aws
кластерный автоскалер .

Вышеуказанная настройка — требует минимального соглашения наших прикладных хит-парадов. Ввести 2 правила сходства узлов или селекторов узлов. В настоящее время более простой способ — это использование nodeSelector, даже если они будут устаревшими.

Найдите примеры (снизьте эту стоимость!)

Благодаря возможности отделить сторону вещей Kubernetes (через конфигурации кластера автоматического масштабирования) и сторону AWS, особенно с учетом того, что мы используем terraform, — у нас появилась возможность экспериментировать с экземплярами Spot. Наша главная цель состояла в том, чтобы сделать спотовые экземпляры максимально прозрачными для людей, развертывающих приложения в кластере, и сделать его более интересным для операторов кластера. Очевидно, что все еще существует большая обеспокоенность / изменение, о котором должны знать все вовлеченные стороны. Повышение волатильности работников кластера, то есть запуск полезных нагрузок на работников, которые могут умереть в течение 2 минут, создает проблемы, о которых должны знать люди, пишущие сервисы в этих кластерах.

Точечные экземпляры могут быть добавлены в смесь с помощью настройки 2 групп автоматического масштабирования, при условии, что вы используете правильный шаблон запуска и смешанные политики экземпляров. Многие люди решают сгруппировать своих работников в более чем 2 ASG, например, вместо 2 у вас может быть 5 или 10, где вы можете более детально контролировать используемые классы EC2 / и их жизненный цикл. Также вы можете ориентировать части своих модулей / приложений на определенные группы работников в зависимости от их возможностей или жизненного цикла.

В общем, чем более точный контроль вы хотите и чем больше вы хотите хеджировать риск спот-терминации, тем больше вы будете склоняться к следующим стратегиям или выборам.

• Разделите ваших работников на разные группы возможностей (спот / OnDemand / зарезервированные один или несколько классов / смешанные политики экземпляров)
• Увеличьте среднее количество модулей в каждом наборе реплик, чтобы вы хеджировали риск, связанный с тем, что блоки одного и того же набора (развертывания) набора реплик на работниках одного и того же типа потенциально могут быть убиты в одно и то же время.
• Больше без гражданства, без государства . Таким образом, ваша платформа может быть в состоянии восстанавливаться после микро- или незначительных простоев Compute / Memory. Чем больше вы полагаетесь на одноуровневые сервисы или централизованные ресурсы, тем больше вы собираетесь хеджировать случайные отключения.

Спотовые экземпляры означают сниженные цены, а также уведомление о прекращении. Когда вы думаете о прекращении текущего паттерна, вам нужно учитывать 3 фактора

1. Регион АМС (ЕС-Запад-1)
2. Наличие AWS (eu-west-1a, eu-west-1b.)
3. Класс (m4.xlarge)

Вышеупомянутый триплет обычно является основным фактором, который будет влиять на спотовую цену класса в целом. Текущая стратегия заключается в том, что ваши полезные нагрузки (контейнеры / контейнеры) должны, очевидно, распространяться максимально эффективно

• Регион : Таким образом, более одного кластера
• AZ : Ваша ASG должна привлечь рабочих ко ВСЕМ доступным зонам, которые предлагает регион.
• Класс : если вы ASG принадлежите к одному классу — ваши шансы на то, что этот класс будет подвергнут случайному окончанию спота и влияют на ваши кластеры, выше, чем при использовании большего списка классов.

Общая идея состоит в том, чтобы застраховать свой риск прерывания точечного экземпляра, запустив свои рабочие нагрузки — multi region / multi asg / multi class. По-прежнему существует некоторый риск — например, AWS массово уходит в отставку — спотовые ресурсы — или быстрое изменение цен.

Это очень сложная область, и настройки ASG могут помочь вам в этом немного больше застраховаться — например, если у вас жесткие правила в отношении ценовых ограничений, ASG может это учитывать, например, правила «не предлагайте цену выше этой цены». для одного точечного ресурса ». Чем больше вы делаете шаблон ASG / запуска строгим, контролируя оценку стоимости — тем больше риск перенести перебои из-за этого жесткого предела и внезапного изменения цены.

Самый гибкий подход — позволить ASG выбрать для вас «самую низкую цену», чтобы вы могли быть уверены, что сделают все возможное, чтобы найти следующую доступную ценовую комбинацию, чтобы наполнить ваш кластер вычислениями и памятью.

Что касается раздачи ваших стручков разным работникам, я думаю, что самый простой совет — не кладите все яйца в одну корзину.
Pod Affinity / AntiAffinity rules — это ваш инструмент № 1 в этих случаях + метки на ваших узлах. Вы можете найти очень хорошую статью здесь .

Последний, но тем не менее важный. Когда происходит прерывание точечных экземпляров, более чем важно иметь возможность реагировать на уровне кластера, чтобы эти рабочие завершения не приводили кластер в бешенство. Чем больше одновременных завершений происходит, тем больше риск того, что вы увидите большие волны передвижения рабочих и рабочих. Kubernetes постарается сбалансировать и заполнить стручки оставшимися ресурсами и, очевидно, задействовать новые ресурсы, но на самом деле очень многое может выдержать эти перемещения, а также контролировать, как происходит перепланирование стручков. В этой области еще один полезный инструмент, доступный для вас, это бюджеты разрушения стручков kubernetes, где он может выступать в качестве дополнительного набора правил, которые хозяева kubernetes учитывают, когда его доступность ресурсов постоянно меняется (то есть рабочие приходят и уходят).

Вдобавок к этому, чтобы изящно обрабатывать эти завершения — что на самом деле происходит с 2-минутным уведомлением, такие наборы демонов (обработчик точечного завершения) облегчат боль + и обеспечат большую видимость. Демон, как только точечный экземпляр получает событие завершения, изящно истощает ваш узел, который, в свою очередь, помечает работника как не готового к приему и планирует рабочие нагрузки, что, в свою очередь, запускает раунд планирования, в котором kubernetes будет пытаться разместить модули на других рабочие, если есть достаточно места или убить новых работников. В конце концов, система попытается сбалансировать и удовлетворить ваши настройки и требования к настройке, но это действительно зависит от количества одновременных завершений, которые у вас будут, и от того, как ваши модули распределены вокруг этих рабочих.

Чем больше разброс, тем меньше влияние. Также вы можете рассмотреть смешанную политику, при которой определенные работники всегда пользуются спросом, а остальные — точечные, так что вы можете хеджировать еще более интенсивные события увольнения экземпляра.

Проблемы с обновлением кластера и worfklow

Обновления кластера требуют некоторой работы с точки зрения координации + установления процесса. Есть 3 случая:

• Нет обновлений версий EKS или kubernetes — только модификации компонентов, установленных поверх кластеров, например, вы хотите обновить fluentd-bit до более новой версии.
• Незначительное обновление EKS (автоматический режим), для которого требуется обновление EKS AMI, приводящее ваших работников в то же состояние версии.
• Основное обновление EKS (например, обновление kubernetes с 1.12 до 1.13) — для этого потребуется обновление AMI + некоторые обновленные компоненты EKS aws.

Третий случай — самый сложный, потому что не только вам нужно испечь новый AMI на основе эталонного провайдера от AWS, вы также должны следовать соглашениям и версиям компонентов, определенным здесь:

• ядро-DNS
• Кубэ-прокси
• Обновление плагина AWS CNI.

Это означает, что перед включением обновлений вам необходимо обновить скрипты конфигурации, в нашем случае переменные terraform, чтобы при появлении нового AMI в рабочей среде и наличии ядра установки кластера, чтобы можно было обновить или перезапустить -установить определенные компоненты. Всегда следуйте этому руководству. Документация AWS довольно солидна.

Регулирование API AWS и EKS

Мастера AWS — это черный ящик для вас как конечного пользователя, но настоятельно рекомендуется, чтобы по умолчанию у вас были включены журналы CloudWatch. Это было огромным улучшением для нас по сравнению с нашими предыдущими кластерами. Основные журналы изолированы и легко доступны для поиска, поэтому мы избегаем шума фильтрации или поиска большого количества журналов. Кроме того, проверьте эту очень полезную утилиту, на которую обычно ссылаются во многих случаях поддержки сборщик логов EKS .

Мастера, как и любой другой компонент EKS, используют API-интерфейс AWS для достижения цели. Это относится ко всему, что работает на AWS. Необходимо помнить, что если вы работаете с занятыми централизованными учетными записями AWS, всегда существует квота на вызовы API, поступающие из разных компонентов (EC2 / и т. Д.). Ваши мастера EKS также общительны, и вызовы API, сделанные ими, будут учитываться и оплачиваться как остальные вызовы на вашем аккаунте (они не бесплатны и они вносят свой вклад в квоту). Это означает, что когда и если регулирование AWS API происходит в ваших учетных записях — это может повлиять и на ваши кластеры EKS, поэтому убедитесь, что у вас есть соответствующий мониторинг, чтобы проверить, когда это произойдет. Если регулирование происходит в течение большого количества раз — чем выше риск, тем внутренние компоненты EKS не могут синхронизироваться или взаимодействовать друг с другом — это означает, что в целом кластер может начать сообщать о случайных ошибках, которые иногда не могут быть коррелированы. Это сложная задача, и я очень надеюсь, что AWS изменит политику в отношении мастеров EKS и защитит их от регулирования API, которое может произойти в учетной записи. Другое решение состоит в том, чтобы «класть» ваши кластеры в определенные учетные записи и не помещать все свои материалы в одну учетную запись с одной квотой API.

В целом

Миграция и использование EKS в производстве можно считать чрезвычайно успешным. Очевидно, что наша платформа все еще в движении, и изменения происходят и будут происходить с течением времени. То же самое относится и к EKS как к продукту, со временем вы видите изменения и обновления от AWS, что является очень позитивным знаком, поскольку вы видите, что в этот продукт вкладываются средства AWS, и с каждым крупным обновлением kubernetes EKS также развивается. Еще одним положительным моментом является качество поддержки со стороны AWS. Несколько раз нам приходилось перепроверять случаи с помощью поддержки AWS, и я должен признать, что предоставленные разрешение и ответы были очень тщательными.

Как я уже говорил ранее, я думаю, что в какой-то момент AWS решит завершить интеграционный журнал для своих пользователей и предложит решение «под ключ», в котором конфигурация кластера будет полностью автоматизирована (мастера, работники, плагины и настройки). ). Давайте посмотрим.