Служба OVH Managed Kubernetes предлагает вам полностью управляемый кластер, в котором вы выбираете выбранные рабочие узлы в каталоге постоянной производительности виртуальной машины OVH Public Cloud. В настоящее время мы изучаем лучший способ добавить поддержку для работников графических процессоров и «голого металла» (без виртуализации), чтобы вы могли смешивать и подбирать виртуальные машины для еще более специализированных и мощных конфигураций. Помогите нам сформировать новые функции нашего предложения Kubernetes, ответив на короткий опрос (рассказывающий о ваших потребностях в оборудовании и программном обеспечении, ваших конкретных случаях использования ...), и у вас будет возможность получить доступ к закрытой бета-версии в течение лета.
labs.ovh.com/gpu-baremetal-kubernetes-nodes

Одним из ключевых преимуществ использования Kubernetes является огромная экосистема вокруг него. От Rancher до Istio, от Rook до Fission, от gVisor до KubeDB, экосистема Kubernetes богата, динамична и постоянно растет. Мы подошли к тому, что для большинства потребностей в развертывании мы можем сказать, что для этого существует проект с открытым исходным кодом на основе K8s.

Одним из последних дополнений к этой экосистеме является проект Agones, многопользовательский, выделенный хостинг на игровом сервере с открытым исходным кодом, построенный на Kubernetes, разработанный Google в сотрудничестве с Ubisoft. Проект был анонсирован в марте, и уже наделал немало шума…

В OVH Platform Team мы являемся поклонниками онлайн-игр и Kubernetes, поэтому мы сказали себе, что нам нужно протестировать Agones. И какой лучший способ проверить это, чем развернуть его в нашей службе OVH Managed Kubernetes, установить кластер игровых серверов Xonotic и сыграть в старом классе с коллегами?



Почему агон?
Agones (происходит от греческого слова agōn, конкурсы, проводимые во время публичных фестивалей или, в более широком смысле, «соревнование» или «соревнование в играх»), стремится заменить обычные проприетарные решения для развертывания, масштабирования и управления игровыми серверами.
www.merriam-webster.com/dictionary/agones
kubernetes.io/docs/concepts/api-extension/custom-resources/#custom-controllers
kubernetes.io/docs/concepts/api-extension/custom-resources/#customresourcedefinitions

Agones обогащает Kubernetes пользовательским контроллером и пользовательским определением ресурса. С их помощью вы можете стандартизировать инструменты и API Kubernetes для создания, масштабирования и управления кластерами игровых серверов.

Подождите, о каких игровых серверах вы говорите?
Итак, основное внимание Agones уделяют многопользовательским онлайн-играм, таким как FPS и MOBA, быстрым играм, требующим выделенных игровых серверов с малой задержкой, которые синхронизируют состояние игры между игроками и служат источником правды в игровых ситуациях.

Игры такого типа требуют относительно эфемерных выделенных игровых серверов, причем каждое совпадение выполняется на экземпляре сервера. Серверы должны быть с состоянием (они должны сохранять статус игры), причем состояние обычно хранится в памяти на время матча.

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

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



Agones и его пользовательский контроллер и пользовательское определение ресурса заменяет сложную инфраструктуру управления кластером стандартизированными инструментами и API на основе Kubernetes. Службы сватов взаимодействуют с этими API-интерфейсами для создания новых модулей игровых серверов и передачи их IP-адресов и портов заинтересованным игрокам.



Вишня на торте
Использование Kubernetes для этих задач также дает приятный дополнительный бонус, например, возможность развертывать полную игровую инфраструктуру в среде разработчика (или даже в мини-кубе) или легко клонировать ее для развертывания в новом центре обработки данных или облачной области, но также предлагая целую платформу для размещения всех дополнительных услуг, необходимых для создания игры: управление учетными записями, списки лидеров, инвентарь
github.com/kubernetes/minikube

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

Развертывание Agones на управляемых OVH Kubernetes
Есть несколько способов установить Agones в кластер Kubernetes. Для нашего теста мы выбрали самый простой: установка с помощью Helm.
helm.sh/

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

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole=cluster-admin --serviceaccount=kube-system:default

Теперь у нас есть Cluster Role Binding, необходимая для установки.
kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding

Установка диаграммы Agones
Теперь давайте продолжим, добавив хранилище Agones в список хранилищ Helm.

helm repo add agones https://agones.dev/chart/stable

И затем установка стабильной диаграммы Agones:

helm install --name my-agones --namespace agones-system agones/agones

agones.dev/site/docs/installation/helm/

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

Подтверждение Agones началось успешно
Чтобы убедиться, что Agones работает в нашем кластере Kubernetes, мы можем взглянуть на модули в пространстве имен agones-system:

kubectl get --namespace agones-system pods

Если все в порядке, вы должны увидеть модуль контроллера agones со статусом Running:

$ kubectl get --namespace agones-system pods
NAME                                 READY   STATUS    RESTARTS   AGE
agones-controller-5f766fc567-xf4vv   1/1     Running   0          5d15h
agones-ping-889c5954d-6kfj4          1/1     Running   0          5d15h
agones-ping-889c5954d-mtp4g          1/1     Running   0          5d15h

Вы также можете увидеть более подробную информацию, используя:

kubectl describe --namespace agones-system pods

Глядя на описание agones-контроллера, вы должны увидеть что-то вроде:

$ kubectl describe --namespace agones-system pods
Name:               agones-controller-5f766fc567-xf4vv
Namespace:          agones-system
[...]
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True

Где все Условия должны иметь статус True.

Развертывание игрового сервера
Мир Agones Hello довольно скучный, простой эхо-сервер UDP, поэтому мы решили пропустить его и перейти непосредственно к чему-то более интересному: игровому серверу Xonotic.
github.com/GoogleCloudPlatform/agones/tree/release-0.9.0/examples/simple-udp
github.com/GoogleCloudPlatform/agones/blob/release-0.9.0/examples/xonotic
www.xonotic.org/

Xonotic — это многопользовательский FPS с открытым исходным кодом, довольно неплохой, с множеством интересных игровых режимов, карт, оружия и опций настройки.

Развернуть игровой сервер Xonotic поверх Agones довольно просто:

kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/agones/release-0.9.0/examples/xonotic/gameserver.yaml

Развертывание игрового сервера может занять несколько минут, поэтому нам нужно подождать, пока его состояние не станет «Готов», прежде чем использовать его. Мы можем получить статус с:

kubectl get gameserver

Мы ждем, пока извлечение не даст статус Ready на нашем игровом сервере:

$ kubectl get gameserver
NAME      STATE   ADDRESS         PORT   NODE       AGE
xonotic   Ready   51.83.xxx.yyy   7094   node-zzz   5d

Когда игровой сервер готов, мы также получаем адрес и порт, который мы должны использовать для подключения к нашей игре Deathmatch (в моем примере, 51.83.xxx.yyy: 7094).

Время фрагмента
Теперь, когда у нас есть сервер, давайте проверим его!

Мы загрузили клиент Xonotic для наших компьютеров (он работает на Windows, Linux и MacOS, так что оправданий нет) и запустили его:


Затем мы идем в многопользовательское меню и вводим адрес и порт нашего игрового сервера:


И мы готовы играть!


А на стороне сервера?
Со стороны сервера мы можем следить за тем, как идут дела на нашем игровом сервере, используя логи kubectl. Давайте начнем с поиска модуля, на котором запущена игра:

kubectl get pods

Мы видим, что наш игровой сервер работает в модуле под названием xonotic:

$ kubectl get pods 
NAME      READY   STATUS    RESTARTS   AGE
xonotic   2/2     Running   0          5d15h

Затем мы можем использовать логи kubectl. В модуле есть два контейнера, основной ксонотический и колонтитул Agones, поэтому мы должны указать, что нам нужны журналы ксонотического контейнера:

$ kubectl logs xonotic
Error from server (BadRequest): a container name must be specified for pod xonotic, choose one of: [xonotic agones-gameserver-sidecar]
$ kubectl logs xonotic xonotic
>>> Connecting to Agones with the SDK
>>> Starting health checking
>>> Starting wrapper for Xonotic!
>>> Path to Xonotic server script: /home/xonotic/Xonotic/server_linux.sh 
Game is Xonotic using base gamedir data
gamename for server filtering: Xonotic
Xonotic Linux 22:03:50 Mar 31 2017 - release
Current nice level is below the soft limit - cannot use niceness
Skeletal animation uses SSE code path
execing quake.rc
[...]
Authenticated connection to 109.190.xxx.yyy:42475 has been established: client is v6xt9/GlzxBH+xViJCiSf4E/SCn3Kx47aY3EJ+HOmZo=@Xon//Ks, I am /EpGZ8F@~Xon//Ks
LostInBrittany is connecting...
url_fclose: failure in crypto_uri_postbuf
Receiving player stats failed: -1
LostInBrittany connected
LostInBrittany connected
LostInBrittany is now spectating
[BOT]Eureka connected
[BOT]Hellfire connected
[BOT]Lion connected
[BOT]Scorcher connected
unconnected changed name to [BOT]Eureka
unconnected changed name to [BOT]Hellfire
unconnected changed name to [BOT]Lion
unconnected changed name to [BOT]Scorcher
[BOT]Scorcher picked up Strength
[BOT]Scorcher drew first blood! 
[BOT]Hellfire was gunned down by [BOT]Scorcher's Shotgun
[BOT]Scorcher slapped [BOT]Lion around a bit with a large Shotgun
[BOT]Scorcher was gunned down by [BOT]Eureka's Shotgun, ending their 2 frag spree
[BOT]Scorcher slapped [BOT]Lion around a bit with a large Shotgun
[BOT]Scorcher was shot to death by [BOT]Eureka's Blaster
[BOT]Hellfire slapped [BOT]Eureka around a bit with a large Shotgun, ending their 2 frag spree
[BOT]Eureka slapped [BOT]Scorcher around a bit with a large Shotgun
[BOT]Eureka was gunned down by [BOT]Hellfire's Shotgun
[BOT]Hellfire was shot to death by [BOT]Lion's Blaster, ending their 2 frag spree
[BOT]Scorcher was cooked by [BOT]Lion
[BOT]Eureka turned into hot slag
[...]

Добавьте друзей
Следующий шаг в основном приятен: попросить коллег подключиться к серверу и провести настоящий Deathmatch, как в Quake 2 раза.

И сейчас?
У нас есть работающий игровой сервер, но мы едва раскрыли возможности Agones: развертывание флота (набор теплых GameServer, доступных для распределения), тестирование FleetAutoscaler (для автоматического увеличения и уменьшения флота в ответ на спрос), делая некоторые фиктивные услуги распределителя. В будущих публикациях в блоге мы углубимся в это и рассмотрим эти возможности.
agones.dev/site/docs/tutorials/allocator-service-go/
agones.dev/site/docs/reference/fleet/
agones.dev/site/docs/reference/fleetautoscaler/

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

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

Всё же наши сердца греет приятное воспоминание — митап для всех влюблённых в Kubernetes (и не только), который мы провели 14 февраля.

Вся мякотка — в посте на хабре habr.com/ru/company/mailru/blog/442086/

Что нового
Быстрый SSD. Мы предлагаем новый тип SSD: high-IOPS. Некоторые типы приложений требуют высоких показателей IOPS, и обычный диск на основе CEPH, который мы предлагаем, для них не оптимален. Для таких приложений подойдёт наш новый SSD.

Мощный CPU. Для требовательных проектов подключайте виртуальные машины не простые, а сверх-производительные:

• Intel Xeon E5-2667 v4. 3.2 GHz,
• TurboBoost до 3.6 GHz.

Запросить мощный CPU — sales@mcs.mail.ru

Загрузка SSH-ключа. Для подключения к инстансу на уровне ОС раньше приходилось размещать SSH-ключ у себя на устройстве. Теперь вы можете загрузить в облако собственный SSH-ключ.
Как загрузить свой SSH-ключ mcs.mail.ru/help/instance/server


Бэкапы.
Вернее — и бэкапы, и снепшоты. Мы их ускорили в 3 раза.

Базы данных.
Теперь можно ресайзить диски в кластере PostgreSQL.

Подкаст «Завтра облачно»
Мы выпустили две новых серии подкаста «Завтра облачно»:

• Фриланс в IT. Зачем сидеть в офисе, если можно работать удалённо
• IT в быстро растущей компании. Здравый смысл vs хайп

soundcloud.com/mcspodcast/1-frilans-v-it
soundcloud.com/mcspodcast/2-hype-vs-reason

docs.ovh.com/gb/en/kubernetes/using-codefresh/

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/

Сегодня мы расскажем о наших первых новостях в 2019 году.
В конце прошлого года появилась возможность быстрого создания кластера Kubernetes.

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


Возможности kubernetes в облаке:

• автоматическое масштабирование
• легкая миграция приложений
• мощные серверы в россии и соответствие законодательству
• множество готовых прикладных сервисов
• никаких сложностей с настройкой
• все готово для работы в облаке
• посекундная оплата только за потребляемые мощности

Наши эксперты окажут поддержку в построении инфраструктуры для бизнеса с нуля или расширении существующей инфраструктуры за счет облака или полной миграции в облако, миграции между облачными провайдерами. Техническая поддержка работает 24/7.
www.xelent.ru/lp/containers-kubernetes/

Прошлый год закончился успешным партнерством с Hystax.
Итогом этого партнерства стала возможность мигрировать ИТ-инфраструктуру в любые облака без простоев и потери данных в несколько кликов!


Синхронизация данных в режиме реального времени
Реплицируйте данные между двумя площадками без простоев или влияния на производительность бизнес-приложений. Использование Сети оптимизируется с помощью встроенных технологий дедупликации и wan-оптимизации.

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

Переключиться на перенесенный сайт в несколько кликов
Окончательная синхронизация всех дельт между двумя площадками происходит в считанные секунды. Перенесите мигрируемое Приложение с помощью гибких планов миграции и переключитесь на новую площадку.
www.xelent.ru/lp/migration-hystax/

Переезд из амазона с экономией до 40%!
Если вы сейчас в облаке амазон:

• мы подберем для вас решение, за которое можно платить безналом,
• соблюдать фз 152,
• экономить до 40%.

Спланируем и осуществим переезд без простоя инфраструктуры.

Управление 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, и почему мы его создали и открыли

labs.ovh.com/kubernetes-k8s/





labs.ovh.com/swarm64


labs.ovh.com/ha-database

Какая яркая осень! Хабиб победил Конора, Кокорин и Мамаев с размахом отпраздновали юбилей дружбы, а картины начали самоуничтожаться. На фоне этих событий наша активность могла бы померкнуть, но в сентябре мы выкатили новый сервис, которого ждали многие разработчики, и добавили несколько фич в старые.


Мы запустили сервис управляемых и масштабируемых баз данных в облаке с поддержкой PostgreSQL, MySQL, MongoDB. Вы можете создавать как простые, так и сложные master-slave конфигурации, настраивать бэкапы, управлять пользователями и так далее.

mcs.mail.ru/databases


Поддержка Kubernetes 1.11 в сервисе Cloud Containers.

• Поддержка Calico v3 в качестве сетевого драйвера в Kubernetes.
• Полноценный интегрированный мониторинг на базе Prometheus и Grafana.

mcs.mail.ru/app/services/containers/


Управление firewall
Теперь можно управлять firewall за счёт настроек групп безопасности.

mcs.mail.ru/app/services/infra/firewall/

Если у вас есть вопросы по работе с сервисами или возникли сложности, напишите мне в ответном письме, в чат Telegram или Facebook.
Спасибо за выбор Mail.Ru Cloud Solutions!