Дата-центры OVH

and some others



// от редакции

• начало

Kubernetes великолепен, но довольно сложен. Теперь OVH, поставщик услуг облачных вычислений и центров обработки данных, внедряет управляемую услугу Kubernetes. Это должно позволить клиентам легко использовать оркестровку с открытым исходным кодом в инфраструктуре OVH.

По сути, предложение, по словам Алена Фиокко, технического директора OVH, является постоянным кластерным контроллером. Клиенты, которые вносят свои правила использования компьютеров и ресурсов хранения, могут устанавливать их постоянно, даже если они не используют Kubernetes постоянно в OVH. Политика сохраняется.

Номера не нужны клиентам, этот контроллер. «Правда в том, заявляет Fiocco, что нам требуются сравнительно небольшие ресурсы от нас». Однако, как только клиенты используют ресурсы OVH для своего кластера Kubernetes, они платят за фактическое «потребление» или необходимые ресурсы. «В свою очередь, клиенты имеют доступ ко всему общедоступному облаку OVH», согласно CTO, а также к различным виртуальным машинам, например, в OpenStack или VMware.

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

Предложение для разных потребителей Кубернеца
Kubernetes обещает общий стандарт для поставщиков гибридных и мультиоблачных услуг. Являясь одним из немногих сертифицированных поставщиков Cloud Native Computing Foundation (CNCF) в Европе, OVH решила выпустить альтернативу существующим вариантам Kubernetes. Предложение, которое теперь доступно, начинает OVH, чтобы расширить свой облачный портфель 18 октября 2018 года с частной бета-программой. Теперь управляемый сервис Kubernetes состоит из следующих компонентов:

• Балансировщик нагрузки, изначально встроенный в Kubernetes
• Настраиваемые политики для обновлений безопасности
• Выбор между двумя последними версиями Kubernetes, доступными на рынке, в настоящее время 1.11 и 1.12

Преимущества для клиентов следующие:

• Используйте стандартный открытый API, который выигрывает от большого сообщества и широкой экосистемы, включая 627 компаний и проектов, перечисленных на сайте CNCF landscape.cncf.io/. API также предоставляет все преимущества OVH, включая поддержку 24x7, бесплатную защиту от DDoS и доступ к ведущей европейской оптоволоконной сети со скоростью 16 Тбит / с, ведущему европейскому облачному провайдеру.
• В комплекте с Kubernetes-совместимой управляемой службой: хотя службы других поставщиков не работают из-за настройки с некоторыми инструментами, служба OVH Managed Kubernetes полностью совместима с Kubernetes. Например, клиенты могут использовать оригинальное устройство контроля доступа Kubernetes (RBAC).
• Модель биллинга с оплатой по факту использования в публичном облаке OVH обеспечивает прозрачное ценообразование. OVH бесплатно предоставляет программное обеспечение для оркестровки Kubernetes, а также необходимую инфраструктуру. Поэтому клиенты платят только за постоянную систему хранения и вычислительную инфраструктуру, в которой работают их контейнеры, по стандартной цене общедоступного облака OVH и необходимого объема.

Это то, что говорят клиенты
Например, клиенты получают кластер с гарантированной постоянной производительностью ЦП и ОЗУ, начиная с 26,18 евро (включая НДС) в месяц, а инфраструктура, состоящая из пяти рабочих узлов с общим объемом оперативной памяти 35 гигабайт и 10 vCores для 130,90. Евро (с учетом НДС) доступно в месяц. Для клиентов, которые хотят использовать Kubernetes и их контейнеры в облаке OVH, дополнительные расходы не требуются, поскольку входящая и исходящая пропускная способность уже включена.

Три из клиентов, которые уже знают предложение OVH, описывают свое преимущество:

В Saagie мы предлагаем оркестратор Data Labs, который изощренно использует Kubernetes. Мы протестировали несколько управляемых сервисов Kubernetes от других поставщиков. Основанный на стандартах сервис OVH Managed Kubernetes обеспечивает нам отличную мобильность

сказал Юн Чене, технический директор комплексного оператора платформы данных Saagie.

Мы уже пытались построить наш кластер Kubernetes самостоятельно, но мы не смогли сделать это, потому что установка и обслуживание были слишком сложными для нас. Благодаря сервису OVH Managed Kubernetes мы смогли перенести наши приложения в Kubernetes, не беспокоясь об установке и обслуживании платформы. Бета-фаза проекта Kube прошла гладко благодаря присутствию и отзывчивости команды OVH

сказал Винсент Дэви, ответственный за DevOps в ITK, специалисте по решениям для интеллектуального фермерства.

Служба OVH Managed Kubernetes дает нам все необходимое для бесперебойной работы наших служб, и при рассмотрении счета нет никаких неприятных сюрпризов

говорит Жером Балдуччи, технический директор Whoz, поставщик инструментов для искусственного интеллекта в этой области. HR.

Дальнейшее развитие управляемого сервиса Kubernetes
Управляемая служба Kubernetes уже доступна для всех клиентов через центр обработки данных OVH в Гравелине (Франция) и будет постепенно внедряться в различных регионах OVH Public Cloud в течение следующих нескольких месяцев. Кроме того, он скоро будет совместим с технологией «vRack». Это позволяет клиентам OVH

• Создание гибридной частной инфраструктуры на глобальном уровне в нескольких центрах обработки данных с 28 собственными центрами обработки данных OVH на четырех континентах.
• доступ к кластерам Kubernetes как в частной, так и в стандартной общедоступной сети,
• Благодаря расширению «Облачное соединение OVH» объединяются все имеющиеся у них ресурсы как в облаке OVH, так и на локальном уровне.

www.ovh.com/fr/kubernetes/

On the way to the 1000 stars today with cds, ovh is 7th on the Top 10 Developers on GitHub

www.ovh.ie/ovh-deals/

www.ovh.com/fr/public-cloud/instances/tarifs/

Уважаемый клиент, к сожалению, из-за большого количества запросов, проходящих через наш DNS (213.186.33.99), OVH пришлось приостановить разрешение DNS для следующего DNSBL:
zen.spamhaus.org
pbl.spamhaus.org
sbl.spamhaus.org
xbl.spamhaus.org
multi.surbl.org

Следовательно, запрос к одному из этих DNSBL будет последовательно представлять собой ответ NXDOMAIN по состоянию на 25 февраля 2019 года.
В соответствии с рекомендациями последнего, вам следует использовать собственный распознаватель DNS для использования этих служб, а не общедоступного поставщика DNS:
https://www.spamhaus.org/faq/section/DNSBL%20Usage#261
Спасибо за Ваше понимание.

• added a new 4x10G PNI with ukdsltd at London
• upgraded our PNI with transtelco from 4x10G to 1x100G at Dallas and LosAngeles
• added 100G with TeliaCarrier at Ashburn
• added 100G with vodafone_de at Frankfurt

Управление Kubernetes над Kubernetes было хорошей идеей для компонентов без контроля состояния плоскости управления… но как насчет etcd?


В нашем предыдущем посте мы описали архитектуру Kubinception, как мы запускаем Kubernetes над Kubernetes для компонентов без состояний в плоскостях управления кластерами клиентов. Но как насчет компонента с состоянием, etcd?

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

Самая простая идея не всегда хорошая
Первый подход заключается в простом следовании логике Kubinception: для каждого клиентского кластера развертывание кластера etcd в качестве модулей, работающих на административном кластере.


Этот полный подход Kubinception имеет преимущество быть простым, он кажется продолжением того, что мы делаем с компонентами без сохранения состояния. Но если взглянуть на него подробно, он показывает свои недостатки. Развертывание кластера etcd не так просто и просто, как развертывание без сохранения состояния и является критически важным для работы кластера, мы не могли просто обработать его вручную, нам был необходим автоматизированный подход для управления им на более высоком уровне. www.diycode.cc/projects/coreos/etcd-operator

Использование оператора
Мы были не единственными, кто думал, что сложность работы с развертыванием и работой кластера etcd на Kubernetes была чрезмерной, люди из CoreOS заметили это, и в 2016 году они выпустили элегантное решение проблемы: etcd оператор coreos.com/blog/introducing-the-etcd-operator.html

Оператор — это специальный контроллер, который расширяет API Kubernetes для простого создания, настройки и управления экземплярами сложных (часто распределенных) приложений с отслеживанием состояния в Kubernetes. Для записи, понятие оператора было введено CoreOS с оператором etcd.


Оператор etcd управляет кластерами etcd, развернутыми в Kubernetes, и автоматизирует рабочие задачи: создание, уничтожение, изменение размера, аварийное переключение, непрерывное обновление, резервное копирование
kubernetes.io

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

Оператор etcd может быть настроен на использование постоянных томов (PV) для хранения данных, поэтому теоретически проблема была решена. Теоретически, поскольку управление томами не было достаточно зрелым, когда мы тестировали его, и если модуль etcd был убит и переназначен, новый модуль не смог получить свои данные на PV. Таким образом, риск полной потери кворума и блокирования клиентского кластера все еще был у оператора etcd.
kubernetes.io/docs/concepts/storage/persistent-volumes/

Короче говоря, мы немного поработали с оператором etcd и обнаружили, что он недостаточно зрел для нашего использования.

StatefulSet
Помимо оператора, другим решением было использование StatefulSet, своего рода распределенного развертывания, хорошо подходящего для управления распределенными приложениями с отслеживанием состояния.
kubernetes.io/docs/concepts/workloads/controllers/statefulset/
kubernetes.io/docs/concepts/workloads/controllers/deployment/
github.com/helm/charts/tree/master/incubator/etcd

Существует официальная диаграмма ETCD Helm, которая позволяет развертывать кластеры ETCD в виде StafefulSets, которая обменивает некоторую гибкость оператора и удобство для пользователя на более надежное управление PV, которое гарантирует, что перепланированный модуль etcd будет получать свои данные.


Etcd StatefulSet менее удобен, чем оператор etcd, поскольку он не предлагает простого API для операций, таких как масштабирование, отработка отказа, последовательное обновление или резервное копирование. Взамен вы получаете некоторые реальные улучшения в управлении PV. StatefulSet поддерживает липкую идентификацию для каждой записи etcd, и этот постоянный идентификатор сохраняется при любом перепланировании, что позволяет просто связать его с PV.

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

Постоянные объемы, задержка и простой расчет затрат
Etcd StatefulSet казался хорошим решением… пока мы не начали интенсивно его использовать. В etcd StatefulSet используются PV, то есть тома сетевого хранилища. И т.д.DD довольно чувствительны к задержке в сети, ее производительность сильно ухудшается, когда сталкивается с задержкой.

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

В сервисе OVH Managed Kubernetes мы выставляем счета нашим клиентам в соответствии с количеством рабочих узлов, которые они используют, то есть плоскость управления свободна. Это означает, что для обеспечения конкурентоспособности сервиса важно держать под контролем ресурсы, потребляемые плоскостями управления, поэтому нет необходимости удваивать количество пакетов с помощью etcd.

С Kubinception мы пытались мыслить нестандартно, казалось, что для etcd нам нужно было выбраться из этой коробки еще раз.

Мультитенантный кластер etcd
Если мы не хотели развертывать etcd внутри Kubernetes, альтернативой было бы развернуть его снаружи. Мы решили развернуть мультитенантный кластер etcd на выделенных серверах. Все клиентские кластеры будут использовать один и тот же ETCD, каждый сервер API получает свое место в этом мультитенантном кластере etcd.



Благодаря такому решению устойчивость обеспечивается обычными механизмами etcd, проблемы с задержкой не возникает, поскольку данные находятся на локальном диске каждого узла etcd, а количество модулей остается под контролем, поэтому оно решает основные проблемы, которые у нас возникли с другими решение. Компромисс здесь заключается в том, что нам нужно установить и использовать этот внешний кластер etcd, а также управлять контролем доступа, чтобы каждый сервер API имел доступ только к своим собственным данным.

Что дальше?
В следующих статьях из серии Kubernetes мы углубимся в другие аспекты построения OVH Managed Kubernetes и дадим клавиатуру некоторым из наших бета-клиентов, чтобы рассказать о своем опыте использования сервиса.

На следующей неделе давайте сосредоточимся на другой теме, мы разберемся с языком запросов TSL, и почему мы его создали и открыли