Мы в Manifold всегда стремимся получить максимальную отдачу от всего, что мы делаем. По этой причине мы постоянно оцениваем то, что мы сделали, чтобы увидеть, соответствует ли оно нашим стандартам. Некоторое время назад мы решили более подробно изучить настройку нашей инфраструктуры.

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

Если не сломалось, не чини

Когда мы запускали Manifold, мы делали то, что, как мы знали, работало хорошо. Используйте Terraform для развертывания контейнеров на AWS EC2 и их предоставления через ELB . Мы оказались в положении, когда могли потратить дополнительное время на создание более зрелой платформы. Первоначальная реализация была очень простой, но мы начали замечать некоторые болевые точки:

• Развертывание было медленным (~ 15 минут)
• Отсутствие непрерывной доставки означало, что только специалисты по эксплуатации знали, как развертывать
• Запуск одного контейнера для каждого экземпляра может стать дорогостоящим. Увеличив плотность контейнера , мы могли бы снизить стоимость

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

Это приводит нас к еще одному принципу, по которому мы живем: собачьему кормлению . Используя Manifold для создания Manifold, мы бы точно знали, что нужно нашим пользователям.

Выбор кластера

Первый вопрос, который мы задали себе, был «где мы будем запускать этот кластер?». AWS еще не предлагает решение Kubernetes, но Azure и Google Cloud Platform предлагают . Нужно ли нам оставаться в AWS и управлять собственным кластером или мы хотим перенести все на другого облачного провайдера?

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

• Можем ли мы создать кластер высокой доступности на AWS и насколько легко им управлять?
• Как нам подключиться к нашему экземпляру RDS и какова будет задержка?
• Что мы делаем с нашим шифрованием KMS ?

Высокая доступность (HA) с kops

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

Чтобы понять, что означает высокая доступность для Kubernetes, нам нужно сначала понять, что это значит в целом.

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

– Документы Кубернета

В кластере Kubernetes этот уровень хранения называется etcd и работает на основных экземплярах. etcd — это распределенное хранилище ключей/значений, которое следует алгоритму консенсуса Raft для достижения кворума. Достижение кворума означает наличие набора серверов, согласных с набором значений. Чтобы достичь этого консенсуса, требуется согласие менее (n/2)+1 сторон. Поэтому нам всегда нужно нечетное количество экземпляров, по крайней мере, 3.

Ниже мы рассмотрим несколько возможных случаев сбоев.

Допустимый сбой экземпляра

Первый сценарий, который мы рассмотрим, заключается в том, чтобы посмотреть, что произойдет, когда один экземпляр завершится. Можем ли мы оправиться от этого?

Указав необходимое количество узлов, kops создает группу автоматического масштабирования для каждой группы экземпляров. Это гарантирует, что при завершении экземпляра будет создан новый. Это позволяет нам сохранять консенсус в нашем кластере, когда мы теряем экземпляр.

Допустимый сбой зоны

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

Давайте вернемся к нашей формуле консенсуса: более низкий (n/2) + 1 экземпляр как минимум с 3 экземплярами . Мы можем преобразовать это в зоны, что приведет к более низким (n/2)+1 зонам, по крайней мере, с 3 зонами .

С kops это тоже просто. Указав зоны, в которых мы хотим запускать как наши мастера, так и узлы, мы можем настроить высокую доступность на уровне зоны. Однако именно здесь мы столкнулись с нашим первым блокпостом. По произвольным причинам, когда мы запускали Manifold, мы решили использовать регион us-west-1 . Как оказалось, в этом регионе доступно только 2 зоны. Это означало, что нам нужно было найти другое решение, чтобы допустить сбой зоны.

Допустимый сбой региона (и не только)

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

Внутренняя сеть с пирингом

Из-за наших региональных ограничений нам пришлось найти другие способы справиться с отказом зоны. Один из вариантов — создать наш кластер в отдельном регионе.

В каждом регионе работает своя отдельная сеть. Это означает, что мы не можем просто использовать ресурсы одного региона в другом. Для этого мы рассмотрели межрегиональный пиринг VPC . Это позволит нам подключиться к нашему региону us-west-1 и получить доступ к RDS и KMS .

Это тоже отбросило нас назад. Как оказалось, регион us-west-1 — не лучший регион, который вы могли бы использовать. В то время, когда мы исследовали это, us-west-1 не поддерживал пиринг VPC между регионами. Это означает, что мы не могли использовать и это решение.

Решения и компромиссы

Со всеми этими новыми знаниями пришло время принять решение. Останемся ли мы с AWS или перейдем к другому поставщику?

Стоит отметить, что переход к другому провайдеру также сопряжен с большими накладными расходами. Нам пришлось бы раскрыть нашу базу данных, перенести наш KMS и повторно зашифровать все наши данные.

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

Управление собственным кластером может занять много времени. На сегодняшний день мы заметили минимальное влияние, но мы определенно учли обслуживание кластера . Больше всего времени займет обновление кластера .

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

обычный тип

Для нас Копс отлично сработал. Он поставляется с набором значений по умолчанию, о которых вы должны знать и перезаписывать. Одна из ключевых вещей, которые нужно сделать, это включить шифрование etcd . Это делается с помощью флага encrypt-etcd-storage .

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

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

Настройка кластера

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

Ранее управление нашими сервисами с помощью Terraform означало, что у нас был довольно большой контроль над настройкой. Мы управляли нашими ELB, DNS, ведением журналов и т. д. через нашу конфигурацию Terraform. Нам нужно было убедиться, что мы можем сделать это и с нашей настройкой Kubernetes.

Балансировки нагрузки

В Kubernetes есть понятие Services и Ingress . С помощью службы можно сгруппировать модули — обычно управляемые развертыванием — и предоставить их в одной и той же конечной точке. Эта конечная точка может быть внутренней или внешней. При настройке службы как LoadBalancer Kubernetes создаст ELB. Затем этот ELB связывается с настроенной службой.

Это здорово, но есть ограничения на количество ELB , которые вы можете иметь. Используя Ingress, мы можем создать один ELB и маршрутизировать трафик внутри нашего кластера. Доступно несколько Ingress, но мы выбрали Nginx Ingress по умолчанию .

Теперь, когда мы можем направлять трафик к сервису, пришло время предоставить его через домен. Для этого мы использовали проект External DNS . Это отличный способ сохранить настроенные доменные имена рядом с вашим приложением.

Последний шаг, на который нам нужно было обратить внимание при раскрытии наших сервисов, — убедиться, что мы обслуживаем трафик через SSL. Это оказалось просто, и для этого уже есть доступные решения. Мы остановились на cert-manager , который интегрируется с нашим Nginx Ingress.

Конфигурация службы

Конфигурация службы стала для нас легкой победой. Мы уже начали строить Manifold поверх Manifold с нашей Terraform Integration . Из-за этого все необходимые нам учетные данные уже были настроены.

Мы разработали нашу интеграцию Kubernetes с учетом нашей интеграции Terraform. Мы сохранили базовую семантику без изменений, что означало, что миграция учетных данных была легкой задачей.

Мы также добавили опцию для пользовательских типов секретов . Это позволило нам настроить секрет Docker Auth. При извлечении образов Docker из частного реестра вам понадобится этот секрет.

Телеметрия

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

Что касается ведения журналов, мы расширили возможности тестирования и настроили интеграцию с LogDNA для сбора журналов. Сами LogDNA предоставляют конфигурацию DaemonSet . Это позволяет вам отправлять журналы из вашего кластера на их платформу.

Для метрик мы полагались на Datadog , который до сих пор работал у нас хорошо. Как и в случае с LogDNA, Datadog также предоставляет конфигурацию DaemonSet . У них даже есть отличный пост в блоге о том, как это настроить!

Миграция

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

Первым этапом был запуск кластера на отдельном домене . Соединив две системы, мы смогли протестировать ее, никому не мешая. Это помогло нам найти и исправить некоторые проблемы на ранней стадии.

На следующем этапе мы направим часть трафика в кластер Kubernetes . Для этого мы настроили round robin . Это отличный способ увидеть, как ваш кластер ведет себя с реальным трафиком. Примерно через неделю у нас было достаточно уверенности, чтобы перейти к следующему этапу.

На третьем этапе были удалены устаревшие записи DNS . После удаления соответствующей конфигурации Terraform весь наш трафик будет проходить через Kubernetes!

Из-за кеша DNS мы решили оставить устаревшую версию в рабочем состоянии еще на несколько дней. Таким образом, люди с кэшированной записью DNS не столкнутся с ошибкой. Это также дало нам возможность откатиться, если мы увидели, что что-то пойдет не так.

Вывод

Теперь, когда мы мигрировали, мы можем оглянуться назад. Наша команда и компания назвали эту миграцию успешной. Мы сократили время развертывания с ~ 15 минут до ~ 1,5 минут и тем самым сократили эксплуатационные расходы .

Мы еще не закончили конвейер непрерывной доставки, но мы над этим работаем. Мы начали работу над Heighliner , который в первую очередь поможет нам, но, надеюсь, поможет и другим.

Мы столкнулись с одной серьезной неудачей: у нас не было трех доступных зон доступности. Это помешало нам использовать High-Available в разных зонах . Это компромисс, на который мы решили пойти, чтобы заставить нас работать, и мы постараемся исправить это в ближайшее время. 

Эта статья является переводом с сайта https://medium.com/